Adobe Analytics source connector for report-suite data
Adobe Experience Platform allows you to ingest Adobe Analytics data through the Analytics source connector. The Analytics source connector streams data collected by Analytics to Platform in real-time, converting SCDS-formatted Analytics data into Experience Data Model (XDM) fields for consumption by Platform.
This document provides an overview of Analytics and describes the use-cases for Analytics data.
Adobe Analytics and Analytics data
Analytics is a powerful engine that helps you learn more about your customers, how they interact with your web properties, see where your digital marketing spend is effective, and identify areas of improvement. Analytics handles trillions of web-transactions per year and the Analytics source connector allows you to easily tap into this rich behavioral data and enrich the Real-Time Customer Profile in a matter of minutes.
At a high level, Analytics collects data from various digital channels and multiple data centers around the world. Once the data is collected, Visitor Identification, Segmentation and Transformation Architecture (VISTA) rules, and processing rules are applied to shape the incoming data. After raw data has gone through this lightweight processing, it is then considered ready for consumption by Real-Time Customer Profile. In a process parallel to the aforementioned, the same processed data is micro-batched and ingested into Platform datasets for consumption by Query Service, and other data-discovery applications.
See the processing rules overview for more information on processing rules.
Experience Data Model (XDM)
XDM is a publicly documented specification that provides common structures and definitions for an application to use to communicate with services on Experience Platform.
Adhering to XDM standards allows data to be uniformly incorporated, making it easier to deliver data and gather information.
To learn more about XDM, please see the XDM System overview.
How are fields mapped from Adobe Analytics to XDM?
IMPORTANTWhen a source connection is established for bringing Analytics data into Experience Platform using the Platform user interface, data fields are automatically mapped and ingested into Real-Time Customer Profile within minutes. For instructions on creating a source connection with Analytics using the Platform UI, see the Analytics source connector tutorial.
For detailed information on the field mapping that occurs between Analytics and Experience Platform, see the Adobe Analytics field mapping guide.
What is the expected latency for Analytics Data on Platform?
The expected latency for Analytics Data on Platform is outlined in the table below. Latency will vary depending on customer configuration, data volumes, and consumer applications. For example, if the Analytics implementation is configured with A4T the latency to Pipeline will increase to 5-10 minutes.
| Analytics Data | Expected Latency |
|---|---|
| New data to Real-Time Customer Profile (A4T not enabled) | < 2 minutes |
| New data to Real-Time Customer Profile (A4T is enabled) | up to 30 minutes |
| New data to Data Lake | < 2.25 hours |
| New data to Customer Journey Analytics without stitching | < 3.75 hours |
| New data to Customer Journey Analytics with stitching | < 7 hours |
| Backfill of less than 10 billion events | < 4 weeks |
For more information about Customer Journey Analytics latencies, see: Customer Journey Analytics Guardrails.
The Analytics backfill for production sandboxes defaults to 13 months. For Analytics data in non-production sandboxes, backfill is set to three months. The limit of 10 billion events mentioned in the table above is strictly with respect to expected latency.
When you create an Analytics source dataflow in a production sandbox, two dataflows are created:
- A dataflow that does a 13-month backfill of historical report suite data into data lake. This dataflow ends when the backfill is complete.
- A dataflow flow which sends live data to data lake and to Real-Time Customer Profile. This dataflow runs continuously.
NOTEPrimary identifiers in Analytics data
Every hit from the Analytics source connector contains a primary identifier that is dependant on whether an ECID or an AAID exists. If there is an ECID, the ECID is designated as the primary identifier. If there is an AAID, then the AAID is designated as the primary.
The following table provides more information on identity fields in your Analytics data.
| Identity field | Description |
|---|---|
| AAID | The AAID is the primary device identifier in Adobe Analytics and is guaranteed to exist on every event that is passed through the Analytics source. The AAID is sometimes referred to as the Legacy Analytics ID or as the s_vi cookie ID. Despite this, an AAID is created even if the s_vi cookie is not present. The AAID is represented by the post_visid_high and post_visid_low columns in Analytics data feeds. On any given event, the AAID field contains a single identity which may be one of the several different types described in the order of operations for Analytics IDs. Note: Within an entire report suite, an AAID may contain a mix of types across events. |
| ECID | The ECID (Experience Cloud ID) is a separate device identifier field, which is populated in Adobe Analytics when Analytics is implemented using the Experience Cloud Identity Service. The ECID is sometimes also referred to as MCID (Marketing Cloud ID). If an ECID exists on an event, the AAID may be based on ECID depending on whether the Analytics grace period is configured. The ECID is represented by the mcvisid in Analytics data feeds. For more information on ECID, see the ECID overview. For information on how ECID works with Analytics, see the document on Analytics and Experience Cloud ID Requests. |
| AACUSTOMID | The AACUSTOMID is a separate identifier field which is populated in Adobe Analytics based on the use of the s.VisitorID variable in the Analytics implementation. The AACUSTOMID is represented by the cust_visid column in Analytics data feeds. If the AACUSTOMID is present, then the AAID will be based on the AACUSTOMID because the AACUSTOMID trumps all other identifiers as defined by the order of operations for Analytics IDs. |