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

說明 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服務位置提示= Experience 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的第一個interact呼叫在路徑中不會包含區域，因為尚未決定區域，但位置提示會出現在回應中（如上所述）。 原始請求的路徑將只是…/ee/v1/… 不過，後續的呼叫將包含/ee/和/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小時後同步為止。 在像這樣的使用案例中，標準實務就是使用取得ECID getMarketingCloudVisitorID （ID服務）或 getIdentity (Web SDK)函式。 不過，除了取得ECID之外，還必須擷取位置提示並使用 getLocationHint （ID服務）函式或從Web SDK呼叫的回應裝載中擷取此函式。