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