Preguntas más frecuentes de at.js

Respuestas a las preguntas más frecuentes sobre la biblioteca JavaScript Adobe Target at.js.

¿Cuáles son las ventajas de usar at.js en lugar de mbox.js?

La biblioteca at.js reemplaza a mbox.js. La biblioteca mbox.js ya no es compatible. Sin embargo, para la mayoría de las personas, at.js proporciona ventajas con respecto a mbox.js.

Entre otros beneficios, at.js mejora los tiempos de carga de página en implementaciones web, mejora la seguridad y proporciona mejores opciones de implementación en aplicaciones de una sola página.

El diagrama siguiente compara el rendimiento de carga de página de mbox.js y at.js.

Como se ilustra más arriba, al usar mbox.js, el contenido de la página no empezó a cargarse hasta que no se completó la llamada Target . Con at.js, el contenido de la página empieza a cargarse cuando se inicia la llamada a Target y no espera hasta que ha finalizado.

¿Cuál es el impacto de at.js y mbox.js en el tiempo de carga de página?

Muchos clientes y consultores quieren conocer el impacto de at.js y mbox.js en el tiempo de carga de página, especialmente en el contexto de los nuevos usuarios frente a los que regresan. Lamentablemente, es difícil medir y ofrecer números concretos sobre la influencia de at.js o mbox.js en el tiempo de carga, ya que cada cliente dispone de una implementación diferente.

Sin embargo, si la API de visitante está presente en la página, Target puede comprender mejor cómo influyen at.js y mbox.js en el tiempo de carga de la página.

NOTA

La API de visitante y at.js o mbox.js solo afectan al tiempo de carga de página cuando utiliza el mbox global (debido a la técnica de ocultación del cuerpo). Los mboxes regionales no se ven afectados por la integración del API de visitante.

La siguiente tabla describe la secuencia de acciones para los visitantes nuevos y los habituales:

Visitantes nuevos

  1. El API de visitante se carga, se analiza y se ejecuta.

  2. at.js/mbox.js se carga, se analiza y se ejecuta.

  3. Si la creación automática de mbox global está habilitada, la biblioteca JavaScript de Target:

    • Crea una instancia del objeto Visitante.
    • La biblioteca Target intenta recuperar los datos Experience Cloud Visitor ID.
    • Como este visitante es un visitante nuevo, la API de visitante activa una solicitud entre dominios dirigida a demdex.net.
    • Una vez recuperados los datos Experience Cloud Visitor ID, se activa una solicitud a Target.

Visitantes que regresan

  1. El API de visitante se carga, se analiza y se ejecuta.

  2. at.js/mbox.js se carga, se analiza y se ejecuta.

  3. Si la creación automática de mbox global está habilitada, la biblioteca JavaScript Target:

    • Crea una instancia del objeto Visitante.
    • La biblioteca Target intenta recuperar los datos Experience Cloud Visitor ID.
    • La API de visitante recupera datos de las cookies.
    • Una vez recuperados los datos Experience Cloud Visitor ID, se activa una solicitud a Target.
NOTA

Para los nuevos visitantes, cuando la API de visitante está presente, Target tiene que actuar varias veces para asegurarse de que las solicitudes Target contienen Experience Cloud Visitor ID datos. Para los visitantes que regresan, Target va únicamente a Target para recuperar el contenido personalizado.

¿Por qué parece que se obtienen tiempos de respuesta más lentos después de actualizar desde una versión anterior de at.js a la versión 1.0.0?

at.js 1.0.0 y las versiones posteriores activan todas las solicitudes en paralelo. Las versiones anteriores ejecutan las solicitudes de forma secuencial, lo que significa que se ponen en cola y Target espera a que la primera se complete antes de pasar a la siguiente.

El modo en que versiones anteriores de at.js ejecutan las solicitudes es susceptible al llamado “bloqueo de cabeza de línea”. En at.js 1.0.0 y versiones posteriores, cambió a la ejecución de solicitudes en paralelo.Target

