集計可能なレポートをバッチ処理する場合は、プライバシーの上限を超えないようにバッチ処理戦略を最適化することが重要です。レポートのバッチを集計サービスに送信するための推奨戦略をいくつかご紹介します。
レポートを収集する
バッチに含めるレポートを収集する際は、次の点に注意してください。
レポートのアップロードの再試行
注: 再試行条件は変更される場合があります。その場合は、このセクションの情報が更新されます。
ウェブ プラットフォームと 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 がある場合、重複のためにレポートが破棄されないように、両方を同じバッチに含める必要があります。
次の図は、ハッシュ化されて共有 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 を持つ複数のレポートが、異なるバッチ #1 と #2 にバッチ処理されています。共有 ID e679aa を持つすべてのレポートの予算は、バッチ 1 の概要レポートの生成中に消費されるため、バッチ 2 は許可されず、エラーで失敗します。
バッチ レポート
重複を回避し、集計レポートの計算を最適化するために、レポートをバッチ処理する推奨方法は次のとおりです。
広告主ごとのバッチ
注: この戦略は、アトリビューション レポートの集計にのみ推奨されます。
限定公開集計には、広告主である attribution_destination フィールドがありません。バッチごとに集計レポートのアカウント上限に達しないように、広告主ごとにバッチにまとめることをおすすめします。つまり、1 つの広告主に属するレポートを同じバッチに含めます。広告主は共有 ID の生成時に考慮されるフィールドであるため、同じ広告主のレポートに同じ共有 ID が割り当てられることがあります。この場合、エラーを回避するために、同じバッチに含める必要があります。
時間ごとのバッチ処理
バッチ処理を行う場合は、レポートのスケジュール設定されたレポート時間（shared_info.scheduled_report_time）を考慮することをおすすめします。スケジュール設定されたレポートの時間は、共有 ID の生成時に時間単位で切り捨てられるため、少なくともレポートは 1 時間単位でバッチ処理する必要があります。つまり、同じ時間内にスケジュール設定されたレポートはすべて同じバッチに含める必要があります。複数のバッチに同じ共有 ID のレポートが含まれると、ジョブエラーが発生します。
バッチの頻度とノイズ
集計可能なレポートの処理頻度に対するノイズの影響を検討することをおすすめします。集計可能レポートのバッチ処理頻度が速い（レポートが 1 時間に 1 回処理されるなど）場合、含まれるコンバージョン イベントが少なくなり、ノイズの影響が相対的に大きくなります。頻度を減らしてレポートを週に 1 回処理すると、ノイズの影響は相対的に小さくなります。ノイズがバッチに与える影響をより深く理解するには、Noise Lab でテストします。