Skip to main content

​
Configuración y asignación de feature flags

Cuando se actualiza la configuración de un feature flag o se activa o desactiva, los SDKs pueden obtener la configuración actualizada de la Content Delivery Network (CDN) de Cloudflare utilizando polling o streaming. El polling es la opción predeterminada, mientras que el streaming es una opción premium. Los SDKs de Kameleoon están diseñados para cumplir con una política de latencia cero. Esto significa que el SDK no necesita realizar llamadas adicionales a servidores remotos para activar y asignar a los usuarios a un feature flag. Incluso la llamada más rápida a un servidor remoto añadiría un mínimo de 20 ms de latencia a la aplicación y, en función de varios factores, este retraso puede aumentar hasta cientos de milisegundos, o incluso bloquear por completo la carga de la aplicación web para el usuario final. Para evitar esta latencia adicional, los SDKs de Kameleoon asignan a los visitantes a los experimentos localmente.
Para los SDKs del lado del cliente, que se ejecutan en el dispositivo del usuario, la aplicación debe obtener las configuraciones de feature flag activas al inicio de la sesión. Esto requiere una llamada remota con su correspondiente callback asociado, lo que significa que el código de la aplicación que utiliza el SDK no puede ejecutar experimentos ni aplicar feature flags antes de que finalice la ejecución de este callback.

​
Polling (predeterminado)

En este modo, el SDK envía una solicitud al CDN a intervalos regulares (de forma predeterminada, cada 60 minutos) para recuperar la configuración más reciente. El intervalo puede personalizarse en la configuración del SDK mediante el parámetro refresh_interval_minute (o refresh_interval).
Cuando los intervalos están moderadamente espaciados, la actualización de la configuración consume muy pocos recursos de memoria y de red.
Para los SDKs web del lado del cliente, la estrategia de polling incluye una lógica de almacenamiento en caché local:
  1. Carga inicial: Cuando se abre una página web, el SDK intenta primero cargar la configuración desde la caché (si está disponible).
  2. Actualización en segundo plano: Si ha transcurrido el refresh_interval, el SDK realiza una solicitud en segundo plano para actualizar la configuración y refresca la caché.
  3. Validez de la caché: La configuración almacenada en caché se considera válida durante 1,5 horas desde la última actualización satisfactoria. Si el visitante abre una página dentro de esta ventana de 1,5 horas, se utilizará la versión en caché. De lo contrario, la caché se ignora y se realiza una nueva solicitud de inmediato.
Esta estrategia de almacenamiento en caché garantiza cargas de página más rápidas y un uso mínimo de la red, manteniendo al mismo tiempo la configuración razonablemente actualizada.Supongamos que refresh_interval está establecido en 15 minutos y un usuario está expuesto a un feature flag. Si el feature flag se desactiva 10 minutos después y el mismo usuario vuelve al sitio web 20 minutos más tarde:
  • El SDK primero cargará la configuración desde la caché (que sigue mostrando el flag como activo).
  • Simultáneamente, realizará una solicitud en segundo plano para obtener la configuración actualizada y refrescar la caché.
  • Este diseño prioriza el rendimiento, garantizando cargas de página rápidas mientras se sincroniza de forma asíncrona con la configuración más reciente.
Así que, aunque exista una ventana breve en la que un usuario pueda ver una configuración desactualizada (según el intervalo), el SDK la actualiza rápidamente en segundo plano. La configuración actualizada se aplicará la próxima vez que el visitante abra una página.

​
Impacto en experimentos y feature flags recién lanzados

dataFileCacheTtl y dataFileRefreshInterval determinan juntos con qué rapidez se evalúa a los visitantes según la configuración de un experimento o feature flag recién lanzado. Los visitantes cuyo archivo de datos en caché ya haya superado dataFileCacheTtl, o que aún no tengan ninguno, reciben la nueva configuración de inmediato, porque initialize() espera hasta que llega un archivo de datos actualizado. Los visitantes cuyo archivo de datos en caché todavía está dentro de dataFileCacheTtl siguen evaluándose con la configuración anterior hasta que ese caché supera dataFileCacheTtl, o hasta que una actualización en segundo plano se completa y cargan otra página. Como resultado, con el valor predeterminado de dataFileCacheTtl de 90 minutos, el tráfico que entra en un experimento recién lanzado aumenta gradualmente en lugar de alcanzar el volumen completo de inmediato. Por ejemplo, un experimento recién lanzado podría exponer alrededor del 40% de su población objetivo final en la primera hora tras el lanzamiento, alrededor del 57% en la segunda hora, y más del 95% en la tercera hora, una vez que suficientes archivos de datos en caché de los visitantes hayan superado esa ventana de 90 minutos. Ningún visitante queda excluido de forma permanente del experimento; cada uno se incorpora en cuanto su dispositivo obtiene la configuración actualizada.
Al comparar las cifras de exposición de Kameleoon con las de otra herramienta de analítica justo después de lanzar una campaña, espere un período de aumento gradual de aproximadamente dataFileCacheTtl minutos (90 de forma predeterminada) antes de que las cifras de exposición se estabilicen y coincidan con la población objetivo. Un número menor de visitantes expuestos durante ese período no significa que los visitantes se estén perdiendo o segmentando incorrectamente. Si su caso de uso necesita un inicio más rápido, reduzca dataFileCacheTtl (manténgalo por encima de dataFileRefreshInterval para evitar añadir solicitudes bloqueantes innecesarias a la carga de la página), o hable sobre la opción de streaming con el soporte de Kameleoon, que evita por completo este modelo de caché para el archivo de datos del SDK.
Una configuración que combina un SDK del lado del servidor o edge con getEngineTrackingCode() y el script de tracking Engine.js puede mostrar igualmente un aumento gradual similar en los resultados registrados, causado por la caché de navegador independiente de Engine.js. Consulte el comportamiento de caché de Engine.js para más información.

