View a markdown version of this page

Server-side suivi avec insertion d'annonces guidée par serveur (SGAI) - AWS Elemental MediaTailor
Comment fonctionne le beaconing côté serveur sans sessionExigences pour les joueursComparaison entre Stitched et SGAI

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.

Server-side suivi avec insertion d'annonces guidée par serveur (SGAI)

Lorsque vous utilisez l'insertion d'annonces 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 point décrite ci-dessus. Au lieu d'intégrer MediaTailor des segments d'annonces dans le manifeste de contenu (où il suit les /v1/segment demandes), SGAI renvoie les références des annonces sous forme de listes de lecture distinctes dans une réponse à une liste de ressources avec des métadonnées de balise intégrées dans les URI des annonces.

Comment fonctionne le beaconing côté serveur sans session

Les étapes suivantes décrivent le fonctionnement du beaconing côté serveur pour les sessions SGAI :

  1. Initialisation de la session  : le joueur demande la liste de lecture multivariante HLS avec. aws.insertionMode=GUIDED Server-side le reporting est la valeur par défaut (aucun aws.reportingMode paramètre n'est nécessaire). Contrairement au mode Stitched, la réponse d'initialisation de session n'inclut pas de. trackingUrl

  2. Manifeste pouvant être mis en cache  : MediaTailor renvoie un manifeste pouvant être mis en cache contenant des EXT-X-DATERANGE balises CLASS="com.apple.hls.interstitial" et des X-ASSET-LIST attributs pointant vers le point de terminaison de la liste d'actifs MediaTailor interstitiels.

  3. Liste des actifs avec les métadonnées des balises  : lorsque le joueur rencontre une pause 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 les rapports côté serveur sont actifs, la réponse ne comporte aucune section. TRACKING Les URI publicitaires contiennent toutes les données des balises.

  4. Substitution de variables HLS  : le lecteur récupère la playlist multivariante publicitaire. Le manifeste publicitaire utilise des #EXT-X-DEFINE:QUERYPARAM directives pour transmettre les paramètres de balise de la chaîne de requête URI aux URL des segments 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.ts

    Le lecteur résout les {$awsConfigurationName} variables {$awsBeaconData}{$awsBeaconDomain}, et à l'aide des valeurs de la chaîne de requête URI du manifeste publicitaire, puis demande chaque segment d'annonce via MediaTailor.

  5. La balise se déclenche à la demande de segment  : lorsque le joueur demande chaque segment d'annonce, la demande est acheminée MediaTailor. Le service déchiffre les données de la 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 des joueurs pour le beaconing côté serveur SGAI

Pour utiliser le beaconing côté serveur avec SGAI, votre joueur doit répondre aux exigences suivantes :

  • HLS version 11 ou ultérieure

  • Prise en charge de l'CLASSattribut EXT-X-DATERANGE with pour les interstitiels HLS

  • Support pour la substitution de #EXT-X-DEFINE:QUERYPARAM variables (RFC 8216bis). Le joueur doit décoder en pourcentage les valeurs des paramètres de requête avant de les remplacer dans les URL des segments.

Note

Le beaconing SGAI côté serveur est actuellement pris en charge pour HLS uniquement. DASH n'est pas encore pris en charge pour le balisage SGAI côté serveur.

Comparaison avec le suivi côté serveur en mode cousu

Le tableau suivant récapitule les différences entre le suivi côté serveur et l'insertion publicitaire guidée par le serveur :

Aspect Stitched (SSAI) Server-guided (SYGAÏ)
Possibilité de mise en cache manifeste Per-session, ne peut pas être mis en cache Peut être mis en cache, partagé entre les spectateurs
Routage des segments publicitaires /v1/segment/En utilisant l'ID 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 Sessionless : tous les états sont enregistrés dans le paramètre chiffré awsBeaconData
URL de suivi au démarrage de la session Renvoyé dans la réponse d'initialisation de la session Non fourni : les données des balises sont intégrées dans les URI des annonces 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 les manifestes à l'aide de. aws.guidedPrefetchMode=MANIFEST Ceci est distinct de l'API de prélecture basée sur le calendrier utilisée avec les sessions Stitched (SSAI). Pour en savoir plus, consultez Prélecture guidée avec battements de cœur manifestes.