Saltar al contenido principal
Utilice el script de la aplicación Kameleoon para los experimentos web creados con el editor gráfico o el editor de código. Utilice el SDK web para los feature flags y los experimentos de funciones.Tenga en cuenta que Kameleoon puede ejecutarse en modo híbrido. El modo híbrido utiliza tanto los SDKs web como el archivo JavaScript de la aplicación Kameleoon. El modo híbrido le permite utilizar el enfoque óptimo para cada tarea. Por ejemplo, puede implementar y desplegar variaciones más fácilmente del lado del servidor, mientras que el seguimiento puede realizarse de manera más eficaz con el archivo JavaScript.
Kameleoon utiliza servidores CDN durante la inicialización. Una vez que se recibe y almacena en caché la configuración, la recuperación y la actualización se producen rápidamente (50-70 ms en función de la latencia del servidor respecto al CDN más cercano).
Existen dos métodos para obtener la configuración: Polling y Streaming.
Se utiliza el protocolo Server Side Events (SSE o EventSource).
El CDN se purga cada vez que actualiza la configuración de un feature flag (por ejemplo, variaciones, exposiciones de tráfico y segmentación), o cada 24 horas.
Si utiliza un SDK del lado del cliente y el sitio web restringe la carga de recursos (scripts, imágenes, contenido multimedia, CSS) mediante la cabecera HTTP estándar Content-Security-Policy (CSP), actualice la CSP del sitio para permitir la carga de los recursos de Kameleoon:
script-src https://[your-site-code].kameleoon.io https://[your-site-code].kameleoon.eu https://client-config.kameleoon.com https://sdk-config.kameleoon.eu https://*.experimentation.dev 'unsafe-eval';
connect-src https://[your-site-code].kameleoon.io https://[your-site-code].kameleoon.eu https://eu-data.kameleoon.eu https://eu-data.kameleoon.io https://na-data.kameleoon.eu https://na-data.kameleoon.io https://editor.kameleoon.com https://api.kameleoon.com https://customers.kameleoon.com https://logger.kameleoon.io https://client-config.kameleoon.com https://sdk-config.kameleoon.eu https://*.experimentation.dev;
Si utiliza Kameleoon en modo híbrido, el dominio de sus scripts de Kameleoon https://[your-site-code].kameleoon.xx puede variar de un proyecto a otro. Sus proyectos pueden estar alojados en kameleoon.eu o en kameleoon.io según su fecha de creación. Asegúrese de utilizar el dominio que aparece en su proyecto dentro de la aplicación Kameleoon. Sustituya [your-site-code] por el site code de Kameleoon en cada línea en la que aparezca y añádalo a su configuración.
Dado que cada instancia de servidor tiene su propia memoria, todos los datos del visitante recopilados se almacenarán en una instancia determinada. Debe utilizar un framework en el que las solicitudes del mismo visitante sean procesadas por la misma instancia del servidor. De lo contrario, los datos del visitante deben añadirse íntegramente antes de cada solicitud de seguimiento o cargarse mediante el método getRemoteVisitorData.Si el problema está en las diferencias de configuración del SDK, utilice la opción Streaming.
Todas las evaluaciones se realizan localmente para eliminar la latencia. Las solicitudes de seguimiento se envían después de forma asíncrona a los servidores de la Data API de Kameleoon.
Para asignar a un visitante a una variación de un experimento, Kameleoon primero genera un identificador utilizando el código del visitante, el ID del experimento y un posible elemento adicional en caso de respooling. A continuación, una implementación síncrona de la función hash SHA-256 calcula un hash de este identificador. El número entero obtenido mediante el hashing se asigna a un número decimal entre cero y uno para asignarlo a una variación del experimento. La función SHA-256 es determinista, por lo que el mismo usuario (con el mismo código de visitante) se asignará siempre a la misma variación de un experimento, salvo que se solicite explícitamente que se vuelva a calcular la asignación.
Siga la metodología detallada aquí.
Todos los casos posibles se explican en este artículo.
Existen varias razones por las que no se muestran datos en la página de resultados:
  • Espere de 30 a 60 minutos hasta que el servidor de Kameleoon confirme una visita. Cada vez que el mismo visitante accede al sitio web, Kameleoon crea una nueva visita. La visita finaliza en cuanto Kameleoon no recibe nuevos eventos de actividad (por ejemplo, exposición a una campaña, vista de página, scroll, clics) en los últimos 30 minutos. Kameleoon crea una nueva visita tras 30 minutos de inactividad.
  • Si ha activado el filtrado de bots en la configuración del proyecto, podría haber un error con el valor de user-agent configurado en el SDK. Consulte este artículo para más detalles.
  • El consentimiento legal está configurado como Required en los ajustes del proyecto, pero no se ha invocado el método setLegalConsent del SDK. Consulte esta documentación para más detalles.
  • No se ha utilizado ninguno de los métodos del SDK que envían una solicitud de seguimiento a los servidores de Kameleoon.
