將您網站的AAM實作從Client-SideDIL移轉至Server-Side Forwarding

如果您同時擁有Adobe Audience Manager(AAM)和Adobe Analytics,而且您目前正使用「DIL」(Data Integration Library)程式碼將點擊從頁面傳送AAM至頁面,並且從頁面傳送點擊至Adobe Analytics,則本教學課程適用於您。 由於您同時擁有這兩種解決方案,而且這兩種解決方案都屬於Adobe Experience Cloud,因此您有機會遵循開啟「Server-Side Forwarding (SSF)」的最佳實務,這可讓Analytics資料收集伺服器即時將網站分析資料轉送至Audience Manager,而不需讓client-side程式碼從頁面傳送額外點擊至AAM。 本教程將引導您完成將交換機從舊的"Client-Side DIL"實現轉換到較新的"Server-Side forwarding"方法的步驟。

Client-Side (DIL)與 Server-Side

在比較和比較這兩種將Adobe Analytics資料匯入的方AAM法時,首先可能有助於視覺化下列影像的差異:

從用戶端到伺服器端

Client-side DIL實作

如果您使用此方法將Adobe Analytics資料匯入AAM,表示您的網頁有兩個點擊:一個會前往Analytics,一個會前往AAM(複製網頁上的Analytics資料後)。 Segments 會從AAM頁面傳回,可用於個人化等。這被視為「舊版」實作,不再建議使用。

除了未遵循最佳實務外,使用此方法的缺點包括:

  • 來自頁面的兩次點擊,而非僅一次
  • Server-Side Forwarding 需要即時共用觀眾AAM,因此實 Analytics施不 Client-side 允許此功能(以及未來可能的其他功能)

建議您移至Server-Side Forwarding實作方AAM法。

Server-Side Forwarding 實施

如上圖所示,點擊來自網頁至Adobe Analytics。 Analytics 然後即時將資料轉AAM送至,並評估訪客AAM,就像點擊是直接來自頁面一樣。 traits segments

Segments 會在相同的即時點擊中傳回, Analytics將回應轉送至網頁以進行個人化等。

移至伺服器端轉送不會造成時間上的不便。 我們強烈建議任何同時擁有Audience Manager和Analytics的人都使用此實施方法。

您有兩個主要任務

這個網頁上有很多資訊,當然,這都很重要。 但是,可歸結為您需要執行的兩項主要工作:

  1. 將代碼從Client-SideDIL代碼更改為Server-Side Forwarding代碼
  2. 在Analytics Admin Console中翻動交換機以啟動資料的實際轉發(每report suite)

如果跳過其中任一步驟,SSF將無法正常工作。 步驟和其他資料已新增至本檔案,以協助您正確執行這兩個步驟以進行設定。

實施選項

當您從client-side移至server-side時,您要執行的其中一項工作是將程式碼變更為新的Server-Side Forwarding程式碼。 這是使用下列其中一個選項來完成:

  • Adobe Experience Platform Launch-我們建議的Web屬性實作選項。 您將會看到,這是一項非常簡單的工作,因為Launch已為您完成了所有艱難的工作。
  • 在頁面上——如果您尚未(尚未)使用Adobe啟動,您也可以將新的SSF代碼直接放入appMeasurement.js檔案的doPlugins函式中
  • 其他標籤管理器——這些標籤可以視為與上一個(在頁面上)選項一樣,因為您仍會將SSF代碼放在doPlugins中,而其他標籤管理器則儲存AppMeasurement代碼

我們將在「更新程式碼」區段中檢視以下各項。

實施步驟

步驟0:先決條件:Experience CloudID服務(ECID)

移至Server-Side Forwarding的主要先決條件是實作Experience CloudID服務。 如果您使用Experience Platform Launch,這最容易完成,在此情況下,您只需安裝ECID擴充功能,就可完成其他作業。

如果您使用非AdobeTMS或完全沒有TMS,請實作ECID以在​之前執行​任何其他Adobe解決方案。 如需詳細資訊,請參閱ECID檔案。 唯一的先決條件是有關程式碼版本,因此,只要在下列步驟中套用最新版本的程式碼,您就沒問題。

