Migración de la implementación de AAM del sitio del DIL Client-Side a Server-Side Forwarding

Este tutorial se aplica a usted si tiene Adobe Audience Manager (AAM) y Adobe Analytics, y actualmente está enviando una visita desde la página a AAM mediante el código "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 del Adobe Experience Cloud, tiene la oportunidad de seguir la práctica recomendada de activar "Server-Side Forwarding (SSF)", que permite a los servidores de recopilación de datos Analytics reenviar datos de análisis del sitio en tiempo real al Audience Manager, en lugar de tener client-side código que envíe una visita adicional de la página a AAM. Este tutorial lo guiará por los pasos para hacer el cambio de la implementación anterior "Client-Side DIL" al método más reciente "Server-Side forwarding".

Client-Side (DIL) vs. Server-Side

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

Client-side Implementación de DIL

Si utiliza este método para AAM los datos de Adobe Analytics, significa que tiene dos visitas provenientes de las páginas Web: Uno va a Analytics y otro va a AAM (después de haber copiado los datos Analytics en la página Web. Segments se devuelven de AAM a la página, donde se pueden utilizar para la personalización, etc. Se considera una implementación "heredada" y ya no se recomienda.

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

• Dos visitas provenientes de la página en lugar de una sola
• Server-Side Forwarding es necesario para compartir en tiempo real las audiencias de AAM a Analytics, por lo que Client-side las implementaciones no permiten esta función (y otras funciones potencialmente en el futuro)

Se recomienda pasar a un método Server-Side Forwarding de implementación de AAM.

Server-Side ForwardingImplementación

Como se muestra en la imagen anterior, una visita llega 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 AAM traits y segments, como si la visita hubiera venido directamente de la página.

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

No hay una desventaja de tiempo para pasar al reenvío del lado del servidor. Se recomienda encarecidamente que cualquier persona que tenga Audience Manager y Analytics utilice 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, todo se reduce a dos cosas principales que necesita hacer:

1. Cambie el código de Client-Side código de DIL a Server-Side Forwarding código
2. Gire el conmutador en el Analytics Admin Console para inicio del reenvío real de datos (por report suite)

Si omite cualquiera de estos dos, SSF no funcionará correctamente. Se han agregado pasos y datos adicionales a este documento para ayudarle a realizar estos dos pasos correctamente en su configuración.

Opciones de implementación

Al pasar de client-side a server-side, una de las tareas que tendrá es cambiar el código al nuevo código Server-Side Forwarding. Esto se realiza con una de las siguientes opciones:

• Adobe Experience Platform Launch: nuestra opción de implementación recomendada para propiedades web. Verá que esta es una tarea muy fácil, ya que Launch ha hecho todo lo duro por usted.
• En la página: también puede colocar el nuevo código SSF directamente en la función doPlugins dentro del archivo appMeasurement.js si no está (todavía) utilizando Adobe Launch
• Otros administradores de etiquetas: se pueden tratar igual que la opción anterior (En la página), ya que se seguirá colocando el código SSF en doPlugins, dondequiera que el otro administrador de etiquetas almacene el código AppMeasurement

Veremos cada una de estas opciones en la sección Actualización del código.

Pasos de la implementación

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

El requisito previo principal para pasar a Server-Side Forwarding 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 está utilizando un sistema de administración de etiquetas que no es de Adobe, o ningún sistema de administración de etiquetas, implemente ECID para ejecutar antes cualquier otra solución de Adobe. Consulte la documentación de ECID para obtener más detalles. El único otro requisito previo es con respecto a las versiones de código, por lo que, como simplemente aplica las versiones más recientes del código en los siguientes pasos, estará bien.

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

A medida que esté listo para pasar del código de DIL Client-Side a Server-Side Forwarding, el primer paso es identificar todo lo que está haciendo con el código de DIL, incluso la configuración personalizada y los datos enviados a AAM. Entre las cosas que hay que notar y considerar se incluyen:

• Variables normales Analytics, usando el módulo de DIL siteCatalyst.init: no tendrá que preocuparse por esta, ya que su trabajo es simplemente enviar las variables normales Analytics y eso sucederá simplemente por tener SSF habilitado.
• Subdominio de socio: en la función DIL.create, anote el parámetro partner. Esto se conoce como "subdominio de socio" o a veces "ID de socio" y será necesario cuando coloque el nuevo código SSF.
• Visitor Service Namespace - También se le conoce como "Org ID" o "IMS Org ID", lo necesitará también cuando configure el nuevo código SSF. Anote esto.
• containerNSID, uuidCookie y otras opciones avanzadas: tome nota de las opciones avanzadas adicionales que esté utilizando para poder configurarlas también en el código SSF.
• Variables de página adicionales: si se envían otras variables a AAM desde la página (además de las variables Analytics normales administradas por siteCatalyst.init), deberá tener en cuenta dichas variables para que se puedan enviar mediante SSF (alerta de spoiler: mediante contextData variables).

Paso 2: Actualización del código

En la sección anterior titulada "Opciones de implementación", se proporcionan varias opciones con respecto a cómo/dónde está implementando Server-Side Forwarding. 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 describe mejor sus necesidades.

Adobe Experience Platform Launch

Vea el siguiente vídeo para obtener información sobre cómo mover las opciones de implementación del código de DIL Client-Side a Server-Side Forwarding en Experience Platform Launch.

"En la página" o No Adobe Tag Manager

Vea el siguiente vídeo para obtener información sobre cómo mover las opciones de implementación del código de DIL Client-Side a Server-Side Forwarding en el código AppMeasurement, ya sea en un archivo o en un sistema de administración de etiquetas que no sea de Adobe.

Paso 3: Habilitando el reenvío (por Report Suite)

Hasta ahora, en este tutorial hemos dedicado todo nuestro tiempo a cambiar el código de Client-Side DIL a Server-Side Forwarding. Está bien, porque es la parte más difícil. Esta sección, aunque verá que es muy fá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 a 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 servidor Experience Cloud.

Temporización

Como recordatorio, existen dos tareas principales para pasar de Client-Side DIL a Server-Side Forwarding:

1. Actualización del código
2. Volteando el conmutador en el Analytics Admin Console

Pero la pregunta es, ¿cuál haces primero? ¿Importa? Bien, lo siento, fueron dos preguntas. Pero las respuestas son… depende, y sí, puede importar. ¿Cómo es esto para vago? Vamos a desglosarlo. Pero primero una pregunta adicional que puede surgir si usted es una gran organización con muchos sitios: ¿Tengo que hacer todo a la vez? Ese es un poco más fácil. No. Puedes hacerlo pieza a pieza… como que… 😃

Un poco más profundo de buceo

La razón por la que el tiempo y el orden son importantes es por la manera en que el reenvío *realmente funciona, que se puede resumir en los siguientes pocos hechos técnicos:

• Si ha implementado el servicio de ID de Experience Cloud (ECID) y el conmutador de Analytics Admin Console ("el conmutador") está activado, los datos se reenviarán de Analytics a AAM, aunque aún no haya actualizado el código.
• Si no se ha implementado ECID, los datos no se reenviarán, incluso si tiene el conmutador activado, y tiene el código SSF.
• El código SSF (ya sea en Launch o en la página) realmente gestiona la respuesta y, por supuesto, es necesario para completar la migración.
• Recuerde que el conmutador SSF está habilitado por Report Suite, pero que el código se gestiona mediante la propiedad Launch o mediante el archivo AppMeasurement si no utiliza Launch

Prácticas recomendadas

Basándose en estos detalles técnicos, aquí están las recomendaciones para el momento de "qué hacer cuando":

Si NO tiene ECID implementado

1. Gire el conmutador en Analytics para cada report suite que habilite para SSF

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

2. Por sitio, actualice el código de Client-Side DIL a SSF (esto podría estar en Launch o en la página, como se explica en otra sección anterior)

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

Si ha implementado ECID

1. Prepárese y planifique para que esté preparado para actualizar el código de DIL a SSF por report suite que habilitará para SSF:

   1. Gire el conmutador en Analytics para habilitar el SSF

      1. Reenviar inicio WILL porque tiene habilitado ECID

   2. Lo antes posible, actualice el código de Client-Side DIL a SSF (esto podría estar en Launch o en la página, como se explica en otra sección anterior)

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

NOTA 1: Es importante realizar estos dos pasos lo más cerca posible entre sí, ya que entre los pasos 1 y 2 anteriores, se producirá una duplicación de datos en AAM. En otras palabras, el SSF habrá comenzado a enviar datos de Analytics a AAM, y dado que el código de DIL aún está en la página, también habrá una visita que irá directamente de la página a AAM, duplicando así los datos. Tan pronto como actualice el código de DIL a SSF, esto se aliviará.

NOTA 2: Si prefiere tener una pequeña discrepancia en los datos en lugar de una pequeña duplicación de datos, puede cambiar el orden de los pasos 1 y 2 anteriores. Si se mueve el código de DIL a SSF, se detendrá el flujo de datos en AAM hasta que se pueda voltear el conmutador para activar el SSF para el report suite. Generalmente, los clientes prefieren duplicar los datos en lugar de dejar de obtener visitantes en traits y segments.

Temporización de migración cuando tiene muchos sitios y Report Suites

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

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

Sin embargo, esto puede resultar un poco complicado en base a algunos escenarios posibles:

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

Debido a estos elementos, se puede complicar un poco. Lo mejor que puedo sugerir son:

• Tómese algún tiempo para elaborar una estrategia de migración a la SSF, en base a lo que se ha explicado anteriormente
• En base al hecho de que una sola propiedad en Launch (o un solo archivo AppMeasurement) se asigna generalmente a 1 o 2 report suites distintos, es probable que pueda hacer un plan que funcione en estos grupos distintos uno por uno, actualizando su empresa a SSF
• Si está trabajando con la asesoría de Adobe, comuníquese con ellos en relación con su plan de migración para que puedan ayudarle según sea necesario

Validación y resolución de problemas

La forma principal de validar que Server-Side Forwarding esté activo y en funcionamiento es mirando la respuesta a cualquiera de las visitas de Adobe Analytics procedentes de la aplicación.

Si no está haciendo server-side forwarding de datos de Analytics a Audience Manager, no hay realmente ninguna respuesta a la señalización Analytics (además de un píxel 2x2). Sin embargo, si está haciendo SSF, entonces hay elementos que puede verificar en la solicitud y respuesta Analytics que le permitirán saber que Analytics se está comunicando correctamente con Audience Manager, reenviando la visita y obteniendo una respuesta.

ADVERTENCIA: Cuidado con el falso “éxito” - Si hay una respuesta, y todo parece estar funcionando, asegúrate de tener el objeto “material” en la respuesta. Si no lo hace, puede que vea un mensaje que diga “status”:“SUCCESS”. Por más loco que esto suene, esto es prueba de que NO está funcionando correctamente. Si lo ve, significa que ha completado la actualización de código en Launch o AppMeasurement, pero que el reenvío en Analytics Admin Console aún no se ha completado. En este caso, debe verificar que ha habilitado SSF en Analytics Admin Console para su report suite. Si lo han hecho, y no han pasado aún 4 horas, tengan paciencia, ya que puede tomar tanto tiempo hacer todos los cambios necesarios en el servidor.

Para obtener más información sobre Server-Side Forwarding, consulte la documentación.