使用Adobe Advertising ID建立Marketing Channels處理規則
僅整合Adobe Advertising-Adobe Analytics的廣告商
您可以使用Adobe Advertising ID （AMO ID和EF ID）在Adobe Analytics中設定Marketing Channels處理規則。 將Adobe Advertising ID用於您Adobe Advertising行銷活動的特定規則。 您處理規則的順序會決定所有可能的資料是否都已正確擷取。
處理規則中的AMO ID
AMO ID是主要追蹤程式碼，用於報告Analytics內的Adobe Advertising資料。 AMO ID是由Adobe管理的動態值串連，以在Analytics內提供精細報表。 它儲存在Analytics eVar或rVar維度(AMO ID)中。 AMO ID可在Analytics中設定有兩種方式：
-
點進追蹤： Adobe Advertising會在連結中設定
s_kwcid查詢字串引數，而當點進發生時，Analytics會從登陸頁面URL中挑選引數。 -
檢視追蹤（僅限DSP）： Last Event Service會在伺服器端偵測檢視，並將AMO ID傳送至Analytics。 在此情況下，URL不包含
s_kwcid引數。
AMO ID中的動態值表示所追蹤的行銷管道：
-
AMO ID中的前置字元可用來識別Marketing Channels中的最上層通道。
-
AMO ID內文中的字元短語表示更具體的行銷活動型別。
-
尾碼「vt」適用於DSP閱覽流量，可用來建立個別的點進和閱覽DSP管道。
可忽略其餘的AMO ID。
處理規則中的EF ID
AMO EF ID (EF ID)是Analytics for Advertising整合中使用的第二個追蹤程式碼。 其主要用途是追蹤並傳遞Analytics事件資料至Adobe Advertising。 每次點進或檢視發生時，系統都會產生唯一的EF ID，即使同一位訪客擁有完全相同的廣告亦然。 Analytics報表使用者介面中未使用EF ID，因為它通常會超過Analytics中每個變數限制500,000個不重複值，使其無法用於報表。 Adobe Advertising量度和中繼資料不會套用至EF ID，而只會套用至AMO ID。 Adobe Advertising中的行銷活動最佳化需要新增的追蹤粒度，因此兩個ID都是必要的。
雖然EF ID維度並未直接在Analytics報表中使用，但EF ID仍適合用於建立行銷管道。 EF ID尾碼會指出頻道（顯示或搜尋），以及造訪是由點進還是檢視所驅動。 EF ID中的分隔符號是冒號，而非AMO ID中的驚歎號。
Adobe Advertising的處理規則範例
下列範例規則集著重於廣告管道（付費搜尋、顯示ClickThrough和顯示ViewThrough）的規則。 此外也示範付費搜尋偵測的建議規則（包括該規則與免費搜尋行銷管道邏輯的互動方式）以及免費反向連結網域規則的選擇性更新。
注意：顯示區可以分成兩個管道，或根據廣告商偏好設定合併成單一管道。
範例熒幕擷圖中包含其他管道，以說明廣告管道相較於其他管道在典型實施中的建議操作順序。
付費搜尋規則
最佳作法是針對Paid Search規則納入兩個附有「Any」運運算元的條件：
-
成本/點按/曝光資料包含AMO ID，因此請包含AMO ID。 AMO ID應該以「AL！」開頭。 以正確配置點選/成本/曝光資料給Paid Search.
-
Paid Search點進次數的URL一律包含
s_kwcid查詢字串引數，因此請包含該引數，以確保在訪客導覽回登陸頁面時，能正確進行重複資料刪除。 包括「AL！」 在s_kwcid之前，以正確配置點選/成本/曝光資料給Paid Search。
請勿將管道值設為AMO ID。 請改為將名稱設為反向連結網域、搜尋引擎+關鍵字或頁面等。 （這與所有Marketing Channels相關）。
免費搜尋規則
對於Natural Search，請確定您的Paid Search偵測規則包含ef_id和s_kwcid查詢字串引數。 （通常，當Advertising Search、Social和Commerce整合到Analytics中時會自動設定此專案，但如果Analytics管理員在設定整合後變更邏輯，請驗證。）
將規則設為「符合免費搜尋偵測規則」（通常是此管道的預設設定）。
顯示點進規則#1
僅擷取點進次數，以建立「顯示」點進行銷管道。 因為點進和檢視的AMO ID相同，所以此規則會使用EF ID變數和ef_id查詢字串引數。
有時會透過URL （預設值）追蹤點進。 在其他情況下，點進是透過伺服器端的「上次事件服務」追蹤，因此URL不包含ef_id引數。 因此，規則會檢查EF ID變數或ef_id查詢字串引數結尾為":d"的條件。 使用"Any"運運算元，因為您想要為任一條件觸發此規則。
自然反向連結網域規則
（選用）最佳實務是將「是瀏覽的第一個頁面」條件與「任何」運運算元新增至標準Natural Referring Domains規則。 雖然此規則為選用，但若使用者按一下「上一步」按鈕返回登陸頁面，有助於防止自然反向連結處於邊緣案例設定。
顯示CTV瀏覽規則
若要追蹤DSP連線電視(CTV)觀看次數，請建立AMO ID結尾為"!ctv"的規則。 由於訪客未按一下廣告，瀏覽追蹤不會在URL中包含ef_id或s_kwcid，而規則只需要一個條件。
顯示瀏覽規則
若要建立「顯示ViewThrough」管道，請建立EF ID結尾為":i"的規則。 由於訪客未按一下廣告，瀏覽追蹤不會在URL中包含ef_id或s_kwcid，而規則只需要一個條件。
顯示點進規則#2
針對第二個顯示點進規則，設定AMO ID開頭為"AC！"。 此第二個規則是用來擷取直接從Adobe Advertising進入Analytics之顯示頻道的點選/成本/曝光資料。 此資料歸因於AMO ID，但不包含具有ef_id查詢字串的URL，因此這些點選不會與AMO EF ID （這是第一個「顯示ClickThrough」規則擷取的內容）連結。
Marketing Channels規則的作業順序 rule-order
-
將Paid Search 放在 Natural Search之前。 否則，付費搜尋資料可能會分配給免費搜尋。
-
將第一個 Display ClickThrough 放在 Natural Referring Domains和Natural Social之前。
-
當您使用CTV view-throughs時，請將它放在**之前Display ViewThroughs。 否則，CTV檢視將會擷取為Display ViewThroughs。
-
將Display ViewThroughs個 放在 個其他管道之後，但放在Internal和Direct之前，因為在相同的登陸事件中可能會發生檢視和非Advertising點進。 例如，訪客可能會看到Adobe Advertising廣告、獲得印象，然後透過Natural Search前往網站。
最佳實務是將其他管道（Internal和Direct除外）優先於閱覽。
-
有些廣告商可能會選擇將Display ViewThroughs優先順序設為Natural Referring Domains。 切換兩個規則的處理順序即可執行此操作。
-
秒 Display ClickThrough規則可用來擷取直接從Adobe Advertising傳入Analytics的點選/成本/曝光資料。 由於此資料只會歸因於AMO ID，因此這些點選不會與AMO EF ID連結。 如果您未設定此規則，則所有點按/成本/曝光資料都在Direct管道下，這是任何不符合Marketing Channel之資料的預設管道。 此規則必須在檢視規則之後，否則它會選取任何檢視。