​
Streaming (opción premium)

El modo de streaming en tiempo real permite que el SDK aplique automáticamente la nueva configuración sin ningún retraso. Cuando el streaming está habilitado, el SDK de Kameleoon es notificado de cualquier cambio en la configuración en tiempo real gracias a los server-sent events (SSE). Principales ventajas:
  • Actualización inmediata de la configuración (sin esperar al próximo ciclo de polling).
  • Menor uso de tráfico de red que el polling con intervalos cortos. El streaming no envía solicitudes periódicas. Abre la conexión una sola vez y la mantiene permanentemente abierta, lista para recibir datos.
Disponibilidad:
  • Esta es una opción premium que requiere suscripción. Para activar el streaming en tiempo real en una cuenta de Kameleoon, póngase en contacto con el Customer Success Manager o envíe un correo a support@kameleoon.com.
  • El SDK de PHP no es compatible con el streaming debido a limitaciones técnicas. Actualmente, el SDK de PHP no puede escuchar las actualizaciones de configuración de forma no bloqueante, ya que el SDK de PHP no persiste entre solicitudes. Cada solicitud crea una nueva instancia del SDK que se destruye en cuanto recibe una respuesta.
  • El modo de streaming en tiempo real actualmente no es compatible con las plataformas serverless de computación en el edge.
  • Para otros lenguajes, consulte la matriz de compatibilidad de los SDKs para conocer la versión mínima compatible en el lenguaje preferido.

​
Almacenamiento de datos

Los SDKs de Kameleoon están diseñados para ofrecer un rendimiento y una experiencia de usuario óptimos. Para lograrlo, gestionan los datos del visitante localmente, ya sea en el servidor o directamente en el dispositivo, en lugar de obtenerlos desde una fuente remota. Todos los datos del visitante relevantes para los experimentos y feature flags de Kameleoon se almacenan localmente, lo que incluye las asignaciones de experimentos, los datos de segmentos y cualquier dato personalizado añadido mediante métodos como addData() o recuperado del servidor con getRemoteVisitorData(). La forma en que se almacenan estos datos y su vida útil difieren en función de si se utiliza un SDK del lado del servidor o del lado del cliente.

​
SDKs del lado del servidor

En los SDKs del lado del servidor, los datos del visitante se almacenan en la memoria volátil (RAM) del servidor, lo que proporciona un acceso rápido para las evaluaciones de experimentos y feature flags. Los datos se organizan como un mapa, utilizando valores únicos de visitorCode como claves.
  • Almacenamiento basado en sesión: Los datos se conservan en memoria únicamente durante la sesión activa de un usuario, que finaliza, por defecto, tras 30 minutos de inactividad (sin vistas de página, clics, etc.). Todos los datos recopilados durante la sesión expiran al mismo tiempo.
    • Parámetro session_duration: La duración de la sesión puede ajustarse mediante el parámetro session_duration en la configuración del SDK. Este parámetro permite alinear la sesión de Kameleoon con la gestión del lado del servidor de la aplicación.
Aumentar session_duration hará que el SDK necesite asignar más RAM para almacenar los datos adicionales del visitante.
  • Pérdida de datos al reiniciar el servidor: Dado que los datos se almacenan en RAM, se perderán si el servidor de la aplicación se reinicia. Por lo general, la pérdida de datos no supone una preocupación, ya que los datos importantes del visitante (como los IDs de usuario o atributos) se recuperan habitualmente desde una base de datos persistente y se reasignan al visitante en una nueva solicitud.
  • Recuperación de datos de visitas anteriores: El método getRemoteVisitorData() permite recuperar datos personalizados recogidos durante una visita previa del visitante. Este método asocia automáticamente la entrada de datos más reciente para un visitante, eliminando la necesidad de invocar de nuevo addData().

​
SDKs del lado del cliente

A diferencia de los SDKs del lado del servidor, los SDKs del lado del cliente utilizan almacenamiento local persistente en el dispositivo del usuario. Este mecanismo asegura que los datos del visitante puedan conservarse entre sesiones del navegador, reinicios de la aplicación e incluso reinicios del dispositivo. El mecanismo de almacenamiento específico varía según la plataforma:
  • iOS: UserDefaults
  • Android: SharedPreferences
  • JavaScript/TypeScript: LocalStorage
    • Nota para el SDK de JS: El kameleoonVisitorCode también se comparte mediante cookies para garantizar una continuidad de datos y una comunicación fluidas con el archivo de aplicación de Kameleoon (engine.js).
  • React Native: MMKV Storage
