Video Central

L’ensemble de données de ventes TVOD fournit des données de vente au niveau des transactions pour votre activité de vidéo à la demande transactionnelle (TVOD) Prime Video. Chaque enregistrement représente une transaction terminée (achat ou location). Les données sont fournies sous forme de journal des modifications en mode Ajout uniquement via l’API Slate Datasets, ce qui vous donne une flexibilité totale pour créer des analyses personnalisées et calculer des indicateurs adaptés aux besoins de votre entreprise.

Principaux avantages

Des informations plus rapides : les données sur les ventes sont regroupées plusieurs fois par jour, la plupart des transactions étant effectuées dans les 9 heures suivant leur achèvement.
Séparation des coûts et des ventes : les signaux de vente arrivent par lots de 4 heures ; les informations sur les coûts (net_cogs) sont actualisées quotidiennement, afin que vous receviez des signaux de revenus le plus rapidement possible.
Cohérence : mise en forme normalisée pour tous les territoires dans une source unique.
Ingestion simplifiée : modèle de journal des modifications en mode Ajout uniquement avec un modèle Upsert simple pour une ingestion automatique et sans intervention.
Granularité au niveau des transactions : accédez aux données individuelles au niveau des commandes pour optimiser les analyses personnalisées, le suivi des performances au niveau des titres et les intégrations de systèmes internes.
Intégration flexible : intégrez les données de vente TVOD à vos systèmes internes, à vos entrepôts de données et à vos outils de BI.

Fonctionnalité	API Slate Datasets
Type d’accès	Programmatique (API REST)
Idéal pour	Pipelines automatisés, rapports d’entreprise, analyses personnalisées
Authentification	Profil de sécurité du service Connexion avec Amazon (LWA)
Format de données	Fichiers CSV (compressés au format gzip)

Premiers pas

Pré-requis

Partenariat actif avec Prime Video TVOD
Un profil de sécurité du service Connexion avec Amazon (LWA)
ID client enregistré auprès de votre gestionnaire de compte de contenu (CAM)
Un code d’autorisation pour demander un jeton
Un jeton d’authentification LWA valide pour toutes les demandes d’API

Configuration de l’authentification
Pour récupérer des ensembles de données, vous devez d’abord intégrer la suite d’API « Datasets ». Vous trouverez plus de détails ici.

Points de terminaison de l’API

Points de terminaison de détection
Utilisez ces points de terminaison pour rechercher les numéros de votre compte et de votre contrat par programmation :

Point de terminaison	Retours
GET /v2/accounts	Liste des comptes Slate auxquels vous pouvez accéder
GET /v2/accounts/{ACADIA_ID}	Secteurs d’activité disponibles (par exemple, canaux, transactions)
GET /v2/accounts/{ACADIA_ID}/transactions	Liste des numéros de contrat TVOD associés à votre compte
GET /v2/accounts/{ACADIA_ID}/transactions/{CONTRACT_ID}/datasets	Ensembles de données disponibles pour un contrat

Récupération de fichiers d’ensembles de données
Utilisez ce point de terminaison pour récupérer des liens vers les fichiers d’ensembles de données de transactions pour votre contrat :

Paramètres de requête

Paramètre	Description
ACADIA_ID	Votre numéro de compte Slate. Trouvez-le à l’aide de GET /v2/accounts.
CONTRACT_ID	Votre numéro de contrat TVOD.
startDateTime	Définie sur la dernière fois que vous avez collecté des données. Format : YYYY-MM-DDThh:mm:ssZ (UTC).
endDateTime	Définie sur l’heure actuelle. Format : YYYY-MM-DDThh:mm:ssZ (UTC).
limite	Maximum de 1 000 liens par page.

Ce point de terminaison renvoie des liens vers des fichiers CSV téléchargeables (compressés au format gzip) qui contiennent les journaux de transactions, et non les transactions directement.

Pagination
Toutes les réponses sont paginées. Utilisez les paramètres de requête suivants pour parcourir les résultats :

Paramètre	Par défaut	Description
limite	10	Nombre de documents renvoyés par page. Maximum de 1 000.
offset	0	Nombre de pages à ignorer.

Toutes les réponses paginées comportent les champs suivants :

Champ	Description
total	Nombre total de documents sur toutes les pages.
next	L’URL de la page suivante. La valeur est nulle si elle figure sur la dernière page.

Modèle de données

Concepts clés

