Analytics和Adobe Advertising之間的預期資料差異

僅整合Adobe Advertising-Adobe Analytics的廣告商

具有Analytics for Advertising 整合的廣告商會透過Adobe Advertising和Adobe Analytics追蹤付費廣告。 透過多個系統追蹤媒體、行銷活動和管道時,來自不同系統的相同資料集很少完全相符。 本檔案說明您應如何預期透過Adobe Advertising販運的媒體資料,與Analytics內追蹤媒體之不同系統中的資料進行比較。

NOTE
本檔案著重於Adobe Advertising和分析,但許多要點也可以轉移到其他追蹤解決方案。

類似報表中的歸因差異

回顧期間和歸因模型可能不同

Analytics for Advertising整合使用兩個變數(eVars或rVars [保留的eVars]\)來擷取EF ID和AMO ID。 這些變數是透過單一回顧視窗(即點進和檢視歸因的時間)和歸因模型來設定。 除非另有指定,否則變數會設定為符合預設、廣告商層級的點按回顧視窗和Adobe Advertising中的歸因模型。

不過,回顧視窗和歸因模型可在Analytics (透過eVars)和Adobe Advertising中設定。 此外,在Adobe Advertising中,歸因模型不僅可在廣告商層級(用於競標最佳化)設定,也可在個別資料檢視和報告內設定(僅用於報告目的)。 例如,組織可能偏好使用均勻分佈歸因模型來最佳化,但對Advertising DSP或Advertising Search, Social, & Commerce中的報表使用上次接觸歸因。 變更歸因模型會變更已歸因的轉換次數。

如果在一個產品中修改了報表回顧期間或歸因模型,而在另一個產品中修改了報表回顧期間或歸因模型,則來自每個系統的相同報表會顯示不同的資料:

  • 不同回顧期間所導致的差異範例:

    假設Adobe Advertising有60天的點選回顧期間,而Analytics有30天的回顧期間。 並假設使用者透過Adobe Advertising追蹤廣告進入網站,離開,然後在第45天返回並轉換。 Adobe Advertising會將轉換歸因於初始造訪,因為轉換發生在60天回顧期間內。 但是,Analytics無法將轉換歸因於初始造訪,因為轉換發生在30天的回顧期間過期之後。 在此範例中,Adobe Advertising報告的轉換次數高於Analytics。

    歸因於Adobe Advertising但不歸因於Analytics 的轉換範例

  • 不同歸因模型造成的差異範例:

    假設使用者在轉換之前與三個不同的Adobe Advertising廣告互動,且將收入作為轉換型別。 如果Adobe Advertising報表使用平均分配模型來歸因,則會將收入平均歸因於所有廣告。 但是,如果Analytics使用上次接觸歸因模型,則會將收入歸因於最後一個廣告。 在以下範例中,Adobe Advertising會將擷取至這三個廣告的30美元收入中的平均10美元歸因於每個廣告,而Analytics會將所有30美元的收入歸因於使用者看到的最後一個廣告。 當您比較來自Adobe Advertising和Analytics的報告時,可以預期結果會因為歸因不同而有所差異。

    根據不同的歸因模型, 歸因於Adobe Advertising和Analytics的不同收入

IMPORTANT
最佳實務是在Adobe Advertising和Analytics中使用相同的回顧期間和歸因模型。 請視需要與您的Adobe帳戶團隊合作,以識別目前設定並維持設定同步。

這些相同的概念適用於使用不同回顧期間或歸因模型的任何其他類似管道。

檢視追蹤的不同回顧期間 impression-lookback

在Adobe Advertising中,歸因是以點按數和曝光數為基礎,您可以為點按數和曝光數設定不同的回顧期間。 但在Analytics中,歸因是以點進和檢視為基礎,且您無法選擇為點進和檢視設定不同的歸因期間;追蹤從初次網站造訪開始的每個專案。 曝光可能會在檢視發生的同一天或多個天前發生,而時間可能會影響每個系統中歸因視窗的開始位置。