注意

在實施之前,請閱讀本整份檔案。 下方的「計時」一節包含有關您應實作每件作品的​重要資訊,包括ECID(如果尚未實作)。

步驟1:從DIL代碼記錄當前使用的選項

當您準備從Client-SideDIL程式碼移至Server-Side Forwarding時,第一步就是識別您使用DIL程式碼所做的一切,包括自訂設定和傳送至的資料AAM。 需要注意和考慮的事項包括:

  • 使用siteCatalyst.initDIL模組的一般Analytics變數——您不必擔心這個變數,因為其工作只是傳送一般的Analytics變數,而且只要啟用SSF即可。
  • 合作夥伴子域——在DIL.create函式中,記下partner參數。 這稱為「合作夥伴子網域」,有時稱為「合作夥伴ID」,當您放置新的SSF代碼時,將會需要它。
  • Visitor Service Namespace -也稱為「Org ID」或「IMS Org ID」,當您設定新的SSF代碼時,也需要這個選項。記下來。
  • containerNSID、uuidCookie和其他進階選項——記下您使用的任何其他進階選項,以便您也能在SSF程式碼中設定這些選項。
  • 其他頁面變數——如果其他變數是從頁面傳送AAM至(除了由siteCatalyst.init處理的一般Analytics變數外),您需要記下這些變數,以便透過SSF傳送(擾動程式警報:透過contextData變數)。

步驟2:更新代碼

在上述「實作選項」一節中,會針對您實作Server-Side Forwarding的方式/位置提供多個選項。 為了讓本節有效,我們必須將其分為以下幾節(其中兩節合併)。 請至本節最能說明您需求的方法。

Adobe Experience Platform Launch

觀看以下影片,瞭解如何將實作選項從Client-SideDIL程式碼移入Server-Side ForwardingExperience Platform Launch。

"On the Page"或Non-Adobe Tag Manager

觀看以下影片,瞭解如何將實作選項從Client-SideDIL程式碼移至AppMeasurement程式碼中的Server-Side Forwarding,這些選項位於檔案中或非Adobe標籤管理系統中。

步驟3:啟用轉發(每Report Suite)

在本教學課程中,我們一直致力於將程式碼從Client-Side DIL程式碼切換至Server-Side Forwarding。 這沒關係,因為那是比較難的部分。 雖然您會看到本節非常簡單,但與更新程式碼一樣重要。 在此影片中,您將瞭解如何翻轉開關,以啟用從Analytics將資料實際轉送至Audience Manager。

注意: 如影片中所述,請記住,在Experience Cloud後端完全啟用轉送功能需要4小時。

計時

提醒您,從Client-Side DIL移至Server-Side Forwarding有兩個主要工作:

  1. 更新程式碼
  2. 在Analytics Admin Console中翻轉交換機

但問題是,你先做哪一個? 重要嗎? 好,抱歉,有兩個問題。 但答案是……它取決於,是的,它​可以。 這樣很模糊,又如何? 讓我們來劃分。 但首先,如果您是擁有大量網站的大型組織,還會出現另一個問題:我必須一次做所有事嗎? 那個比較容易。 不。 你可以一件件地做,差不多。😃

深入探討

時間和順序問題的原因在於轉發實際如何運作,這可概括為以下幾個技術事實:

  • 如果您已實作Experience CloudID服務(ECID),而Analytics Admin Console ("the switch")中的開關已開啟,資料會從Analytics轉送至AAM,即使您尚未更新程式碼亦然。
  • 如果沒有實作ECID,即使您已開啟切換器,而且有SSF代碼,資料也不會轉送。
  • SSF代碼(無論在Launch中還是在頁面上)確實會處理響應,當然,完成遷移是必需的。
  • 請記住,SSF交換機由Report Suite啟用,但代碼由Launch中的屬性處理,或由AppMeasurement檔案處理(如果您不使用Launch)

最佳實務

根據這些技術細節,以下是有關「何時該做什麼」時機的建議:

