Digital Platform API - レポート サービス
Report Service は、さまざまな種類のレポートへのアクセスを提供するために使用されます。 また、各ユーザーの種類が、その種類に適したレポートにのみアクセスできるようになります。 たとえば、ネットワーク ユーザーはすべてのレポートの種類にアクセスでき、広告主と発行元のユーザーはごく一部のユーザーにのみアクセスできます。
使用可能なメトリックはレポートの種類によって異なりますが、広告枠に費やされた金額、表示または販売されたインプレッション数、収益などが含まれます。 このドキュメントでは、レポート サービスからデータを要求およびダウンロードする方法について説明します。 また、サポートされている各レポートの種類に関する詳細情報を取得する方法と、各レポートの種類に関する詳細なドキュメントへのリンクを提供する方法についても説明します。
注:
- レポート データベースに Xandr データを同期する方法の詳細については、「 一括レポート フィード」を参照してください。
- これは読み取り専用サービスです。JSON 形式のレポート要求を
POST
しますが、サーバーに格納されているデータは変更されません。
レポートの種類
レポートの種類 | ユーザーの種類 | 説明 | データ保持 |
---|---|---|---|
Network Analyticsnetwork_analytics |
Network | 何が起こっているかの一般的な概要。 何が提供されているのか、何がうまくいっているのか、両方の買い物と売りの面で。 | 有効期間 - 100 日後に細分性が低下したデータ。 |
ネットワーク課金network_billing |
Network | 広告主に請求する必要がある内容、パブリッシャーまたは Xandr によって課金される場合があります。 | 有効期間 - 100 日後に細分性が低下したデータ。 |
課金レポートの購入buyer_invoice_report |
Network | 関連する請求金額の購入に関する財務調整のレポート。 | 1095 日 |
販売請求レポートseller_invoice_report |
Network | 関連する料金の販売に関する財務調整のレポート。 | 1095 日 |
ネットワーク広告主分析network_advertiser_analytics |
Network | 広告主に関するネットワーク レポート。 | 有効期間 - 100 日後に細分性が低下したデータ。 |
Network Publisher Analyticsnetwork_publisher_analytics |
Network | 発行元のネットワーク レポート。 | 有効期間 - 100 日後に細分性が低下したデータ。 |
Publisher Analyticspublisher_analytics |
ネットワーク、パブリッシャー | 発行元に表示される内容のレポート。 | 有効期間 - 100 日後に細分性が低下したデータ。 |
広告主向けアナリティクスadvertiser_analytics |
ネットワーク、広告主 | 広告主に表示される内容のレポート。 | 有効期間 - 100 日後に細分性が低下したデータ。 |
Network Video Analyticsvideo_analytics_network |
Network | 広告主とパブリッシャー間のビデオ イベント レポート。 | 420 日 |
ネットワーク広告主向け Video Analyticsvideo_analytics_network_advertiser |
Network | 1 人の広告主のビデオ イベント レポート。 | 420 日 |
Network Publisher Video Analyticsvideo_analytics_network_publisher |
Network | 1 人のパブリッシャーのビデオ イベント レポート。 | 420 日 |
購入者セグメントのパフォーマンス レポートbuyer_segment_performance |
Network | キャンペーンと複数の広告主のセグメントのパフォーマンスに関するレポート。 | 45 日 |
販売者ブランド レビュー レポートseller_brand_review |
Network | ネットワークのすべてのインベントリに対するブランドのパフォーマンスに関するレポート。 | 428 日 |
パブリッシャー ブランド レビュー レポートpublisher_brand_review |
Publisher | すべてのパブリッシャーのインベントリに対するブランドのパフォーマンスに関するレポート。 | 428 日 |
ネットワーク クリエイティブ周波数 & レジェンシーnetwork_advertiser_frequency_recency |
Network | 1 人の広告主のクリエイティブの頻度とリジェンシーに関するネットワーク レポート。 | 120 日間 |
広告主のクリエイティブの頻度 & リジェンシーadvertiser_frequency_recency |
ネットワーク、広告主 | 広告主がクリエイティブの頻度とリジェンシーについて確認する必要がある内容のレポート。 | 120 日間 |
ネットワーク サイト ドメインのパフォーマンスnetwork_site_domain_performance |
Network | 広告主間のドメインパフォーマンスに関するネットワーク レポート。 | 45 日 |
サイト ドメインのパフォーマンス レポートsite_domain_performance |
ネットワーク、広告主 | 1 人の広告主のドメインパフォーマンスに関するレポート。 | 45 日 |
販売者サイト ドメインseller_site_domain |
Network | 発行元を通じて発生するインベントリに関するレポート。 | 60 日 |
セグメント読み込みレポートsegment_load |
Network | セグメントに関するネットワーク レポート。 | 30 日間 |
広告主の属性付きコンバージョンattributed_conversions |
Network | 広告主の属性コンバージョンに関するネットワーク レポート。 | 90 日間 |
Geo Analytics レポートgeo_analytics |
Network | キャンペーンの配信とパフォーマンスを地理的領域別に分解します。 | 45 日 |
Network Carrier Analyticsnetwork_carrier_analytics |
Network | モバイル デバイスの通信事業者に基づく購入側および販売側のパフォーマンス データに関するレポート。 | 46 日 |
Network Device Analyticsnetwork_device_analytics |
Network | インプレッションが配信されたデバイスに基づいて、購入側と販売側のパフォーマンス データをレポートします。 | 428 日 |
コンバージョン ピクセルの最終起動pixel_fired |
Network | 広告主のコンバージョン ピクセルの最終火災日時に関するネットワーク レポート。 | 一生 |
完了したクリエイティブ監査レポートcompleted_creative_audits |
Network | クリエイティブがどのように監査プロセスを進んでいるかについての洞察を提供するように設計されたネットワーク レポート | 365 日 |
一括レポート フィードnetwork_analytics_feed clicktrackers |
Network | 集計されたレポートをレポート データベースに同期する機能。 | 30 日間 |
データ使用状況レポートbuyer_data_usage_analytics |
Network | 第三者 (ユーザー セグメント プロバイダーなど) によって提供されるデータの使用状況、そのデータがユーザーをターゲットに使用された広告申込情報/キャンペーンのコストの詳細を示すネットワーク レポート。 | 60 日 |
仕入先使用状況レポートbuyer_vendor_usage_analytics |
Network | サード パーティベンダー (ユーザー セグメント プロバイダーなど) が提供するデータまたはプラットフォームの使用状況、そのデータまたは機能の使用状況のコスト、ベンダーのコストが適用された広告申込情報/キャンペーンの詳細を提供するネットワーク レポート。 | 60 日 |
購入者エンゲージメント レポート buyer_engagement_report |
広告 主 | ディスプレイおよびビデオ クリエイティブの表示可能な期間に関する分析情報を提供します。 | 過去 5 週間 |
購入者取引メトリックbuyer_deal_metrics |
広告主、ネットワーク | 買い手に関連する取引メトリック、パフォーマンス、拒否の理由に関する重要な情報。 | 30 日間 |
販売者取引の指標seller_deal_metrics |
Publisher、Network | 販売者に関連する取引メトリック、パフォーマンス、拒否の理由に関する重要な情報。 | 30 日間 |
マルチバイヤー販売者取引の指標multi_buyer_seller_deal_metrics |
Publisher、Network | 販売者に関連する取引メトリック、パフォーマンス、拒否の理由に関する重要な情報。 | 30 日間 |
Key Value Analyticskey_value_analytics |
Network | ネットワークの定義されたターゲット キーと値に関連付けられている情報に関するネットワーク レポート。 キー/値ターゲティングを使用したインプレッションは、キー名のkw_プレフィックスを含むプレースメント タグによって記録されたインプレッションに対してのみ配信され、報告されます。 | 428 日 |
キュレーター分析レポートcurator_analytics |
学芸員 | キュレーションされたマーケットプレース内で需要から供給に資金がどのように流れているかについて、キュレーターに洞察を提供します。 | 14 か月 |
キュレーターセグメントパフォーマンスレポートcurator_segment_performance |
学芸員 | キュレーションされた取引の全体的なパフォーマンスに、対象セグメントがどのように貢献しているかをキュレーターに分析情報を提供します。 | 14 か月 |
購入者のリーチと頻度レポートbuyer_approximate_unique_users_hourly |
Network | 広告に公開される一意のデバイスまたはユーザーの数である "リーチ" と、一意のデバイスまたはユーザーが広告に公開された平均回数である "頻度" に関連付けられた情報を提供します。 | 90 日間 |
オフライン属性レポートoffline_attribution |
広告 主 | 対象ユーザーの間で店舗内購入に影響を与える広告申込情報のパフォーマンスに関する分析情報を提供します。 オフライン属性レポートには、広告申込情報でオフライン販売属性が有効になっているクライアントのみがアクセスできます。 | 120 日間 |
販売者 CMP 分析レポートcmp_analytics |
Network | エンドポイントへの販売者広告要求に関する IAB Transparency & Consent Framework (IAB TCF) 文字列の数、有効性、およびコンテンツに関する分析情報を提供します。 | 30 日間 |
Prebid Server Premium Seller Analytics レポートprebid_server_analytics |
Network | Prebid Server Premium Seller Analytics レポートには、構成された Prebid Server Premium (PSP) 需要パートナーに関するパフォーマンス情報が含まれています。 最終的な配信とパフォーマンスに使用します。 | 30 日間 |
Prebid Server Premium Health Analytics レポートpsp_health_analytics |
Network | Prebid Server Premium の入札要求とトランザクションに関連するデータ。 トラブルシューティングと最適化に役立ちます。 レポートは、 PSP アクティビティの全量を推定するために乗算されたサンプル データに基づいています。 このような目的で 、Prebid Server Premium Analytics レポート やその他の Microsoft 収益化レポートを使用します。 | 99 日 |
インベントリ可用性レポートplatform_inventory_availability |
広告主、パブリッシャー | インベントリ可用性レポートでは、プラットフォームで使用可能なインベントリの種類に関する分析情報が提供されます。 | 30 日間 |
メタデータを表示するための REST API
HTTP メソッド | エンドポイント | 説明 |
---|---|---|
GET |
https://api.appnexus.com/report?meta | すべてのレポートのメタデータを返します。 |
GET |
https://api.appnexus.com/report?meta=REPORT_TYPE | 特定のレポートの種類のメタデータを返します。 |
メタデータを表示するための JSON フィールド
メタ配列には、次のフィールドが含まれます。
フィールド | 説明 |
---|---|
time_granularity |
レポートでデータを提供できる時間の細分性。 使用可能な値: - "hourly" - "daily" - "monthly" - "yearly" - "lifetime" "hourly" または"lifetime" 場合、データは年、月、日、および時間で使用できます。 "daily" 、"monthly" 、または"yearly" の場合、データは年、月、日でのみ使用できます。 |
columns |
要求できる列。 列ごとに、名前と型が JSON 応答に一覧表示されます。 |
filters |
フィルターとして使用できる列。 列ごとに、名前と型が JSON 応答に一覧表示されます。 |
time_intervals |
レポートを実行できる時間範囲。 |
注:
一部のレポートの種類では、カスタム時間枠のレポートを実行できます。 これを行うには、レポート要求の start_date
フィールドと end_date
フィールドを設定します。
メタデータ応答の例 ( network_analytics
レポートを使用)
$ curl -b cookies -c cookies 'https://api.appnexus.com/report?meta=network_analytics'
{
"response": {
"status": "OK",
"meta": {
"time_granularity": "hourly",
"columns": [
{
"column": "month",
"type": "date"
},
{
"column": "day",
"type": "date"
},
{
"column": "hour",
"type": "date"
},
{
"column": "buyer_member_id",
"type": "int"
},
{
"column": "seller_member_id",
"type": "int"
},
{
"column": "seller_member_name",
"type": "string"
},
{
"column": "seller_member",
"type": "string"
},
{
"column": "advertiser_id",
"type": "int"
},
...
],
"filters": [
{
"column": "hour",
"type": "date"
},
{
"column": "day",
"type": "date"
},
{
"column": "month",
"type": "date"
},
{
"column": "buyer_member_id",
"type": "int"
},
{
"column": "seller_member_id",
"type": "int"
},
...
],
"havings": [
{
"column": "imps"
},
{
"column": "clicks"
},
{
"column": "cost"
},
{
"column": "revenue"
},
{
"column": "booked_revenue"
},
{
"column": "reseller_revenue"
},
{
"column": "profit"
},
...
],
"time_intervals": [
"current_hour",
"last_hour",
"last_48_hours",
"today",
"yesterday",
"last_7_days",
"month_to_date",
"quarter_to_date",
"last_month",
"lifetime",
"mtd"
]
}
}
}
データ取得のための REST API
HTTP メソッド | エンドポイント | 説明 |
---|---|---|
POST |
https://api.appnexus.com/report (レポート JSON) |
レポートを要求します。 |
GET |
https://api.appnexus.com/report?id=REPORT_ID | レポートの状態を要求します。 |
GET |
https://api.appnexus.com/report-download?id=REPORT_ID | レポート データを取得します。 |
注:
ネットワーク ユーザーは、クエリ文字列に advertiser_id=ADVERTISER_ID
または publisher_id=PUBLISHER_ID
を追加することで、広告主レベルと発行元レベルのレポートを実行できます。
データ取得用の JSON フィールド
フィールド | 必須 POST |
種類 | 説明 |
---|---|---|---|
report_type |
はい | 列挙 | これにより、返される情報が決まります。 使用可能な値: - "network_analytics" - "network_billing" - "buyer_invoice_report" - "seller_invoice_report" - "network_advertiser_analytics" - "network_publisher_analytics" - "network_site_domain_performance" - "advertiser_analytics" - "video_analytics_network" - "video_analytics_network_advertiser" - "video_analytics_network_publisher" - "buyer_segment_performance" - "seller_brand_review" - "publisher_brand_review" - "publisher_analytics" - "network_creative_search" - "publisher_creative_search" - "network_advertiser_frequency_recency" - "advertiser_frequency_recency" - "site_domain_performance" - "seller_site_domain" - "inventory_domain_analytics" - "inventory_source_analytics" - "inventory_daily_uniques" - "segment_load" - "attributed_conversions" - "pixel_fired" - "network_analytics_feed" - "clicktrackers" - "key_value_analytics" - "prebid_server_analytics" - "psp_health_analytics" |
timezone |
いいえ | string (50) | これにより、データが報告されるタイム ゾーンが決まります。 使用可能なタイムゾーン値の一覧については、「 API タイムゾーン」を参照してください。 手記: network_billing 、network_analytics 、network_advertiser_analytics 、network_publisher_analytics 、advertiser_analytics 、publisher_analytics のレポートの種類については、100 日を超えるデータが UTC で報告されます。 また、 network_site_domain_performance 、 site_domain_performance 、 seller_site_domain など、時間単位のデータを提供しないレポートの種類は UTC で報告されます。 |
filters |
いいえ | 配列 | レポートに適用するフィルター オブジェクトの一覧。 以下の「レポートの実行方法」セクションの手順 1 を参照してください。 |
group_filters |
いいえ | オブジェクトの配列 | 1 つ以上のフィルターで実行する操作を指定できます。 たとえば、キャンペーン別にグループ化された合計インプレッション数を選択する場合は、このフィールドを使用して、少なくとも 10,000 インプレッションを持たないキャンペーンを除外できます。 |
columns |
はい | 文字列の配列 | レポートに含める列の一覧。 以下 の「JSON 形式のレポート要求を作成する 」を参照してください。 少なくとも 1 つの列を指定する必要があります。 |
row_per 又は groups |
いいえ | 配列 |
注:非推奨。 既定では、レポートの結果は、 columns のディメンションによって自動的にグループ化されます。 これらのフィールドを渡しても効果はありません。ほとんどのレポートでは、選択したディメンションが自動的にグループ化されます。 たとえば、 "advertiser_id" 、 "campaign_id" 、 "creative_id" 、 "imps" の列を含めると、レポート データの各行に広告主、キャンペーン、クリエイティブの組み合わせごとのインプレッションが表示されます。 |
start_date |
いいえ | string | レポートの開始日。 - 時間単位のデータを提供するレポートの種類の場合、これは "YYYY-MM-DD HH:MM:SS" 形式にする必要があります。注: MM:SS は 00:00 する必要があります。これは、分と秒のデータを使用できないのでです。- 時間単位のデータを提供しないレポートの種類の場合、これは "YYYY-MM-DD" 形式にする必要があります。 |
end_date |
いいえ | string | レポートの終了日。 手記: end_date は非包括的です。 たとえば、 "2017-07-01 00:00:00" でレポートを開始し、 "2017-07-01 23:00:00" でレポートを終了した場合、レポートにはその日の過去 1 時間のデータは含まれません。 このデータを取得する正しい方法は、 "2017-07-02 00:00:00" でレポートを終了することです。- 時間単位のデータを提供するレポートの種類の場合、これは "YYYY-MM-DD HH:MM:SS" 形式にする必要があります。 ただし、 MM:SS は 00:00 する必要があります。データは分と秒では使用できません。 たとえば、"2017-07-02 00:00:00" に"2017-07-01 00:00:00" すると、1 日のデータ全体が取得されます。- 時間単位 (日単位、週単位など) より長い間隔で集計されたレポートの場合は、形式を "YYYY-MM-DD" する必要があります。 たとえば、"2017-07-02" に"2017-07-01" すると、1 日のデータ全体が取得されます。 |
report_interval |
いいえ | 列挙 | レポートの時間範囲。 すべてのレポートですべての間隔を受け入れるわけではありません。 詳細については、各レポートのドキュメントとメタデータを参照してください。 使用可能な値: - current_hour - last_hour - today - yesterday - last_48_hours - last_2_days - last_7_days - last_14_days - month_to_yesterday - month_to_date - quarter_to_date - last_month - lifetime - 30_days |
orders |
いいえ | オブジェクトの配列 | 並べ替える列の一覧。 以下の 「レポートを実行する方法」を 参照してください。 |
format |
いいえ | 列挙 | レポート データが返される形式。 このフィールドが指定されていない場合は、既定で "csv" されます。使用可能な値: - "csv" : コンマ区切りの値- "excel" : タブ区切りの値- "html" |
reporting_decimal_type |
いいえ | 列挙 | レポートで使用される 10 進マーク。 使用可能な値: - "comma" - "decimal" (期間)このフィールドが渡されると、ユーザーレベルとメンバーレベルで設定されたレポートの 10 進設定がオーバーライドされます。 |
emails |
いいえ | 配列 | レポート データの送信先となるメール アドレスの一覧。 レポート データは添付ファイルとして送信され、電子メールの本文には以下の情報が含まれています。 - レポートの種類 - メンバー、広告主、またはパブリッシャーの名前と ID - 実行日 -開始日 - 終了日 - タイムゾーン - レポートを生成したユーザー。 手記: 15 MB を超えるレポート結果は電子メールで送信されません。 結果が大きくなりすぎないようにする方法については、「 レポートのベスト プラクティス」を参照してください。 |
escape_fields |
いいえ | ブール値 |
true すると、レポート出力の各フィールドの周囲に引用符が追加され、Excel へのより安全なインポートが可能になります。 これは、CSV およびタブ区切りのレポートにのみ適用されます。 |
group_filters
例
{
"group_filters": [
{
"imps": {
"value": 10000,
"operator": ">="
}
}
]
}
レポートを実行する方法
- 手順 1. JSON 形式のレポート要求を作成する
- 手順 2.
POST
Report Service への要求 - 手順 3.
GET
レポート サービスからのレポートの状態 - 手順 4.
GET
レポート ダウンロード サービスからのレポート データ
手順 1: JSON 形式のレポート要求を作成する
JSON ファイルには、実行する特定の report_type
と、取得する columns
(ディメンションとメトリック) と report_interval
("today"
、 "yesterday"
、 "month_to_date"
など) が含まれている必要があります。 ディメンションの filters
を含め、粒度 (year
、 month
、 day
) を定義し、データを返す format
を指定することもできます。
format
オプションは次のとおりです。
-
"csv"
- コンマ区切りファイル -
"excel"
- タブ区切りファイル -
"xlsx"
- 最新の XML 互換 Excel 形式 (zip 形式)
注:
複数の値でディメンションをフィルター処理するには、配列を使用します。 例:
そうです:
"filters": [{"bid_type": ["learn","optimized"]},
{"geo_country":"US"}]
間違った:
"filters": [{"bid_type":"learn"},
{"bid_type":"optimized"},`` {"geo_country":"US"}]
要求に含めることができるフィールドの詳細については、上記の JSON フィールド を参照してください。 使用可能なディメンションとメトリックの完全な一覧については、「 メタデータを表示するための REST API」で説明されているように、実行する特定のレポートの種類に関するドキュメントを参照するか、そのレポートのメタデータをプルします。
$ cat report_request
{
"report": {
"report_type": "network_analytics",
"report_interval": "last_48_hours",
"columns": ["day","imps","clicks"],
"filters": [{"geo_country":"US"}],
"orders": [{"order_by":"day", "direction":"ASC"},{"order_by":"imps", "direction":"DESC"}],
"format": "csv"
}
}
手順 2: 要求をレポート サービスに POST
する
JSON 要求を POST
し、レポート ID を取得します。
$ curl -b cookies -c cookies -X POST -d @report_request 'https://api.appnexus.com/report'
{
"response": {
"status": "OK",
"report_id": "ca9955709eade9a0e89f5cda5345c12r"
}
}
または、保存したレポート ID を使用して、 POST
要求を介してレポート ID を取得することもできます。 詳細については、 保存されたレポート サービスに関するページを参照してください。
curl -c cookies -b cookies -X POST 'https://api.appnexus.com/report?saved_report_id=30'
手順 3: レポート サービスからレポートの状態を GET
する
レポート ID を使用して GET
呼び出しを行って、レポートの状態を取得します。
execution_status
が"ready"
されるまで、この呼び出しを続けます。 次に、 report-download
サービスを使用して、レポート データをファイルに保存します。 (これについては、次の手順で説明します)。
$ curl -b cookies -c cookies 'https://api.appnexus.com/report?id=ca9955709eade9a0e89f5cda5345c12r'
{
"response": {
"status": "OK",
"report": {
"name": null,
"created_on": "2017-03-13 18:15:48",
"cache_hit": false,
"fact_cache_hit": false,
"json_request": "{\"report\":{\"report_type\":\"network_analytics\",\"report_interval\":
\"last_48_hours\",\"columns\":[\"day\",\"imps\",\"clicks\"],\"filters\":[{\"geo_country\":
\"US\"},{\"entity_member_id\":\"514\"},{\"entity_member_id\":null}],\"orders\":
[{\"order_by\":\"day\",\"direction\":\"ASC\"},{\"order_by\":\"imps\",\"direction\":
\"DESC\"}]}}",
"header_info": "Report type:,network_analytics\r\n,\r\nRun at:,2017-03-13 18:15:48\r\nStart date:,
\r\nEnd date:,\r\nTimezone:,\r\nUser:,John Smith (9385)\r\n",
"report_size": "10",
"row_count": "35",
"url": "report-download?id=ca9955709eade9a0e89f5cda5345c12r"
},
"execution_status": "ready"
}
}
手順 4: レポート ダウンロード サービスからレポート データを GET
する
レポート データをファイルにダウンロードするには、レポート ID を使用して別の GET
呼び出しを行いますが、今回は report-download
サービスに呼び出します。 サービスとレポート ID は、前の GET
応答の url フィールドにあります。 保存するファイルを特定するときは、最初のPOST
で指定した"format"
のファイル拡張子を使用してください。
注:
ダウンロード中にエラーが発生した場合、応答ヘッダーには HTTP エラー コードとメッセージが含まれます。 要求で -i
または -v
を使用して、応答ヘッダーを公開します。
curl -i -b cookies -c cookies 'https://api.appnexus.com/report-download?id=ca9955709eade9a0e89f5cda5345c12r' > /tmp/network_analytics.csv
その後、Microsoft Excel または同様のソフトウェアを使用して csv ファイルを開くことができます。
レポート データ サイズの制限事項
15 MB を超えるレポート結果は、JSON 要求で指定された受信者に電子メールで送信されません。
処理に 15 分を超える時間がかかるレポートはタイムアウトになり、エラー状態で返されます。 この処理時間は、約 1MM 行のデータに相当します。 レポートが定期的にタイムアウトする場合は、次のいずれかのオプションを検討してください。
- すべてのデータが本当に必要であることを確認します。 そうでない場合は、短い時間間隔または少ないディメンションでレポート要求を更新します。 レポートが不必要に大きすぎたり、処理に時間がかかるのを防ぐヒントについては、以下 の「レポートのベスト プラクティス 」を参照してください。
- すべてのデータが本当に必要な場合は、「 Report Pagination」の指示に従ってください。
レポートの調整
すべてのユーザーに対してシステムが可能な限りスムーズに動作するように、 Report Service はメンバー レベルとユーザー レベルの両方でレポート要求を調整します。 このページでは、制限の決定方法と、各メンバーと各ユーザーに対して定義されている制限を超える要求を処理する方法について説明します。
ユーザー制限
ユーザー A によってレポートが送信されると、ユーザー A が過去 15 分間に保留中の状態または現在処理中の 5 つのレポート要求を送信したかどうかを確認するチェックが実行されます。 その場合は、エラーが通知されます。
メンバーの制限
特定のメンバーは、同時に処理される n 個のレポート要求に制限されます。 ここで、n はメンバーのコントラクトによって決定されます (これは、api.member テーブルの max_concurrent_reports_processing
フィールドによって内部的に指定されます)。制限に達した後に送信されたすべてのレポート要求は、キューに配置されます。 警告やアラートは表示されません。
例
ユーザーレベルとメンバーレベルの調整は、次の例に示すように相互に対話します。 ユーザー A とユーザー B が同じメンバーに関連付けられているとします。このメンバーには、5 つの同時レポート要求の制限があります。 この例では、次のレポート要求がすべて 15 分以内に送信されることを前提としています。
レポート要求 | User | 結果 |
---|---|---|
1 | ユーザー A | Processing |
2 | ユーザー A | Processing |
3 | ユーザー B | Processing |
4 | ユーザー B | Processing |
5 | ユーザー B | Processing |
6 | ユーザー A | エンキュー |
7 | ユーザー A | エンキュー |
8 | ユーザー A | エンキュー |
9 | ユーザー A | Error |
このメンバーに対して既に 5 つのレポート要求が処理されているため、レポート要求 # 6 がキューに配置されます。 同じ理由で、要求 # 6 から 8 もキューに配置されます。 最後に、ユーザー A が 15 分以内に 6 番目のレポート要求を送信したので、要求 # 9 によってエラーが通知されることがわかります。
変換データ
レポート内の変換 (および関連データ) は非同期的に処理されます。 その結果、レポートをより迅速に利用できるようになりますが、一部の変換関連データはバックグラウンドでまだ処理されています。 詳細については、「 レポート データの可用性 」ページの「非同期変換属性」を参照してください。
レポートのベスト プラクティス
レポートが不必要に大きくなるのを防いだり、処理に時間がかかるのを防ぐためのヒントを次に示します。
-
report_interval
を短くします (たとえば、"lifetime"
から"last_48_hours"
)。 - より高いレベルのフィルターを追加します (たとえば、特定のパブリッシャー、広告主、キャンペーンなど)。
- これにより行数が指数関数的に増加するため、詳細な買い側ディメンションと販売側ディメンション (クリエイティブや配置など) を組み合わせることは避けてください。 このような組み合わせについて報告する必要がある場合は、 一括レポート フィード または ログ レベル データ (LLD) フィードの使用を検討してください。
処理に時間がかかる大きなレポートをプルする必要がある場合は、「 レポートの改ページ」の手順に従ってください。
レポートが最後に更新されたタイミングを確認するには、 レポートの状態サービスを使用します。