アトリビューション スコープを使用してアトリビューションの前にソースをフィルタする

アトリビューション スコープを使用すると、API 呼び出し元は、ソースとトリガーの登録時に、アトリビューションが行われる前にフィルタリングに使用できる文字列のリストを指定できます。これにより、より細かい粒度のフィルタリングが可能になり、API の効率が向上し、柔軟性が高まります。たとえば、同じサイトで異なる広告主を個別にトラッキングできます。また、1 つの広告バナー内で複数のキャンペーンや商品をトラッキングすることも容易になります。

アトリビューション スコープは、ソースとトリガーの登録時に設定できるオプションのフィールドです。アトリビューションの際、トリガーのアトリビューション スコープ値の少なくとも 1 つを含むアトリビューション スコープ値を持つソースのみがアトリビューションの対象となります。トリガーでスコープが指定されていない場合は、すべてのソースが考慮されます。続行する前に、アトリビューション レポート API高レベル フィルタについて理解しておく必要があります。

ソースの登録中

ヘッダー Attribution-Reporting-Register-Source にオプション パラメータ attribution_scopes が追加されます。ヘッダー Attribution-Reporting-Register-Source には、必須パラメータ(values、limit)が 2 つ、オプション パラメータ(max_event_states)が 1 つ含まれています。

  • limit: 送信元レポート送信元で、送信先ごとに許可される固有のスコープの合計数を表します。レポートの配信元と配信先が同じで、上限が小さい既存の登録済みソースは削除されます。
  • values: 特定のソースの属性スコープのリストを表します。これらの値は、最大長が 50 の文字列である必要があります。
  • max_event_states(省略可): API 呼び出し元が後続のすべてのイベントソース登録で使用する予定のイベント状態の最大数を表します。レポートのオリジンと宛先が同じで max_event_states value が異なる既存の登録済みソースは削除されます。この省略可能なフィールドのデフォルト値は 3 です。

ソース登録のサンプル

  Attribution-Reporting-Register-source: {
  //optional
  "attribution_scopes":{
  "limit": <int>,
  "values": <list of strings>,
  // optional
  "max_event_states": <int>
    },
  ...
  }

トリガー登録中

トリガー登録時に、ヘッダー Attribution-Reporting-Register-Trigger にオプション パラメータ attribution_scopes が追加されます。パラメータ値がトリガーのスコープを表す文字列のリストであることを確認します。トリガーの attribution_scopes が指定されている場合、トリガーは、attribution_scopes 値パラメータにトリガーの attribution_scopes の少なくとも 1 つが含まれているソースにのみ一致します。

トリガー登録のサンプル

Attribution-Reporting-Register-Trigger: {
//optional
"attribution_scopes": <list of strings>,
...
}

アトリビューション スコープの例

次の例は、アトリビューション スコープを使用しながら、トリガーがソースに帰属する場合を示しています。

ソースの登録 #1

  Attribution-Reporting-Register-source: {
  "destination": "https://trigger.example",
  "attribution_scopes": {
  "limit": 2,
  "values": ["advertiser1"],
  "max_event_states": 3
  },
  ...
  }

ソースの登録 #2

  Attribution-Reporting-Register-source: {
  "destination": "https://trigger.example",
  "attribution_scopes": {
  "limit": 2,
  "values": ["advertiser2"],
  "max_event_states": 3
  },
  ...
  }

トリガーの登録

  Attribution-Reporting-Register-Trigger: {
  "attribution_scopes": ["advertiser1"],
  ...
  }

トリガー登録が発生すると、API は、トリガー登録の値と交差する attribution_scopes 値を持つ、アトリビューションの対象となるソースを選択します。一致するソース登録は、残りのアトリビューション フローで続行されます。この例では、API 呼び出し元は、トリガー登録を最初のソース登録に帰属させるアトリビューション レポートを受け取ります。

アトリビューション スコープとフィルタ

アトリビューション スコープとフィルタの機能は似ているように見えますが、トリガー登録フローのどこで適用されるかが異なります。アトリビューション スコープのフィルタリングは、アトリビューションの前に実行されます。つまり、有効期限が切れていない候補ソースのプールを、同じ宛先サイトとレポート送信元を持つソースに絞り込みます。この絞り込みは、トリガーで見つかったスコープと交差するスコープを持つソースに基づいて行われます。ただし、トップレベルのフィルタは、トリガーが単一のソースに帰属された後に適用されます。ソースフィルタとトリガー フィルタが交差しない場合、レポートは生成されません。

次の図は、同じ宛先サイトとレポート送信元を持ち、有効期限が切れていないソースとトリガーのグループを示しています。アトリビューション スコープとフィルタの使用方法、および利用可能なソースとトリガーに基づいてレポートが生成されるかどうかについて簡単に説明します。

