Saltar al contenido principal

​
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.

​
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.

​
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:
URLUtilizado por
https://sdk-config.kameleoon.eu/<sitecode>Archivo de configuración
https://<sitecode>.kameleoon.io/sdk-config / https://client-config.kameleoon.com/mobileArchivo de configuración (obsoleto)
https://events.kameleoon.com:8110/sseStreaming en tiempo real
https://api.kameleoon.com/oauth/tokenAutenticación
https://eu-data.kameleoon.io/ https://na-data.kameleoon.ioSeguimiento
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.