El siguiente artículo ofrece ayuda adicional para depurar el problema.
Si observa un gran número de visitas de visitantes, podrían ser bots. Para evitar que los bots afecten a su experimento, active la opción de filtrado de bots en los ajustes de su proyecto. Para indicar que un visitante no es un bot, debe pasar los datos UserAgent de Kameleoon mediante el método del SDK. La invocación del método evitará que Kameleoon filtre al usuario.
Si sus informes muestran una asignación inesperada (por ejemplo, 10/90 en lugar de 50/50) o si faltan visitantes, puede deberse a alguno de los siguientes motivos:
  • Reducción del grupo de visitantes para variaciones específicas: Si primero invoca getVariations(onlyActive: true, track: false), el SDK solo devuelve los visitantes asignados a las variaciones activas (ON). Si después solo muestra las páginas del experimento e invoca getVariation(track: true) para esos visitantes concretos, Kameleoon solo realiza el seguimiento de la variación ON, lo que resulta en un informe que muestra una única variación.
  • Tiempo insuficiente para las solicitudes de seguimiento: Kameleoon envía datos a un intervalo determinado. Si un visitante permanece en una página con un cliente Kameleoon integrado para la variación ON, pero pasa a una página sin él para la variación OFF, es posible que el cliente no tenga tiempo suficiente para enviar la solicitud de seguimiento de la variación OFF.
  • Configuración ausente para variaciones específicas: Es posible que haya omitido el UserAgent o setLegalConsent para algunas variaciones. Por ejemplo, si solo proporciona el consentimiento en la página de la variación ON, Kameleoon no podrá realizar el seguimiento de los visitantes de la variación OFF.
  • Datos del visitante ausentes: El SDK no recopila datos del visitante de forma automática; debe añadirlos explícitamente para que la segmentación y el seguimiento funcionen correctamente.

​
Compruebe la configuración de su segmentación

Si sospecha que existen problemas de segmentación, siga estos pasos:
  1. Cree una regla sin segmentación con exposición del 100 % y asigne la variación deseada.
  2. Añada la segmentación y compruebe que el usuario deja de recibir la variación.
  3. Añada los datos necesarios de Kameleoon.