Por ejemplo, si se comprueba el esquema de etiquetas de red de at.js 0.9.1, se ve que no se comienza una solicitud de hasta que la anterior ha finalizado. Target Esta secuencia no es el caso de at.js 1.0.0 y posterior, donde todas las solicitudes comienzan básicamente al mismo tiempo.

Desde la perspectiva del tiempo de respuesta, matemáticamente, esta secuencia se puede resumir de esta manera

  • at.js 0.9.1: Tiempo de respuesta de todas las solicitudes de Target = suma del tiempo de respuesta de las solicitudes
  • at.js 1.0.0 y versiones posteriores: Tiempo de respuesta de todas las solicitudes de Target = tiempo máximo de respuesta de las solicitudes

La versión 1.0.0 de la biblioteca at.js completa las solicitudes más rápido. Además, las solicitudes de at.js son asíncronas, de modo que no bloquea la representación de páginas. Target Aunque las solicitudes tarden segundos en completarse, seguirá viendo la página representada; no obstante, algunas partes de la página quedarán en blanco hasta que Target obtenga una respuesta del borde Target.

¿Puedo cargar la biblioteca Target asincrónicamente?

La versión at.js 1.0.0 permite cargar la biblioteca Target de forma asíncrona.

Para cargar at.js de forma asíncrona:

  • El método recomendado es mediante etiquetas en Adobe Experience Platform.

  • También puede cargar at.js de forma asíncrona añadiendo el atributo async a la etiqueta de script que carga at.js. Utilice algo similar a esto:

    <script src="<URL to at.js>" async></script>
    
  • También puede cargar at.js de forma asíncrona utilizando este código:

    var script = document.createElement('script'); 
    script.async = true; 
    script.src = "<URL to at.js>"; 
    document.head.appendChild(script);
    

Cargar at.js de forma asíncrona es un modo excelente de evitar el bloqueo de presentación por parte del navegador; sin embargo, esta técnica puede producir parpadeos en la página web.

Puede evitar el parpadeo utilizando un fragmento de ocultamiento previo que oculta la página (o partes especificadas) y luego lo revela después de que se hayan cargado at.js y la solicitud global. El fragmento debe añadirse antes de cargar at.js.

Si va a implementar at.js a través de una implementación asíncrona Adobe Experience Platform, asegúrese de incluir el fragmento de ocultamiento previo directamente en las páginas, antes de implementar Target mediante Adobe Experience Platform código incrustado.

Si implementa at.js a través de una implementación sincrónica de DTM, el fragmento de ocultamiento previo se puede añadir a través de una regla de carga de página activada en la parte superior de la misma.

Para obtener más información, consulte Cómo gestiona at.js el parpadeo.

¿at.js es compatible con la integración Adobe Experience Manager (Experience Manager)?

Ahora, Adobe Experience Manager 6.2 con FP-11577 (o posterior) es compatible con las implementaciones de at.js mediante su integración Servicios de nube de Adobe Target.

¿Cómo puedo evitar el parpadeo en la carga de la página al utilizar at.js?

Target ofrece varias maneras de prevenir el parpadeo en la carga de la página. Para obtener más información, consulte Prevención de parpadeo con at.js.

¿Cuál es el tamaño de archivo de at.js?

El archivo at.js pesa aproximadamente 109 kB cuando se descarga. Sin embargo, como la mayoría de los servidores comprimen los archivos automáticamente para reducir el tamaño, el at.js pesa unos 34 kB cuando se comprime (mediante GZIP u otro método) en el servidor y se carga con las visitas de los usuarios a su sitio web. La configuración de compresión definida en el servidor donde instaló at.js determina su tamaño comprimido real.

¿Por qué at.js es más grande que mbox.js?

