位置提示、AAM DCS區域節點和ID服務位置提示

瞭解Adobe Experience Platform (AEP) WebSDK位置提示、Experience CloudID服務位置提示和Adobe Audience Manager (AAM) DCS區域節點之間的關係。

說明 description

環境

問題/症狀

AEP (Adobe Experience Platform) WebSDK位置提示、Experience CloudID服務、位置提示和AAM DCS區域節點之間的關係是什麼，為什麼理解這種關係很重要？

解決方法 resolution

AEP WebSDK (會將資料傳送至Experience Edge)和Adobe Audience Manager (AAM)即時資料收集作業會發生在分散於全球的區域節點。 有7個地區節點以及AEP WebSDK/Experience Edge和AAM資料收集使用相同的節點。 AAM的資料收集伺服器(DCS)會利用與Experience Edge相同的網路基礎結構。 同樣地，由於Experience CloudID服務採用AAM技術，因此ID服務位置提示會與AAM區域資料收集節點相同。 換句話說， AAM DCS節點= ID服務位置提示=  體驗Edge位置提示。 此檔案中列出AAM的區域節點，而此檔案中列出相同的Experience Edge區域節點。

即使AAM的區域節點和ID服務位置提示以數字識別，而Experience Edge是以英數字元識別，您仍會注意到它們全都對齊相同的區域（巴西除外）。  下列查閱表格示範它們的排列方式：

大部分需要即時回應的Adobe Experience Cloud功能都利用這些區域節點。 網頁或行動應用程式上的第一個呼叫ID服務或Experience Edge呼叫會決定要使用哪個區域節點。 在回應這些呼叫時，可以找到位置提示：

Experience CloudID服務：

AEP Web SDK：

一旦確定與一般使用者最接近的區域節點，便能透過Analytics、Target和AEP WebSDK呼叫傳遞區域識別碼。 在Analytics中，會以aamlh查詢字串引數的形式傳遞：

在Target中，它會傳遞至要求裝載的experienceCloud.audienceManager.locationHint物件：

若為AEP Web SDK，呼叫的路徑會更新以反映區域節點：

注意： 來自AEP WebSDK的第一通互動呼叫在路徑中不會包含地區，因為尚未決定地區，但回應中將會包含位置提示（如上所述）。 原始請求的路徑將只是..../ee/v1/....。不過，後續呼叫將包含/ee/ and /v1/路徑元素之間的區域節點資訊。

這些引數可確保伺服器端轉送的Analytics資料會轉送至正確的AAM邊緣節點、Target會要求來自相同邊緣節點的區段資訊，以及AEP資料會將資料傳送至AAM （和對象庫）正確的區域節點。

以非標準方式將伺服器端或使用者端點選傳送至Adobe的解決方案時，務必要瞭解此資訊。 例如，頁面上手動建構的AEP WebSDK呼叫，純粹為了將ECID (Experience CloudID)與AEP設定檔同步，必須傳送至正確的Experience Edge區域節點。 如果沒有，從AEP共用至AAM的任何資料都會前往AAM後端資料庫，然後額外花費48小時讓AAM將該資料推送至每個邊緣節點，大幅降低Target能夠使用傳送至AAM （或對象庫）的任何AEP區段的時間。 或者，如果伺服器端Analytics請求已傳送至節點7，但使用者的頁面上Target實作使用區域9，則資料將會轉送至AAM的美國東部節點，而Target則會撥動美國西部節點以取得區段資訊。 一般使用者將無法取得使用對象庫對象/AAM區段的任何Target活動的資格，直到最終節點在24到48小時後同步為止。 在像這樣的使用案例中，標準做法是使用getMarketingCloudVisitorID （ID服務）或getIdentity (Web SDK)函式來取得ECID。 不過，除了取得ECID之外，還必須擷取位置提示，並使用getLocationHint （ID服務）函式或從Web SDK呼叫的回應裝載中擷取它來加以使用。

在我們的Experience League促銷活動社群中提問
若您有任何關於此主題的疑問或想閱讀之前的解答，請檢視包含本文的Experience League社群部落格，傳送您的問題和意見，並加入我們的Experience LeagueCampaign社群！