Migre la implementación de Audience Manager de su sitio desde el DIL del lado del cliente al reenvío del lado del servidor

Este tutorial se aplica si tiene Adobe Audience Manager (AAM) y Adobe Analytics, y actualmente está enviando una visita desde la página a AAM con el DIL (Data Integration Library) y también enviando una visita desde la página a Adobe Analytics. Dado que tiene ambas soluciones y que ambas forman parte de Adobe Experience Cloud, tiene la oportunidad de seguir la práctica recomendada de activar el reenvío del lado del servidor, que habilita la función Analytics servidores de recopilación de datos para reenviar datos de análisis del sitio en tiempo real al Audience Manager, en lugar de hacer que el código del lado del cliente envíe una visita adicional desde la página a AAM. Este tutorial lo acompaña durante los pasos necesarios para realizar el cambio de la implementación de DIL del lado del cliente anterior al método de reenvío del lado del servidor más reciente.

Lado del cliente (DIL) frente a lado del servidor

Al comparar y contrastar estos dos métodos de obtención de datos de Adobe Analytics en AAM, podría resultar útil visualizar primero las diferencias en la siguiente imagen:

Implementación del DIL del lado del cliente

Si utiliza este método para obtener datos de Adobe Analytics en AAM, tiene dos visitas provenientes de las páginas web: Una que va a Analyticsy uno que va a AAM (después de haber copiado el Analytics datos de la página web. Segments se devuelven de AAM a la página, donde se pueden utilizar para la personalización, etc. Esto se considera una implementación heredada y ya no se recomienda.

Más allá del hecho de que esto no sigue las prácticas recomendadas, las desventajas de utilizar este método incluyen:

• Dos visitas provenientes de la página en lugar de solo una
• el reenvío del lado del servidor es necesario para el uso compartido en tiempo real de AAM audiencias a Analytics, de modo que las implementaciones del lado del cliente no permiten esta función (y otras funciones potenciales en el futuro)

Se recomienda pasar a un método de reenvío del lado del servidor de AAM implementación.

Implementación de reenvío del lado del servidor

Como se muestra en la imagen anterior, una visita viene de la página web a Adobe Analytics. Analytics luego reenvía esos datos a AAM en tiempo real, y los visitantes se evalúan en rasgos AAM y segments, igual que si la visita hubiera llegado directamente desde la página.

Segments se devuelven en la misma visita en tiempo real a Analytics, que reenvía la respuesta a la página web para su personalización, etc.

No hay un inconveniente en el tiempo para pasar al reenvío del lado del servidor. Adobe recomienda encarecidamente que cualquier persona que tenga un Audience Manager y Analytics utiliza este método de implementación.

Tiene dos tareas principales

Hay bastante información en esta página, y todo es importante, por supuesto. Sin embargo, sí todo se reduce a dos cosas principales que debe hacer:

1. Cambie el código de código de DIL del lado del cliente a código de reenvío del lado del servidor
2. Girar el interruptor en la Analytics Admin Console para iniciar el reenvío real de datos (por report suite)

Si omite cualquiera de estas tareas, el reenvío del lado del servidor no funcionará correctamente. Se han añadido pasos y datos adicionales a este documento para ayudarle a realizar correctamente estos dos pasos en la configuración.

Opciones de implementación

Al pasar del lado del cliente al reenvío del lado del servidor, una de las tareas que tendrá es cambiar el código por el nuevo código de reenvío del lado del servidor. Esto se realiza mediante una de las siguientes opciones:

• Etiquetas Adobe Experience Platform : la opción de implementación recomendada por Adobe para las propiedades web. Verá que esta es una tarea fácil, ya que las etiquetas de Platform han hecho todo el trabajo duro por usted.
• En la página : también puede colocar el nuevo código SSF directamente en el doPlugins dentro de su appMeasurement.js , si todavía no está utilizando Adobe Launch
• Otros administradores de etiquetas : se pueden tratar como la opción anterior (En la página), ya que aún colocará el código SSF en doPlugins, donde el otro administrador de etiquetas almacene la variable AppMeasurement code

Veremos cada uno de estos elementos en la Actualización del código para obtener más información.

Pasos de implementación

Los siguientes pasos describen la implementación.

Paso 0: Requisito previo: Servicio de ID de Experience Cloud (ECID)

El requisito previo principal para pasar al reenvío del lado del servidor es tener implementado el servicio de ID de Experience Cloud. Esto se hace más fácilmente si utiliza Experience Platform Launch, en cuyo caso simplemente instala la extensión ECID y hará el resto.

Si utiliza un sistema de administración de etiquetas que no es de Adobe o ningún sistema de administración de etiquetas, implemente el ECID para ejecutar before cualquier otra solución de Adobe. Consulte la Documentación de ECID para obtener más información. El único otro requisito previo es el de las versiones de código, por lo que, como simplemente aplica las versiones más recientes del código en los pasos siguientes, estará bien.

Paso 1: Registrar las opciones usadas actualmente desde el código del DIL

A medida que se prepara para pasar del código de DIL del lado del cliente al reenvío del lado del servidor, el primer paso es identificar todo lo que está haciendo con el código de DIL, incluida la configuración personalizada y los datos enviados a AAM. Algunas cosas que hay que tener en cuenta y considerar son:

• Normal Analytics usando la variable siteCatalyst.init Módulo de DIL: no necesita preocuparse por esto, ya que su trabajo es simplemente enviar la variable Analytics y esto sucede simplemente teniendo habilitado el reenvío del lado del servidor.
• Subdominio de socio : en la variable DIL.create , tome nota de la función partner parámetro. Esto se conoce como su "subdominio de socio" o, en ocasiones, "ID de socio" y será necesario cuando coloque el nuevo código de reenvío del lado del servidor.
• Visitor Service Namespace - También conocido como suOrg ID" o "IMS Org ID," también lo necesitará cuando configure el nuevo código de reenvío del lado del servidor. Anote esto.
• containerNSID, uuidCookie y otras opciones avanzadas : tome nota de las opciones avanzadas adicionales que esté utilizando para que pueda configurarlas también en el código de reenvío del lado del servidor.
• Variables de página adicionales : si se envían otras variables a AAM desde la página (además de la variable Analytics variables gestionadas por siteCatalyst.init), deberá tener en cuenta dichas variables para que se puedan enviar mediante reenvío del lado del servidor (alerta de spoiler: via contextData ).

Paso 2: Actualizar el código

En Opciones de implementación (arriba), se ofrecen múltiples opciones sobre cómo y dónde se implementa el reenvío del lado del servidor. Para que esta sección sea efectiva, necesitamos dividirla en estas secciones (con dos de ellas combinadas). Vaya al método de esta sección que describa mejor sus necesidades.

Etiquetas de Adobe Experience Platform

Vea el siguiente vídeo para obtener más información sobre cómo mover las opciones de implementación del código de DIL del lado del cliente al reenvío del lado del servidor en Experience Platform Launch.

"En la página" o el administrador de etiquetas que no sean de Adobe

Vea el siguiente vídeo para obtener más información sobre cómo mover las opciones de implementación del código de DIL del lado del cliente al reenvío del lado del servidor en AppMeasurement código, que reside en un archivo o en un sistema de administración de etiquetas que no es de Adobe.

Paso 3: Activación del reenvío (por Report Suite)

Hasta ahora, en este tutorial hemos invertido todo nuestro tiempo en cambiar el código del código del DIL del lado del cliente al reenvío del lado del servidor. Está bien, porque es la parte más difícil. Esta sección, aunque verá que es superfácil, es tan importante como actualizar el código. En este vídeo, verá cómo voltear el conmutador que habilita el reenvío real de datos de Analytics al Audience Manager.

NOTA: Como se indica en el vídeo, recuerde que la habilitación del reenvío tardará hasta 4 horas en implementarse completamente en el backend del Experience Cloud.

Temporización

Como recordatorio, existen dos tareas principales para pasar del DIL del lado del cliente al reenvío del lado del servidor:

1. Actualización del código
2. Girando el interruptor en el Analytics Admin Console

Pero la pregunta es, ¿cuál haces primero? ¿Importa? Bien, perdón, fueron dos preguntas. Pero las respuestas son… depende, y sí, can materia. ¿Cómo es eso para vago? Desglosémoslo. Pero primero una pregunta adicional que puede surgir si es una organización grande con numerosos sitios: ¿Tengo que hacer todo a la vez? Ese es un poco más fácil. No. Puedes hacerlo pieza a pieza.

Un poco más profundo

La razón por la que el tiempo y el orden importan es por la forma en que se reenvían real , que puede resumirse en los siguientes aspectos técnicos:

• Si tiene implementado el servicio de ID de Experience Cloud (ECID) y el conmutador en la variable Analytics Admin Console ("el conmutador") está activado, los datos se reenviarán desde Analytics para AAM, aunque aún no haya actualizado el código.
• Si no tiene implementado ECID, los datos no se reenviarán, aunque tenga el conmutador activado, y el código de reenvío del lado del servidor.
• El código de reenvío del lado del servidor (ya sea en etiquetas de Platform o en la página) realmente gestiona la respuesta y es necesario para completar la migración.
• Recuerde que el conmutador de reenvío del lado del servidor está habilitado por el report suite, pero que el código lo gestiona la propiedad de las etiquetas de Platform o la AppMeasurement si no utiliza etiquetas de Platform.

Prácticas recomendadas

Basándose en estos detalles técnicos, estas son las recomendaciones para el momento en el que debe hacerse y cuándo:

Si NO tiene ECID aún implementado

1. Gire el interruptor hacia dentro Analytics para cada report suite que habilitará para el reenvío del lado del servidor.

   1. El reenvío aún no comienza porque no tiene ECID.

2. Por sitio, actualice el código desde el DIL del lado del cliente al reenvío del lado del servidor (puede estar en etiquetas de Platform) o en la página, tal como se explica en otra sección anterior).

   1. El reenvío ahora fluye (como ha añadido ECID) y también debe recibir una respuesta JSON adecuada a su Analytics señalización (consulte la sección Validación y solución de problemas a continuación para obtener más información).

