Migre la implementación de Audience Manager del sitio del DIL del lado del cliente al reenvío del lado del servidor migrating-your-site-s-aam-implementation-from-client-side-dil-to-server-side-forwarding
Este tutorial se aplica si tiene Adobe Audience Manager AAM () y Adobe Analytics AAM, y está enviando una visita de la página a los usuarios mediante el uso del código de DIL (Data Integration Library) y también enviando una visita de 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 permite a los servidores de recopilación de datos de Analytics reenviar los datos de análisis del sitio en tiempo real al Audience Manager AAM, en lugar de hacer que el código del lado del cliente envíe una visita adicional de la página a. Este tutorial le guiará por los pasos para realizar el cambio de la implementación de DIL del lado del cliente más antigua al método de reenvío del lado del servidor más reciente.
Lado del cliente (DIL) frente a lado del servidor client-side-dil-vs-server-side
Al comparar y contrastar estos dos métodos para introducir datos de Adobe Analytics AAM en los datos de los informes, puede resultar útil visualizar primero las diferencias en la siguiente imagen:
Implementación del DIL del lado del cliente client-side-dil-implementation
Si usa este método para obtener datos de Adobe Analytics en la página de inicio, tiene dos visitas provenientes de sus páginas web: una que va a Analytics y otra que va a la página de inicio de sesión (después de haber copiado los datos de Analytics en la página web). La página de inicio de sesión de AAM AAM tiene dos visitas provenientes de sus páginas web: una que va a y otra que va a la página de inicio (después de haber copiado los datos de ). AAM Segments se devuelven de los recursos de la página, donde se pueden usar para la personalización, entre otros. Se considera una implementación heredada y ya no se recomienda.
Además de no seguir las prácticas recomendadas, las desventajas de utilizar este método son las siguientes:
- Dos visitas procedentes de la página en lugar de una sola
- AAM se requiere el reenvío del lado del servidor para el uso compartido en tiempo real de audiencias de la en Analytics, de modo que las implementaciones del lado del cliente no permiten esta característica (y posiblemente otras características en el futuro)
AAM Se recomienda pasar a un método de reenvío del lado del servidor para la implementación de la.
Implementación del reenvío del lado del servidor server-side-forwarding-implementation
Como se muestra en la imagen anterior, una visita procede de la página web a Adobe Analytics. AAM AAM Analytics reenvía esos datos a los visitantes en tiempo real, y los visitantes son evaluados en rasgos de la visita y en segments, tal como si la visita hubiera provenido directamente de la página.
Segments se devuelven en la misma visita en tiempo real de vuelta a Analytics, que reenvía la respuesta en a la página web para su personalización, etc.
El paso al reenvío del lado del servidor no presenta inconvenientes temporales. El Adobe recomienda encarecidamente que cualquier persona que tenga tanto Audience Manager como Analytics utilice este método de implementación.
Tiene dos tareas principales you-have-two-main-tasks
Hay bastante información en esta página, y todo es importante, por supuesto. Sin embargo, todo se reduce a dos cosas principales que debe hacer:
- Cambie el código del código del DIL del lado del cliente al código de reenvío del lado del servidor
- Invertir el modificador en 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 agregado pasos y datos adicionales a este documento para ayudarle a realizar estos dos pasos correctamente para su configuración.
Opciones de implementación implementation-options
A medida que pasa del lado del cliente al reenvío del lado del servidor, una de las tareas que tendrá es cambiar el código al nuevo código de reenvío del lado del servidor. Esto se realiza mediante una de las siguientes opciones:
- Etiquetas de Adobe Experience Platform: opción de implementación recomendada por el Adobe para propiedades web. Verá que esto 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 la función
doPluginsdentro del archivoappMeasurement.jssi (aún) no está utilizando Launch de Adobe - Otros administradores de etiquetas: se pueden tratar igual que la opción anterior (en la página), ya que aún colocará el código SSF en
doPlugins, independientemente de si el otro administrador de etiquetas almacena el código AppMeasurement
Observaremos cada uno de estos elementos en la sección Actualización del código.
Pasos de implementación implementation-steps
Los siguientes pasos describen la implementación.
Paso 0: Requisito previo: Servicio de ID de Experience Cloud (ECID) step-prerequisite-experience-cloud-id-service-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 solo tiene que instalar la extensión ECID y hará el resto.
Si usa un sistema de administración de etiquetas que no es de Adobe o no lo usa, implemente ECID para ejecutar antes de cualquier otra solución de Adobe. Consulte la documentación de ECID para obtener más información. El único otro requisito previo es con respecto a las versiones del código, por lo que al aplicar las versiones más recientes del código en los siguientes pasos, estará bien.
Paso 1: Registrar las opciones utilizadas actualmente del código de DIL step-record-currently-used-options-from-dil-code
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 AAM, incluida la configuración personalizada y los datos enviados a los. Los aspectos a tener en cuenta incluyen:
- Variables Analytics normales, con el módulo de DIL
siteCatalyst.init: no tiene que preocuparse por esta, ya que su trabajo consiste únicamente en enviar las variables Analytics normales, y esto sucede simplemente porque tiene habilitado el reenvío del lado del servidor. - Subdominio de socio: en la función
DIL.create, anote el parámetropartner. Esto se conoce como su "subdominio de socio", o a veces "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 su "Org ID" o "IMS Org ID", también lo necesitará cuando configure el nuevo código de reenvío del lado del servidor. Tome nota de ello.
- containerNSID, uuidCookie y otras opciones avanzadas: tome nota de cualquier opción avanzada adicional que esté utilizando para poder establecerla también en el código de reenvío del lado del servidor.
- AAM Variables de página adicionales: si se envían otras variables a desde la página (además de las variables normales Analytics gestionadas por siteCatalyst.init), tendrá que tomar nota de ellas para que se puedan enviar mediante reenvío del lado del servidor (alerta de spoiler: a través de variables contextData).
Paso 2: Actualizar el código step-updating-the-code
En Opciones de implementación (arriba) se ofrecen varias opciones con respecto a 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 mejor describa sus necesidades.
Etiquetas Adobe Experience Platform launch-by-adobe
Vea el siguiente vídeo para obtener más información sobre cómo mover las opciones de implementación del código del DIL del lado del cliente al reenvío del lado del servidor en Experience Platform Launch.
Administrador de etiquetas "En la página" o que no sea de Adobe on-the-page-or-non-adobe-tag-manager
Vea el siguiente vídeo para obtener información sobre cómo mover opciones de implementación del código de DIL del lado del cliente al reenvío del lado del servidor en código AppMeasurement, que reside en un archivo o en un sistema de administración de etiquetas que no es de Adobe.
Paso 3: Habilitar el reenvío (por Report Suite) step-enabling-the-forwarding-per-report-suite
Hasta ahora, en este tutorial hemos dedicado todo nuestro tiempo a cambiar el código del DIL del lado del cliente al reenvío del lado del servidor. Eso 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 activación del reenvío tardará hasta 4 horas en implementarse completamente en el servidor del Experience Cloud.
Programación timing
Como recordatorio, existen dos tareas principales para pasar de un DIL del lado del cliente al reenvío del lado del servidor:
- Actualización del código
- Cambiando el conmutador en Analytics Admin Console
Pero la pregunta es, ¿cuál haces primero? ¿Importa? Vale, lo siento, fueron dos preguntas. Pero las respuestas son… depende, y sí, puede importar. ¿Cómo es eso de vago? Vamos a descomponerlo… Pero primero una pregunta adicional que puede surgir si usted 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 por pieza.
Un poco más profundo a-little-deeper-dive
La razón por la que el tiempo y el orden son importantes es por el modo en que funciona el reenvío de realmente, lo cual se puede resumir en los siguientes hechos técnicos:
- Si tiene implementado el Servicio de ID de Experience Cloud AAM (ECID) y el conmutador en Analytics Admin Console ("el conmutador") está activado, los datos SE REENVIARÁN de Analytics a, aunque aún no haya actualizado el código.
- Si no tiene implementado ECID, los datos no se reenviarán, aunque tenga el conmutador encendido 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 report suite, pero que el código lo gestiona la propiedad en etiquetas de Platform o el archivo AppMeasurement si no utiliza etiquetas de Platform.
Prácticas recomendadas best-practices
En función de estos detalles técnicos, estas son las recomendaciones para el momento de qué hacer y cuándo:
Si TODAVÍA NO ha implementado ECID if-you-do-not-have-ecid-yet-implemented
-
Cambie el conmutador Analytics para cada report suite que habilitará para el reenvío del lado del servidor.
- El reenvío aún no comienza porque no tiene ECID.
-
Por sitio, actualice el código del DIL del lado del cliente al reenvío del lado del servidor (esto podría estar en las etiquetas de Platform ) o en la página, como se describe en otra sección anterior).
- El reenvío ahora fluye (tal como ha agregado ECID) y también debería recibir una respuesta JSON adecuada para su señalización Analytics (consulte la sección Validación y solución de problemas a continuación para obtener más detalles).
Si tiene ECID implementado if-you-do-have-ecid-implemented
-
Prepare y planifique para que esté listo para actualizar su código de DIL a reenvío del lado del servidor PER report suite que habilitará para el reenvío del lado del servidor:
-
Cambie el conmutador Analytics para habilitar el reenvío del lado del servidor.
- El reenvío comenzará porque tiene ECID habilitado.
-
Actualice lo antes posible el código del DIL del lado del cliente al reenvío de un solo lado (puede estar en las etiquetas de Platform o en la página, como se explica en otra sección anterior).
- Debe recibir una respuesta JSON adecuada a su señalización Analytics (consulte la sección Validación y solución de problemas más abajo para obtener más detalles).
-
Tiempo de migración cuando tiene muchos sitios y report suites migration-timing-when-you-have-many-sites-and-report-suites
Este tema se trata brevemente en secciones anteriores, ya que la estrategia principal se puede resumir 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 función de algunos escenarios posibles:
- Tiene un sitio que contiene varios report suites distintos
- Tiene un(a) report suite que incluye varios sitios (como un(a) report suite global)
- Utilice una propiedad de etiquetas de Platform para cubrir varios sitios
- Tiene diferentes equipos de desarrollo para diferentes sitios
Debido a estos artículos, puede ser un poco complicado. Las mejores cosas que puedo sugerir son:
- Dedique algún tiempo a crear una estrategia para migrar al reenvío del lado del servidor, en función de los aspectos explicados anteriormente
- Teniendo en cuenta que una sola propiedad en etiquetas de Platform (o un solo archivo de AppMeasurement) suele asignarse a 1 o 2 report suites distintos, probablemente podrá realizar un plan que funcione en estos grupos distintos uno por uno, actualizando la empresa al reenvío del lado del servidor
- Si está trabajando con Adobe Consulting, 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 validation-and-troubleshooting
La manera principal de comprobar que el reenvío del lado del servidor funciona es consultar la respuesta a cualquiera de sus visitas de Adobe Analytics que llegan desde la aplicación.
Si no reenvía datos del lado del servidor de Analytics al Audience Manager, no hay respuesta a la señalización Analytics (más allá de un píxel 2x2). Sin embargo, si está realizando el reenvío del lado del servidor, puede comprobar ciertos elementos en la solicitud y la respuesta de Analytics que le permiten saber que Analytics se está comunicando correctamente con el Audience Manager, reenviando la visita y obteniendo una respuesta.
stuff en la respuesta. Si no lo hace, puede que vea un mensaje que dice "status":"SUCCESS". Por muy loco que suene, esto es en realidad la prueba de que NO está funcionando correctamente.
Para obtener más información acerca del reenvío del lado del servidor, consulte la documentación.