Las implementaciones de at.js utilizan una sola biblioteca (at.js), mientras que las de mbox.js utilizan dos bibliotecas (mbox.js y target.js). Así pues, una comparación más justa sería de at.js con mbox.js y target.js. Comparando los tamaños comprimidos en formato gzip de las dos versiones, la versión 1.2 de at.js ocupa 34 kB y la versión 63 de mbox.js, 26,2 kB. ``

at.js tiene un tamaño mayor porque realiza mucho más análisis de DOM en comparación con mbox.js. Esto es necesario porque at.js obtiene datos “sin procesar” en la respuesta de JSON y tiene que darle sentido. mbox.js usaba document.write() y todo el análisis lo realizaba el explorador.

A pesar del mayor tamaño de archivo, nuestra prueba determina que las páginas se cargan más rápido con at.js en comparación con mbox.js. Además, at.js es superior desde una perspectiva de seguridad porque no carga archivos adicionales de forma dinámica ni utiliza document.write.

¿at.js incluye jQuery? ¿Puedo eliminar esta parte de at.js porque ya cuento con jQuery en mi sitio web?

Actualmente, at.js utiliza partes de jQuery y, por lo tanto, puede ver la notificación de licencia de MIT en la parte superior de at.js. jQuery no se expone y no interfiere con la biblioteca jQuery que ya tenga en su página, cuya versión es posible que difiera. No admite la eliminación del código jQuery en at.js.

¿at.js permite definir Safari y el dominio cruzado en x-solamente?

No, si el dominio cruzado se establece en x-solamente y Safari tiene deshabilitadas las cookies de terceros, tanto mbox.js como at.js establecen una cookie deshabilitada y no se ejecuta ninguna solicitud de mbox para el dominio de ese cliente en particular.

Para permitir el acceso desde Safari, habría que “deshabilitar” (solo establece una cookie de origen) o “habilitar” (solo establece una cookie de origen en Safari, pero establece cookies de origen y de terceros en otros navegadores) un mejor dominio x.

¿Puedo usar el Target Compositor de experiencias visuales (VEC) en mis aplicaciones de una sola página?

Sí, puede usar el VEC para su SPA si utiliza at.js 2.x. Para obtener más información, consulte Compositor de experiencias visuales de una sola página (SPA).

¿Puedo usar el Adobe Experience Cloud Debugger con implementaciones de at.js?

Sí. También puede utilizar mboxTrace con fines de depuración, o puede usar las herramientas de desarrollo de su navegador para inspeccionar las solicitudes de red y filtrar “mbox”, aislando así las llamadas a mbox.

¿Puedo utilizar caracteres especiales en nombres de mbox con at.js?

Sí, igual que con mbox.js.

¿Por qué no se activan los mboxes en mis páginas web?

Target a veces, los clientes utilizan instancias basadas en la nube con Target para realizar pruebas o simplemente exponer conceptos. Estos dominios, y muchos otros, son parte de la Lista pública de sufijos.

Los navegadores modernos no guardan las cookies si se utilizan estos dominios, a menos que se personalice la configuración cookieDomain mediante targetGlobalSettings(). Para obtener más información, consulte Uso de instancias basadas en la nube con Target.

¿Pueden usarse direcciones IP como el dominio de la cookie al utilizar at.js?

Compruebe que está utilizando la versión 1.2 o posterior de at.js. Adobe recomienda mantener actualizado con la versión más reciente, sin embargo.

NOTA

Los siguientes ejemplos no son necesarios si utiliza la versión 1.2 o posterior de at.js.

Según la forma en que use targetGlobalSettings, es posible que tenga que realizar más modificaciones en el código tras descargar at.js. Por ejemplo, si necesita emplear unas configuraciones que difieran un poco para las implementaciones de Target en varios sitios web y no puede definirlas de forma dinámica mediante JavaScript personalizado, haga las personalizaciones manualmente después de descargar el archivo y antes de cargarlo en el sitio web correspondiente.

Los siguientes ejemplos le permiten utilizar la función targetGlobalSettings() de at.js para insertar un fragmento de código para admitir las direcciones IP:

Este ejemplo es para una dirección IP única:

if (window.location.hostname === '123.456.78.9') { 
    window.targetGlobalSettings = window.targetGlobalSettings || {}; 
    window.targetGlobalSettings.cookieDomain = window.location.hostname; 
}

Este ejemplo es para un intervalo de direcciones IP:

if (/^123\.456\.78\..*/g.test(window.location.hostname)) { 
    window.targetGlobalSettings = window.targetGlobalSettings || {}; 
    window.targetGlobalSettings.cookieDomain = window.location.hostname; 
}

¿Por qué veo mensajes de aviso como “acciones con selectores ausentes”?

Estos mensajes no están relacionados con la funcionalidad at.js . La biblioteca at.js intenta informar de todo lo que no pueda encontrarse en el DOM.

Las siguientes son posibles causas para que aparezca este mensaje de advertencia:

  • La página se está creando dinámicamente y at.js no puede encontrar el elemento .

  • La página se está creando lentamente (debido a una red lenta) y at.js no puede encontrar el selector en el DOM.

  • Se ha cambiado la estructura de la página en la que se ejecuta la actividady. Si vuelve a abrir la actividad en elCompositor de experiencias visuales (VEC), debería recibir un mensaje de advertencia. Actualice la actividad para que se puedan encontrar todos los elementos necesarios.

  • La página subyacente es parte de una Aplicación de una sola página (SPA) o la página contiene elementos que aparecen más adelante y el "mecanismo de sondeo selector" de at.js no puede encontrar esos elementos. Aumentar el valor de selectorsPollingTimeout podría ser de ayuda. Para obtener más información, consulte targetGlobalSettings().

  • Cualquier métrica de seguimiento de clics intenta añadirse a todas las páginas, independientemente de la dirección URL en la que se estableciera dicha métrica. Aunque es algo inofensivo, esta situación provoca la aparición de muchos de estos mensajes.

    Para obtener los mejores resultados, descargue y utilice la versión más reciente de at.js. Para obtener más información, consulte Detalles de versión de at.js y Descargar at.js.

¿Cuál es el dominio tt.omtrdc.net al que se dirigen las llamadas al servidor Target?

tt.omtrdc.net es el nombre de dominio de la red EDGE de Adobe, que se utiliza para recibir todas las llamadas de servidor para Target.

¿Por qué at.js no siempre utiliza los indicadores de cookies HttpOnly y Secure?

HttpOnly solo se puede establecer mediante código del servidor. TargetLas cookies de , como mbox, se crean y guardan mediante código JavaScript, de modo que no puede utilizar el indicador de cookie HttpOnly.Target Target utiliza set HttpOnly para cookies de terceros establecidas del lado del servidor cuando el dominio cruzado está habilitado.

Secure se puede establecer mediante JavaScript solo cuando la página se carga mediante HTTPS. Si la página se carga inicialmente mediante HTTP, JavaScript no puede establecer este indicador. Además, si se utiliza el indicador Secure , la cookie solo está disponible en páginas HTTPS. Para las páginas cargadas mediante HTTPS, Target establece los atributos Secure y SameSite=None .

Para asegurarse de que Target puede rastrear correctamente a los usuarios y porque las cookies se generan en el lado del cliente, Target no utiliza ninguno de estos indicadores excepto en las situaciones mencionadas anteriormente.

¿Con qué frecuencia inicia at.js una solicitud de red?

Target ejecuta todas sus decisiones en el servidor. Esto significa que at.js inicia una solicitud de red cada vez que la página se vuelve a cargar o se invoca una API pública at.js.

En el mejor de los casos, ¿podemos esperar que el usuario no experimente ningún efecto visible en la carga de la página relacionada con ocultar, reemplazar y mostrar contenido?