Si tiene implementado ECID

1. Prepare y planifique para que esté preparado para actualizar su código de reenvío del lado del DIL al lado del servidor PER report suite que habilitará para el reenvío del lado del servidor:

   1. Gire el interruptor hacia dentro Analytics para habilitar el reenvío del lado del servidor.

      1. El reenvío empezará porque tiene ECID habilitado.

   2. Tan pronto como sea posible, actualice el código desde el DIL del lado del cliente al reenvío de un solo lado (esto podría estar en las etiquetas de Platform o en la página, como se ha analizado en otra sección anterior).

      1. Debe recibir una respuesta JSON adecuada a su Analytics señalización (consulte la Validación y solución de problemas para obtener más información).

Temporización de migración cuando tiene muchos sitios y report suites

Este tema se ha abordado brevemente en secciones anteriores, ya que la estrategia principal puede resumirse de la siguiente manera:

Migración de un sitio/report suite (o grupo de sitios/report suites) a la vez.

Sin embargo, esto puede resultar un poco complicado en función de algunos escenarios posibles:

• Tiene un sitio que contiene varias report suites
• Tiene un report suite que incluye varios sitios (como una report suite)
• Utilice una propiedad de etiquetas de Platform para cubrir varios sitios
• Tiene diferentes equipos de desarrollo para diferentes sitios

