Conector de origen de Adobe Analytics para datos de grupos de informes
Adobe Experience Platform le permite introducir datos de Adobe Analytics a través del conector de origen de Analytics. El conector transmite los datos del grupo de informes a un conjunto de datos de Platform en tiempo real, lo que lo convierte al formato XDM.
Cómo funciona el conector de origen de Analytics
La implementación de Adobe Analytics existente, como AppMeasurement o la extensión de etiquetas de Adobe Analytics, se sigue utilizando para recopilar datos en los grupos de informes. El conector de origen no cambia la forma en que se recopilan esos datos ni se crea un informe sobre ellos. Una vez que los datos llegan a los servidores de recopilación de datos de Analytics, el conector captura una copia.
Esta copia es un formulario procesado parcialmente de cada visita, conocido como valores medios. Analytics produce valores medios después del procesamiento previo (como reglas de procesamiento), pero antes del procesamiento de nivel de visita y visitante. Como resultado, no incluyen el contexto posterior al procesamiento, como el número de visita. La visita original continúa a través de la canalización para escribirse en el grupo de informes como de costumbre.
El conector transmite estos valores medios a un conjunto de datos en Experience Platform en tiempo real. Desde el lago de datos, los datos están disponibles para el servicio de consultas y otras aplicaciones de detección de datos, y también pueden enriquecer el perfil del cliente en tiempo real.
Para obtener más información sobre cómo Analytics recopila y procesa datos, incluida la fase de valores medios, consulte Orden de procesamiento de datos en Adobe Analytics.
Asignación de campos de Adobe Analytics a XDM
Al crear una conexión de origen en la interfaz de usuario de Experience Platform, los campos de Analytics se asignan automáticamente a XDM y se incorporan en un conjunto de datos de Platform. Para obtener instrucciones, consulte el tutorial del conector de origen de Analytics.
Para obtener información detallada sobre la asignación de campos que se produce entre Analytics y Experience Platform, consulte la guía de asignación de campos de Adobe Analytics.
Identificadores principales en datos de Analytics
Cada visita del conector de origen de Analytics contiene un identificador principal que depende de si existe un ECID o un AAID. Si hay un ECID, el ECID se designa como identificador principal. Si hay un AAID, entonces el AAID se designa como el principal.
La siguiente tabla proporciona más información sobre los campos de identidad en los datos de Analytics.
s_vi. A pesar de esto, se crea un AAID aunque la cookie s_vi no esté presente. AAID está representado por las columnas post_visid_high y post_visid_low en fuentes de datos de Analytics. En cualquier evento determinado, el campo AAID contiene una sola identidad que puede ser uno de los distintos tipos descritos en el orden de operaciones para los ID de Analytics. Nota: dentro de un grupo de informes completo, un AAID puede contener una combinación de tipos entre eventos.mcvisid en las fuentes de datos de Analytics. Para obtener más información sobre ECID, consulte la descripción general de ECID. Para obtener información sobre cómo funciona ECID con Analytics, consulte el documento sobre Solicitudes de ID de Analytics y Experience Cloud.visitorID en la implementación de Analytics. Si el AACUSTOMID está presente, AAID se basa en el AACUSTOMID porque este supera todos los demás identificadores definidos por el orden de operaciones para los ID de Analytics.Cómo trata la fuente de Analytics las identidades
El origen de Analytics pasa estas identidades a Experience Platform en forma XDM de la siguiente manera:
endUserIDs._experience.aaid.idendUserIDs._experience.mcid.idendUserIDs._experience.aacustomid.id
Estos campos no están marcados como identidades. En su lugar, las mismas identidades (si están presentes en el evento) se copian en el XDM identityMap como pares clave-valor:
{ "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 } ] }
Cuando la identidad o identidades se copian en identityMap, endUserIDs._experience.mcid.namespace.code también se establece en el mismo evento:
- Si AAID está presente,
endUserIDs._experience.aaid.namespace.codese establece como “AAID”. - Si ECID está presente,
endUserIDs._experience.mcid.namespace.codeestá establecido en “ECID”. - Si AACUSTOMID está presente,
endUserIDs._experience.aacustomid.namespace.codese establece como “AACUSTOMID”.
En el mapa de identidad, si ECID está presente, se marca como la identidad principal del evento. En este caso, AAID puede basarse en ECID debido al período de gracia del servicio de identidad. De lo contrario, AAID se marca como la identidad principal del evento. AACUSTOMID nunca se marca como ID principal para el evento. Sin embargo, si AACUSTOMID está presente, AAID se basa en AACUSTOMID debido al orden de operaciones de Experience Cloud.
Precisión de marca de tiempo de visitas y orden de eventos
El conector recibe los datos de Analytics como valores medios, que llevan marcas de tiempo de visitas de segundo nivel. Dado que Analytics registra el tiempo solo con precisión de segundo nivel y no rastrea el tiempo subsegundo, el orden de las visitas recopiladas dentro del mismo segundo no es determinista. Como resultado, el orden de los eventos del mismo segundo introducidos a través del conector puede diferir del orden mostrado en los informes de Analytics.
Customer Journey Analytics resuelve las marcas de tiempo en milisegundo, pero los datos procedentes de Analytics solo rellenan segundos enteros. Por lo tanto, la marca de tiempo por sí sola no puede establecer el orden relativo de los eventos que comparten el mismo segundo. Esto es más evidente cuando se recopilan varias visitas en el mismo segundo (por ejemplo, una vista de página y una visita de Adobe Target (A4T)).
Para obtener más información sobre la precisión de la marca de tiempo de Analytics, consulte la variable timestamp de Adobe Analytics y la documentación Profundidad de la visita. Para los campos de marca de tiempo que el conector asigna a XDM (hit_time_gmt y post_cust_hit_time_gmt), consulte la guía Asignación de campos Adobe Analytics.
Las opciones de precisión de marca de hora incluyen:
- Aceptar pequeñas diferencias de orden de mismo segundo. En la mayoría de los informes, el efecto se limita a los eventos que comparten el mismo segundo y no afecta a las métricas agregadas. Este es el método recomendado, incluso para escenarios de vistas de página mixtas y Adobe Target (A4T).
- Para casos de uso que distinguen entre pedidos, prefiera Web SDK. El envío de datos a través de Adobe Experience Platform Web SDK directamente a Experience Platform y Customer Journey Analytics conserva la precisión de la marca de tiempo de los subsegundos (milisegundos) y evita el reprocesamiento de Analytics. Este método se recomienda cuando el orden de eventos es importante.
Latencia de datos y relleno
La latencia esperada para los datos de Analytics en Experience Platform se describe en la siguiente tabla. La latencia varía según la configuración del cliente, los volúmenes de datos y las aplicaciones de los consumidores. Por ejemplo, si la implementación de Analytics está configurada con A4T, la latencia de la canalización aumenta de 5 a 10 minutos.
Para obtener más información sobre las latencias de Customer Journey Analytics, consulte: Protecciones de Customer Journey Analytics.
El relleno de Analytics para zonas protegidas de producción tiene un valor predeterminado de 13 meses. Para los datos de Analytics en entornos limitados que no son de producción, el relleno se establece en tres meses. El límite de 10 000 millones de eventos mencionado en el cuadro anterior se aplica estrictamente a la latencia esperada.
Al crear un flujo de datos de origen de Analytics en una zona protegida de producción, se crean dos flujos de datos:
- Un flujo de datos que rellena los datos históricos de los grupos de informes en el lago de datos durante 13 meses. Este flujo de datos finaliza cuando se completa el relleno.
- Flujo de datos que envía datos en directo al lago de datos y al perfil del cliente en tiempo real. Este flujo de datos se ejecuta continuamente.
Prácticas recomendadas
Siga estas prácticas recomendadas para evitar exceder los derechos de licencia y saturar las métricas totales de almacenamiento y riqueza de datos:
- Configure el Tiempo de vida (TTL) de retención de conjuntos de datos de eventos de experiencia al principio para optimizar la administración del ciclo de vida de datos y la eficiencia del almacenamiento. Para obtener más información, consulte la guía sobre administración de la retención de conjuntos de datos de evento de experiencia en el lago de datos mediante TTL.
- Cuando cree un flujo de datos de origen de Analytics, comience configurando el conector para introducir datos solo en el lago de datos. Después de confirmar que el flujo de datos funciona, puede habilitar la Ingesta de perfiles para el conjunto de datos. Este método funciona mejor cuando los filtros de fila y columna reducen de forma eficaz el volumen de datos. Obtenga más información en la documentación de conexión de Adobe Analytics a Experience Platform.