一般而言,大部分的檢視轉換發生得足夠快,以至於兩個系統都可計入評分。 不過,某些轉換可能會發生在Adobe Advertising曝光回顧期間之外,但發生在Analytics回顧期間內;這類轉換歸因於Analytics中的檢視,但不會歸因於Adobe Advertising中的曝光。

在以下範例中,假設訪客在第1天收到廣告,在第2天執行瀏覽式造訪(也就是在沒有先前按一下廣告的情況下造訪廣告的登陸頁面),並在第45天轉換。 在此情況下,Adobe Advertising將會從1天到14天追蹤使用者(使用14天回溯),Analytics將會從2天到61天追蹤使用者(使用60天回溯),而第45天的轉換將會歸因於Analytics內的廣告,但不會歸因於Adobe Advertising內的廣告。

歸因於Analytics而非Adobe Advertising 的檢視轉換範例

不一致的其他原因在於,在Adobe Advertising中,您可以指派自訂的​ 瀏覽權數,此自訂權數與點選型轉換的歸因權數相關。 預設的檢視權重為40%,這表示檢視轉換會計為點按式轉換值的40%。 Analytics未提供此類顯示轉換的加權。 舉例來說,如果您使用預設的檢視權數,在Analytics中擷取的100美元收入訂單會在Adobe Advertising中折扣為40美元,差異為60美元。

比較Adobe Advertising與Analytics報表之間的檢視轉換時,請考量這些差異。

可用的歸因模型

Adobe Advertising歸因
Analytics歸因
eVar/rVar配置
Last Event
Last Touch
Most Recent
First Event
First Touch
Original Value
Weight First Event More
不適用
不適用
Even Distribution
Linear
Linear

不使用*
Weight Last Event More
不適用
不適用
U-Shaped
U-Shaped
不適用
不適用
J-Shaped
不適用
不適用
Inverse-J
不適用
不適用
Custom
不適用
不適用
Participation
不適用
不適用
Algorithmic
不適用
NOTE
若為線性配置,Analytics會平均分配單一造訪中所有eVar值的成功事件,因此請使用具有「造訪」的eVar到期日的線性配置。 不過,針對廣告,使用線性歸因會導致配置並非真正為線性,且產生的不太理想的報表。 例如,如果訪客在轉換至三個個別造訪之前與三個廣告互動,則只有上次造訪中看到的廣告會歸因於轉換,而非全部三個廣告。
此外,將轉換配置切換至「線性」或是從「線性」切換分配時,不會顯示歷史資料,導致報表中的資料陳述錯誤。 例如,線性配置可能會將收入分配給多個不同的eVar值。 如果您將配置變更為「最近」,則該收入的100%將與最近的單一值相關聯。 此關聯可能會導致錯誤的結論。
為避免混淆,Analytics會在報表介面中隱藏歷史資料。 如果您將eVar變更回初始配置設定,則可以檢視歷史資料,但您不應僅為了存取歷史資料而變更eVar配置設定。 Adobe建議,當您想要為已記錄的資料套用新的配置設定時,請使用新的eVar,而不是變更已具有大量歷史資料的eVar的配置設定。

https://experienceleague.adobe.com/docs/analytics-platform/using/cja-workspace/attribution/models.html?lang=zh-Hant檢視Analytics歸因模型及其定義的清單。

如果您已登入Search, Social, & Commerce,您可以找到清單

Adobe Advertising中的事件日期歸因

在Adobe Advertising中,您可以依關聯的點選日期/事件日期(點選或曝光事件的日期)或交易日期(轉換日期)來報告轉換資料。 Analytics中不存在點選/事件日期報告的概念;在Analytics中追蹤的所有轉換都會依交易日期報告。 因此,可能會以Adobe Advertising和Analytics中的不同日期報告相同的轉換。 例如,假設有一位使用者在1月1日點選廣告並在1月5日轉換。 如果您依Adobe Advertising的事件日期檢視轉換資料,則轉換會在發生點按的1月1日回報。 在Analytics中,相同的轉換在1月5日回報。

歸因於不同日期的轉換範例

Analytics Marketing Channels中的歸因

