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 Adobe Analytics como fuente de informes para Adobe Target (A4T).
¿Admite Analytics for Adobe Target (A4T) ofertas de redireccionamiento? section_46B8B03ED4D542C6AD875F5F61176298
¿Cuáles son los requisitos mínimos para utilizar ofertas de redireccionamiento con A4T? section_FA9384C2AA9D41EDBCE263FFFD1D9B58
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.
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?
¿Cómo puedo minimizar las discrepancias en la distribución del tráfico al utilizar ofertas de redireccionamiento en actividades de A4T? discrepancies
Un número limitado de clientes ha informado de grados de variación más altos en la distribución del tráfico al utilizar ofertas de redireccionamiento en actividades configuradas con Analytics for Target (A4T).
Tenga en cuenta lo siguiente:
-
El orden incorrecto de las llamadas a Target y Analytics puede ser responsable de grados de variación más altos.
La llamada de Target debe preceder a la llamada de Analytics 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 varias Target solicitudes de ubicación en la página de origen (donde se produce la redirección), Adobe recomienda que ejecute la actividad de redirección en la primera Target solicitud de ubicación.
La ejecución de la actividad de redireccionamiento en la primera solicitud de ubicación de Target reduce las posibilidades de que se cuenten en el informe las cualificaciones de actividad que se produzcan en otras Target solicitudes de ubicación. Los visitantes que son redirigidos no tienen por qué contarse en los informes de otras actividades, ya que no verán las experiencias.
¿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? section_B8F6CC2190B84CF08D945E797C5AF07B
Al utilizar la versión 1.6.3 o posterior de at.js, el recuento de vistas de página en ambas páginas no supone un problema. Esta condición de carrera solo afecta a los clientes que utilizan versiones más antiguas. El equipo de Target mantiene dos versiones de at.js: la actual y la penúltima. Actualice at.js cuando sea posible para garantizar que dispone de versión compatible.
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.
¿Son compatibles el Compositor de experiencias visuales (VEC) y el Compositor de experiencias basado en formularios? section_FDA26FE7909B48539DA770559E687677
Sí, ambos son compatibles siempre y cuando 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? section_BA73E8B3CFCC4CBEB5BE3F76B2BC8682
Los siguientes parámetros de cadena de consulta están asociados con ofertas de redireccionamiento:
table 0-row-2 1-row-2 2-row-2 | |
---|---|
Parámetro | Descripción |
adobe_mc_sdid |
El parámetro adobe_mc_sdid pasa el ID de datos suplementarios (SDID) y el ID de organización de Experience Cloud de la página predeterminada a la nueva página. Estos ID permiten a A4T "unir" la solicitud de Target en la página predeterminada con la solicitud de Analytics en la nueva página.El formato esperado para pasar sdid en la dirección URL (para aplicaciones híbridas o de una aplicación al sitio web o un sitio web a otro) es `ex. adobe_mc_sdid=SDID=123 |
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 utiliza este valor de 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? section_0C2DDB72939F4875B6D0428B8DCB38E5
adobe_mc_sdid
y adobe_mc_ref
) se vean incluidos en la lista de permitidos.¿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? section_9E608D75FF9349FE96C65FEDD7539F45
Utilice una redirección con código personalizado si:
- 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.
¿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? section_5EFE5F012B944C40865731EA18E7E79E
Si usa A4T y ofertas de redireccionamiento, Target anexa 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. 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 que hable con su equipo de TI para asegurarse de que adobe_mc_ref
y adobe_mc_sdid
estén incluidos en la lista de permitidos de modo que estos valores no se transformen en modo alguno.
¿Por qué se debe pasar la dirección URL de referencia a la nueva página? section_91AB8B0891F6416CBF7E973DCAF54EB5
Supongamos que un visitante hace clic en un vínculo de www.google.com
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 Analytics de 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). Los informes no reflejaban el hecho de que usted llegó al sitio desde www.google.com
.
Con at.js versión 0.9.6 (o posterior) y AppMeasurement.js 2.1 (o posterior), la solicitud Analytics de la nueva página informa de que la dirección URL de referencia es www.google.com
.
¿Puedo utilizar ofertas de redireccionamiento personalizadas/HTML? section_E49F9A83A286488C8F1098A040203D7E
¿Admite Adobe Experience Platform Web SDK ofertas de redireccionamiento para A4T? platform
Las siguientes preguntas frecuentes proporcionan más información sobre el uso de A4T y redirigen ofertas con Platform Web SDK.