報告套裝資料的Adobe Analytics來源聯結器
Adobe Experience Platform可讓您透過Adobe Analytics來源聯結器擷取Analytics資料。 聯結器會即時將報表套裝資料串流至Platform資料集，並將其轉換為XDM格式。
Analytics來源聯結器的運作方式
您可繼續使用現有的Adobe Analytics實作（例如AppMeasurement或Adobe Analytics標籤擴充功能），將資料收集至報表套裝中。 來源聯結器不會變更您收集或報告該資料的方式。 當您的資料送達Analytics資料收集伺服器後，聯結器會擷取該資料的副本。
此復本是每個點選的部分處理形式，稱為mid-values。 Analytics會在預先處理（例如處理規則）之後、造訪和訪客層級處理之前產生中間值。 因此，它們不包含後續處理的內容，例如造訪次數。 原始點選會透過管道繼續，並照常寫入您的報表套裝。
聯結器會即時將這些中間值串流到Experience Platform中的資料集。 從資料湖，資料可用於Query Service和其他資料探索應用程式，也可以豐富即時客戶個人檔案。
如需Analytics如何收集與處理資料（包括中間值階段）的詳細資訊，請參閱Adobe Analytics中資料的處理順序。
將Adobe Analytics欄位對應至XDM
當您在Experience Platform使用者介面中建立來源連線時，Analytics欄位會自動對應至XDM，並內嵌至Platform資料集。 如需指示，請參閱Analytics來源聯結器教學課程。
如需Analytics與Experience Platform之間發生之欄位對應的詳細資訊，請參閱Adobe Analytics欄位對應指南。
Analytics資料中的主要識別碼
來自Analytics來源聯結器的每個點選都包含主要識別碼，此識別碼取決於ECID或AAID是否存在。 如果有ECID，則會將ECID指定為主要識別碼。 如果有AAID，則會將AAID指定為主要的。
下表提供Analytics資料中身分欄位的詳細資訊。
s_vi Cookie ID。 儘管如此，即使s_vi Cookie不存在，仍會建立AAID。 AAID由Analytics資料摘要中的post_visid_high和post_visid_low欄表示。 在任何特定事件上，AAID欄位都包含單一身分識別，該身分識別可能是Analytics ID🔗作業順序中說明的幾種型別之一。 注意：在整個報告套裝中，AAID可能包含跨事件的多種型別。mcvisid表示。 如需有關ECID的詳細資訊，請參閱ECID概觀。 如需ECID如何與Analytics搭配使用的詳細資訊，請參閱Analytics與Experience Cloud ID要求的相關檔案。Analytics來源如何處理身分
Analytics來源將這些身分識別以XDM形式傳遞給Experience Platform，如下所示：
endUserIDs._experience.aaid.idendUserIDs._experience.mcid.idendUserIDs._experience.aacustomid.id
這些欄位不會標籤為身分。 相反地，相同的身分（如果存在於事件中）會作為索引鍵值配對複製到XDM的identityMap中：
{ "key": "AAID", "value": [ { "id": "<identity>", "primary": <true or false> } ] }{ "key": "ECID", "value": [ { "id": "<identity>", "primary": <true or false> } ] }{ "key": "AACUSTOMID", "value": [ { "id": "<identity>", "primary": false } ] }
將身分或身分複製至identityMap時，endUserIDs._experience.mcid.namespace.code也會設定在相同事件上：
- 如果AAID存在，
endUserIDs._experience.aaid.namespace.code會設為"AAID"。 - 如果ECID存在，
endUserIDs._experience.mcid.namespace.code會設為"ECID"。 - 如果AACUSTOMID存在，
endUserIDs._experience.aacustomid.namespace.code會設為「AACUSTOMID」。
在身分對應中，如果ECID存在，則會標示為事件的主要身分。 在這種情況下，由於Identity服務寬限期，AAID可能會以ECID為基礎。 否則，AAID會標示為事件的主要身分識別。 絕不會將AACUSTOMID標示為事件的主要ID。 不過，如果AACUSTOMID存在，則由於Experience Cloud的作業順序，AAID會以AACUSTOMID為基礎。
點選時間戳記精確度和事件順序
聯結器會以中間值形式接收Analytics資料，這些中間值包含第二層級點選時間戳記。 由於Analytics僅以第二層級的精確度記錄時間，且不會追蹤次秒時間，因此同一秒內收集的點選順序不是決定性的。 因此，透過聯結器擷取的相同秒事件順序，可能會與Analytics報表中顯示的順序不同。
Customer Journey Analytics會將時間戳記解析為毫秒，但Analytics來源的資料只會填入整秒。 因此，僅時間戳記無法建立共用相同秒數的事件相對順序。 在同一秒內收集數個點選時(例如頁面檢視和Adobe Target (A4T)點選)，這項現象最引人注目。
如需Analytics時間戳記精確度的詳細資訊，請參閱Adobe Analytics 時間戳記變數和點選深度檔案。 對於聯結器對應到XDM （hit_time_gmt和post_cust_hit_time_gmt）的時間戳記欄位，請參閱Adobe Analytics欄位對應指南。
您的時間戳記精確度選項包括：
- 接受微小的相同秒順序差異。 對於大多數報表，此影響僅限於共用相同秒數的事件，不會影響彙總量度。 這是建議使用的方法，包括針對混合頁面檢視和Adobe Target (A4T)案例。
- 若為訂單敏感型使用案例，則偏好使用網頁SDK。 透過Adobe Experience Platform Web SDK直接將資料傳送到Experience Platform，Customer Journey Analytics會保留次秒（毫秒）的時間戳記精確度，並避免Analytics重新處理。 當事件順序很重要時，建議使用此方法。
資料延遲和回填
下表列出Experience Platform上Analytics資料的預期延遲。 延遲會依客戶組態、資料磁碟區和消費者應用程式而有所不同。 例如，如果Analytics實施是以A4T設定，則管道的延遲會增加5至10分鐘。
如需Customer Journey Analytics延遲的詳細資訊，請參閱： Customer Journey Analytics護欄。
生產沙箱的Analytics回填預設為13個月。 對於非生產沙箱中的Analytics資料，回填會設定為三個月。 上表提及的100億個事件上限嚴格與預期延遲有關。
在生產沙箱中建立Analytics來源資料流時，會建立兩個資料流：
- 此資料流會將13個月的歷史報告套裝資料回填至資料湖。 此資料流會在回填完成時結束。
- 將即時資料傳送至資料湖和即時客戶個人檔案的資料流。 此資料流會持續執行。
最佳實務
請遵循下列最佳實務，以避免超出授權許可權，並超出總儲存量和資料豐富度量度：
- 一開始即設定體驗事件資料集保留存留時間(TTL)，以最佳化資料生命週期管理和儲存效率。 如需詳細資訊，請參閱使用TTL🔗在資料湖中管理Experience Event資料集保留的指南。
- 建立Analytics來源資料流時，一開始先將聯結器設定為僅將資料擷取至資料湖。 確認資料流正常運作後，您可以啟用資料集的設定檔擷取。 當列和欄篩選器有效地減少資料量時，此方法的最佳運作方式。 在將Adobe Analytics連線至Experience Platform檔案中進一步瞭解。