如果您尚未實作ECID

  1. 針對要為SSF啟用的每個report suite,在Analytics中翻轉交換機

    1. 轉送尚未開始,因為您沒有ECID
  2. 請依據網站將程式碼從Client-Side DIL更新為SSF(此程式碼可能位於Launch中,或在頁面上,如上節所述)

    1. 轉送功能現在會流動(如您已新增ECID),您也應該收到對Analytics信標的正確JSON回應(如需詳細資訊,請參閱下方的驗證與疑難排解一節)

如果您已實作ECID

  1. 準備並計畫,以便您準備好將代碼從DIL更新為將為SSF啟用的SSF PER report suite :

    1. 在Analytics中翻轉交換機以啟用SSF

      1. 轉發將啟動,因為您已啟用ECID
    2. 盡快將代碼從Client-Side DIL更新為SSF(此代碼可能位於Launch或頁面上,如上節所述)

      1. 您應該會收到對Analytics信標的正確JSON回應(如需詳細資訊,請參閱下方的驗證與疑難排解一節)

注意1: 請務必盡可能地將這兩個步驟彼此接近,因為在上述步驟1和2之間,您將會有重複的資料進AAM入。換言之,SSF將開始從Analytics傳送資料至AAM,而且由於DIL程式碼仍在頁面上,因此也會有點擊從頁面直接傳入頁面AAM,因此資料倍增。 一旦您將代碼從DIL更新到SSF,此問題就會得到緩解。

注2:如 果您寧願在資料上稍微有差異,也不願在資料上稍微重複一下,您可以切換上述步驟1和2的順序。將代碼從DIL移動到SSF將停止資料流進入,AAM直到您能夠開啟交換機以開啟report suite的SSF。 通常,客戶寧願將資料加倍一小部分,也不要錯過讓訪客進入traits和segments的機會。

有多個站點和Report Suites時的遷移時間

本主題在前幾節中簡要介紹,主要策略可概括如下:

一次遷移一個站點/report suite(或一組站點/report suites)。

不過,這可能會因為幾個可能的情況而變得有些棘手:

  • 您的網站包含數個不同的report suites
  • 您有一個report suite,其中包含數個網站(例如全域report suite)
  • 您使用一個Launch屬性來覆蓋數個網站
  • 您有不同的開發團隊,負責不同的網站

因為有了這些項目,它會變得有些複雜。 我能建議的最好事情是:

  • 請花點時間,根據上述說明制定移轉至SSF的策略
  • 根據Launch(或單個AppMeasurement檔案)中的單個屬性通常映射到1或2個不同report suites的事實,您可能可以逐個制定適用於這些不同組的計畫,將企業更新為SSF
  • 如果您正在與Adobe咨詢合作,請與他們討論有關遷移計畫的問題,以便他們能夠根據需要提供幫助

驗證和疑難排解

驗證Server-Side Forwarding是否已啟動並正在執行的主要方式,是查看您對應用程式中任何Adobe Analytics點擊的回應。

如果您未從Analytics將資料server-side forwarding從移至Audience Manager,則對Analytics信標(除2x2像素外)沒有任何回應。 不過,如果您正在執行SSF,則有些項目可在Analytics請求和回應中驗證,讓您知道Analytics正在與Audience Manager正確通訊、轉送點擊並取得回應。

警告: 小心錯誤的「成功」 —— 如果有回應,而且一切似乎都正常運作,請確定回應中包含「內容」物件。如果您不這麼做,您可能會看到訊息顯示"status":“SUCCESS”。 雖然這聽起來很瘋狂,但這實際上證明它無法正常運作。 如果您看到這一點,表示您已完成Launch或AppMeasurement中的程式碼更新,但Analytics Admin Console中的轉送尚未完成。 在這種情況下,您需要驗證是否已在Analytics Admin Console中為report suite啟用SSF。 如果您已經有,而且還沒有4小時,請耐心等待,因為在後端進行所有必要的變更可能需要這麼長時間。

假成功

有關Server-Side Forwarding的更多資訊,請參閱檔案

本頁內容