View a markdown version of this page

Demande Vaste - AWS Elemental MediaTailor
Quand l’utiliserChamps de configurationComment la demande est traitéeChamps de réponseComment les publicités analysées s'intègrent aux sorties HookComportement de défaillanceExemple : récupérer des publicités depuis un serveur publicitaire secondaire

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Demande Vaste

Quand l’utiliser

À utiliser VAST_REQUEST lorsque votre fonction doit récupérer des publicités depuis un terminal VAST (Video Ad Serving Template). MediaTailor envoie la demande, analyse la réponse en tant que VAST avec les redirections de wrapper résolues et met les publicités analysées à la disposition de vos expressions de sortie. Les cas d'utilisation courants incluent la récupération de publicités depuis un serveur publicitaire secondaire pour compléter une courte réponse principale, et la récupération d'annonces ou de promotions internes à injecter dans des pauses publicitaires insuffisamment remplies.

VAST_REQUESTles fonctions sont prises en charge au niveau des hooks POST_ADS_RESPONSE et PRE_MANIFEST_INSERTION du cycle de vie, seules ou en tant qu'étapes dans un exécuteur. Les publicités analysées par une VAST_REQUEST fonction s'intègrent aux sorties de ces crochets en toute fidélité. Pour en savoir plus, consultez Comment les publicités analysées s'intègrent aux sorties Hook.

Champs de configuration

Une VAST_REQUEST fonction comporte les champs suivants :

  • Runtime  : langage d'expression. Réglez ce paramètre surJSONATA.

  • MethodType— La méthode HTTP. Les valeurs prises en charge sont GET (par défaut) etPOST.

  • Url  : point de terminaison VAST auquel envoyer la demande. Vous pouvez utiliser une URL statique ou une expression JSonata qui génère l'URL de manière dynamique. Une URL statique doit utiliser ce https schéma.

  • En-têtes : en-têtes HTTP à inclure dans la demande, spécifiés sous forme de paires nom d'en-tête et valeur. Utilisez la syntaxe des {%...%} expressions pour les valeurs d'en-tête dynamiques.

  • Corps  : corps de la demande à envoyer. Utilisé avec les POST demandes, par exemple pour envoyer une demande d'offre OpenRTB. Vous pouvez utiliser une expression JSonata pour construire le corps de manière dynamique.

  • RequestTimeoutMilliseconds(obligatoire) — Combien de temps faut-il attendre pour obtenir une réponse ?

  • Sortie  : définit les valeurs à produire une fois l'appel terminé. Chaque entrée associe une clé de sortie à une expression qui peut faire référence à l'responseobjet, notammentresponse.parsedAds.

Les limites de requêtes HTTP qui s'appliquent aux HTTP_REQUEST fonctions s'appliquent également ici. Pour en savoir plus, consultez Restrictions.

Comment la demande est traitée

  1. Génère la demande  : MediaTailor évalue les Body expressions UrlHeaders, et par rapport à l'état actuel de la session, puis envoie la demande. POSTles demandes sont envoyées avec le type de application/json contenu.

  2. Analyser la réponse  : MediaTailor analyse le corps de la réponse comme étant VAST. Si une annonce est un wrapper VAST, elle MediaTailor suit la chaîne de redirection et la transforme en annonce en ligne finale. Les demandes de redirection Wrapper sont toujours envoyées avecGET, comme l'exige la spécification VAST. Si votre terminal renvoie un document contenant une URL VAST au lieu du VAST lui-même (comme le font certains enchérisseurs), enchaînez une HTTP_REQUEST étape qui récupère l'URL, suivie d'une VAST_REQUEST étape qui la récupère.

  3. Traite les publicités analysées  : MediaTailor évalue les expressions du bloc de sortie. Ces expressions peuvent faire référence à l'état de session d'origine et à l'responseobjet.

Champs de réponse

