Ofertas de redireccionamiento: preguntas más frecuentes sobre A4T

• Servicio ID de visitante de Experience Cloud: visitorAPI.js versión 2.3.0 o posterior.
• Adobe Analytics: appMeasurement.js versión 2.1.
• Adobe Target: at.js versión 1.6.2 o posterior.

Las tres bibliotecas deben incluirse en la página con la oferta de redireccionamiento y en aquella a la que se redireccione al visitante.

Tenga en cuenta lo siguiente:

• Orden incorrecto de Target y Analytics las llamadas de podrían ser responsables de grados de variación más altos.

  El Target La llamada de debe preceder a Analytics invoque en la página de origen (donde se produce el redireccionamiento) y en la página de destino (donde termina el redireccionamiento).

• Asegúrese de utilizar ofertas de redireccionamiento en las actividades de redireccionamiento de A4T.

• Si hay varios Target solicitudes de ubicación en la página de origen (donde se produce la redirección), Adobe recomienda ejecutar la actividad de redireccionamiento en la primera Target solicitud de ubicación.

  Ejecución de la actividad de redirección en la primera Target la solicitud de ubicación reduce las posibilidades de que se produzcan cualificaciones de actividad en otros Target solicitudes de ubicación y cómo se cuentan en el informe. Los visitantes que son redirigidos no tienen por qué contarse en los informes de otras actividades, ya que no verán las experiencias.

Si utiliza una versión anterior y no compatible de at.js, existe la posibilidad de que se produzca una condición de carrera que pueda provocar que la llamada de Analytics se active antes de que se ejecute la redirección en la primera página. Esta situación puede provocar que se cuenten las vistas de página en la página original y en la página de redirección. Como consecuencia, se cuenta una vista de página adicional en la primera página, cuando en realidad el visitante nunca “vio” esa primera página.

Se recomienda utilizar el compositor basado en formularios para crear una actividad de redireccionamiento a fin de aumentar la velocidad del redireccionamiento de páginas, ya que el código se ejecuta en la página. También se recomienda crear una oferta de redireccionamiento para cada experiencia, incluso para la experiencia predeterminada, en la que la redirección devuelva la página original. La creación de una oferta de redireccionamiento para cada experiencia garantiza que, si se produce un recuento incorrecto, se produzca en todas las experiencias. Los informes y análisis siguen siendo válidos para la prueba.

Una ventaja de utilizar ofertas de redireccionamiento para todas las experiencias de la actividad, incluida la experiencia predeterminada (control), es que puede reunir las mismas condiciones en todas las experiencias. Por ejemplo, si la experiencia predeterminada no tiene una oferta de redireccionamiento y las demás experiencias sí, la velocidad de la experiencia sin la oferta de redireccionamiento tiene una ventaja inherente. Solo se recomiendan las ofertas de redireccionamiento para situaciones temporales, como las pruebas. No se recomiendan ofertas de redireccionamiento para situaciones permanentes, como la personalización. Después de determinar el "ganador", debe eliminar la redirección para mejorar el rendimiento de carga de página.

Si utiliza su propio código personalizado para el redireccionamiento, debe asegurarse de rellenar los dos nuevos parámetros asociados con direcciones URL de redireccionamiento (adobe_mc_sdid y adobe_mc_ref, explicados más adelante).

Estos parámetros se agregan automáticamente a las direcciones URL de redireccionamiento al utilizar las ofertas de redireccionamiento integradas en el Compositor de experiencias visuales y el Compositor de experiencias basado en formularios cuando se implementa en la página el servicio Visitor Id. Si está utilizando código personalizado de redireccionamiento en VEC o el Compositor de experiencias basado en formularios, debe asegurarse de pasar estos parámetros junto al código personalizado.

• No utiliza A4T en su actividad de redireccionamiento
• Ha implementado el servicio de ID de visitante
• No desea que estos parámetros se agreguen automáticamente a las direcciones URL

En cualquier caso, se recomienda mantener el parámetro adobe_mc_ref en la dirección URL para transmitir correctamente a Analytics la información del referente.

Debido a esta doble codificación, cuando la API de visitante intenta descodificar el valor adobe_mc_sdid, no consigue extraer el valor SDID y genera un SDID nuevo. Este proceso lleva a que se envíen valores SDID incorrectos a Target y Analytics, y que se vean divisiones de redireccionamiento desiguales en los informes de Analytics.

El Adobe recomienda hablar con su equipo de TI para asegurarse de que adobe_mc_ref y adobe_mc_sdid están incluidos en la lista de permitidos para que estos valores no se transformen de ninguna manera.

Anteriormente, la solicitud de Analytics para la nueva página informaría de que la dirección URL de referencia es www.mysite.com/index.html, no www.google.com. Este comportamiento provocaba informes imprecisos en Analytics en cuanto a las direcciones URL de referencia (por ejemplo, en los informes de canales de mercadotecnia). No se reflejaba el hecho de que se había llegado al sitio desde www.google.com.

Con at.js versión 0.9.6 (o posterior) y AppMeasurement.js 2.1 (o posterior), la variable Analytics en los informes de nueva página, una dirección URL de referencia de www.google.com.