O Conjunto de dados de vendas de TVOD fornece dados de vendas em nível de transação para o seu negócio de vídeo sob demanda transacional (TVOD) no Prime Video. Cada registro representa uma transação concluída (compra ou aluguel). Os dados são entregues como um registro de alterações somente para acréscimo por meio da API de Conjuntos de dados do Slate, o que dá total flexibilidade para criar análises personalizadas e calcular métricas adaptadas às necessidades do seu negócio.
Principais benefícios
- Informações mais rápidas — Os dados de vendas são agrupados em lotes várias vezes por dia, e a maioria das transações é entregue em cerca de 9 horas após a conclusão.
- Separação entre custo e vendas — Os sinais de vendas chegam em lotes de 4 horas; as informações de custeio (net_cogs) são atualizadas diariamente, para que você receba os sinais de receita o mais rápido possível.
- Consistência — Formatação padronizada em todos os territórios em uma única fonte.
- Ingestão simplificada — Modelo de registro de alterações somente para acréscimo, com um padrão de upsert simples para uma ingestão automatizada e sem intervenção.
- Granularidade em nível de transação — Acesse dados individuais em nível de pedido para viabilizar análises personalizadas, rastreamento de desempenho em nível de título e integrações com sistemas internos.
- Integração flexível — Integre os dados de vendas de TVOD aos seus sistemas internos, data warehouses e ferramentas de BI.
Recurso |
API de Conjuntos de dados do Slate |
Tipo de acesso |
Programático (API REST) |
Ideal para |
Pipelines automatizados, relatórios corporativos, análises personalizadas |
Autenticação |
Perfil de segurança do Login com a Amazon (LWA) |
Formato de dados |
Arquivos CSV (compactados com gzip) |
Primeiros passos
Pré-requisitos
- Parceria de TVOD ativa com o Prime Video
- Um perfil de segurança do Login com a Amazon (LWA)
- ID do cliente registrada com o seu Gerenciador de conta de conteúdo (CAM)
- Um código de autorização para solicitar um token
- Um token de autenticação LWA válido para todas as solicitações de API
Configuração de autenticação
Para recuperar conjuntos de dados, primeiro você precisa fazer a integração ao pacote da API de Conjuntos de dados. Mais informações podem ser encontradas aqui.
Endpoints da API
Endpoints de descoberta
Use esses endpoints para consultar as IDs da sua conta e do seu contrato de forma programática:
Endpoint |
Retorno |
|---|---|
GET /v2/accounts |
Lista de contas do Slate a que você tem acesso |
GET /v2/accounts/{ACADIA_ID} |
Linhas de negócios disponíveis (por exemplo, canais, transações) |
GET /v2/accounts/{ACADIA_ID}/transactions |
Lista de IDs de contrato de TVOD na sua conta |
GET /v2/accounts/{ACADIA_ID}/transactions/{CONTRACT_ID}/datasets |
Conjuntos de dados disponíveis para um contrato |
Recuperação de arquivos do conjunto de dados
Use este endpoint para recuperar links para os arquivos do conjunto de dados de transações do seu contrato: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
Parâmetros de solicitação
Parâmetro |
Descrição |
|---|---|
ACADIA_ID |
A ID da sua conta Slate. Encontre-a usando GET /v2/accounts. |
CONTRACT_ID |
A ID do seu contrato de TVOD. |
startDateTime |
Defina como o horário da última extração. Formato: YYYY-MM-DDThh:mm:ssZ (UTC). |
endDateTime |
Defina como o horário atual. Formato: YYYY-MM-DDThh:mm:ssZ (UTC). |
limit |
Máximo de 1000 links por página. |
Este endpoint retorna links para arquivos CSV que podem ser baixados (compactados com gzip) e que contêm os registros de transações, não as transações diretamente.
Paginação
Todas as respostas são paginadas. Use os seguintes parâmetros de consulta para navegar pelos resultados:
Parâmetro |
Padrão |
Descrição |
|---|---|---|
limit |
10 |
Número de documentos retornados por página. Máximo de 1000. |
offset |
0 |
Número de páginas a serem puladas. |
Todas as respostas paginadas contêm os seguintes campos:
Campo |
Descrição |
|---|---|
total |
Contagem total de documentos em todas as páginas. |
next |
URL para a próxima página. Null se estiver na última página. |
Modelo de dados
Conceitos-chave
Conceito |
Descrição |
Transação |
Um evento de pedido concluído (compra ou aluguel). Cada transação é identificada por um order_item_id exclusivo. |
Modelo de registro de alterações |
Os dados são somente para acréscimo. Se os atributos de um registro mudarem (por exemplo, se o custo chegar), um novo registro é publicado com o mesmo order_item_id, mas com um last_update_time_utc mais recente. |
Chave primária |
order_item_id é o identificador exclusivo de cada transação. Sempre faça a deduplicação por esse campo. |
Custo vs. vendas |
Os dados de vendas chegam em lotes de 4 horas. O custeio (net_cogs) é atualizado diariamente, portanto os registros recebem o custo quando ele fica disponível. |
Atualização dos dados
Atributo |
Alvo |
Entrega dos dados de vendas |
A cada 4 horas (em lote) |
Atualização do custeio (net_cogs) |
A cada 24 horas |
Latência de ponta a ponta |
~9 horas da transação até a disponibilidade dos dados |
Retenção de dados |
Máximo de 2 anos |
Precisão dos dados
Atributo |
Detalhes |
Fonte da verdade |
Os ganhos e as demonstrações financeiras continuam sendo a fonte final da verdade para pagamentos e custeio. |
Variação esperada |
Pode haver pequena variação devido a nuances de data e hora e a diferenças de agregação em comparação com os relatórios financeiros/de royalties. |
Escopo |
Pedidos concluídos no nível da transação para rastreamento de desempenho. Não substitui os relatórios financeiros nem os de royalties. |
Este conjunto de dados foi projetado para um rastreamento de desempenho mais rápido e contínuo. Espere pequenas variações em comparação com os relatórios financeiros (por exemplo, Resumo de nível diário do ASIN de vídeo) devido a nuances de data e hora e a diferenças de agregação. Esse é o comportamento esperado, não um problema de qualidade de dados.
Definições de dados
Campos principais
A tabela a seguir descreve todos os campos disponíveis no conjunto de dados transactions_event_log:
Nome do campo |
Tipo |
Anulável |
Descrição |
Exemplo |
|---|---|---|---|---|
order_item_id |
STRING |
Não |
Identificador exclusivo de cada transação. Chave primária para deduplicação. |
ABC123XYZ |
transaction_datetime_utc |
TIMESTAMP |
Não |
Horário da transação em UTC. |
2026-01-14T00:04:41.575 |
transaction_datetime_local |
TIMESTAMP |
Não |
Horário da transação no fuso horário local. |
2026-01-14T01:04:41.575 |
pv_title_id |
STRING |
Não |
Identificador exclusivo do título. |
tt1234567 |
content_type |
STRING |
Não |
Tipo de conteúdo comprado. |
Filme, Episódio de série, Temporada de série |
purchase_type |
STRING |
Não |
Indicador de compra ou aluguel. |
EST (compra), VOD (aluguel) |
content_quality |
STRING |
Não |
Nível de qualidade do vídeo. |
SD, HD, UHD |
território |
STRING |
Não |
Código do território. |
US, GB, DE, JP, AU |
device_class |
STRING |
Sim |
Categoria do dispositivo. |
Fire TV, celular, Web |
title_name |
STRING |
Não |
Nome do título. |
A Grande Aventura |
currency |
STRING |
Não |
Código de moeda ISO 4217. |
USD, EUR, JPY |
vendor_sku |
STRING |
Sim |
SKU fornecido pelo parceiro. |
WB-MOV-001 |
net_cogs |
DECIMAL |
Sim |
Custo líquido dos produtos vendidos, excluindo impostos. É atualizado diariamente. Pode ser NULL inicialmente. |
4,99 |
net_revenue |
DECIMAL |
Não |
Receita líquida, excluindo impostos. |
14,99 |
create_time_utc |
TIMESTAMP |
Não |
Horário de criação do registro em UTC. |
2026-01-14T01:39:06.619 |
last_update_time_utc |
TIMESTAMP |
Não |
Horário da última atualização do registro. Usado na lógica de deduplicação. |
2026-01-14T01:39:06.619 |
Observações sobre os campos
Os campos a seguir têm características de comportamento importantes que os parceiros devem conhecer:
Campo |
Cálculo/Lógica |
Observações |
|---|---|---|
net_cogs |
É atualizado diariamente |
Pode aparecer inicialmente como NULL ou 0; é atualizado em 24 horas quando o custeio chega. |
last_update_time_utc |
Prevalece o carimbo de data/hora mais recente |
Quando existirem vários registros para o mesmo order_item_id, mantenha somente o registro com o last_update_time_utc mais recente. |
territory |
Conjunto de dados único para todos os territórios |
Não há arquivos por território; filtre pelo código do território conforme necessário. |
purchase_type |
Valores de enumeração fixos |
EST = venda eletrônica (compra permanente). VOD = aluguel por tempo limitado. |
Deduplicação
Visão geral
O conjunto de dados usa um modelo de registro de alterações. Quando um registro é atualizado (por exemplo, quando o custeio chega), uma nova versão é publicada com o mesmo order_item_id e um last_update_time_utc mais recente. Para manter os dados precisos, sempre aplique a lógica de deduplicação antes de gravar registros no seu destino.
Consulta de deduplicação
Use o padrão de SQL a seguir para fazer a deduplicação e manter somente a versão mais recente de cada transação:-- 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;
Padrão de upsert
Use este padrão para manter uma tabela local com o estado mais recente de cada transação: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 de ETL
Visão geral
Siga este processo de quatro etapas para criar um pipeline de ingestão confiável e automatizado para os dados de vendas de TVOD.
Etapas do pipeline
- Extração inicial de dados — Extraia todos os arquivos do seu contrato no intervalo de tempo desejado usando o endpoint da API. Faça download de todos os arquivos retornados. Cada arquivo contém registros de transações no formato CSV (compactado com gzip).
- Deduplicação — Quando existirem vários registros para o mesmo order_item_id durante o processamento de vários dias de dados, mantenha somente o registro com o last_update_time_utc mais recente usando a consulta de deduplicação da Seção 6.2.
- Upsert no destino — Combine os registros deduplicados na sua tabela de destino usando order_item_id como chave. Veja o padrão de upsert na Seção 6.3.
- Processamento incremental — Para carregamentos de dados contínuos, defina startDateTime como o horário da última extração e endDateTime como o horário atual. Processe todos os arquivos retornados e faça o upsert no seu destino.
Defina os seguintes parâmetros para as execuções incrementais:startDateTime = {last_successful_pull_timestamp}
endDateTime = {current_utc_timestamp}
Cadência de ingestão recomendada
Recomendação |
Detalhes |
Cadência recomendada |
A cada 4 a 6 horas para ficar o mais atualizado possível. |
Estratégia de processamento incremental |
Defina startDateTime como o último carimbo de data/hora recuperado e endDateTime como o horário atual. Processe todos os arquivos retornados. |
Consumidores diários/semanais |
Se você faz a busca diária ou semanal, processe todos os arquivos do período inteiro para não perder registros. |
Horário de início recomendado |
Para trabalhos diários, comece à 1h UTC para capturar as conclusões do dia anterior. |
Exemplos de consultas
Use estes padrões de SQL para começar pelos casos de uso comuns de análise. Substitua [START_DATE], [END_DATE] e [X] pelos valores desejados.
Os X principais títulos por receita em um períodoSELECT
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];
Receita total por tipo de compraSELECT
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;
Resumo diário de vendasSELECT
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;
Receita por territórioSELECT
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;
Padrões de qualidade
Metas de qualidade de dados
Dimensão de qualidade |
Alvo |
Medição |
Completude |
>99% das transações capturadas |
Comparação com os relatórios financeiros |
Pontualidade |
~9 horas de latência de ponta a ponta |
Tempo da transação até a disponibilidade dos dados |
Consistência |
Formato único padronizado |
Todos os territórios em um único conjunto de dados |
Limitações conhecidas
Limitação |
Descrição |
Impacto |
Atraso no custeio |
net_cogs é atualizado diariamente, não em tempo real. |
Inicialmente, os registros podem mostrar custo NULL ou 0; a atualização ocorre em 24 horas. |
Retenção de dados |
Máximo de 2 anos de dados históricos. |
Solicitações com carimbos de data/hora com mais de 2 anos não retornarão resultados. |
Expiração do token |
Os tokens de acesso LWA expiram após 1 hora. |
É necessário implementar a lógica de token de atualização para acesso ininterrupto. |
Entrega baseada em arquivos |
A API retorna links para arquivos, não linhas de dados diretas. |
Exige uma etapa de download no seu pipeline antes do processamento. |
Variação financeira |
Pequena variação em relação aos relatórios financeiros/de royalties. |
Comportamento esperado devido a nuances de data e hora; não é um problema de qualidade de dados. |