Analytics Marketing Channels 報告可讓您設定規則,以根據點選資訊的不同方面識別不同的行銷管道。 您可以使用ef_id查詢字串引數來識別管道,以將Adobe Advertising追蹤管道(Display Click Through、Display View Through和Paid Search)追蹤為Marketing Channels。 不過,即使Marketing Channels報表可以追蹤Adobe Advertising管道,資料可能因為數個原因而與Adobe Advertising報表不符。 如需詳細資訊,請參閱下列章節。

NOTE
下列核心概念也適用任何涉及Adobe Advertising中未追蹤之行銷活動的多頻道追蹤,例如campaign變數(也稱為「追蹤代碼」維度或"eVar 0")和自訂eVar追蹤。

Marketing Channels中可能有不同的歸因模型

大部分Marketing Channels報告已設定Last Touch歸因,而最後偵測到的行銷管道已為其指派100%轉換值。 對Marketing Channels報表和Adobe Advertising報表使用不同的歸因模型,會導致歸因轉換中的差異。

Marketing Channels中可能不同的回顧期間

可以自訂Marketing Channels的回顧期間。 在Adobe Advertising中,點按回顧視窗是可供設定的,但固定的60天視窗很常見。 如果這兩種產品使用不同的回顧期間,可能會出現資料不一致的情況。

Marketing Channels中的不同頻道歸因

Adobe Advertising報表只會擷取透過Adobe Advertising販運的付費媒體(針對Advertising Search, Social, & Commerce個廣告的付費搜尋,以及針對Advertising DSP廣告的顯示),而Marketing Channels報表則可以追蹤所有數位頻道。 這可能會導致歸因於轉換的管道不一致。

例如,付費搜尋和免費搜尋管道通常具有共生關係,每個管道互相協助。 Marketing Channels報告將某些轉換歸因於Adobe Advertising沒有的免費搜尋,因為它沒有追蹤免費搜尋。

也可以考慮檢視顯示廣告、點選付費搜尋廣告、點選電子郵件訊息內部,然後下單30美元的客戶。 即使Adobe Advertising和Marketing Channels都使用上次接觸歸因模型,轉換仍會分別以不同方式歸因於各個。 Adobe Advertising沒有Email管道的存取權,所以將計入轉換的付費搜尋。 但是,Marketing Channels可以存取所有三個管道,因此會將Email的轉換歸功。

Adobe Advertising與Analytics Marketing Channels 中不同的轉換歸因範例

如需量度可能有所差異的詳細解釋,請參閱"為何管道資料在Adobe Advertising和 Marketing Channels之間可能有所差異"。

Adobe Analytics Paid Search Detection中的資料差異

Analytics中的舊版 Paid Search Detection功能可讓公司定義規則,以追蹤指定搜尋引擎的付費和有機搜尋流量。 Paid Search Detection規則同時使用查詢字串和反向連結網域來識別付費和免費搜尋流量。 Paid Search Detection報告是較大的尋找方法報告群組的一部分,這些報告會在指定事件(例如購物車結帳)發生或造訪結束時過期。

以下是建立Paid Search Detection規則集的介面:

Analytics 中付費搜尋偵測規則集的範例

產生的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 Advertising和Analytics報表會顯示實際的關鍵字,因此請勿期望它們與Paid Search Detection關鍵字報表一致。

  • 當Paid Search Detection功能最初建立時,原始搜尋查詢(使用者在搜尋引擎的搜尋列中輸入的字元字串)更容易透過轉介URL提供給廣告商。 現今,搜尋引擎大多將搜尋查詢模糊化,且Paid Search Detection關鍵字報告的值有限,因為大部分查詢資料都在「未指定」下。

    透過Analytics for Advertising,廣告商仍可在Analytics中追蹤付費關鍵字。 反向連結網域會通知引擎報告哪個搜尋引擎帶動了流量。 由於廣告商特定帳戶資訊未繫結至反向連結網域,因此所有流量都會列在搜尋引擎下。 在相同搜尋引擎中有多個帳戶的廣告商,應參考Adobe Advertising或Analytics報表,以取得帳戶特定報表。

為什麼要設定Paid Search Detection?