Une fois l'appel terminé, vous pouvez référencer les champs suivants dans vos expressions de sortie :

Champ Type Description
response.parsedAds Tableau Les publicités analysées, avec les redirections d'emballage, ont été résolues. Chaque annonce a la même forme que les adsResponse.ads entrées du POST_ADS_RESPONSE crochet : adId durationSecondsadSystem,adTitle,creativeId, sequencemediaFiles, ettrackingEvents. Défini sur un tableau vide lorsque l'appel échoue ou que la réponse n'est pas valide VAST.
response.statusCode Entier Code d'état HTTP renvoyé par le point de terminaison. Réglez null sur en cas de défaillance du réseau.

Comme les publicités analysées utilisent la même forme queadsResponse.ads, vous pouvez déplacer des expressions entre les deux surfaces sans avoir à réécrire les références de champs.

Comment les publicités analysées s'intègrent aux sorties Hook

Chaque annonce analysée par une VAST_REQUEST fonction est conservée en interne MediaTailor, à l'aide de l'ID d'annonce VAST de l'annonce, pendant la durée de l'invocation du hook. Cela donne aux annonces analysées un traitement de première classe dans les sorties hook :

  • ÀPOST_ADS_RESPONSE, l'ajout d'une annonce analysée à adsResponse.ads by its adId restaure les données VAST analysées complètes de l'annonce, y compris la liste complète des fichiers multimédia et les événements de suivi.

  • ÀPRE_MANIFEST_INSERTION, injecter une annonce uniquement avec son contenu vastAdId permet de MediaTailor sélectionner le meilleur fichier multimédia et de gérer automatiquement l'enregistrement du transcodage.

Important

Les publicités conservées ne sont pas reportées entre les invocations de hook. Un VAST_REQUEST appel passé à l'adresse n'POST_ADS_RESPONSEest pas disponible pour une PRE_MANIFEST_INSERTION invocation ultérieure. Appelez VAST_REQUEST la chaîne de fonctions du hook dans laquelle vous utilisez ses résultats.

Comportement de défaillance

Si l'appel échoue en raison d'une erreur réseau ou d'un délai d'attente, si le point de terminaison renvoie une erreur HTTP ou si la réponse ne peut pas être analysée comme VAST, un tableau response.parsedAds est vide et la chaîne de fonctions se poursuit. Assurez-vous response.statusCode de distinguer une panne HTTP d'une réponse VAST qui ne contient réellement aucune publicité.

Astuce

Reste RequestTimeoutMilliseconds serrée. La résolution du wrapper VAST peut impliquer plusieurs allers-retours sur le réseau, et tous sont pris en compte dans le délai d'expiration du hook et le budget de hook partagé.

Exemple : récupérer des publicités depuis un serveur publicitaire secondaire

La fonction suivante récupère les publicités à partir d'un serveur publicitaire de sauvegarde et stocke les publicités analysées dans des données temporaires. Une CUSTOM_OUTPUT étape plus loin dans la même séquence peut les ajouter àadsResponse.ads. Il est conçu pour répondre aux exigences du POST_ADS_RESPONSE cycle de vie.

{
    "FunctionId": "fetchBackupAds",
    "FunctionType": "VAST_REQUEST",
    "VastRequestConfiguration": {
        "Runtime": "JSONATA",
        "MethodType": "GET",
        "Url": "{%'https://backup-ads.example.com/vast?sid=' & session.uuid%}",
        "Headers": {
            "Accept": "application/xml"
        },
        "RequestTimeoutMilliseconds": 1000,
        "Output": {
            "temp.backupAds": "{%response.parsedAds%}"
        }
    }
}

Pour envoyer une demande d'offre OpenRTB MethodType à la place, définissez POST et saisissez la demande d'offre dans. Body Le soumissionnaire doit renvoyer VAST dans le corps de la réponse.

Pour une présentation complète d'un exemple similaire, consultezExemples de fonctions.