Debido a estos elementos, puede resultar un poco complicado. Las mejores cosas que puedo sugerir son:

• Tómese algún tiempo para crear una estrategia para migrar al reenvío del lado del servidor, en función de lo que se ha explicado anteriormente
• Basado en el hecho de que una sola propiedad en etiquetas de Platform (o una sola AppMeasurement archivo) normalmente se asigna a 1 o 2 distintos report suites, es probable que pueda realizar un plan que funcione en estos grupos diferentes uno a uno, actualizando su empresa al reenvío del lado del servidor
• Si está trabajando con la asesoría de Adobe, hable con ellos acerca de su plan de migración para que puedan ayudarle según sea necesario

Validación y solución de problemas

La forma principal de validar que el reenvío del lado del servidor funciona es consultar la respuesta a cualquiera de sus visitas de Adobe Analytics procedentes de la aplicación.

Si no realiza el reenvío de datos del lado del servidor desde Analytics al Audience Manager, entonces no hay respuesta a la variable Analytics señalización (aparte de un píxel 2x2). Sin embargo, si está reenviando del lado del servidor, hay elementos que puede verificar en la variable Analytics solicitud y respuesta que le harán saber que Analytics se está comunicando correctamente con Audience Manager, reenviando la visita y obteniendo una respuesta.

Para obtener más información sobre el reenvío del lado del servidor, consulte la documentación.