Skip to main content

​
Información general

Los SDKs de Kameleoon le permiten realizar experimentos para mejorar la experiencia de usuario en aplicaciones web y móviles. Según el diagrama siguiente, implementar un experimento con un SDK de Kameleoon implica tres fases: inicialización, identificación del usuario y asignación de atributos, y asignación de variaciones y tracking. Este artículo ofrecerá una explicación detallada de cada una de estas fases.
SDK Flow
Los métodos (y sus nombres) descritos en cada paso a continuación tendrán sintaxis diferentes en función de la convención del lenguaje concreto del SDK.

​
1. Inicialización

Al inicializarse, el SDK recupera cualquier configuración actualizada de feature flag a través de la Content Delivery Network de Cloudflare mediante dos métodos: Polling, una opción predeterminada en la que el SDK envía periódicamente una solicitud a la CDN (el intervalo por defecto es cada 60 minutos) para obtener la configuración más reciente, y Streaming, una opción premium en la que el SDK de Kameleoon es notificado en tiempo real de cualquier cambio en la configuración mediante server-sent events (SSE). Una vez recuperadas las configuraciones, el SDK comienza la asignación del código de visitante junto con las variaciones y el proceso de segmentación. Para más información, consulte consideraciones técnicas.
Como se muestra en el diagrama, durante el Streaming, el método on_configuration_update (recuerde que el nombre varía en cada SDK) permite gestionar el evento cuando la configuración tiene datos actualizados. Toma un parámetro de entrada (handler). El handler se llamará cuando la configuración se actualice mediante un evento de configuración en tiempo real. Para más información, consulte los SDKs específicos para Web y Mobile.

​
2. Identificación del usuario y asignación de atributos

En esta fase, para calcular la variación, se asigna el código de visitante y se incorporan los atributos del usuario:
  • 1. Asignación del código de visitante: la inicialización ofrece la posibilidad de asignar un ID único a un visitante. Para los SDKs web, el método getVisitorCode() recupera el código de visitante de la cookie en las cabeceras de la solicitud. Si el código de visitante no existe, el método genera un código de visitante aleatorio y lo almacena en una cookie de cabecera de respuesta. Para los SDKs móviles, el código de visitante se obtiene de la memoria del dispositivo móvil.
  • 2. Adición de atributos de usuario para la segmentación: las condiciones de segmentación de Kameleoon permiten activar feature flags en función de atributos de usuario. Para usar estas condiciones de forma eficaz, establezca los valores mediante el método addData() y/o getRemoteVisitorData() para recuperar y usar criterios específicos. Los atributos del usuario se almacenan después en la memoria del servidor para los SDKs server-side, en el local storage del navegador para los SDKs client-side, o en la memoria del dispositivo para los SDKs móviles. Para más detalles, consulte el artículo sobre almacenamiento de datos.
  • 3. Adición de datos externos para la segmentación: los datos externos, como las preferencias del usuario o los datos de CRM, pueden almacenarse mediante la Data API (una API REST) a través del endpoint POST. Estos datos se recuperan luego en el SDK utilizando el método getRemoteData().

​
3. Asignación de variaciones y tracking

En los SDKs de Kameleoon, el método getVariation() (isFeatureFlagActive() / getVariations()) recupera la configuración de un feature experiment que contiene varias variaciones. Puede usarse para obtener la(s) clave(s) de variación asignada(s) a un usuario específico. Cuando un visitante cumple todas las condiciones de segmentación y reglas de exposición del feature flag, Kameleoon utiliza una función de hash para asignar al visitante a una variación y, a continuación, envía un evento de experimento al servicio de tracking. Si el visitante no cumple las condiciones, se envía un evento de actividad para indicar que el usuario está activo en la web o en la app móvil. Además, se puede usar el método flush() para enviar al servicio de tracking cualquier otro dato almacenado.

​
4. Documentos de ayuda

Para integraciones específicas por lenguaje, consulte los artículos sobre Web SDK y Mobile SDK: Web SDKs Mobile SDKs Recursos adicionales

​
FAQ

Por lo general, no es necesario llamar manualmente al método flush: otras llamadas a métodos del SDK envían los datos junto con ellas. Sin embargo, si necesita enviar datos a la Data API sin activar el feature flag del visitante, utilice el método flush.
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.El SDK envía una solicitud de seguimiento:
  • Periódicamente: De forma predeterminada, el SDK envía una solicitud cada 1000 ms (1 segundo). Puede cambiar este intervalo configurando el valor de tracking interval.
  • Bajo demanda: Al instante, si su código llama a un método como flush(instant=true).
En concreto, llamar a cualquiera de los siguientes métodos antes de que expire el intervalo activa una solicitud de seguimiento:
  • getVariation (cuando establece track en true).
  • getVariations (cuando establece track en true).
  • isFeatureFlagActive (cuando establece track en true).
  • trackConversion
  • flush (con o sin instant=true)
Los SDK del lado del cliente también envían una solicitud de seguimiento cada 60 segundos de forma predeterminada si no se ha producido ninguna otra actividad, lo que ayuda a mantener la sesión del visitante. Puede cambiar este valor predeterminado configurando el parámetro activityTrackingIntervalMillisecond (o activity_tracking_interval_millisecond) en la configuración del SDK.En el caso de los SDK 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 única solicitud. Este enfoque agrega la información de todos los visitantes afectados y la envía una vez por intervalo, lo que mejora la eficiencia y reduce la carga del servidor.
Las solicitudes de seguimiento están sujetas a los límites de tasa de la Data API.En el caso de los SDK del lado del cliente, en entornos donde varios visitantes comparten la misma red (por ejemplo, en una oficina), los visitantes 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.
Los distintos SDK pueden denominar estos métodos de forma diferente debido a las particularidades de cada lenguaje.
A continuación se muestra una lista de los métodos del SDK que realizan solicitudes HTTP:
  • isFeatureFlagActive / getVariation / 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 que recibe el usuario). Kameleoon utiliza esta información para mostrar estadísticas en app.kameleoon.com.
  • getRemoteData / getRemoteVisitorData / getVisitorWarehouseAudience
    • Estos métodos realizan solicitudes a la Data API para obtener información sobre el visitante. En el SDK de JavaScript son asíncronos, por lo que debe esperar el resultado (await) antes de usarlo.
  • Además, el SDK realiza solicitudes asíncronas para obtener la configuración necesaria para su funcionamiento interno.
Llame a isFeatureFlagActive cuando necesite saber si el feature flag está activo, pero no necesite conocer la variación exacta que recibió el visitante. Cuando utilice experiment rules, es preferible llamar a getVariation si tiene dos o más variaciones distintas de off.