考慮將使用者端廠商標籤移動到事件轉送

考慮將使用者端廠商標籤移出瀏覽器和裝置，並移至伺服器有幾個吸引人的理由。 在本文中，我們將討論如何評估使用者端廠商標籤以潛在地將其移動到事件轉送屬性。

只有當您考慮移除使用者端廠商標籤，並在事件轉送屬性中將其取代為伺服器端資料發佈時，才需要執行這項評估。 本文假設您熟悉資料彙集和事件轉送的基本知識。

瀏覽器廠商正在改變他們對待協力廠商Cookie的方式。 Advertising和行銷供應商及技術通常需要使用許多使用者端標籤。 這些挑戰只是我們的客戶增加伺服器端資料散佈的兩個極具吸引力的原因。

使用案例和資料 use-cases-data

第一步是定義使用使用者端廠商標籤實作的使用案例。 例如，以Facebook (Meta)畫素為例。 將其從我們的網站移至Meta Conversions API （搭配事件轉送擴充功能），表示會先記錄特定使用案例。

若為目前使用者端廠商程式碼：

提供清單、試算表、圖表或其他資料和事件順序的記錄，以記錄此評估會很有幫助 — 即使它僅供您自己使用。 請務必加入資料來源的標籤 — 來源位置？ 目的地 — 前往何處？ 以及轉換 — 來源和目的地之間會發生什麼情況？

在我們的範例中，當訪客在檢視Facebook廣告後與我們的網站互動時，我們使用Facebook畫素追蹤轉換。 他們檢視其他社交平台上的相關廣告後，也可以與我們的網站互動。 若要在Facebook廣告工具和報表中檢視這些轉換，必須向Facebook取得所需資料。 此資料可能包含下載、註冊、喜歡或購買等轉換事件。

資料 data

有了現有的使用者端標籤，當標籤在我們的網站上執行或執行時，使用案例的資料會發生什麼事？ 我們可以擷取使用者端中所需的資料，而不使用廠商標籤，以便傳送給事件轉送嗎？ 使用標籤或其他標籤管理系統時，大部分的訪客互動資料都可供收集與發佈。 但我們在使用案例中所需的資料，是否可以在需要時、在需要的地方以需要的格式提供，而不需要使用者端廠商的標籤？ 以下是進一步要考慮的資料問題：

大部分使用者端廠商標籤對於任何特定使用案例不需要許多資料點，但在這些評估期間記下使用案例和所需資料會很有幫助。

廠商API vendor-apis

現在我們知道要實作的特定使用案例、所需的資料，以及從來源到目的地的事件順序。 為了判斷使用案例是否適合事件轉送，我們現在可以調查供應商API詳細資訊。

調查API investigate-apis

以下是一些調查廠商API端點的步驟。

廠商是否設計有API以用於伺服器對伺服器的事件資料傳輸？ 首先，找出這些特定API端點的需求：

換句話說：

如果我們可以對這些問題回答「是」，則標籤可能是從使用者端移至事件轉送屬性中我們伺服器的良好候選項。

如果廠商沒有可支援使用案例的API端點，那麼廠商標籤顯然不適合使用事件轉送來取代使用者端廠商標籤。

如果他們有API，但在每個API呼叫中也需要一些不重複訪客或使用者ID，該怎麼辦？ 如果網站上未執行廠商使用者端代碼（標籤），我們如何存取該ID？

有些廠商在沒有協力廠商Cookie的情況下會針對新世界更換系統。 這些變更包括使用替代的唯一識別碼，例如UUID或其他客戶產生的ID。 如果供應商允許客戶產生的ID，我們就能使用Web或Mobile SDK從使用者端將其傳送至Platform Edge Network，或透過事件轉送中的API呼叫取得。 我們在事件轉送規則中傳送資料給該供應商時，只需視需要納入該識別碼即可。

如果廠商需要只有其自己的使用者端標籤才能產生或存取的資料（例如廠商特有的唯一ID），那麼該廠商標籤就很可能不是移動的良好候選者。 不建議嘗試將使用者端標籤進行反向工程，將資料收集移至沒有適當API的事件轉送。

Adobe Experience Platform Cloud Connector擴充功能可視需要向具備適當伺服器對伺服器事件資料傳輸API的廠商提出HTTP請求。 雖然廠商專用的擴充功能已很好用，而且目前有更多的擴充功能正在積極開發中，但我們現在可以使用Cloud Connector擴充功能實作事件轉送規則，不需等候其他廠商的擴充功能。

工具 tools

使用Postman之類的工具，或Visual Studio Code Thunder Client或HTTP Client之類的文字編輯器延伸模組，更容易調查和測試廠商API端點。

後續步驟 next-steps

本文提供了一系列步驟，用於評估廠商使用者端標籤，以及在事件轉送屬性中可能將其移動到伺服器端。 如需相關主題的詳細資訊，請參閱下列連結：