集計可能なレポートをバッチ処理する場合は、プライバシーの上限を超えないようにバッチ処理戦略を最適化することが重要です。レポートのバッチを集計サービスに送信する際のおすすめの方法は次のとおりです。
レポートを収集する
バッチに含めるレポートを収集する際は、次の点に注意してください。
レポートのアップロードの再試行
注: 再試行条件は変更される場合があります。その場合は、このセクションの情報が更新されます。
ウェブ プラットフォームと OS プラットフォームの両方で、プラットフォームはレポートの送信を 3 回試みますが、3 回目の試行でレポートが送信されなかった場合は、送信されません。レポートを送信できるタイミングに関係なく、元の scheduled_report_time 値は保持されます。再試行のタイムラインはプラットフォームによって異なります。
- ウェブブラウザがオンラインになると、レポートが送信されます。レポートの送信に失敗した場合、2 回目の再試行は 5 分間待機し、3 回目は 15 分間待機します。ブラウザがオフラインになった場合、次の再試行はオンラインに戻ってから 1 分後になります。ウェブでのレポート送信には最大遅延時間はありません。つまり、ブラウザがオフラインになった場合、レポートが生成されてからどれだけ時間が経過していても、ブラウザがオンラインに戻ると、再試行ポリシーに従ってレポートの送信が試行されます。
- Android スマートフォンのネットワーク接続は安定しています。そのため、1 時間に 1 回レポートを送信するジョブが実行されます。つまり、レポートの送信に失敗した場合、次の 1 時間後に再試行され、その後 1 時間後に再試行されます。デバイスが接続されていない場合、デバイスは、デバイスがネットワークに再度接続した後に実行される次のレポートジョブでレポートの送信を再試行します。最大遅延は 28 日です。つまり、28 日以上前に生成されたレポートはデバイスから送信されません。
報告を待つ
バッチ処理のためにレポートを収集する場合は、遅れて届くレポートを待つことをおすすめします。遅延レポートは、scheduled_report_time 値とレポートの受信日時を照らし合わせて判断できます。これらのレポート間の時間差は、遅れて到着するレポートをどの程度待つかを判断するのに役立ちます。たとえば、遅延レポートが収集されたら、scheduled_report_time フィールドを確認し、レポートの 90%、95%、99% が受信されたときの遅延時間を時間単位で記録します。このデータを使用して、遅延したレポートを待機する時間を決定できます。即時集計レポートを使用すると、レポートの遅延を回避できます。
次の図は、遅延したレポートが、レポートのスケジュール設定時間に応じて適切なバッチに保存されていることを示しています。バッチ T は scheduled_report_time を表し、T+X は遅延レポートの待機時間を表します。これにより、バッチに含まれるレポートの大部分が、レポートのスケジュール設定時間に対応するサマリー レポートに含まれます。
集計可能レポートのアカウンティング
集計サービスは「重複なし」ルールを維持します。このルールにより、同じ共有 ID を持つすべての集計可能レポートが同じバッチに含まれる必要があります。
レポートを収集したら、同じ共有 ID を持つすべてのレポートが 1 つのバッチに含まれるようにバッチ化する必要があります。
レポートが別のバッチですでに処理されている場合、処理によってプライバシー バジェットの上限を超えたエラーが発生することがあります。レポートを正しくバッチ処理することで、「重複なし」ルールによってバッチが拒否されるのを防ぐことができます。
共有 ID は、集計可能なレポートのアカウントを追跡するためにレポートごとに生成されるキーです。共有 ID を使用すると、同じ共有 ID を持つレポートでは、生成される概要レポートが 1 つだけになります。つまり、1 つの共有 ID にマッピングされるレポートは、すべて 1 つのバッチに含める必要があります。たとえば、レポート X とレポート Y の両方に同じ共有 ID がある場合は、重複のためにレポートが削除されることを避けるため、レポート X とレポート Y の両方を同じバッチに含める必要があります。
次の図は、ハッシュ化されて共有 ID を生成する shared_info コンポーネントを示しています。
次の図は、2 つの異なるレポートに同じ共有 ID を設定できることを示しています。
注: scheduled_report_time は時間単位で切り捨てられ、source_registration_time は日単位で切り捨てられます。また、report_id は共有 ID の作成では使用されません。時間粒度は、今後更新される可能性があります。
バッチ内の重複するレポート
集計可能レポートの shared_info フィールドの report_id フィールドには UUID が含まれます。これは、バッチ内の重複するレポートを識別するために使用されます。バッチ内に同じ report_id を持つレポートが複数ある場合、最初のレポートのみが集計され、残りは重複と見なされてサイレントで破棄されます。集計は通常どおり行われ、エラーは送信されません。必須ではありませんが、集計前に同じレポート ID の重複レポートを除外することで、広告テクノロジーのパフォーマンスが向上する可能性があります。
report_id はレポートごとに一意です。
バッチ間で重複する報告
各レポートには共有 ID が割り当てられます。これは、レポートの shared_info フィールドから取得されたデータポイントを組み合わせて生成された ID です。複数のレポートに同じ共有 ID を含めることができ、各バッチに複数の共有 ID を含めることができます。同じ共有 ID を持つレポートはすべて同じバッチに含める必要があります。同じ共有 ID のレポートが複数のバッチに分散されている場合、最初のバッチのみが承認され、残りは重複として拒否されます。これを回避するには、バッチを適切に作成する必要があります。
次の図は、複数のバッチで同じ共有 ID が使用されていると、後のバッチが失敗する可能性がある例を示しています。この画像では、同じ共有 ID e679aa を持つ 2 つ以上のレポートが、異なるバッチ #1 と #2 にバッチ処理されています。共有 ID e679aa を持つすべてのレポートの予算は、バッチ 1 の概要レポートの生成中に消費されるため、バッチ 2 は許可されず、エラーで失敗します。
バッチ レポート
重複を回避し、集計レポートの計算を最適化するために、レポートをバッチ処理するおすすめの方法は次のとおりです。
広告主ごとのバッチ
注: この戦略は、アトリビューション レポートの集計にのみ推奨されます。
限定公開集計には、広告主である attribution_destination フィールドがありません。バッチごとに集計レポートのアカウント上限に達しないように、広告主ごとにバッチにまとめることをおすすめします。つまり、1 つの広告主に属するレポートを同じバッチに含めるということです。広告主は共有 ID の生成時に考慮されるフィールドであるため、同じ広告主のレポートには同じ共有 ID が割り当てられる可能性があります。この場合、エラーを回避するために、同じバッチに含める必要があります。
時間ごとのバッチ処理
バッチ処理を行う場合は、レポートのスケジュール設定されたレポート時間（shared_info.scheduled_report_time）を考慮することをおすすめします。スケジュール設定されたレポートの時間は、共有 ID の生成時に時間単位で切り捨てられるため、少なくともレポートは 1 時間単位でバッチ処理する必要があります。つまり、同じ時間内にスケジュール設定されたレポートはすべて同じバッチに含める必要があります。これにより、複数のバッチに同じ共有 ID のレポートが存在し、ジョブエラーが発生するのを回避できます。
バッチ頻度とノイズ
集計可能なレポートの処理頻度に対するノイズの影響を考慮することをおすすめします。集計可能レポートのバッチ処理頻度がより高い場合（レポートが 1 時間に 1 回処理される場合など）は、含まれるコンバージョン イベントが少なくなり、ノイズの影響が相対的に大きくなります。頻度を減らしてレポートを週に 1 回処理すると、ノイズの影響は相対的に小さくなります。ノイズがバッチに与える影響を詳しく把握するには、ノイズラボでテストします。