Le jeu de données des ventes TVOD fournit des données de vente au niveau des transactions pour votre activité de vidéo transactionnelle à la demande (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 à ajouter 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
- Informations plus rapides — Les données de vente sont regroupées plusieurs fois par jour, la plupart des transactions étant livrées dans les 9 heures suivant leur fin.
- 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 tous les jours, afin que vous puissiez obtenir des signaux de revenus le plus rapidement possible.
- Cohérence — Formatage standardisé sur tous les territoires dans une source unique.
- Ingestion simplifiée — Modèle de journal des modifications avec ajout uniquement avec un schéma d’insertion simple pour une ingestion automatique et sans intervention directe.
- 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 du titre 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 |
Connectez-vous avec le profil de sécurité Amazon (LWA) |
Format des données |
Fichiers CSV (compressés au format gzip) |
Commencer
Prérequis
- Partenariat TVOD actif avec Prime Video
- Profil de sécurité d’une 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 Discovery
Utilisez ces points de terminaison pour rechercher les identifiants de votre compte et de votre contrat par programmation :
Point final |
Retours |
|---|---|
GET /v2/comptes |
Liste des comptes Slate auxquels vous pouvez accéder |
OBTENEZ /v2/accounts/ {ACADIA_ID} |
Secteurs d’activité disponibles (par exemple, canaux, transactions) |
GET /v2/accounts/ {ACADIA_ID} /transactions |
Liste des identifiants de contrats TVOD associés à votre compte |
GET /v2/accounts/ {ACADIA_ID} /transactions/ {CONTRACT_ID} /ensembles de données |
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 des fichiers d’ensembles de données de transactions pour votre contrat : curl -X GET \
-H "Authorization: Bearer Atza|auth_token" \
https://videocentral.amazon.com/api/v2/accounts/{ACADIA_ID}/transactions/{CONTRACT_ID}/\
datasets/transactions_event_log\
?startDateTime=YYYY-MM-DDThh:mm:ssZ\
&endDateTime=YYYY-MM-DDThh:mm:ssZ\
&offset=0&limit=1000
Paramètres de demande
Paramètre |
Description |
|---|---|
ACADIA_ID |
L’identifiant de votre compte Slate. Trouvez-le à l’aide de GET /v2/accounts. |
IDENTIFIANT_CONTRAT |
L’identifiant de votre contrat TVOD. |
Date/heure de début |
Réglez sur la dernière fois que vous avez tiré. Format : YYYY-MM-DDTHH:MM:SSZ (UTC). |
Date/heure de fin |
Réglé à 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) contenant les journaux des 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 |
Number de documents renvoyés par page. 1 000 au maximum. |
décalage |
0 |
Nombre de pages à ignorer. |
Tous/Toutes les réponses paginées contiennent les champs suivants :
Champ |
Description |
|---|---|
total |
Nombre total de documents sur toutes les pages. |
suivant |
URL de la page suivante. Null s’il se trouve 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 Changelog |
Les données peuvent être ajoutées uniquement. Si les attributs d’un enregistrement changent (par exemple, le 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. Dédupliquez toujours dans ce champ. |
Coût par rapport aux ventes |
Les données de vente arrivent par lots de 4 heures. Costing (net_cogs) est actualisé tous les jours, 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 |
2 ans maximum |
Exactitude des données
Attribut |
Détails |
Source de vérité |
Les bénéfices et les états financiers restent la dernière source de vérité pour les paiements et les coûts. |
Écart attendu |
Un écart mineur peut exister en raison des nuances de date et d’heure et des différences d’agrégation par rapport aux rapports financiers/de redevances. |
Portée |
Commandes terminées au moment de la transaction pour le suivi des performances. Ne remplace pas les rapports financiers ou de redevances. |
Cet ensemble de données est conçu pour un suivi des performances plus rapide et continu. Attendez-vous à un léger écart par rapport aux rapports financiers (par exemple, Video ASIN Daily Level Summary) en raison des nuances de date et d’heure et des différences d’agrégation. Il s’agit d’un comportement attendu 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 le jeu de données transactions_event_log :
Nom du champ |
Type |
Nullable |
Description |
Exemple |
|---|---|---|---|---|
ID de l’article de commande |
CHAÎNE |
Non |
Identifiant unique pour chaque transaction. Clé primaire pour la déduplication. |
ABC123XYZ |
date_transaction_heure_utc |
HORODATAGE |
Non |
Heure de la transaction en UTC. |
2026-01-14T 00:04:41.575 |
date_transaction_time_local |
HORODATAGE |
Non |
Heure de la transaction dans le fuseau horaire local. |
14-01-2026T 01:04:41,575 |
pv_title_id |
CHAÎNE |
Non |
Identifiant de titre unique. |
tt1234567 |
type_contenu |
CHAÎNE |
Non |
Type de contenu acheté. |
Film, Épisode télévisé, Saison télévisée |
type_achat |
CHAÎNE |
Non |
Indicateur d’achat ou de location. |
EST (achat), VOD (location) |
qualité_du contenu |
CHAÎNE |
Non |
Niveau de qualité vidéo. |
SD, HD, UHD |
territoire |
CHAÎNE |
Non |
Code du Territoire. |
ÉTATS-UNIS, GB, DE, JP, AU |
classe_appareil |
CHAÎNE |
Oui |
Catégorie d’appareil. |
Fire TV, téléphone portable, Internet |
nom_titre |
CHAÎNE |
Non |
Nom du titre. |
La grande aventure |
devise |
CHAÎNE |
Non |
Code de devise ISO 4217. |
USD, EUR, JPY |
vendor_sku |
CHAÎNE |
Oui |
SKU fourni par le partenaire. |
WB-MOV-001 |
net_cogs |
DÉCIMALE |
Oui |
Coût net des biens vendus, hors taxes. Rafraîchit tous les jours. Peut être NULL au départ. |
4,99 |
revenu_net |
DÉCIMALE |
Non |
Recettes nettes, hors taxes. |
14,99 |
créer_heure_utc |
HORODATAGE |
Non |
Enregistrez l’heure de création en UTC. |
14-01-2026T 01:39:06 .619 |
heure_de_dernière_actualisation_utc |
HORODATAGE |
Non |
Enregistrez l’heure de la dernière mise à jour. Utilisé pour la logique de déduplication. |
14-01-2026T 01:39:06 .619 |
Remarques sur
le terrain Les domaines suivants présentent des caractéristiques comportementales importantes que les partenaires doivent connaître :
Champ |
Calcul/Logique |
Remarques |
|---|---|---|
net_cogs |
Se rafraîchit tous les jours |
Peut initialement apparaître sous la forme NULL ou 0 ; les mises à jour sont effectuées dans les 24 heures suivant l’arrivée des coûts. |
heure_de_dernière_actualisation_utc |
Les dernières victoires par horodatage |
Lorsque plusieurs enregistrements existent pour le même order_item_id, ne conservez que l’enregistrement contenant le dernier last_update_time_utc. |
territoire |
Un jeu de données unique pour tous les territoires |
Aucun fichier par territoire ; filtrez par code de territoire selon les besoins. |
type_achat |
Valeurs d’énumération fixes |
EST = vente électronique (achat permanent). VOD = location limitée dans le temps. |
Déduplication
Aperçu
Le jeu de données utilise 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 garantir l’exactitude des données, 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 conserver uniquement la dernière version de chaque transaction : -- Deduplicate to latest version of each transaction
SELECT *
FROM (
SELECT *,
ROW_NUMBER() OVER (
PARTITION BY order_item_id
ORDER BY last_update_time_utc DESC
) AS rn
FROM your_transactions_table
) t
WHERE rn = 1;
Modèle Upsert
Utilisez ce modèle pour conserver une table locale avec l’état le plus récent de chaque transaction : MERGE INTO your_table AS target
USING s3_staging_table AS source
ON target.order_item_id = source.order_item_id
WHEN MATCHED AND source.last_update_time_utc > target.last_update_time_utc THEN
UPDATE SET
transaction_datetime_utc = source.transaction_datetime_utc,
net_cogs = source.net_cogs,
net_revenue = source.net_revenue,
last_update_time_utc = source.last_update_time_utc
-- ... all other columns
WHEN NOT MATCHED THEN
INSERT (order_item_id, transaction_datetime_utc, ..., last_update_time_utc)
VALUES (source.order_item_id, source.transaction_datetime_utc, ..., source.last_update_time_utc);
Pipeline ETL
Aperçu
Suivez ce processus en quatre étapes pour créer un pipeline d’ingestion fiable et automatisé pour les données de ventes de TVOD.
Étapes du pipeline
- Extraction initiale des données : extrayez tous les fichiers de votre contrat dans le délai souhaité à 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.
- Transférer vers la destination — Fusionnez les enregistrements dédupliqués dans votre table de destination en utilisant order_item_id comme clé. Voir le schéma d’augmentation dans la section 6.3.
- Traitement incrémentiel : pour les chargements de données en cours, définissez StartDateTime sur la dernière extraction et EndDateTime sur l’heure actuelle. Traitez tous les fichiers renvoyés et insérez-les dans votre destination.
Définissez les paramètres suivants pour les exécutions incrémentielles : startDateTime = {last_successful_pull_timestamp}
endDateTime = {current_utc_timestamp}
Cadence d’ingestion recommandée
Recommandation |
Détails |
Cadence recommandée |
Toutes les 4 à 6 heures pour rester le plus à jour possible. |
Stratégie de traitement incrémentielle |
Définissez StartDateTime sur le dernier horodatage récupéré et EndDateTime sur l’heure actuelle. Traitez tous les fichiers renvoyés. |
Consommateurs quotidiens ou hebdomadaires |
Si vous récupérez des fichiers 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 heure du matin UTC pour enregistrer les tâches terminées le jour précédent. |
Exemples de requêtes
Utilisez ces modèles SQL pour commencer à utiliser les cas d’utilisation courants en matière d’analyse. Remplacez [START_DATE], [END_DATE] et [X] par les valeurs souhaitées.
Les X titres les plus populaires par chiffre d’affaires sur une période SELECT
title_name,
COUNT(DISTINCT order_item_id) AS total_orders,
SUM(net_revenue) AS total_revenue
FROM your_table
WHERE transaction_datetime_utc BETWEEN '[START_DATE]' AND '[END_DATE]'
GROUP BY title_name
ORDER BY total_revenue DESC
LIMIT [X];
Chiffre d’affaires total par type d’achat SELECT
purchase_type,
SUM(net_revenue) AS total_revenue
FROM your_table
WHERE transaction_datetime_utc BETWEEN '[START_DATE]' AND '[END_DATE]'
GROUP BY purchase_type
ORDER BY purchase_type;
Récapitulatif des ventes quotidiennes SELECT
DATE(transaction_datetime_utc) AS transaction_date,
COUNT(DISTINCT order_item_id) AS total_orders,
SUM(net_revenue) AS total_revenue,
SUM(net_cogs) AS total_cogs
FROM your_table
WHERE transaction_datetime_utc BETWEEN '[START_DATE]' AND '[END_DATE]'
GROUP BY DATE(transaction_datetime_utc)
ORDER BY transaction_date DESC;
Recettes par Territoire SELECT
territory,
COUNT(DISTINCT order_item_id) AS total_orders,
SUM(net_revenue) AS total_revenue
FROM your_table
WHERE transaction_datetime_utc BETWEEN '[START_DATE]' AND '[END_DATE]'
GROUP BY territory
ORDER BY total_revenue DESC;
Normes de Qualité
Objectifs de Qualité des données
Dimension de qualité |
Cible |
Mesure |
Intégralité |
> 99 % des transactions capturées |
Comparaison avec les rapports financiers |
Respect des délais |
~9 heures de latence de bout en bout |
Temps écoulé entre la transaction et la disponibilité des données |
Cohérence |
Format standardisé unique |
Tous/Toutes les régions réunies dans un seul jeu de données |
Limitations connues
Limitation |
Description |
Incidence |
Retard d’établissement des coûts |
net_cogs s’actualise tous les jours, pas en temps réel. |
Les enregistrements peuvent initialement indiquer un coût nul ou nul ; les mises à jour se font 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 renverront aucun résultat. |
Expiration des jetons |
Les jetons d’accès LWA expirent au bout d’une heure. |
Doit implémenter une logique de jeton d’actualisation 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. |
Finances diverses |
Écart mineur par rapport aux rapports financiers/de redevances. |
Comportement attendu dû à une nuance de date et d’heure ; il ne s’agit pas d’un problème de qualité des données. |