Concept	Description
Transaction	Un événement de commande terminé (achat ou location). Chaque transaction est identifiée par un order_item_id unique.
Modèle de journal des modifications	Les données sont en mode ajout uniquement. Si les attributs d’un enregistrement changent (par exemple, un coût arrive), un nouvel enregistrement est publié avec le même order_item_id mais un last_update_time_utc plus récent.
Clé primaire	order_item_id est l’identifiant unique de chaque transaction. Effectuez toujours la déduplication sur ce champ.
Coût par rapport à Ventes	Les données de vente arrivent par lots de 4 heures. Les coûts (net_cogs) sont actualisés quotidiennement, de sorte que les enregistrements sont mis à jour avec le coût lorsqu’ils sont disponibles.

Actualité des données

Attribut	Cible
Livraison des données de vente	Toutes les 4 heures (par lots)
Actualisation des coûts (net_cogs)	Toutes les 24 heures
Latence de bout en bout	Environ 9 heures entre la transaction et la disponibilité des données
Conservation des données	Maximum de 2 ans

Exactitude des données

Attribut	Détails
Source de vérité	Les résultats et les états financiers restent la dernière source de vérité pour les paiements et les coûts.
Écart attendu	Des écarts mineurs peuvent exister en raison de nuances entre la date et l’heure et de différences d’agrégation par rapport aux rapports financiers/sur les redevances.
Portée	Commandes finalisées au moment de la transaction pour le suivi des performances. Ne remplace pas les rapports financiers ou les rapports sur les redevances.

Cet ensemble de données est conçu pour un suivi plus rapide et continu des performances. Attendez-vous à une légère variation par rapport aux rapports financiers (par exemple, le résumé du niveau quotidien d’ASIN vidéo) en raison des nuances entre la date et l’heure et des différences d’agrégation. Il s’agit d’un comportement normal et non d’un problème de qualité des données.

Définitions des données

Champs principaux
Le tableau suivant décrit tous les champs disponibles dans l’ensemble de données transactions_event_log :

Nom du champ	Type	Nullable	Description	Exemple
order_item_id	CHAÎNE DE CARACTÈRES	Non	Identifiant unique pour chaque transaction. Clé primaire pour la déduplication.	ABC123XYZ
transaction_datetime_utc	HORODATAGE	Non	Heure de la transaction en UTC.	2026-01-14T00:04:41.575
transaction_datetime_local	HORODATAGE	Non	Heure de la transaction dans le fuseau horaire local.	2026-01-14T01:04:41.575
pv_title_id	CHAÎNE DE CARACTÈRES	Non	Identifiant de titre unique.	tt1234567
content_type	CHAÎNE DE CARACTÈRES	Non	Type de contenu acheté.	Film, épisode télévisé, saison télévisée
purchase_type	CHAÎNE DE CARACTÈRES	Non	Indicateur d’achat ou de location.	EST (achat), VOD (location)
content_quality	CHAÎNE DE CARACTÈRES	Non	Niveau de qualité vidéo.	SD, HD, UHD
territoire	CHAÎNE DE CARACTÈRES	Non	Code territoire.	US, GB, DE, JP, AU
device_class	CHAÎNE DE CARACTÈRES	Oui	Catégorie d’appareil.	Fire TV, mobile, Web
title_name	CHAÎNE DE CARACTÈRES	Non	Nom du titre.	The Great Adventure
devise	CHAÎNE DE CARACTÈRES	Non	Code de devise ISO 4217	USD, EUR, JPY
vendor_sku	CHAÎNE DE CARACTÈRES	Oui	SKU fourni par le partenaire.	WB-MOV-001
net_cogs	VALEUR DÉCIMALE	Oui	Coût net des biens vendus, hors taxes. S’actualise tous les jours. Peut être NULL au départ.	4,99
net_revenue	VALEUR DÉCIMALE	Non	Revenu net, hors taxes.	14,99
create_time_utc	HORODATAGE	Non	Heure de création de l’enregistrement en UTC.	2026-01-14T01:39:06.619
last_update_time_utc	HORODATAGE	Non	Enregistrez l’heure de la dernière mise à jour. Utilisée pour la logique de déduplication.	2026-01-14T01:39:06.619

Remarques sur les champs
Les champs suivants présentent des caractéristiques comportementales importantes que les partenaires doivent connaître :

Champ	Calcul/Logique	Remarques
net_cogs	S’actualise quotidiennement	Peut initialement apparaître comme NULL ou 0 ; mise à jour dans les 24 heures suivant la réception des coûts.
last_update_time_utc	C’est l’horodatage le plus récent qui compte	Lorsque plusieurs enregistrements existent pour le même order_item_id, ne conservez que l’enregistrement contenant le dernier last_update_time_utc.
territoire	Ensemble de données unique pour tous les territoires	Aucun fichier par territoire ; filtrez par code de territoire si nécessaire.
purchase_type	Valeurs d’énumération fixes	EST = Vente électronique (achat permanent). VOD = location limitée dans le temps.

Déduplication

