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".
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:
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:
Se recomienda pasar a un método Server-Side Forwarding de implementación de AAM.
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.
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:
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.
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:
doPlugins
dentro del archivo appMeasurement.js si no está (todavía) utilizando Adobe LaunchdoPlugins
, dondequiera que el otro administrador de etiquetas almacene el código AppMeasurementVeremos cada una de estas opciones en la sección Actualización del código.
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.
Lea todo este documento antes de la implementación. La sección "Temporización" de abajo tiene información importante sobre cuándo debe implementar cada pieza, incluyendo ECID (si aún no se ha implementado).
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:
partner
. Esto se conoce como "subdominio de socio" o a veces "ID de socio" y será necesario cuando coloque el nuevo código SSF.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.
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.
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.
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.
Como recordatorio, existen dos tareas principales para pasar de Client-Side DIL a Server-Side Forwarding:
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… 😃
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:
Basándose en estos detalles técnicos, aquí están las recomendaciones para el momento de "qué hacer cuando":
Gire el conmutador en Analytics para cada report suite que habilite para SSF
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)
Prepárese y planifique para que esté preparado para actualizar el código de DIL a SSF por report suite que habilitará para SSF:
Gire el conmutador en Analytics para habilitar el SSF
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)
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.
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:
Debido a estos elementos, se puede complicar un poco. Lo mejor que puedo sugerir son:
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.