Paid Search Detection報告可讓您識別Analytics Marketing Channels 報告中的免費搜尋流量。 區分付費搜尋流量與免費搜尋流量,是瞭解免費搜尋為完整行銷生態系統帶來價值的重要方法。

Analytics for Advertising的點進資料驗證 data-validation

針對您的整合,您應該驗證點進資料,以確保網站上的所有頁面都正確追蹤點進。

在Analytics中,驗證Analytics for Advertising追蹤的最簡單方法之一,就是使用「AMO ID例項與點按」計算量度來比較例項與點按,其計算方式如下:

AMO ID Instances to Clicks = (AMO ID Instances / Adobe Advertising Clicks)

AMO ID Instances代表在網站上追蹤AMO ID的次數。 每次點選廣告時,AMO ID (s_kwcid)引數都會新增至登陸頁面URL。 因此,AMO ID Instances的數量類似於點選次數,並可根據實際的廣告點選進行驗證。 我們通常看到Search, Social, & Commerce有85%的符合率,而DSP流量有30%的符合率(篩選為僅包含點進AMO ID Instances時)。 搜尋和顯示之間的預期差異,可以用預期的流量行為來解釋。 搜尋會擷取意圖,因此使用者通常打算從他們的查詢按一下搜尋結果。 然而,看過顯示廣告或線上視訊廣告的使用者更有可能無意中點選廣告,然後或是從網站跳出,或是捨棄在追蹤頁面活動之前載入的新視窗。

在Adobe Advertising報表中,您可以使用"EF ID Instances"量度而非AMO ID Instances,以類似方式比較例項與點按:

EF ID Instances to Clicks = (EF ID Instances / Adobe Advertising Clicks)

雖然您應該預期AMO ID與EF ID之間的符合率很高,但不要預期100%的同位檢查,因為AMO ID和EF ID基本上會追蹤不同的資料,而且此差異可能會導致總計AMO ID Instances和EF ID Instances的細微差異。 如果Analytics中的總計AMO ID Instances與Adobe Advertising中的EF ID Instances相差1%以上,請連絡您的Adobe帳戶團隊以尋求協助。

如需AMO ID與EF ID的詳細資訊,請參閱Analytics使用的Adobe AdvertisingID

疑難排解點按和執行個體之間的差異

如果EF ID Instances對點按率低於85%,請檢查下列專案:

  • 您是否遺漏了帳戶或任何子層級的點選追蹤,或者您是否擁有重複的點選追蹤(例如,帳戶和促銷活動層級)?

    在「搜尋、社交和Commerce」中,下載帳戶的大量表單以檢查追蹤URL。

    此外,在Analytics中,您可以檢視是否使用"AMO ID至EF ID"計算量度一致附加AMO ID和EF IF,其計算方式如下:

    code language-none
    AMO ID to EF ID = (AMO ID / EF ID)
    

    大於100%的值表示遺失的EF ID比AMO ID還多。

  • 登入頁面是否有載入問題,以致無法擷取AMO ID和EF ID?

  • 是否重新導向登陸頁面URL,導致AMO ID和EF ID遺失?

  • 所有登入頁面都使用設定的報表套裝嗎?

NOTE
理論上,一個例項有可能有多個點按。 請務必檢查不同裝置(例如桌上型電腦、行動裝置和平板電腦)上的點選次數。

比較Analytics for Advertising中的資料集與Adobe Advertising中的資料集

AMO ID (s_kwcid查詢字串引數)是用於Analytics中的報告,而EF ID (ef_id查詢字串引數)是用於Adobe Advertising中的報告。 由於這些值是不同的值,因此一個值可能會損毀或未新增至登陸頁面。

例如,假設我們有下列登陸頁面:

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不會進行分類,在Analytics個報表中,與其相關的轉換會落在"unspecified"或"none"之下。

幸運的是,雖然這類問題很常見,但通常不會造成高比例的差異。 但是,如果您發現Analytics中的AMO ID與Adobe Advertising中的EF ID之間有大幅差異,請聯絡您的Adobe帳戶團隊以尋求協助。

其他量度考量事項

點按與造訪之間的差異 clicks-vs-visits