El usuario debería volver a recibir la variación. Si no es así, pruebe a usar condiciones de segmentación más simples para aislar el problema.
Sí, los datos están disponibles inmediatamente para la segmentación. Los datos estarán disponibles durante la sesión del visitante en los SDKs basados en servidor y durante el tiempo de vida configurado en los SDKs basados en cliente (móviles y web).
Depende del tipo de SDK.En los SDKs de servidor, los datos del visitante se almacenan en la memoria operativa durante la sesión del visitante. La duración de la sesión puede configurarse, aunque el valor predeterminado es de 30 minutos.
Cuanto mayor sea la duración de la sesión mediante el parámetro sessionDuration, más datos retendrá el SDK en memoria. Más datos significan un mayor consumo. La sesión se prolonga 30 minutos adicionales cada vez que se contacta con un visitante. De este modo, el SDK garantiza que los datos no se eliminarán al menos durante 30 minutos desde la última solicitud.
En los SDKs cliente (móviles y web), los datos se almacenan en almacenamientos locales (en el LocalStorage del navegador). Los datos pueden almacenarse de forma indefinida; sin embargo, mediante el parámetro dataExpirationInterval o targetingDataCleanupInterval, puede establecer la fecha de expiración de los datos, tras la cual estos se eliminarán.
Por lo general, no es necesario invocar el método “flush” manualmente: los datos se envían junto con otras llamadas a los métodos del SDK. No obstante, si necesita enviar datos a la Data API sin activar el feature flag del visitante, utilice el método “flush”.
Si dispone de un SDK basado en servidor, los datos se almacenan durante la sesión de un visitante. No es necesario cargar los datos en cada solicitud si la sesión del usuario no ha caducado. En los SDKs móviles, los datos se almacenan indefinidamente (o conforme a su configuración).Si la sesión del usuario ya no está activa o si el visitante se desplaza entre dispositivos en el SDK cliente, invoque el método getRemoteVisitorData con los parámetros adecuados para obtener los datos enviados a la Data API. Tras la carga, los datos se incluyen en la segmentación del visitante.
Si el consentimiento legal está activado, los datos solo pueden recopilarse con el consentimiento de los visitantes.
Si está utilizando la regla Experimento y no recibe estadísticas de los visitantes, asegúrese de que:
  • En la aplicación Kameleoon
    • La regla se ha creado para el entorno correcto (producción, staging o desarrollo).
    • La regla está habilitada (activada).
    • La regla se dirige a tráfico que realmente puede estar expuesto.
    • Si el filtrado de bots está activado en su proyecto, añada User Agent al filtro.
  • En el SDK
    • El KameleoonClient se ha creado con la configuración correcta (siteCode, variable de entorno y, en su caso, networkDomain).
    • getVisitorCode se invoca una sola vez y su valor se reutiliza dondequiera que se necesite el visitorCode.
    • Si se utiliza el modo híbrido (engine.js en el front), el visitorCode está correctamente sincronizado con el front end.
    • Para las reglas de experimento, se invoca setLegalConsent(true) para garantizar que se permite la recopilación de datos.
    • Para las reglas de entrega, se invoca isFeatureActive() (o getVariation()) y devuelve true (o la variación esperada).
    • Para las reglas de experimento, se invoca getVariation() y devuelve la variación esperada.
  • Consejos de depuración
    • Muestre en consola: el valor del consentimiento, el visitorCode y los valores de las variaciones, y compruebe que coinciden con lo que observa en el navegador.
    • Active el registro del SDK y compruebe si aparecen errores.
Según las reglas del RGPD, sin el consentimiento del visitante, Kameleoon solo utiliza la información técnica necesaria para el correcto funcionamiento de la funcionalidad del producto.Sin consentimiento, Kameleoon envía las variaciones de las reglas de Targeted Delivery (pero no las de las reglas de Experimento). El resto de la información (por ejemplo, CustomData, vistas de página y geolocalización) se envía únicamente con el consentimiento del visitante (cuando se ha otorgado el permiso).Puede leer sobre la gestión del consentimiento con más detalle aquí.
De forma predeterminada, el SDK agrupa varios eventos y envía una solicitud de seguimiento a los servidores de Kameleoon con fines analíticos en un intervalo configurable. Este enfoque mejora la eficiencia y reduce la carga del servidor.Se enviará una solicitud de seguimiento:
  • Periódicamente: De forma predeterminada, se envía una solicitud cada 1000 milisegundos (1 segundo). Puede cambiar este intervalo configurando el valor del intervalo de seguimiento.
  • Bajo demanda: Al instante, si se invoca un método como flush(instant=true) en su código.
Concretamente, se desencadena una solicitud de seguimiento si se invoca cualquiera de los siguientes métodos antes de que expire el intervalo:
  • getVariation (cuando track se establece en true).
  • getVariations (cuando track se establece en true).
  • isFeatureActive (cuando track se establece en true).
  • trackConversion
  • flush (con o sin instant=true)
Además de las invocaciones de los métodos anteriores, los SDKs del lado del cliente envían una solicitud de seguimiento cada 15 segundos si no se ha producido ninguna otra actividad. Esta solicitud ayuda a mantener la sesión del visitante. El intervalo de seguimiento de la actividad puede configurarse con los SDKs de Android y de iOS.En el caso de los SDKs del lado del servidor, el agrupamiento de eventos resulta especialmente útil, ya que cada solicitud de seguimiento puede consolidar los datos de varios visitantes en una sola solicitud. Este enfoque agrega la información de todos los visitantes afectados y la envía una vez por intervalo, mejorando la eficiencia y reduciendo la carga del servidor.
Las solicitudes de seguimiento están sujetas a los límites de tasa de la Data API.Para los SDKs del lado del cliente, en entornos donde varios visitantes comparten la misma red (por ejemplo, en una oficina), pueden parecer originarse desde la misma dirección IP, lo que puede superar el límite de tasa y provocar un error 429 - Too Many Requests.
En diferentes SDKs los métodos pueden tener nombres distintos debido a las particularidades de cada lenguaje.
A continuación se muestra una lista de los métodos del SDK que realizan solicitudes HTTP:
  • isFeatureActive / getFeatureVariationKey / getFeatureVariable / trackConversion / flush
    • Estos métodos realizan solicitudes asíncronas a la Data API para almacenar toda la información sobre el visitante (incluidas las variaciones recibidas por el usuario), que se utilizan para mostrar estadísticas en app.kameleoon.com.
  • getRemoteData / getRemoteVisitorData / getWarehouseAudience
    • Estos métodos realizan solicitudes síncronas a la Data API para obtener información sobre el visitante.
  • Además, el SDK realiza solicitudes asíncronas para obtener la configuración necesaria para su funcionamiento interno.
