具有Adobe廣告的廣告商 — 僅Adobe Analytics整合
廣告商 Analytics for Advertising 通過Adobe廣告和Adobe Analytics跟蹤付費廣告。 當您通過多個系統跟蹤媒體、活動和渠道時,來自不同系統的相同資料集很少完全匹配。 本文檔說明您如何期望通過Adobe廣告傳播的媒體與跟蹤媒體的不同系統中的資料進行比較 Analytics。
本文檔重點介紹Adobe廣告和分析,但許多關鍵點也可以轉移到其他跟蹤解決方案。
的 Analytics for Advertising 整合使用兩個變數(eVars或rVars [保留的eVars]\)捕獲 EF ID和AMO ID。 這些變數配置有單個回望窗口(將點擊檢查和查看檢查被歸屬的時間)和一個屬性模型。 除非另有指定,否則將配置這些變數以匹配Adobe廣告中預設的廣告商級按一下回望窗口和屬性模型。
但是,在分析(通過eVars)和Adobe廣告中,回望窗口和屬性模型都可配置。 此外,在Adobe廣告中,屬性模型不僅可在廣告商級別(用於投標優化)配置,而且可在單個資料視圖和報告(僅用於報告目的)內配置。 例如,組織可能更喜歡使用均勻分配屬性模型進行優化,但是對廣告或廣告中的報告使用最後DSP觸摸屬性 Advertising Search, Social, & Commerce。 更改屬性模型會更改屬性轉換的數量。
如果在一個產品中修改了報告回望窗口或屬性模型,而在另一個產品中修改了,則來自每個系統的相同報告將顯示不同的資料:
不同回望窗口導致差異的示例:
假設「Adobe廣告」有60天的按一下回望窗口, Analytics 有30天的回望窗口。 假設一個用戶通過Adobe廣告追蹤的廣告來到網站,離開,然後在第45天返回並轉換。 Adobe廣告將將轉換屬於初始訪問,因為轉換發生在60天回望窗口內。 Analytics但是,無法將轉換屬性化為初始訪問,因為轉換發生在30天回望窗口過期之後。 在此示例中,Adobe廣告報告的轉換次數比 Analytics 會的。
不同屬性模型導致差異的示例:
假設用戶在轉換前與三個不同的Adobe廣告進行交互,並將收入作為轉換類型。 如果Adobe廣告報告使用偶數分佈模型進行分配,則它將在所有廣告中均勻地分配收入。 如果 Analytics 然而,使用最後一個觸摸屬性模型,則將收益歸結於最後一個廣告。 在下例中,Adobe廣告將30美元收入中的10美元歸屬於三個廣告中的每個,而 Analytics 將所有30 USD的收入屬性為用戶看到的最後一個廣告。 當您比較來自Adobe廣告和 Analytics你可以看到不同歸因的影響。
最佳做法是在Adobe廣告和 Analytics。 根據需要與您的Adobe帳戶團隊協作,以確定當前設定並保持配置同步。
這些相同的概念適用於使用不同回望窗口或屬性模型的任何其它類似通道。
在Adobe廣告中,屬性基於點擊和印象,您可以配置不同的點擊和印象回望窗口。 在 Analytics但是,屬性是基於點擊瀏覽和視圖瀏覽的,並且您沒有選擇為點擊瀏覽和視圖瀏覽設定不同的屬性窗口;在初始站點訪問時開始跟蹤每個站點。 在進行查看之前的同一天或多天可能會產生一種印象,這可能會影響每個系統中屬性窗口的開始位置。
通常,大多數直觀轉換發生得足夠快,以至於兩個系統都屬於信用。 但是,某些轉換可能發生在Adobe廣告印象回望窗口之外,但發生在 Analytics 後視窗;此轉換歸因於 Analytics 但Adobe廣告的印象卻沒有。
在以下示例中,假設訪問者在第1天收到廣告,在第2天執行瀏覽訪問(即,訪問廣告登錄頁而不先按一下廣告),然後在第45天轉換。 在這種情況下,Adobe廣告將從第1天到第14天(使用14天的回望功能)跟蹤用戶, Analytics 將從第2天到第61天(使用60天的回顧)跟蹤用戶,第45天的轉換將歸因於廣告 Analytics 但不是Adobe廣告。
出現差異的另一個原因是,在Adobe廣告中,您可以指定通過視圖轉換的自定義 透視權重 與基於按一下的轉換所屬的權重相關。 預設的「查看」權重為40%,這意味著「查看」轉換被計為基於按一下的轉換值的40%。 Analytics 不提供視圖轉換的這種加權。 例如,一個100美元的收入訂單 Analytics 如果您使用預設的查看權重,則在Adobe廣告中將折扣為40美元。
在比較Adobe廣告和 Analytics 報告。
Adobe廣告歸因 | Analytics 歸因 | eVar/風險分配 |
---|---|---|
Last Event | Last Touch | Most Recent |
First Event | First Touch | Original Value |
Weight First Event More | n/a | n/a |
Even Distribution | Linear | Linear 不要使用* |
Weight Last Event More | n/a | n/a |
U-Shaped | U-Shaped | n/a |
n/a | J-Shaped | n/a |
n/a | Inverse-J | n/a |
n/a | Custom | n/a |
n/a | Participation | n/a |
n/a | Algorithmic | n/a |
對於線性分配, Analytics 將成功事件在單個訪問中的所有eVar值中均等地屬性,因此使用「訪問」eVar到期時的線性分配。 但是,對廣告來說,使用線性屬性會導致分配不是真正的線性,並導致報告不理想。 例如,如果訪問者在進行三次單獨訪問之前與三個廣告進行交互,則只有上次訪問時看到的廣告被歸因於轉換,而不是全部三個廣告。
此外,將轉換分配切換到或從「線性」防止顯示歷史資料,這可能導致報告中資料陳述錯誤。 例如,線性分配可能會將收入劃分為多個不同的eVar值。 如果將分配更改為「最近」,則100%的收入將與最近的單個值相關聯。 這種關聯會導致您得出錯誤的結論。
為了防止混亂, Analytics 使歷史資料在報告介面中不可用。 如果將eVar更改回初始分配設定,則可以查看歷史資料,儘管您不應僅僅為了訪問歷史資料而更改eVar分配設定。 Adobe建議在要為已記錄的資料應用新分配設定時使用新eVar,而不是更改已具有大量歷史資料的eVar的分配設定。
請參閱 Analytics 歸屬模型及其定義 https://experienceleague.adobe.com/docs/analytics-platform/using/cja-workspace/attribution/models.html?lang=zh-Hant?lang=zh-Hant。
如果您登錄 Search, Social, & Commerce,您可以找到
在「Adobe廣告」中,您可以按關聯的按一下日期/事件日期(按一下或印象事件的日期)或按事務處理日期(轉換日期)報告轉換資料。 中不存在按一下/事件日期報告的概念 Analytics;跟蹤的所有轉換 Analytics 按交易記錄日期報告。 因此,相同轉換可於Adobe廣告及 Analytics。 例如,考慮在1月1日按一下廣告並在1月5日轉換廣告的用戶。 如果您在Adobe廣告中按事件日期查看轉換資料,則轉換將在1月1日按一下時報告。 在 Analytics1月5日將報告相同的轉換。
Analytics Marketing Channels 報告 允許您配置規則以根據擊中資訊的不同方面來識別不同的市場營銷渠道。 您可以跟蹤Adobe廣告跟蹤頻道(Display Click Through。 Display View Through, Paid Search) Marketing Channels 使用 ef_id
查詢字串參數以標識通道。 然而,儘管 Marketing Channels 報告可以跟蹤Adobe廣告渠道,資料可能與Adobe廣告報告不匹配,原因有幾。 有關詳細資訊,請參閱以下各節。
以下核心概念也適用於任何涉及未在Adobe廣告中跟蹤的市場活動的多渠道跟蹤,如 campaign
變數(也稱為「跟蹤代碼」Dimension或「eVar0」)和自定義eVar跟蹤。
最多 Marketing Channels 報告配置為 Last Touch 屬性,為其分配100%的轉換值,最後檢測到的營銷渠道。 使用不同的屬性模型 Marketing Channels 報告和Adobe廣告報告將導致屬性轉換中的差異。
用於 Marketing Channels 可以定制。 在「Adobe廣告」中,按一下回望窗口是可配置的,但固定60天窗口是常見的。 如果這兩種產品使用不同的回望窗口,則您可能會發現資料差異。
Adobe廣告報告僅捕獲通過Adobe廣告販運的付費媒體(付費搜索 Advertising Search, Social, & Commerce 廣告和顯示),DSP而 Marketing Channels 報告可以跟蹤所有數字通道。 這可能導致轉換所屬的渠道出現差異。
例如,付費搜索和自然搜索通道往往具有共生關係,每個通道互相協助。 的 Marketing Channels report將將某些轉換屬於自然搜索,而Adobe廣告不會這樣做,因為它不跟蹤自然搜索。
再考慮一下查看顯示廣告、按一下付費搜索廣告、在電子郵件內按一下,然後下30美元訂單的客戶。 即使Adobe廣告 Marketing Channels 兩者都使用最後一個觸摸歸屬模型,轉換的屬性仍然不同。 Adobe廣告無法訪問 Email channel,因此它將對轉換進行付費搜索。 Marketing Channels但是,它可以進入所有三個渠道,因此它會 Email 的子菜單。
有關度量可能不同的原因的詳細說明,請參見「渠道資料為何會因Adobe廣告和 Marketing Channels"
的 舊 Paid Search Detection 特徵 Analytics 允許公司 定義跟蹤付費和有機搜索流量的規則 指定的搜索引擎。 的 Paid Search Detection 規則使用查詢字串和引用域來標識付費和自然搜索流量。 的 Paid Search Detection 報告是 查找方法 報告,在指定事件(如Cart Checkout)發生或訪問結束時過期。
以下是建立 Paid Search Detection 規則集:
結果 Paid Search Detection 報告包括 Paid Search Engine。 Paid Search Keywords。 Natural Search Engine, Natural Search Keywords 報告。
請注意以下兩個限制,其中的資料 Paid Search Detection 報告:
的 Paid Search Keywords 和 Natural Search Keywords 報告顯示由引用URL標識的搜索查詢,而不是用戶出價的關鍵字。 Adobe廣告 Analytics 報告顯示實際關鍵字,因此不要期望它們與 Paid Search Detection 關鍵字報告。
當 Paid Search Detection 最初建立了特徵,原始搜索查詢(用戶輸入到搜索引擎搜索欄中的字串)通過參考URL更容易地提供給廣告商。 如今,搜索引擎在很大程度上模糊了搜索查詢, Paid Search Detection 關鍵字報告的值有限,因為大多數查詢資料都屬於「未指定」。
與 Analytics for Advertising廣告商仍然可以跟蹤付費關鍵字 Analytics。 所述參考域通知引擎報告哪個搜索引擎驅動了所述業務。 由於廣告商特定帳戶資訊不與參考域相關,所以所有通信都列在搜索引擎下。 在同一搜索引擎中具有多個帳戶的廣告主應參考Adobe廣告或 Analytics 針對特定於帳戶的報告進行報告。
的 Paid Search Detection 報告允許您識別自然搜索通信 Analytics Marketing Channels 報告。 將付費搜索流量與自然搜索流量分開,是理解自然搜索給整個營銷生態系統帶來的價值的絕佳途徑。
對於您的整合,您應驗證您的點擊資料,以確保站點上的所有頁面都正確跟蹤點擊瀏覽。
在 Analytics,驗證的最簡單方法之一 Analytics for Advertising 跟蹤是使用「按一下到AMO ID Instances」計算度量將按一下與實例進行比較,該度量按如下計算:
Clicks to AMO ID Instances = (AMO ID Instances / AMO Clicks)
AMO ID Instances 表示AMO ID的次數(s_kwcid
參數)。 每次點擊廣告, s_kwcid
參數將添加到登錄頁URL。 數 AMO ID Instances因此,它與點擊次數類似,可以根據實際廣告點擊進行驗證。 我們通常會看到80%的匹配率 Search, Social, & Commerce 和30%的匹配率 DSP 流量(過濾後僅包括按一下 AMO ID Instances)。 搜索和顯示之間的期望值差異可以通過預期的通信行為來解釋。 搜索捕獲目的,因此用戶通常打算按一下其查詢中的搜索結果。 但是,看到顯示或線上視頻廣告的用戶更有可能無意中點擊該廣告,然後從站點退出,或放棄在跟蹤頁面活動之前載入的新窗口。
在「Adobe廣告」報告中,您同樣可以使用「 」將按一下與實例進行比較ef_id_instances"度量而不是 AMO ID Instances:
Clicks to [EF ID Instances = (ef_id_instances / Clicks)
雖然您應該期望AMO ID和EF ID之間的匹配率較高,但不要期望100%奇偶校驗,因為AMO ID和EF ID從根本上跟蹤不同的資料,而這種差異可能導致總資料的細微差異 AMO ID Instances 和 EF ID Instances。 如果總 AMO ID Instances 在 Analytics 不同 EF ID Instances 但是,在Adobe廣告中,比例超過1%,請聯繫您的Adobe客戶團隊以獲得幫助。
有關AMO ID和EF ID的詳細資訊,請參見 Adobe分析使用的廣告ID。
下面是一個工作區的示例,用於跟蹤對實例的按一下。
的 AMO ID (s_kwcid查詢字串參數)用於報告 Analytics的 EF ID 用於Adobe廣告中的報告。 因為它們是不同的值,所以可能有一個值被損壞或未添加到登錄頁。
例如,假設我們有以下登錄頁:
www.adobe.com/?ef_id=test_ef_id&s_kwcid=test_amo_id
其中EF ID為"test_ef_id
"和AMO ID為"test_amo_id
"
如果發生站點端重定向,則URL可能會以下方式結束:
www.adobe.com/?ef_id=test_ef_id&s_kwcid=test_amo_id#redirectAnchorTag
其中EF ID為"test_ef_id
"和AMO ID為"test_amo_id#redirectAnchorTag
"
在本示例中,添加錨點標籤會向AMO ID添加意外字元,導致Analytics無法識別的值。 此AMO ID不會被分類,與其關聯的轉換將屬於「」unspecified"或"none" Analytics 報告。
幸運的是,儘管這類問題很常見,但通常不會導致高比例的差異。 但是,如果您注意到中的AMO ID之間存在很大差異 Analytics 和Adobe廣告中的EF ID ,請聯繫您的Adobe帳戶團隊以獲得幫助。
它們看起來很類似,但點擊和訪問代表著不同的資料:
按一下: DSP 或者,當訪問者點擊發佈者網站上的廣告時,搜索引擎會記錄點擊。
訪問: Analytics 定義 訪問 作為用戶的一系列頁面視圖,根據以下幾個條件之一結束,例如30分鐘的不活動。
從定義上講,點擊可能導致多次訪問。
請考慮以下示例:用戶1和用戶2都通過按一下Adobe廣告訪問站點。 用戶1查看四頁,然後離開一天,因此初始按一下將導致一次訪問。 用戶2查看兩頁,離開45分鐘午餐,返回,再查看兩頁,然後離開;在這種情況下,初始按一下會導致兩次訪問。
點擊和點通是兩種不同的度量:
按一下: DSP 或者,當訪問者點擊發佈者網站上的廣告時,搜索引擎會記錄點擊。
點通: Analytics 當訪問者到達目標網站、登錄頁載入和 Analytics 頁面底部的請求將資料發送到 Analytics。
點擊和點擊免提可能因廣告的意外點擊而有很大不同。 我們注意到,顯示廣告上的大多數點擊都是偶然的點擊,這些偶然的訪問者在登錄頁載入之前點擊了「後退」按鈕,因此 Analytics 無法記錄點擊。 對於意外點擊的可能性更大的廣告尤其如此,例如移動廣告、視頻廣告和廣告,這些廣告填充了螢幕,在用戶查看頁面之前必須關閉。
在移動設備上載入的站點也不太可能導致點擊穿越,因為頻寬較低或可用的處理能力較低,導致載入登錄頁的時間更長。 50%到70%的點擊率不會導致點擊免檢的情況並不少見。 在移動環境中,差異可能高達90%,因為瀏覽器速度較慢,而且用戶在瀏覽頁面或嘗試關閉廣告時意外點擊廣告的可能性較高。
點擊資料也可以記錄在無法使用當前跟蹤機制(例如進入或從移動應用的點擊)記錄點擊瀏覽的環境中,或廣告商只部署了一種跟蹤方法(例如,使用通過查看的JavaScript方法,阻止第三方cookie的瀏覽器將跟蹤點擊,但不會跟蹤點擊瀏覽)。 Adobe建議同時部署點擊URL跟蹤和通過JavaScript查看跟蹤方法的一個關鍵原因是最大化可跟蹤點擊瀏覽的覆蓋範圍。
Adobe廣告為分析提供 廣告特定的流量指標和相關維度 DSP 和 Search, Social, & Commerce。 Adobe廣告提供的度量僅適用於指定的Adobe廣告維,並且資料對於中的其他維不可用 Analytics。
例如,如果您查看 AMO Clicks 和 AMO Cost 按帳戶列出的度量(即Adobe廣告維),您將看到總數 AMO Clicks 和 AMO Cost 按帳戶。
但是,如果您查看 AMO Clicks 和 AMO Cost 按Adobe廣告不提供資料的頁維(如頁)列出的度量,然後 AMO Clicks 和 AMO Cost 每頁將為零(0)。
因為你不能 AMO Clicks 使用現場維度時,您可能希望找到與按一下相同的內容。 你可能會忍不住想用「訪問」來代替「訪問」,但它們不是最佳選擇,因為每個訪問者可能有多次訪問。 (請參閱「點擊與訪問的區別" 相反,我們建議使用 AMO ID Instances,即捕獲AMO ID的次數。 同時 AMO ID Instances 不匹配 AMO Clicks 確切地說,它們是測量站點上點擊流量的最佳選項。 有關詳細資訊,請參閱「」資料驗證 Analytics for Advertising"