at.js intenta evitar la ocultación previa de los elementos BODY de HTML u otros elementos DOM durante un periodo prolongado, pero esto depende de las condiciones de red y la configuración de la actividad. at.js proporciona ajustes que puede utilizar para personalizar el estilo del CSS oculto de BODY, de modo que, en lugar de borrar todo el BODY de HTML, puede ocultar solo algunas partes de la página. La expectativa es que esas partes contengan elementos DOM que deben ser “personalizados”.

¿Cuál es la secuencia de eventos en un escenario promedio donde un usuario califica para una actividad?

La solicitud at.js es una solicitud XMLHttpRequest asincrónica, por lo que realizamos los pasos siguientes:

  1. La página se carga.
  2. at.js oculta previamente BODY de HTML. Hay una configuración para ocultar previamente un contenedor en particular en lugar de BODY de HTML.
  3. at.js solicita activaciones.
  4. Una vez recibida la respuesta Target, Target extrae los selectores CSS.
  5. Mediante selectores CSS, Target crea etiquetas STYLE para ocultar previamente los elementos DOM que se van a personalizar.
  6. Se elimina STYLE de ocultamiento previo de BODY de HTML.
  7. Target comienza a sondear los elementos DOM.
  8. Si se encuentra un elemento DOM, Target aplica los cambios DOM y el elemento de ocultamiento previo STYLE se elimina.
  9. Si no se encuentran elementos DOM, un tiempo de espera global desoculta los elementos para evitar tener una página rota.

¿Con qué frecuencia el contenido de la página está completamente cargado y es visible cuando at.js no oculta finalmente el elemento que está cambiando la actividad?

Teniendo en cuenta el escenario anterior, ¿con qué frecuencia el contenido de la página está completamente cargado y es visible cuando at.js finalmente muestra el elemento que está cambiando la actividad? En otras palabras, la página es totalmente visible, excepto por el contenido de la actividad, que luego se revela ligeramente después del resto del contenido.

at.js no bloquea el procesamiento de la página. Un usuario puede ver algunas regiones en blanco en la página que representan elementos personalizados por Target. Si el contenido que se va a aplicar no contiene muchos recursos remotos, como SCRIPT o IMG, todo debería procesarse rápidamente.

¿Cómo afectaría una página en caché completa al escenario anterior? ¿Sería más probable que el contenido de la actividad se hiciera visible después de que se cargara el resto del contenido de la página?

Si una página se almacena en caché en una CDN que está cerca de la ubicación del usuario, pero no cerca del borde Target, ese usuario podría ver algunos retrasos. Target los bordes están bien distribuidos en todo el mundo, por lo que no es un problema la mayor parte del tiempo.

¿Es posible que se muestre una imagen a pantalla completa y cambie después de un breve retraso?

Si tenemos en cuenta el escenario siguiente:

El tiempo de espera Target es de cinco segundos. Un usuario carga una página que tiene una actividad para personalizar una imagen a pantalla completa. at.js envía la solicitud para determinar si hay una actividad para aplicar, pero no hay una respuesta inicial. Supongamos que el usuario ve el contenido normal de la imagen a pantalla completa, ya que no se recibió respuesta de Target con respecto a si hay una actividad asociada. Después de cuatro segundos, Target devuelve una respuesta con el contenido de la actividad.

En este momento, ¿sería posible mostrar la versión alternativa? Entonces, después de cuatro segundos, ¿podría cambiar la imagen a pantalla completa y podría el usuario notar este cambio de imagen?

Inicialmente, el elemento DOM de la imagen a pantalla completa está oculto. Una vez recibida la respuesta de Target, at.js aplica los cambios de DOM, como reemplazar la IMG y mostrar la imagen a pantalla completa personalizada.

¿Qué tipo de documento HTML requiere at.js?

at.js requiere el tipo de documento HTML 5.

Esta sintaxis es:

<!DOCTYPE html>

El tipo de documento HTML 5 garantiza que la página se carga en modo estándar. Cuando se carga en modo quirks, algunas API de JS de las que depende at.js están desactivadas. Target deshabilita at.js en modo quirks.

En esta página