isFeatureActive puede invocarse cuando necesite saber si el flag está activo, pero no necesite conocer la variación exacta recibida por el visitante. Cuando se usan reglas de experimento, es preferible invocar getFeatureVariationKey si dispone de dos o más variaciones además de “off”.
Sí, puede implementar una integración híbrida utilizando tanto un SDK del lado del cliente (como el SDK JavaScript de Kameleoon o el archivo de aplicación engine.js) como un SDK del lado del servidor. En esta configuración es imprescindible invocar el método getVisitorCode. Esto garantiza un reconocimiento coherente del visitante entre el navegador y el servidor, y asegura una asignación coherente de variaciones al ejecutar tanto el código del lado del cliente (por ejemplo, el seguimiento de eventos) como el del lado del servidor (como la ejecución de funciones) para un mismo feature flag.
Debe utilizar getVisitorCode en los casos en los que esté empleando una integración híbrida (sitio web <-> SDK servidor, JS SDK <-> servidor, engine <-> SDK servidor). Al invocar getVisitorCode, se obtendrá el código del visitante y se transmitirá mediante una cookie. Si no utiliza una integración híbrida, no necesita invocar getVisitorCode; aun así, puede invocarlo para generar un código de visitante aleatorio.
La instalación del dominio es necesaria para getVisitorCode. De lo contrario, podrían asignarse variaciones distintas a un mismo visitante, ya que tendría códigos de visitante diferentes en los distintos subdominios de su sitio.
Si utiliza simultáneamente SDKs de servidor y de cliente, debe establecer el consentimiento en ambos SDKs.Consulte este artículo para más detalles.
Kameleoon, como muchas soluciones de optimización de la experiencia, puede ser bloqueado por ciertos bloqueadores de anuncios. Estos afectan principalmente al archivo de aplicación de Web Experimentation (engine.js) y a los SDKs del lado del cliente, que dependen de código JavaScript cargado en su sitio web. Los SDKs del lado del servidor, sin embargo, operan dentro de sus servidores y no se ven afectados por los bloqueadores de anuncios.Si desea que los usuarios con bloqueadores de anuncios se incluyan en sus experimentos, Kameleoon ofrece una opción premium que le permite utilizar un dominio personalizado en lugar del dominio predeterminado de Kameleoon. Los dominios personalizados impiden que los bloqueadores de anuncios detecten y bloqueen Kameleoon. Una vez configurado, Kameleoon utilizará su dominio personalizado para todas las solicitudes de red salientes hacia nuestros servidores, ya sea con fines de seguimiento o para obtener actualizaciones de configuración del SDK.Utilizar un dominio personalizado no es lo mismo que el self-hosting. Cuando utiliza un dominio personalizado, la infraestructura de Kameleoon sigue alojando y sirviendo todo el contenido (por ejemplo, engine.js, la configuración del SDK, las llamadas de seguimiento). La diferencia es que estas solicitudes se enrutan a través de un dominio que usted controla, como experiments.mydomain.com.Para habilitar esta opción, póngase en contacto con su Technical Account Manager. Debe proporcionar un dominio completo (por ejemplo, experiments-mydomain.com), no un subdominio (por ejemplo, experiments.mydomain.com). El nombre de dominio no puede contener la subcadena kameleoon.
  • Para Web Experimentation, sustituya las referencias al dominio predeterminado de Kameleoon (kameleoon.) por su dominio personalizado.
    • Ejemplo: //SITE_CODE.{your-domain}/engine.js
  • Para los SDKs del lado del cliente, utilice el parámetro networkDomain en la inicialización del SDK.
Si prefiere alojar usted mismo en lugar de usar un dominio personalizado, siga esta guía.