TAP et TAP Programmatic renvoient un fichier VAST Inline Remarque : TAP renvoyait auparavant un fichier VAST Wrapper, mais cela a été interrompu à partir du 2022-07-14.
Le contenu réel de chaque fichier VAST retourné dépend du gestionnaire de contenu créatif utilisé. Vous devez donc ignorer les champs non mentionnés ici que votre analyseur syntaxique ne reconnaît pas ou ne peut pas traiter.
Pour plus d’informations sur la réponse publicitaire avec séparation des secteurs, voir Séparation des secteurs.
Codes de réponse HTTP
Code | Message | Description |
|---|---|---|
200 | OK | Succès. La réponse peut contenir une publicité ou non. |
400 | Bad Request | Un des paramètres est absent ou contient une valeur non valide (par ex. : l'identifiant de placement n'existe pas). |
404 | Not Found | La terminaison appelée est incorrecte. |
D’autres erreurs HTTP standard, telles que 500 Internal Server Error ou 405 Method Not Allowed, peuvent également être renvoyées. Les applications doivent gérer les codes de réponse HTTP conformément aux conventions standard, telles que décrites dans le protocole w3.org RFC9110.
200 - Réponse publicitaire
La publicité retournée par le service de publicités à la demande est conforme à VAST. L'application du client doit donc prendre en charge la dernière spécification VAST d'IAB en date.
Le sous-ensemble VAST qui doit être pris en charge par les applications clientes est le suivant :
Publicités audio en ligne
Types de contenu audio: MP3, AAC
Titre de publicité
URL d'impression (voir Rapport d'impression)
Fichiers média utilisant une livraison progressive (plusieurs fichiers peuvent être retournés)
URL de suivi pour les quartiles (voir Quartiles)
Bannières d'accompagnement
IFrameResource, HTMLResource et StaticResource
Types de contenu de bannière : JPG, PNG, GIF
URL de suivi de clic sur les bannières d'accompagnement (à la fois des URL de destination et URL de suivi)
Suivre des évènements : creativeView
Bannière Alt Text
Élément <Error>
La réponse VAST (lorsqu’il ne s’agit pas d’une opportunité manquée) inclut un élément <Error> avec un URI à appeler si la publicité renvoyée n’est pas diffusée.
Le <Error> permet au lecteur multimédia de fournir des commentaires aux serveurs publicitaires lorsqu’une publicité ne peut pas être diffusée. La spécification VAST (section 2.3.6: Rapports d'erreurs) décrit la fonctionnalité de rapport d'erreurs plus en détail. Le tableau des codes d’erreur VAST pour remplacer la [ERRORCODE] macro sont décrites à la section 2.3.6.3.
Triton Digital vous recommande vivement de mettre en place une logique dans votre lecteur pour appeler l’élément <Error> quand la publicité n’est pas diffusée, en effet :
Fournir des codes d'erreur plus détaillés permet d'obtenir de meilleurs diagnostics et facilite l'amélioration de la technologie postérieurement.
Le plafonnement est déclenché par la demande, et non par l’impression. Ainsi, si vous utilisez le plafonnement et que vous n’appelez pas l’URI d’erreur quand une publicité n’est pas diffusée, le serveur publicitaire considère que la publicité a été diffusée et applique donc le plafonnement là où il n’est pas nécessaire.
Reportez-vous à la section Options de codage d’URL pour l’élément d’erreur ci-dessous.
200 - Pas de réponse publicitaire (opportunité manquée)
Si le service de publicité à la demande ne dispose d’aucune publicité disponible correspondant aux paramètres de la demande, il renverra tout de même un code de réponse 200 OK et un fichier VAST, mais sans <Ad> . Au lieu de cela, un paramètre facultatif <Error> peut être inclus dans le fichier, comme :
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<VAST version=" 4.3">
<Error>
<![CDATA[https://adserver.com/?dur=%5BTD_DURATION%5D]]>
</Error>
</VAST>Le <Error> élément facultatif, mais s’il est inclus, le lecteur doit envoyer une requête à l’URI fourni quand et si une impression a été générée (par exemple, si du contenu de remplissage a été lu). Cela permet à Triton Digital d'enregistrer la durée de remplissage de l'opportunité manquée afin de générer des prévisions précises.
Si une
[TD_DURATION]macro est incluse dans l’URI, elle doit être remplacée par la durée réelle, en secondes, du contenu rempli. Si la macro n'est pas remplacée, une durée de 30 secondes sera supposée par défaut. Pour toute demande de publicité, cet URI peut être appelé à plusieurs reprises (la durée totale finale enregistrée correspond à la somme de chaque durée).Si une
[ERRORCODE]macro est incluse dans l’URI, le lecteur doit la remplacer par la valeur 202.
Options de codage de l'URL pour l'élément d'erreur
Il existe deux options pour la gestion <error> de l'élément décrit ci-dessus, selon que vous utilisez ou non la substitution de macro.
Si vous n'utilisez pas la substitution de macro :
Appelez le CDATA tel quel (sous une forme valide codée en URL) sans effectuer de substitution de macro.
Par exemple, vous recevrez : <![CDATA[http://adserver.com/?dur=%5BTD_DURATION%5D]]>
...et vous devez appeler : https://adserver.com/?dur=%5BTD_DURATION%5D
Si vous utilisez la substitution de macro :
Décodage URL de l'élément, application de transformations macro, puis codage URL avant l'envoi de la demande.
Par exemple, vous recevrez : <![CDATA[http://adserver.com/?dur=%5BTD_DURATION%5D]]>
...que vous décodez en : https://adserver.com/?dur=[TD_DURATION]
...puis remplacez [TD_DURATION] avec la valeur réelle de la durée (dans cet exemple, 20)
...et vous devez appeler : https://adserver.com/?dur=20