Show Menu
TEMAS×

Ofertas de redireccionamiento: preguntas más frecuentes sobre A4T

En este tema encontrará respuestas a preguntas que se plantean a menudo sobre el uso de ofertas de redireccionamiento al usar Analytics como fuente de informes para Target (A4T).

¿Admite Analytics for Target (A4T) ofertas de redireccionamiento?

Sí, siempre que su implementación utilice at.js. Sin embargo, la implementación debe cumplir los requisitos mínimos enumerados a continuación para utilizar ofertas de redireccionamiento en actividades que usen Analytics como fuente de informes.
Hay un problema conocido que provoca que un número limitado de clientes que utilizan redireccionamientos con A4T vean un porcentaje más alto de tasas de visitas no vinculadas. Consulte Problemas conocidos y problemas resueltos .

¿Cuáles son los requisitos mínimos para utilizar ofertas de redireccionamiento con A4T?

Su implementación debe cumplir los siguientes requisitos mínimos:
  • 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.
    La biblioteca mbox.js no admite ofertas de redireccionamiento con A4T. La implementación debe utilizar at.js.
Las tres bibliotecas deben incluirse en la página con la oferta de redireccionamiento y en aquella a la que se redireccione al visitante.

¿Por qué algunas veces hay discrepancias en los datos entre A4T y Analytics?

Se esperan algunas discrepancias en los datos. Para obtener más información, consulte Variaciones de datos previstas entre Target y Analytics al utilizar y no utilizar A4T .

¿Por qué las vistas de página a veces se cuentan en la página original y a veces en la página de redirección?

Al utilizar la versión 1.6.3 o posterior de at. js, no es un problema. Esta condición de carrera solo afecta a los clientes que utilizan versiones anteriores. El equipo de Target mantiene dos versiones de at. js: la versión actual y la segunda versión más reciente. Upgrade at.js as necessary to ensure that you are running a supported version .
Si utiliza una versión anterior 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. Esto puede provocar que se cuenten tanto las vistas de página de la página original como las de 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.
Para aumentar la velocidad de redirección de la página, se recomienda utilizar el compositor basado en formulario para crear una actividad de redirección. Esto depende del lugar de la página en que se ejecuta el código. 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. Así se garantiza que si se produce un error de recuento, este se produzca en todas las experiencias, de modo que los informes y los análisis sigan siendo válidos para la prueba.
Una de las razones por las que puede interesarle utilizar ofertas de redireccionamiento para todas las experiencias de la actividad, incluida la experiencia predeterminada (control), es reunir las mismas condiciones en todas las experiencias. Por ejemplo, si la experiencia predeterminada no tiene una oferta de redireccionamiento pero las demás experiencias tienen ofertas de redireccionamiento, 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 escenarios permanentes, como personalización. Después de determinar el ganador, debe eliminar la redirección para mejorar el rendimiento de carga de página.
For more information about this issue, see the "Redirect offers" information in Known Issues .

¿Puedo utilizar ofertas de redireccionamiento con A4T si empleo la biblioteca mbox.js de JavaScript?

La biblioteca mbox.js no admite ofertas de redireccionamiento con A4T. La implementación debe utilizar at.js.

¿Son compatibles el Compositor de experiencias visuales (VEC) y el Compositor de experiencias basado en formularios?

Sí, ambos son compatibles mientras se utilicen las ofertas de redireccionamiento integradas.
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).

¿Cuáles son los nuevos parámetros de cadena de consulta agregados a las direcciones URL de redireccionamiento?

Los siguientes parámetros de cadena de consulta se asocian con las ofertas de redireccionamiento:
Parámetro
Descripción
adobe_mc_sdid
El parámetro adobe_mc_sdid pasa los valores Supplemental Data Id (SDID) y Experience Cloud Org Id de la página predeterminada a la nueva página para que A4T “vincule” la solicitud de Target para la página predeterminada con la solicitud de Analytic de la nueva página.
adobe_mc_ref
El parámetro adobe_mc_ref pasa la dirección URL de referencia de la página predeterminada a la nueva página. Cuando se utiliza con la versión 2.1 (o posterior) de AppMeasurement.js, Analytics emplea el valor de este parámetro como dirección URL de referencia en la nueva página.
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.

Mis servidores web eliminan estos parámetros de mis direcciones URL, ¿qué debo hacer?

Debe trabajar junto a su equipo de TI para que los parámetros ( adobe_mc_sdid y adobe_mc_ref ) resulten admitidos.

¿Qué sucede si yo no utilizo A4T en mi actividad de redireccionamiento y no quiero que se agreguen estos parámetros adicionales a mis direcciones URL?

Si no utiliza A4T en su actividad de redireccionamiento, tiene implementado el servicio Visitor Id y no quiere que estos parámetros se agreguen automáticamente a sus direcciones URL, debe utilizar código personalizado para el redireccionamiento.
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.

¿Por qué los parámetros adobe_mc_ref y adobe_mc_sdid se codifican dos veces en la dirección URL en mi implementación?

Si utiliza A4T y ofertas de redireccionamiento, Target añade los parámetros adobe_mc_ref y adobe_mc_sdid a la dirección URL. Estos valores ya están codificados en la dirección URL. La mayoría de las veces, todo funciona según lo esperado, pero algunos clientes podrían disponer de equilibradores de carga o servidores WEB que traten de codificar una vez más los parámetros de la cadena de consulta.
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. Esto provoca que se envíen valores SDID incorrectos a Target y a Analytics, y que se vean divisiones de redireccionamiento desiguales en los informes de Analytics.
Se recomienda hablar con el equipo de TI para asegurar que adobe_mc_ref y adobe_mc_sdid estén en la lista de admitidos, de manera que estos valores no se transformen de modo alguno.

¿Por qué se debe pasar la dirección URL de referencia a la nueva página?

Supongamos que un visitante hace clic en `www.google.com` en un vínculo a su página de inicio ([ www.mysite.com/index.html] ), y que una actividad de redireccionamiento en dicha página lo redirige a una nueva página (`www.mysite.com/index2.html`).
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 las versiones 0.9.6 (o posterior) de at.js y 2.1 (o posterior) de AppMeasurement.js, la solicitud de Analytics para la nueva página informa de que la dirección URL de referencia es `www.google.com`.

¿Puedo utilizar ofertas de redireccionamiento personalizadas/HTML?

No, debe utilizar una oferta de redireccionamiento integrada para las actividades que empleen Analytics como fuente de informes (A4T). Desde la perspectiva de Target, las ofertas HTML son opacas: Target no tiene forma de saber si un fragmento particular de HTML contiene código JavaScript que crea una instancia de redireccionamiento.