Aperçu
L’ensemble de données s’appuie sur un modèle de journal des modifications. Lorsqu’un enregistrement est mis à jour (par exemple, lorsque les coûts arrivent), une nouvelle version est publiée avec le même order_item_id et un last_update_time_utc plus récent. Pour conserver des données précises, appliquez toujours une logique de déduplication avant d’écrire des enregistrements vers votre destination.

Requête de déduplication
Utilisez le modèle SQL suivant pour dédupliquer et ne conservez que la dernière version de chaque transaction :

Modèle Upsert
Utilisez ce modèle pour gérer une table locale avec l’état le plus récent de chaque transaction :

Pipeline ETL

Aperçu
Suivez ce processus en 4 étapes pour créer un pipeline d’ingestion fiable et automatisé pour les données de vente de TVOD.

Étapes du pipeline

Collecte initiale des données :collectez tous les fichiers de votre contrat dans les délais souhaités à l’aide du point de terminaison de l’API. Téléchargez tous les fichiers renvoyés. Chaque fichier contient des enregistrements de transactions au format CSV (compressé au format gzip).
Déduplication : lorsque plusieurs enregistrements existent pour le même order_item_id lors du traitement de plusieurs jours de données, ne conservez que le dernier enregistrement last_update_time_utc à l’aide de la requête de déduplication de la Section 6.2.
Upsert vers la destination : fusionnez les enregistrements dédupliqués dans votre table de destination en utilisant order_item_id comme clé. Consultez le modèle Upsert dans la section 6.3.
Traitement incrémentiel : pour les chargements de données continus, définissez startDateTime sur l’heure de la dernière collecte et endDateTime sur l’heure actuelle. Traitez tous les fichiers renvoyés et faites « Upsert » dans votre destination.

Définissez les paramètres suivants pour les exécutions incrémentielles :

Cadence d’ingestion recommandée

Recommandation	Détails
Cadence recommandée	Toutes les 4 à 6 heures pour rester aussi à jour que possible.
Stratégie de traitement incrémentiel	Définissez startDateTime sur le dernier horodatage récupéré et endDateTime sur l’heure actuelle. Traitez tous les fichiers renvoyés.
Consommateurs quotidiens/hebdomadaires	Si vous effectuez des collectes tous les jours ou toutes les semaines, assurez-vous de traiter tous les fichiers pendant toute la période afin d’éviter de manquer des enregistrements.
Heure de début recommandée	Pour les tâches quotidiennes, commencez à 1 h UTC pour enregistrer les tâches terminées la veille.

Exemples de requêtes

Utilisez ces modèles SQL pour vous familiariser avec les cas d’utilisation courants de l’analytique. Remplacez [START_DATE], [END_DATE] et [X] par les valeurs souhaitées.

Les X meilleurs titres par chiffre d’affaires sur une période donnée

Total des recettes par type d’achat

Résumé des ventes quotidiennes

Recettes par territoire

Normes de qualité

Objectifs de qualité des données

Dimension de qualité	Cible	Mesure
Exhaustivité	> 99 % des transactions enregistrées	Comparaison avec les rapports financiers
Respect des délais	Environ 9 heures de latence de bout en bout	Délai entre la transaction et la disponibilité des données
Cohérence	Format normalisé unique	Tous les territoires dans un seul ensemble de données

Limitations connues

Limite	Description	Impact
Retard dans l’établissement des coûts	net_cogs s’actualise quotidiennement, pas en temps réel.	Les enregistrements peuvent initialement afficher un coût NULL ou 0 ; les mises à jour sont effectuées dans les 24 heures.
Conservation des données	Maximum de 2 ans de données historiques.	Les demandes dont l’horodatage remonte à plus de 2 ans ne donneront aucun résultat.
Expiration du jeton	Les jetons d’accès au service LWA expirent au bout d’une heure.	Doit implémenter une logique d’actualisation des jetons pour un accès ininterrompu.
Livraison basée sur des fichiers	L’API renvoie des liens vers des fichiers, et non des lignes de données directes.	Nécessite une étape de téléchargement dans votre pipeline avant le traitement.
Écart financier	Différences mineures par rapport aux rapports financiers/sur les redevances.	Comportement attendu dû à une nuance entre la date et l’heure ; il ne s’agit pas d’un problème de qualité des données.

Foire aux questions

Cet ensemble de données fournit les commandes terminées au stade de la transaction pour un suivi des performances plus rapide et continu. Il ne remplace pas les rapports financiers ou de redevances. Les bénéfices et les états financiers restent la dernière source de vérité pour les paiements et les coûts. Attendez-vous à un écart mineur en raison des nuances de date et d’heure et des différences d’agrégation.

API de l’ensemble de données de ventes TVOD