兩者看似類似,但點按和造訪代表不同的資料:

  • 點按: DSP或搜尋引擎在訪客點按發佈者網站上的廣告時記錄點按。

  • 造訪: Analytics會將造訪定義為使用者的一系列頁面檢視,並根據數個條件之一結束,例如30分鐘未活動。

顧名思義,點選可能導致多次造訪。

考量以下範例:使用者1和使用者2都可以透過按一下Adobe Advertising廣告來存取網站。 使用者1檢視了四個頁面,然後離開一天了,所以最初的點按會導致一次造訪。 使用者2檢視兩個頁面,離開進行45分鐘的午餐,返回,再檢視兩個頁面,然後離開;在這種情況下,初始點按導致兩次造訪。

點按與造訪之間差異的範例

點按與點進之間的差異

點按和點進是兩個不同的量度:

  • 點按: DSP或搜尋引擎在訪客點按發佈者網站上的廣告時記錄點按。

  • 點進次數: Analytics在訪客登陸目的地網站時記錄點進,登陸頁面載入,且頁面底部的Analytics請求將資料傳送到Analytics。

點按和點進次數可能會因為意外廣告點按而有很大的差異。 我們觀察到顯示廣告上的大部分點按都是意外點按,且這些意外訪客在登陸頁面載入前點選了「上一步」按鈕,因此Analytics無法記錄點進。 這尤其適用於最有可能意外點選的廣告,例如行動廣告、視訊廣告和填滿畫面的廣告,且必須在使用者檢視頁面之前關閉。

由於頻寬或可用的處理能力較低,在行動裝置上載入的網站也不太可能導致點進,導致載入登陸頁面所需的時間較長。 50-70%的點按不會產生點進次數,這種情況很常見。 在行動環境中,差異可能高達90%,這是由於瀏覽器速度較慢,以及使用者在捲動頁面或嘗試關閉廣告時意外點按廣告的可能性較高。

點按資料也可能會記錄於無法以目前追蹤機制記錄點進的環境中(例如進入或離開行動應用程式的點按),或廣告商僅針對其部署了一種追蹤方法(例如使用閱覽JavaScript方法,即封鎖第三方Cookie追蹤點按但不追蹤點進的瀏覽器)。 Adobe建議同時部署點選URL追蹤和閱覽JavaScript追蹤方法的一個主要原因,就是為了將可追蹤點進的涵蓋範圍最大化。

對非Adobe AdvertisingDimension使用Adobe Advertising流量量度

Adobe Advertising為Analytics提供廣告專用流量量度以及來自 DSP 和 Search, Social, & Commerce的相關維度。 Adobe Advertising提供的量度僅適用於指定的Adobe Advertising維度,而且資料不適用於Analytics中的其他維度。

例如,如果您依帳戶檢視Adobe Advertising Clicks和Adobe Advertising Cost量度(這是Adobe Advertising維度),則帳戶會顯示總計Adobe Advertising Clicks和Adobe Advertising Cost。

使用Adobe Advertising維度的報表中Adobe Advertising量度的範例

不過,如果您依頁面上的維度(例如頁面)檢視Adobe Advertising Clicks和Adobe Advertising Cost量度(其Adobe Advertising未提供資料),則每個頁面的Adobe Advertising Clicks和Adobe Advertising Cost均為零(0)。

使用不支援之維度的報表中Adobe Advertising量度的範例

使用AMO ID Instances代替具有非Adobe AdvertisingDimension的點按

由於您無法將AMO Clicks與網站上的維度搭配使用,因此您可能想要找到等同於點按的維度。 您可能會以造訪次數來替代,但這並非最佳選項,因為每位訪客可能會有多次造訪。 (請參閱"點按與造訪之間的差異"。 我們建議改用AMO ID Instances,這是擷取AMO ID的次數。 雖然AMO ID Instances與AMO Clicks不完全相符,但這是測量網站點按流量的最佳選項。 如需詳細資訊,請參閱針對 Analytics for Advertising的點進資料驗證。

不支援的維度 的範例AMO ID Instances而非Adobe Advertising Clicks

recommendation-more-help
fbbdcc36-f208-41e5-b715-a077abaec5c3