A diferencia de los SDKs del lado del servidor, que utilizan una session_duration global, los SDKs del lado del cliente no operan con una expiración basada en sesión para todos los datos. En su lugar, utilizan targetingDataCleanupInterval o data_expiration_interval_minute para controlar cuánto tiempo se almacena cada dato individualmente.
  • targetingDataCleanupInterval/data_expiration_interval_minute: Estos parámetros determinan la vida útil individual de cada entrada de datos concreta. De forma predeterminada, los datos se almacenan de forma indefinida (hasta que se eliminen explícitamente) para garantizar experiencias de usuario coherentes entre visitas. Puede establecer este parámetro en un número específico de minutos si necesita que ciertos datos expiren transcurrido un determinado tiempo.
  • Persistencia de los datos: Esta diferencia fundamental implica que los datos persisten incluso si el usuario cierra la pestaña del navegador, abandona el sitio o cierra la aplicación móvil.
  • Justificación de la convención de nombres: La diferencia en la terminología de los parámetros (session_duration frente a data_expiration_interval_minute) refleja directamente la filosofía de almacenamiento subyacente. session_duration rige la vida útil global de todos los datos dentro de una sesión del lado del servidor. data_expiration_interval_minute permite un control granular sobre la vida útil de cada dato concreto almacenado de forma persistente en el cliente.

​
SDKs en el edge

Los SDKs en el edge, desplegados mediante los starter kits de serverless edge compute, no conservan los datos del visitante entre solicitudes de la misma manera que los SDKs del lado del servidor o del lado del cliente. Una plataforma edge puede destruir y recrear una instancia de worker en cualquier momento, por lo que un parámetro session_duration no tiene memoria duradera a la que aplicarse, y un edge worker no tiene garantía de ver una solicitud posterior del mismo visitante. Por esta razón, su integración es responsable de poner los datos del visitante a disposición del edge worker en cada solicitud, normalmente transmitiéndolos como cookie y llamando a addData() antes de evaluar un feature flag o experimento. Consulte Restricciones de targeting en el edge para obtener la explicación completa y un ejemplo de código.

​
Lista de dominios

Los SDKs de Kameleoon requieren acceso a un conjunto de URIs que proporcionan servicios específicos al SDK. Si está restringiendo el acceso y necesita incluir dominios explícitamente en la lista blanca, asegúrese de que nuestros SDKs puedan alcanzar los siguientes dominios: Para permitir estos dominios en una cabecera Content-Security-Policy, consulte Dominios de Kameleoon que debe permitir, que enumera todos los dominios que utilizan los productos de Kameleoon.
El dominio de sus scripts de Kameleoon 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 se muestra en su proyecto dentro de la aplicación Kameleoon.

​
FAQ

Kameleoon utiliza servidores CDN durante la inicialización. Una vez que el SDK recibe y almacena en caché la configuración, la recuperación y las actualizaciones se producen rápidamente, normalmente entre 50 y 70 ms, según la latencia del servidor desde el CDN más cercano.
Existen dos métodos para obtener la configuración: Polling y Streaming.
Streaming utiliza el protocolo server-sent events (SSE o EventSource).
Kameleoon purga el CDN cada vez que actualiza la configuración de un feature flag (por ejemplo, variaciones, exposiciones de tráfico y targeting), o cada 24 horas.
Cada instancia del servidor almacena en su propia memoria los datos del visitante que recopila. Dirija las solicitudes del mismo visitante a la misma instancia del servidor. De lo contrario, añada los datos completos del visitante con addData() antes de cada solicitud de seguimiento, o cárguelos con el método getRemoteVisitorData.Si distintas instancias del servidor aplican configuraciones del SDK diferentes al mismo tiempo, utilice la opción Streaming para que cada instancia reciba los cambios de configuración en tiempo real.
Todas las evaluaciones se realizan de forma local para eliminar la latencia. Después, las solicitudes de seguimiento se envían de forma asíncrona a los servidores de la Data API de Kameleoon.
Para asignar un visitante a una variación de un experimento, Kameleoon primero genera un identificador a partir del código de visitante, el ID del experimento y un elemento adicional opcional en caso de respooling. Después, una implementación síncrona de la función hash SHA-256 calcula un hash de ese identificador. El entero obtenido mediante el hash 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) siempre recibe la misma variación de un experimento, salvo que solicite explícitamente volver a calcular la asignación.
En el artículo Añadir una nueva regla de despliegue se explican todos los casos posibles.
Los SDK del lado del servidor mantienen los datos del visitante en memoria durante la sesión del visitante, que dura 30 minutos de forma predeterminada. Los SDK del lado del cliente los guardan en el almacenamiento local del dispositivo, donde persisten hasta que los borre o hasta que transcurra un intervalo de caducidad configurado. Consulte Almacenamiento de datos para más detalles.