ソース番号 1 ~ 4 のラベルが付いた 4 つのボックスと、[トリガー #1] のラベルが付いた 1 つのボックス。最初のソースには、次の属性「アトリビューション スコープ」: 「activewear」と優先度: 2 があります。2 つ目のソースには、属性「アトリビューション スコープ」: 「アクティブウェア」とフィルタ: 「アウターウェア」があります。3 番目のソースには、属性「アトリビューション スコープ」: 「カジュアルウェア」、フィルタ: 「アウターウェア」があります。4 つ目のソースには、属性「アトリビューション スコープ」: 「カジュアルウェア」、フィルタ: 「アウターウェア」、優先度: 1 があります。トリガーには、属性「アトリビューション スコープ」: 「カジュアルウェア」とフィルタ: 「アウターウェア」があります。
アトリビューション スコープとフィルタを使用したアトリビューションの仕組みの例

アトリビューション前

  • ソース #1 は、アトリビューション スコープがトリガーの casualwear のスコープと一致しないため、除外されます。利用可能なすべてのソースの中で最も優先度が高い場合でも、プリ アトリビューション フィルタリングは優先度の確認前に行われるため、フィルタリングで除外される可能性があります。
  • ソース #2 も、トリガーと同じスコープがないため除外されます。このソースにもトリガーと同じフィルタがありますが、高レベルのフィルタはアトリビューションが完了するまで適用されません。

アトリビューション中

  • Source #3 は Source #4 よりも優先度が低いため、アトリビューションの対象として選択されません。
  • ソース #4 は、トリガーと一致するアトリビューション スコープを持ち、優先度が最も高いため、選択されます。上位レベルのフィルタはアトリビューション後に適用されるため、アトリビューション プロセスでは考慮されません。

投稿のアトリビューション

  • 選択したソース(ソース #4)とトリガーのハイレベル フィルタが交差しないため、レポートは生成されません。

上記の例では、レポートは生成されません。ただし、4 番目のソースが完全に削除された場合は、次のようになります。

ソース番号 1 ~ 4 のラベルが付いた 4 つのボックスと、「トリガー #1」のラベルが付いた 1 つのボックス。この画像では、[Source #4] というラベルの付いたボックスが赤い X で取り消し線が引かれています。
アトリビューション スコープとフィルタでアトリビューションがどのように機能するかについての例を修正

アトリビューション中

  • トリガーと交差するアトリビューション スコープを持つソース #3 が選択されます。

投稿のアトリビューション

  • ソース #3 は、フィルタがトリガーのフィルタと交差しているため、拒否されません。その後、アトリビューションは残りの投稿アトリビューション チェックに進み、すべてのチェックに合格するとレポートが生成されます。

アトリビューション スコープを使用すると、アトリビューションの対象となるソースの数が減ります。残りのアトリビューション ステップは、このより小さなソースプールに適用され、レポートが生成される可能性があります。

アトリビューション フローにおけるアトリビューション スコープの位置

アトリビューション スコープは、アトリビューションのソースが選択される前に適用されます。これは、トップレベル フィルタとカスタム レポート期間のフィルタリングよりも優先されます。次の図は、アトリビューション スコープがアトリビューションと残りのアトリビューション チェックの前に行われる、アトリビューション フロー全体の簡略版を示しています。

アトリビューション フローの簡略版。各ステップは正方形で表され、次のステップに矢印でリンクされています。手順は、「ソースの登録」、「トリガーの登録」、「ソースのマッチング」、「アトリビューション スコープの確認」、「アトリビューション」、「フィルタの確認」、「他のソースの無効化」、「アトリビューションの確認」、「レポートの生成」の順です。
簡素化されたアトリビューション フロー

アトリビューション フローのオペレーション

アトリビューション フローで実行されるさまざまなオペレーションの概要は次のとおりです。

  • ソース登録: ユーザーが広告主のサイトで広告を操作すると、ソースイベントが登録されます。デバイスはレポート送信元のエンドポイントにリクエストを送信し、エンドポイントはソース イベントデータを含むヘッダーで応答します。
  • トリガー登録: 広告主のサイトでコンバージョンが発生すると、トリガー イベントが登録されます。デバイスからレポート送信元に別のリクエストが送信され、レポート送信元はトリガー イベント データを含むヘッダーで応答します。
  • ソースのマッチング: デバイスは、リンク先サイト、レポートの配信元、有効期限などの条件に基づいて、ソースイベントとトリガー イベントを照合します。
  • アトリビューション スコープのチェック: ソースとトリガーの attribution_scopes 値の共通部分に基づいてソースがフィルタされます。
  • アトリビューション: 複数のソースが一致する場合、デバイスはアトリビューションの優先度が最も高いソースを選択します。優先度が同じ場合は、最も新しいものが選択されます。
  • フィルタのチェック: デバイスは、ソースフィルタとトリガー フィルタを比較して、一致するかどうかを判断します。フィルタが一致しない場合、アトリビューションは破棄されます。
  • 他のソースの無効化: 選択したソースのフィルタが一致した場合、デバイスはソース マッチング ステージで一致したソースを無効化します。無効化されたソースには、アトリビューション スコープがトリガー スコープと一致しないソースが含まれます。
  • アトリビューション後のチェック: デバイスは、選択されたアトリビューションに対して、ソースが偽のレポートでノイズ処理されているかどうかのチェック、重複除去キーを使用した重複アトリビューションのチェック、トリガーがソースのレポート ウィンドウ内に収まっているかどうかのチェック、レート制限のチェックなど、より多くのチェックを行います。
  • レポートの生成: すべてのチェックに合格すると、デバイスはアトリビューション レポートを生成し、レポート オリジンのエンドポイントに送信するようスケジュールします。

次のステップ