報告套裝資料的Adobe Analytics來源聯結器
Adobe Experience Platform可讓您透過Adobe Analytics來源聯結器擷取Analytics資料。 Analytics來源聯結器會即時將Analytics所收集的資料串流到Platform，將SCDS格式的Analytics資料轉換為Experience Data Model (XDM)欄位以供Platform使用。
本檔案提供Analytics的概觀，並說明Analytics資料的使用案例。
Adobe Analytics和Analytics資料
Analytics是一款功能強大的引擎，可協助您進一步瞭解客戶、客戶如何與您的Web屬性互動、瞭解您的數位行銷支出在何處有效，以及找出需要改善的領域。 Analytics每年會處理數萬億個網頁交易，而Analytics來源聯結器可讓您輕鬆擷取此豐富的行為資料，並在幾分鐘內擴充Real-Time Customer Profile。
基本上，Analytics會從全球各個數位頻道和多個資料中心收集資料。 收集到資料後，會套用訪客識別、細分和轉換架構(VISTA)規則和處理規則來塑造傳入的資料。 原始資料經過此輕量型處理之後，就會被視為Real-Time Customer Profile已可供使用。 在上述平行處理程式中，相同的已處理資料會經過微批次處理，並擷取至Platform資料集，以供Query Service和其他資料探索應用程式使用。
如需處理規則的詳細資訊，請參閱處理規則總覽。
體驗資料模式 (XDM)
XDM是公開記錄的規格，為應用程式提供通用結構和定義，用於與Experience Platform上的服務通訊。
遵守XDM標準可讓資料統一整合，讓您更輕鬆地傳送資料及收集資訊。
若要深入瞭解XDM，請參閱XDM系統總覽。
欄位如何從Adobe Analytics對應至XDM？
當建立來源連線以使用Platform使用者介面將Analytics資料帶入Experience Platform時，資料欄位會自動對應，並在數分鐘內擷取到Real-Time Customer Profile。 如需使用Platform UI與Analytics建立來源連線的指示，請參閱Analytics來源聯結器教學課程。
如需Analytics與Experience Platform之間發生之欄位對應的詳細資訊，請參閱Adobe Analytics欄位對應指南。
Platform上Analytics資料的預期延遲為何？
下表列出Platform上Analytics資料的預期延遲。 延遲會依客戶組態、資料磁碟區和消費者應用程式而有所不同。 例如，如果Analytics實作設定為A4T，則管道的延遲將增加到5-10分鐘。
如需Customer Journey Analytics延遲的詳細資訊，請參閱： Customer Journey Analytics護欄。
生產沙箱的Analytics回填預設為13個月。 對於非生產沙箱中的Analytics資料，回填會設定為三個月。 上表提及的100億個事件上限嚴格與預期延遲有關。
在生產沙箱中建立Analytics來源資料流時，會建立兩個資料流：
- 此資料流會將13個月的歷史報表套裝資料回填至Data Lake。 此資料流會在回填完成時結束。
- 將即時資料傳送到資料湖和Real-Time Customer Profile的資料流流程。 此資料流會持續執行。
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識別碼要求的相關檔案。s.VisitorID變數的使用情況在Adobe Analytics中填入。 AACUSTOMID由Analytics 資料摘要中的cust_visid資料行表示。 如果AACUSTOMID存在，則AAID將會以AACUSTOMID為基礎，因為AACUSTOMID會勝過 Analytics 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存在，則AAID會因為作業順序Experience Cloud而以AACUSTOMID為基礎。