歸因範圍可讓 API 呼叫端在來源和觸發條件登錄期間指定字串清單，供歸因前篩選使用。這項功能可進行更精細的篩選，提高 API 效率並提供更多彈性。舉例來說，這項功能可讓您在同一個網站上，清楚追蹤不同的廣告主。此外，您也能在單一廣告橫幅中追蹤多個廣告活動或產品。
歸因範圍是選用欄位，可在來源和觸發條件登錄期間設定。在歸因期間，只有歸因範圍值包含至少一個觸發條件歸因範圍值的來源，才會納入歸因考量。如果觸發條件中未指定範圍，系統會將所有來源納入考量。如要繼續操作，請先熟悉 Attribution Reporting API 和高層級篩選器。
來源登錄期間
標頭 Attribution-Reporting-Register-Source 中新增了選用參數 attribution_scopes，其中包含兩個必要參數：值和限制；以及一個選用參數：max_event_states。
- 限制：代表來源報表來源可為每個目的地提供的非重複範圍總數。系統會刪除任何現有已註冊的來源，這些來源的報表來源和目的地相同，但限制較小。
- 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 的來源。
觸發條件登錄範例
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 會選取歸因範圍值與觸發條件登錄值相交的來源，以供歸因。系統會繼續進行其餘歸因流程，並比對來源登錄。在本例中，API 呼叫端會收到歸因報表，將觸發事件登錄歸因至第一個來源登錄。
歸因範圍與篩選器
歸因範圍和篩選器功能看似相似，但兩者的區別在於觸發條件註冊流程中的套用位置。歸因範圍篩選作業會在歸因前執行。也就是說，系統會根據來源的範圍是否與觸發條件中的範圍相交，減少具有相同目的地網站和報表來源的未過期候選來源集區。不過，系統會在將觸發歸因於單一來源後，才套用頂層篩選器。如果來源和觸發條件篩選器沒有交集，系統就不會產生任何報表。
下圖顯示一組來源和觸發條件，這些來源和觸發條件具有相同的目的地網站和報表來源，且未過期。我們會簡要說明如何使用歸因範圍和篩選器，以及系統是否會根據可用的來源和觸發條件產生報表。
歸因前
- 來源 #1 的歸因範圍與觸發事件的
casualwear範圍不符，因此遭到篩除。即使來源在所有可用來源中優先順序最高，系統仍可能將其篩除，因為前歸因篩除作業會在檢查優先順序前執行。 - 來源 #2 也會因範圍與觸發事件不同而遭到篩除。這個來源的篩選器與觸發事件相同，但系統會在完成歸因後才套用高階篩選器。
歸因期間
- 由於來源 #3 的優先順序低於來源 #4，因此系統不會選取來源 #3 進行歸因。
- 系統會選取來源 #4，因為該來源的歸因範圍與觸發事件相符，且優先順序最高。高層級篩選器會在歸因後套用，因此歸因程序不會將其納入考量。
貼文歸因
- 由於所選來源 (來源 #4) 和觸發條件的高層級篩選器沒有交集，因此系統不會產生報表。
上一個範例不會產生報表。不過，如果完全移除第四個來源：
歸因期間
- 系統會選取來源 #3，因為該來源與觸發事件的歸因範圍有交集。
貼文歸因
- 來源 #3 的篩選條件與觸發條件中的篩選條件相交，因此不會遭到拒絕。接著，歸因程序會完成其餘的後歸因檢查，如果通過所有檢查，就會產生報表。
歸因範圍會減少歸因時考量的來源數量。接著，系統會對這個較小的來源集套用其餘歸因步驟，並產生報表。
歸因範圍在歸因流程中的位置
系統會先套用歸因範圍，再選取歸因來源。這項篩選條件的優先順序也高於頂層篩選條件和自訂報表期間篩選條件。下圖顯示簡化的整體歸因流程，歸因範圍發生在歸因和其餘歸因檢查之前。
歸因流程作業
以下是歸因流程中執行的各種作業：
- 來源登錄：使用者與廣告主網站上的廣告互動時，系統會登錄來源事件。裝置接著會將要求傳送至報表來源的端點，後者則會傳送包含來源事件資料的標頭做為回應。
- 觸發事件登錄：當廣告主的網站發生轉換時，系統會登錄觸發事件。裝置會向報表來源傳送另一項要求，後者則會傳回含有觸發事件資料的標頭。
- 來源比對：裝置會根據目的地網站、回報來源和有效期限等條件，比對來源和觸發事件。
- 檢查歸因範圍：系統會根據來源和觸發條件 attribution_scopes 值之間的交集，篩選來源。
- 歸因：如果有多個來源符合條件，裝置會選取優先順序最高的來源進行歸因。如果優先順序相同，系統會選取最近的優先順序。
- 篩選器檢查：裝置會比較來源和觸發事件篩選器，判斷兩者是否相符。如果篩選器不相符，系統就會捨棄歸因。
- 停用其他來源：如果所選來源的篩選條件相符，裝置會在來源比對階段停用相符的來源。停用的來源包括歸因範圍與觸發範圍不符的來源。
- 歸因後檢查：裝置會對所選歸因執行更多檢查，例如檢查來源是否因虛假報表而產生雜訊、使用重複資料刪除鍵檢查重複歸因、檢查觸發事件是否在來源的報表視窗內，以及檢查頻率限制。
- 產生報表：如果所有檢查都通過，裝置會產生歸因報表，並排定傳送至報表來源端點的時間。
後續步驟
- 如要進一步瞭解歸因範圍，請參閱 GitHub 上的前歸因篩選說明。
- 如要進一步瞭解篩選器，請參閱「使用篩選器定義顧客規則」。