TVOD売上データセットは、Prime Videoのトランザクション型ビデオオンデマンド(TVOD)ビジネスのトランザクションレベルの売上データを提供します。各レコードは、完了した取引(購入またはレンタル)を表します。データはSlate Datasets APIを介して追加のみの変更ログとして納品されるため、カスタム分析を柔軟に構築し、ビジネスニーズに合わせた指標を計算できます。
主なメリット
- より迅速な洞察 — 売上データは1日に複数回のバッチで処理され、ほとんどの取引は完了後約9時間以内に送信されます。
- 原価と売上の分離 — 売上シグナルは4時間ごとにまとめて届きます。原価計算情報(net_cogs)は毎日更新されるため、収益シグナルをできるだけ早く得ることができます。
- 一貫性 — 単一のソースであらゆる地域にわたる標準化されたフォーマット。
- シンプルな取り込み — 追加専用の変更ログモデルと、手間をかけずに自動で取り込むためのシンプルなアップサートパターンを採用しています。
- トランザクションレベルの細分化 — 個々の注文レベルのデータにアクセスして、カスタム分析、タイトルレベルのパフォーマンストラッキング、内部システム統合を強化します。
- 柔軟な統合 — TVOD販売データを社内システム、データウェアハウス、BIツールと統合します。
機能 |
Slate Datasets API |
アクセスタイプ |
プログラマティック(REST API) |
最適な用途 |
自動パイプライン、エンタープライズレポート、カスタム分析 |
認証 |
Amazonでログイン(LWA)セキュリティプロファイル |
データ形式 |
CSVファイル(gzip圧縮済み) |
はじめに
前提条件
- 有効なPrime Video TVODパートナーシップ
- Amazonでログイン(LWA)セキュリティプロファイル
- コンテンツアカウントマネージャー(CAM)に登録されているクライアントID
- トークンをリクエストするための認証コード
- すべてのAPIリクエストに有効なLWA認証トークン
認証セットアップ
データセットを取得するには、まずデータセットAPIスイートにオンボードする必要があります。詳しくは、こちらをご覧ください。
APIエンドポイント
ディスカバリーエンドポイント
以下のエンドポイントを使用して、アカウントIDと契約IDをプログラムで調べてください。
エンドポイント |
返品 |
|---|---|
GET /v2/accounts |
アクセスできるSlateアカウントのリスト |
GET /v2/accounts/{ACADIA_ID} |
利用可能なビジネスライン(チャンネル、トランザクションなど) |
GET /v2/accounts/{ACADIA_ID}/transactions |
アカウントのTVODコントラクトIDのリスト |
GET /v2/accounts/{ACADIA_ID}/transactions/{CONTRACT_ID}/datasets |
契約で利用できるデータセット |
データセットファイルの取得
このエンドポイントを使用して、契約のトランザクションデータセットファイルへのリンクを取得します。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
リクエストパラメーター
パラメーター |
説明 |
|---|---|
ACADIA_ID |
あなたのSlateアカウントID。GET /v2/accountsを使用して検索してください。 |
CONTRACT_ID |
あなたのTVODコントラクトID。 |
startDateTime |
前回引き出した時点に設定されます。形式: YYYY-MM-DDThh:mm:ssZ (UTC)。 |
endDateTime |
現在の時刻に設定します。形式: YYYY-MM-DDThh:mm:ssZ (UTC)。 |
限定 |
1ページあたり最大1000リンク。 |
このエンドポイントは、トランザクションログを含むダウンロード可能なCSVファイル(gzip圧縮)へのリンクを返します。トランザクションを直接返すわけではありません。
ページネーション
すべての回答はページ分割されています。次のクエリパラメータを使用して結果をナビゲートします。
パラメーター |
デフォルト |
説明 |
|---|---|---|
限定 |
10 |
1ページあたりに返されるドキュメントの数。最大1000です。 |
オフセット |
0 |
スキップするページ数。 |
すべてのページネーションされたレスポンスには、以下のフィールドが含まれます。
フィールド |
説明 |
|---|---|
合計 |
全ページの合計文書数。 |
次へ |
次のページへのURL。最後のページの場合はNull。 |
データモデル
主要概念
概念 |
説明 |
トランザクション |
完了した注文イベント(購入またはレンタル)。各トランザクションは一意のorder_item_idによって識別されます。 |
変更ログモデル |
データは追加専用です。レコードの属性が変更された場合(コストが確定した場合など)、同じorder_item_idを持ち、より新しいlast_update_time_utcを持つ新しいレコードが公開されます。 |
主要キー |
order_item_idは各トランザクションの一意の識別子です。このフィールドでは常に重複排除を行います。 |
コスト対売上 |
売上データは4時間ごとにまとめて届きます。原価計算(net_cogs)は毎日更新されるため、原価のデータが入手可能になると、レコードが更新されます。 |
データ鮮度
属性 |
ターゲット |
売上データ配信 |
4時間ごと(一括処理) |
原価計算(net_cogs)の更新 |
24時間ごと |
エンドツーエンドの遅延 |
トランザクションからデータが利用可能になるまで、最大9時間 |
データ保持 |
最長2年間 |
データ精度
属性 |
詳細 |
正式な情報源 |
支払いや原価計算において、収益および財務諸表は依然として最終的な根拠となります。 |
予想される差異 |
日時の微妙な違いや集計方法が、財務/ロイヤリティレポートと比べると若干異なる場合があります。 |
スコープ |
パフォーマンス追跡のための、取引単位ごとの完了済み注文。財務レポートやロイヤリティ報告書の代わりにはなりません。 |
このデータセットは、より迅速で継続的なパフォーマンス追跡を目的としています。日時の微妙な違いや集計の違いにより、財務レポート(例:動画ASINの日次レベルの概要)とは若干異なる場合があります。これは予想される動作であり、データ品質の問題ではありません。
データの定義
コアフィールド
次の表では、transactions_event_logデータセットで使用可能なすべてのフィールドについて説明しています。
フィールド名 |
タイプ |
無効化可能 |
説明 |
例 |
|---|---|---|---|---|
order_item_id |
文字列 |
いいえ |
各トランザクションの一意の識別子。重複排除の主要キー。 |
ABC123XYZ |
transaction_datetime_utc |
タイムスタンプ |
いいえ |
UTCのトランザクション時間。 |
2026-01-14T00:04:41.575 |
transaction_datetime_local |
タイムスタンプ |
いいえ |
ローカルタイムゾーンのトランザクション時間。 |
2026-01-14T01:04:41.575 |
pv_title_id |
文字列 |
いいえ |
一意のタイトル識別子。 |
tt1234567 |
content_type |
文字列 |
いいえ |
購入したコンテンツのタイプ。 |
映画、TVエピソード、TVシーズン |
purchase_type |
文字列 |
いいえ |
購入またはレンタルの指標。 |
EST(購入)、VOD(レンタル) |
content_quality |
文字列 |
いいえ |
ビデオ品質レベル。 |
SD、HD、UHD |
地域 |
文字列 |
いいえ |
地域コード。 |
US、GB、DE、JP、AU |
device_class |
文字列 |
はい |
デバイスカテゴリ。 |
Fire TV、携帯電話、ウェブ |
title_name |
文字列 |
いいえ |
タイトル名。 |
ザ・グレート・アドベンチャー |
通貨 |
文字列 |
いいえ |
ISO 4217の通貨コードです。 |
USD、EUR、JPY |
vendor_sku |
文字列 |
はい |
パートナー提供のSKU。 |
WB-MOV-001 |
net_cogs |
少数 |
はい |
売上商品の正味原価(税別)。毎日更新します。最初はNULLの場合があります。 |
4.99 |
net_revenue |
少数 |
いいえ |
純収益(税別) |
14.99 |
create_time_utc |
タイムスタンプ |
いいえ |
作成日時をUTCで記録する。 |
2026-01-14T01:39:06.619 |
last_update_time_utc |
タイムスタンプ |
いいえ |
最終更新時間を記録する。重複排除ロジックに使用されます。 |
2026-01-14T01:39:06.619 |
フィールドノート
以下のフィールドには、パートナーが知っておくべき重要な行動特性があります。
フィールド |
計算/論理 |
メモ |
|---|---|---|
net_cogs |
毎日更新します |
最初はNULLまたは0と表示されることがありますが、原価計算が確定してから24時間以内に更新されます。 |
last_update_time_utc |
最新のタイムスタンプが優先されます |
同じorder_item_idのレコードが複数存在する場合は、最新のlast_update_time_utcのレコードのみを保持します。 |
地域 |
すべての地域を対象とした単一のデータセット |
地域ごとのファイルはありません。必要に応じてテリトリーコードでフィルタリングできます。 |
purchase_type |
固定列挙値 |
EST =電子セルスルー(永久購入)。VOD =期間限定レンタル。 |
重複排除
概要
データセットは変更ログモデルを使用しています。レコードが更新されると(原価計算が確定するなど)、同じorder_item_idとより新しいlast_update_time_utcの新しいバージョンが公開されます。正確なデータを維持するには、宛先にレコードを書き込む前に必ず重複排除ロジックを適用してください。
重複排除クエリ
次のSQLパターンを使用して、各トランザクションの最新バージョンのみを重複排除して保持します。-- 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;
アップサートパターン
このパターンを使用して、すべてのトランザクションの最新の状態を含むローカルテーブルを管理します。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);
ETLパイプライン
概要
この4段階のプロセスに従って、TVOD販売データの信頼性の高い自動取り込みパイプラインを構築してください。
パイプラインステップ
- 初期データプル — APIエンドポイントを使用して、希望の時間範囲内に契約のすべてのファイルをプルします。返されたファイルをすべてダウンロードします。各ファイルには、CSV形式(gzip圧縮)のトランザクションレコードが含まれています。
- 重複排除 — 数日分のデータを処理しているときに、同じorder_item_idのレコードが複数存在する場合は、セクション6.2の重複排除クエリを使用して最新のlast_update_time_utcレコードのみを保持します。
- 宛先へのアップサート — order_item_id をキーとして使用して、重複排除されたレコードを宛先テーブルにマージします。セクション6.3のアップサートパターンを参照してください。
- インクリメンタル処理 — 継続的なデータロードでは、startDateTimeを最後にプルした時刻に設定し、endDateTimeを現在の時刻に設定します。返されたファイルをすべて処理し、宛先にアップサートします。
インクリメンタル実行には次のパラメータを設定します。startDateTime = {last_successful_pull_timestamp}
endDateTime = {current_utc_timestamp}
推奨取り込み頻度
推奨事項 |
詳細 |
推奨頻度 |
4〜6時間おきに、できるだけ最新の状態に保ってください。 |
インクリメンタル処理戦略 |
startDateTimeを最後に取得したタイムスタンプに設定し、endDateTimeを現在の時刻に設定します。返されたすべてのファイルを処理します。 |
日次/週次消費者 |
毎日または毎週データを取得する場合は、記録の欠落を防ぐため、対象期間全体のすべてのファイルを確実に処理するようにしてください。 |
推奨開始時間 |
毎日のジョブの場合は、午前1:00 (UTC)に開始して前日の完了を記録します。 |
サンプルクエリ
これらのSQLパターンを使用して、一般的な分析ユースケースを開始してください。[START_DATE]、[END_DATE]、[X]を希望の値に置き換えます。
ある期間の収益別の上位Xタイトル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];
購入タイプ別の総収益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;
日次売上概要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;
地域別の収益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;
品質スタンダード
データ品質目標
品質の構成要素 |
ターゲット |
測定 |
完全性 |
トランザクションの99%以上がキャプチャ済み |
財務報告との比較 |
適時性 |
最大 9 時間のエンドツーエンドの遅延 |
トランザクションからデータが利用可能になるまでの時間 |
一貫性 |
単一スタンダードフォーマット |
1つのデータセット内のすべての地域 |
既知の制限事項
制限事項 |
説明 |
影響 |
原価計算遅延 |
net_cogsはリアルタイムではなく毎日更新されます。 |
レコードには、最初はNULLまたは0コストが表示される場合があり、24時間以内に更新されます。 |
データ保持 |
最大2年間の履歴データ。 |
タイムスタンプが2年以上前のリクエストでは結果は返されません。 |
トークンの有効期限 |
LWAアクセストークンは1時間後に期限切れになります。 |
アクセスが中断されないようにするには、更新トークンのロジックを実装する必要があります。 |
ファイルベースの納品 |
APIは直接データ行ではなく、ファイルへのリンクを返します。 |
処理する前に、パイプラインにダウンロードステップが必要です。 |
財務差異 |
若干の差異と財務/ロイヤルティレポート。 |
データ品質の問題ではなく、日時の微妙な違いによる予想される動作。 |