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.
Suivi côté serveur avec insertion publicitaire guidée par le serveur (SGAI)
Lorsque vous utilisez l'insertion publicitaire guidée par le serveur (SGAI), le suivi côté serveur utilise un mécanisme de balisage sans session qui diffère de l'approche en mode assemblé décrite ci-dessus. Au lieu d' MediaTailor intégrer des segments publicitaires dans le manifeste de contenu (où il suit les /v1/segment demandes), SGAI renvoie les références publicitaires sous forme de playlists distinctes dans une réponse à la liste d'actifs avec les métadonnées des balises intégrées à l'annonce. URIs
Comment fonctionne le beaconing sans session côté serveur
Les étapes suivantes décrivent le fonctionnement du balisage côté serveur pour les sessions SGAI :
-
Initialisation de session : le joueur demande la playlist multivariante HLS avec.
aws.insertionMode=GUIDEDLe reporting côté serveur est la valeur par défaut (aucunaws.reportingModeparamètre n'est nécessaire). Contrairement au mode assemblé, la réponse d'initialisation de session n'inclut pas de.trackingUrl -
Manifeste pouvant être mis en cache : MediaTailor renvoie un manifeste pouvant être mis en cache contenant des
EXT-X-DATERANGEbalisesCLASS="com.apple.hls.interstitial"et desX-ASSET-LISTattributs pointant vers le point de terminaison de la liste d' MediaTailoractifs interstitiels. -
Liste des actifs avec métadonnées relatives aux balises : lorsque le joueur rencontre une interruption publicitaire, il récupère la liste des actifs. MediaTailorrenvoie une réponse JSON dans laquelle chaque URI d'annonce inclut des métadonnées de balise cryptées :
{ "ASSETS": [ { "DURATION": 30.0, "URI": "https://cdn.example.com/ad/master.m3u8?awsBeaconData=<encrypted>&awsBeaconDomain=<MediaTailor-endpoint>&awsConfigurationName=<config-name>" } ] }Lorsque le reporting côté serveur est actif, la réponse n'inclut aucune section.
TRACKINGL'annonce contient URIs toutes les données des balises. -
Substitution de variables HLS : le lecteur récupère la liste de lecture multivariée de l'annonce. Le manifeste publicitaire utilise des
#EXT-X-DEFINE:QUERYPARAMdirectives pour transmettre les paramètres de balise de la chaîne de requête URI au segment URLs via la substitution de variables HLS :#EXTM3U #EXT-X-DEFINE:QUERYPARAM="awsBeaconData" #EXT-X-DEFINE:QUERYPARAM="awsBeaconDomain" #EXT-X-DEFINE:QUERYPARAM="awsConfigurationName" #EXTINF:5.0, {$awsBeaconDomain}/segment/hash/{$awsConfigurationName}/{$awsBeaconData}/0/0?aws.segmentRelativePath=asset_00001.tsLe joueur résout les
{$awsConfigurationName}variables{$awsBeaconData}{$awsBeaconDomain}, et en utilisant les valeurs de la chaîne de requête URI du manifeste publicitaire, puis demande le passage de chaque segment publicitaire MediaTailor. -
Balise déclenchée à la demande d'un segment : au fur et à mesure que le joueur demande chaque segment publicitaire, la demande est transmise MediaTailor. Le service déchiffre les données de balise, détermine la position du segment dans l'annonce (impression, premier quartile, point médian, troisième quartile ou complet) et envoie la balise de suivi VAST appropriée au serveur publicitaire. MediaTailor redirige ensuite le lecteur vers le segment de contenu publicitaire proprement dit.
Exigences relatives aux joueurs pour le balisage SGAI côté serveur
Pour utiliser le balisage côté serveur avec SGAI, votre joueur doit répondre aux exigences suivantes :
-
HLS version 11 ou ultérieure
-
Support
EXT-X-DATERANGEavecCLASSattribut pour HLS Interstitials -
Support pour la substitution de
#EXT-X-DEFINE:QUERYPARAMvariables (RFC 8216bis). Le joueur doit décoder en pourcentage les valeurs des paramètres de requête avant de les substituer dans un segment. URLs
Note
Le balisage SGAI côté serveur n'est actuellement pris en charge que pour le HLS. DASH n'est pas encore compatible avec le balisage SGAI côté serveur.
Comparaison avec le suivi côté serveur en mode cousu
Le tableau suivant résume les différences entre le suivi côté serveur entre l'insertion d'annonces cousues et l'insertion guidée par le serveur :
| Aspect | Cousu (SSAI) | Guidé par le serveur (SGAI) |
|---|---|---|
| Possibilité de mise en cache du manifeste | Par session, ne peut pas être mis en cache | Peut être mis en cache, partagé entre les spectateurs |
| Routage des segments publicitaires | En /v1/segment/ utilisant l'identifiant de session |
/v1/segment/En utilisant un blob de données de balise crypté |
| État de session pour les balises | Stocké par session dans MediaTailor | Sans session : tous les états sont enregistrés dans le paramètre crypté awsBeaconData |
| URL de suivi lors de l'initialisation de la session | Renvoyé dans la réponse d'initialisation de session | Non fourni : les données de balise sont intégrées à l'annonce URIs dans chaque réponse à la liste d'actifs |
| Prise en charge de DASH | Pris en charge | Pas encore pris en charge |
Note
Pour les sessions SGAI en direct, vous pouvez activer la prélecture des annonces basée sur le manifeste à l'aide de. aws.guidedPrefetchMode=MANIFEST Ceci est distinct de l'API de prélecture basée sur un calendrier utilisée avec les sessions Stitched (SSAI). Pour en savoir plus, consultez Prélecture guidée avec battements de cœur manifestes.