Skip to main content
Con el SDK de Java de Kameleoon, puede ejecutar experimentos y activar feature flags en su servidor de aplicaciones Java EE / Jakarta EE. Primeros pasos: Para obtener ayuda para comenzar, consulte la guía del desarrollador Changelog: Última versión del SDK de Java: 4.22.0 Changelog. Métodos del SDK: Para la documentación de referencia completa del SDK de Java, consulte la sección referencia.

Guía del desarrollador

Esta guía está diseñada para ayudarle a integrar nuestro SDK en unos minutos y comenzar a ejecutar experimentos en sus aplicaciones Java.

Primeros pasos

Kit de inicio

Para facilitarle el comienzo, Kameleoon proporciona un kit de inicio y una aplicación de demostración para probar el SDK. El kit de inicio incluye una aplicación totalmente configurada con ejemplos que muestran cómo se pueden utilizar los métodos del SDK en una aplicación. El kit de inicio, la aplicación de demostración y las instrucciones detalladas están disponibles en Starter kit for Java

Instalación del cliente Java

El paquete de instalación está disponible en el repositorio Maven Central. Puede instalar el SDK de Java añadiendo una dependencia al archivo pom.xml de su proyecto, como se muestra en el ejemplo de la derecha. Si utiliza otro sistema de gestión de proyectos, consulte la página de integraciones para ver ejemplos adicionales.
pom.xml

Configuración adicional

Cree un archivo de configuración .properties para proporcionar las credenciales y personalizar el comportamiento del SDK. También puede descargar nuestro archivo de configuración de ejemplo. Recomendamos guardar este archivo en la ruta predeterminada, /etc/kameleoon/client-java.conf, pero puede guardarlo en cualquier ubicación dentro del classpath con el nombre kameleoon-client-java.properties. La siguiente tabla muestra las propiedades disponibles que puede configurar:

Inicialización del cliente Kameleoon

Después de instalar el SDK en su aplicación y configurar sus credenciales y el comportamiento del SDK (en /etc/kameleoon/client-java.conf), el siguiente paso es crear el cliente Kameleoon en el código de su aplicación. Por ejemplo:
Un KameleoonClient es un objeto singleton que actúa como puente entre su aplicación y la plataforma Kameleoon. Incluye todos los métodos y propiedades que necesita para ejecutar un experimento. Tenga en cuenta que también admitimos el uso de un proxy HTTP en el SDK de Java (consulte la referencia del método create() para más detalles).
Es su responsabilidad asegurarse de que la lógica del código de su aplicación sea correcta en el contexto del A/B testing a través de Kameleoon. Una buena práctica es asumir siempre que puede excluir al visitante actual del experimento si aún no ha lanzado el experimento. Esta exclusión es sencilla porque corresponde a la implementación de la lógica de variación predeterminada y de referencia.
Ya está listo para comenzar a crear e implementar experimentos y feature flags.

Activación de un feature flag

Asignación de un ID único a un usuario
Para asignar un ID único a un usuario, puede utilizar el método getVisitorCode(). Si no existe un visitor code (en la cookie de los encabezados de la solicitud), el método genera un ID único aleatorio o utiliza un defaultVisitorCode que usted haya generado. A continuación, el ID se establece en una cookie en los encabezados de respuesta. Si está usando Kameleoon en modo híbrido, llamar al método getVisitorCode() garantiza que el ID único (visitor code) se comparta entre el archivo de aplicación engine.js (anteriormente llamado kameleoon.js) y el SDK.
Recuperación de la configuración de un flag
Para implementar un feature flag en su código, primero debe crear el feature flag en su cuenta de Kameleoon. Para determinar el estado o la variación de un feature flag para un usuario específico, debe utilizar el método getVariation() o isFeatureActive() para recuperar la configuración basada en el featureKey. El método getVariation() gestiona tanto los feature flags simples con estados ON/OFF como los flags más complejos con múltiples variaciones. El método recupera la variación adecuada para el usuario comprobando las reglas de la funcionalidad, asignando la variación y devolviéndola en función del featureKey y el visitorCode. El método isFeatureActive() puede utilizarse si desea recuperar la configuración de un feature flag simple que solo tiene un estado ON u OFF, a diferencia de los feature flags más complejos con múltiples variaciones u opciones de segmentación. Si su feature flag tiene variables asociadas (como comportamientos específicos vinculados a cada variación), getVariation() también le permite acceder al objeto Variation, que proporciona detalles sobre la variación asignada y su experimento asociado. Este método comprueba si el usuario está segmentado, encuentra la variación asignada al visitante y la guarda en almacenamiento. Cuando track=true, el SDK enviará el evento de exposición al experimento especificado en la siguiente solicitud de seguimiento, que se desencadena automáticamente según el tracking_interval_millisecond del SDK. De forma predeterminada, este intervalo está configurado en 1000 milisegundos (1 segundo). El método getVariation() le permite controlar si se realiza el seguimiento. Si track=false, el SDK no enviará eventos de exposición. Esto es útil si prefiere no realizar el seguimiento de los datos a través del SDK y, en su lugar, basarse en el seguimiento del lado del cliente gestionado por el motor de Kameleoon, por ejemplo. Además, establecer track=false resulta útil cuando se utiliza el método getVariations(), donde puede que solo necesite las variaciones de todos los flags sin desencadenar eventos de seguimiento. Si desea saber más sobre cómo funciona el seguimiento, consulte este artículo
Adición de puntos de datos para segmentar a un usuario o filtrar / desglosar visitas en informes
Para segmentar a un usuario, asegúrese de haber añadido los puntos de datos relevantes a su perfil antes de recuperar la variación de la funcionalidad o comprobar si el flag está activo. Utilice el método addData() para añadir estos puntos de datos al perfil del usuario. Para recuperar puntos de datos recopilados en otros dispositivos o acceder a datos pasados del usuario (recopilados en el lado del cliente cuando se utiliza Kameleoon en modo híbrido), utilice el método getRemoteVisitorData(). Este método obtiene datos de los servidores de forma asíncrona. Es importante llamar a getRemoteVisitorData() antes de recuperar la variación o comprobar si el feature flag está activo, ya que estos datos pueden ser necesarios para asignar a un usuario a una variación determinada. Para obtener más información sobre las condiciones de segmentación disponibles, consulte el artículo detallado sobre este tema. Además, los puntos de datos que añade al perfil del visitante estarán disponibles al analizar sus experimentos, lo que le permite filtrar y desglosar sus resultados por factores como el dispositivo y el navegador. El modo híbrido de Kameleoon recopila automáticamente una variedad de puntos de datos en el lado del cliente, lo que facilita desglosar sus resultados en función de estos puntos de datos previamente recopilados. Consulte la lista completa aquí. Si necesita realizar el seguimiento de puntos de datos adicionales más allá de los que se recopilan automáticamente, puede utilizar la funcionalidad de Custom Data de Kameleoon. Custom Data le permite capturar y analizar información específica relevante para sus experimentos. No olvide llamar al método flush() para enviar los datos recopilados a los servidores de Kameleoon para su análisis.
Para asegurarse de que sus resultados sean precisos, se recomienda filtrar los bots utilizando el tipo de dato UserAgent.
Seguimiento de conversiones de objetivos
Cuando un usuario completa una acción deseada (como realizar una compra), se registra como una conversión. Para hacer seguimiento de las conversiones, utilice el método trackConversion() y proporcione los parámetros requeridos visitorCode y goalId. La solicitud de seguimiento de conversiones se enviará junto con la siguiente solicitud de seguimiento programada, que el SDK envía a intervalos regulares (definidos por tracking_interval_millisecond). Si prefiere enviar la solicitud de inmediato, utilice el método flush() con el parámetro instant=true.
Envío de eventos a soluciones de analítica
Para realizar el seguimiento de las conversiones y enviar eventos de exposición a su solución de analítica de cliente, primero debe implementar Kameleoon en modo híbrido. A continuación, utilice el método getEngineTrackingCode(). El método getEngineTrackingCode() recupera el código de seguimiento único necesario para enviar eventos de exposición a su solución de analítica. El uso de este método le permite registrar eventos y enviarlos a la plataforma de analítica que desee.

Gestión de errores

Todos los errores que genera el SDK son una KameleoonException, por lo que un único controlador para ese tipo captura todos los fallos del SDK. Gestione un tipo de error específico cuando su aplicación necesite reaccionar ante un fallo concreto, por ejemplo, para recurrir a su comportamiento predeterminado cuando un feature flag no está en la configuración o el SDK aún no se ha inicializado. La sección de referencia de cada método enumera los errores que puede generar. Los errores se lanzan como excepciones. KameleoonException es una excepción comprobada que deriva de Exception, y cada error específico es una subclase anidada de ella. Por lo tanto, puede capturar un único error, como KameleoonException.FeatureNotFound, o la clase base KameleoonException. Los métodos asíncronos como waitInit() no lanzan excepciones. En su lugar, el CompletableFuture devuelto falla con el error.
Los errores del SDK son un comportamiento esperado, no fallos críticos. Un feature flag que aún no está activado, un SDK que todavía está cargando su configuración o un fallo de red son situaciones normales. Cuando falle la evaluación de una feature, registre el error y recurra a su comportamiento predeterminado para que el visitante siga teniendo una experiencia funcional.

Uso de una clave de bucketing personalizada

De forma predeterminada, Kameleoon utiliza un ID de visitante anónimo y único (visitorCode) para asignar usuarios a las variaciones de los feature flags. Este ID se genera y almacena habitualmente en el dispositivo del usuario (en una cookie del navegador para los SDKs del lado del cliente y del lado del servidor, y en almacenamiento persistente para los SDKs móviles). Sin embargo, en determinados escenarios puede necesitar asegurarse de que todos los usuarios de la misma organización vean la misma variante de un feature flag. La opción Custom Bucketing Key le permite anular este comportamiento predeterminado proporcionando su propio identificador personalizado para el bucketing. Esta anulación garantiza que la lógica de asignación de Kameleoon utilice la clave que usted especifique en lugar del visitorCode predeterminado.

Casos de uso

El uso de una clave de bucketing personalizada es esencial para mantener la consistencia y precisión en las asignaciones de sus feature flags, especialmente en estas situaciones:
  • Experimentos a nivel de cuenta u organización: Para productos B2B o escenarios en los que desea asignar a todos los usuarios de la misma organización a la misma variación, puede utilizar un identificador como accountId. Las claves de bucketing personalizadas son cruciales para probar mediante A/B funcionalidades que afecten a todo un equipo o empresa.
Al implementar una clave de bucketing personalizada, garantiza una mayor consistencia y precisión en sus experimentos, lo que se traduce en resultados más fiables y en una mejor experiencia de usuario.

Detalles técnicos

Cuando configura una clave de bucketing personalizada para un feature flag, proporciona a Kameleoon un identificador específico de los datos de su aplicación:
  • Proporcionar la clave personalizada: Usted proporciona su identificador personalizado al SDK de Kameleoon mediante el método addData(). En este método, pasará la clave de bucketing personalizada que haya elegido como un objeto CustomData. Aquí, newVisitorCode hace referencia al identificador que desea usar para el bucketing (por ejemplo, el nuevo userId o accountId).
Para que la clave de bucketing personalizada funcione correctamente, también debe definirse y configurarse para el feature flag durante el proceso de creación o edición del flag. Sin esta configuración correspondiente, el bucketing del SDK no aplicará su clave personalizada. Para obtener instrucciones detalladas sobre cómo configurar esto en Kameleoon, consulte este artículo.
  • Lógica de bucketing: Una vez que se proporciona una clave de bucketing personalizada a través del método addData(), todos los cálculos de hash para asignar usuarios a las variaciones utilizarán este newVisitorCode (su clave personalizada) en lugar del visitorCode predeterminado. Usar el newVisitorCode significa que la decisión de bucketing queda ligada a su identificador personalizado, garantizando asignaciones consistentes en los diversos contextos en los que esté presente ese identificador.
  • Seguimiento de datos y analítica: Es crucial tener en cuenta que, aunque el newVisitorCode (su clave personalizada) se utiliza para las decisiones de bucketing, todos los datos posteriores (eventos de seguimiento y conversiones, por ejemplo) se envían y se asocian con el visitorCode original. Esta separación garantiza que su analítica refleje con precisión los recorridos e interacciones individuales de los usuarios dentro del contexto más amplio de su experimento, incluso cuando el bucketing se realiza a un nivel superior (como una cuenta) o a través de varios dispositivos/sesiones. Sus datos originales del visitante permanecen intactos para una elaboración de informes completa.

Requisitos técnicos

Para utilizar eficazmente una clave de bucketing personalizada:
  • La clave debe ser un String.
  • Debe ser única para la entidad que pretende agrupar (por ejemplo, si utiliza un userId, el ID de cada usuario debe ser único).
  • La clave debe estar disponible para el SDK en el momento exacto en que se evalúa la decisión del feature flag para ese usuario o solicitud.

Condiciones de segmentación

Los SDKs de Kameleoon admiten una variedad de condiciones de segmentación predefinidas que puede usar para segmentar a los usuarios en sus campañas. Para ver la lista de condiciones que admite este SDK, consulte usar el historial de visitas para segmentar a los usuarios. También puede utilizar sus propios datos externos para segmentar a los usuarios.

Experimentación entre dispositivos

Para dar soporte a los visitantes que acceden a una aplicación desde varios dispositivos, Kameleoon permite sincronizar los datos del visitante previamente recopilados entre cada uno de sus dispositivos y reconciliar su historial de visitas entre dispositivos mediante la experimentación entre dispositivos. Los casos de estudio y la información detallada sobre cómo Kameleoon gestiona los datos entre dispositivos están disponibles en el artículo sobre experimentación entre dispositivos.

Sincronización de datos personalizados entre dispositivos

Aunque la sincronización de mapeo personalizado se utiliza para alinear los datos del visitante entre dispositivos, no siempre es necesaria. A continuación se presentan dos escenarios en los que no se requiere la sincronización de mapeo personalizado: Mismo ID de usuario en todos los dispositivos Si el mismo ID de usuario se utiliza de forma consistente en todos los dispositivos, la sincronización se gestiona automáticamente sin necesidad de una sincronización de mapeo personalizado. Basta con llamar al método getRemoteVisitorData() cuando desee sincronizar los datos recopilados entre varios dispositivos. Instancias multi-servidor con IDs consistentes En configuraciones complejas que involucran varios servidores (por ejemplo, instancias de servidor distribuidas), donde el mismo ID de usuario está disponible en todos los servidores, la sincronización entre servidores (con getRemoteVisitorData()) es suficiente sin necesidad de una sincronización adicional de mapeo personalizado. Los clientes que necesiten datos adicionales pueden consultar la descripción del método getRemoteVisitorData() para obtener más orientación. En el código siguiente se asume que el mismo identificador único (en este caso, el visitorCode, que también puede denominarse userId) se utiliza de manera consistente entre los dos dispositivos para una recuperación precisa de los datos.
Si desea sincronizar los datos recopilados en tiempo real, debe elegir el ámbito Visitor para sus datos personalizados.
Device A
Device B

Uso de datos personalizados para la fusión de sesiones

La experimentación entre dispositivos permite combinar el historial de un visitante en cada uno de sus dispositivos (reconciliación de historial). La reconciliación de historial permite fusionar diferentes sesiones de un visitante en una sola. Para reconciliar el historial de visitas, utilice CustomData para proporcionar un identificador único del visitante. Para más información, consulte la documentación dedicada. Una vez habilitada la reconciliación entre dispositivos, al llamar a getRemoteVisitorData() con el parámetro userId se recuperan todos los datos conocidos para un usuario determinado. Las sesiones con el mismo identificador siempre verán la misma variación en un experimento. En la vista Visitor de las páginas de resultados de su experimento, estas sesiones aparecerán como un único visitante. La configuración del SDK garantiza que las sesiones asociadas siempre vean la misma variación del experimento. Sin embargo, existen algunas limitaciones en cuanto a la asignación de variaciones entre dispositivos. Estas limitaciones se describen aquí. Siga la guía de activación de la reconciliación de historial entre dispositivos para configurar sus datos personalizados en la plataforma Kameleoon. Posteriormente, puede usar el SDK de forma normal. Los siguientes métodos pueden ser útiles en el contexto de la fusión de sesiones:
  • getRemoteVisitorData() con UniqueIdentifier(true) añadido: para recuperar datos de todos los visitantes vinculados.
  • trackConversion() o flush() con datos UniqueIdentifier(true) añadidos: para hacer seguimiento de datos de un visitante específico asociado con otro visitante.
Como el dato personalizado que utiliza como identificador debe configurarse con ámbito Visitor, necesita usar la sincronización de datos personalizados entre dispositivos para recuperar el identificador con el método getRemoteVisitorData() en cada dispositivo.
A continuación se muestra un ejemplo de cómo usar datos personalizados para la fusión de sesiones.
En este ejemplo, la aplicación tiene una página de inicio de sesión. Como el ID de usuario es desconocido en el momento del inicio de sesión, se utiliza un identificador de visitante anónimo generado por el método getVisitorCode(). Después de que el usuario inicia sesión, el visitante anónimo se asocia con el ID de usuario y se utiliza como identificador único del visitante.

Registro de eventos

El SDK genera registros que reflejan diversos procesos internos y problemas.

Niveles de registro

El SDK admite la configuración para limitar el registro mediante un nivel de log.

Gestión personalizada de los registros

El SDK escribe sus registros en la salida de la consola de forma predeterminada. Este comportamiento puede anularse.
El filtrado por nivel de log se realiza de forma independiente de la lógica de gestión de los registros.

Referencia

Esta es la documentación de referencia completa del SDK de Java.

Inicialización

create()

Para utilizar el SDK, debe finalizar la inicialización. Su aplicación realiza todas las interacciones con el SDK a través de un objeto de la clase KameleoonClient. Cree este objeto utilizando el método estático create() en KameleoonClientFactory.
Parámetros
Valor de retorno
Excepciones lanzadas

waitInit()

Use waitInit() cuando su aplicación deba esperar a que el cliente de Kameleoon termine la inicialización antes de evaluar feature flags. La llamada devuelve el resultado de la búsqueda de configuración: se completa correctamente cuando el cliente termina de inicializarse y falla si la búsqueda de configuración inicial falla antes de que el cliente esté listo. Los reintentos de fondo continúan después de ese primer fallo. Una vez que un reintento se realiza correctamente, las llamadas posteriores devuelven un resultado exitoso. Si no hay ningún resultado de inicialización disponible antes de que el tiempo de espera expire, la llamada falla. Si no proporciona un valor timeoutMillis, el SDK utiliza el tiempo de espera predeterminado de KameleoonClientConfig.defaultTimeout.
Llame a waitInit() una vez al iniciar la aplicación para esperar hasta que el SDK haya cargado su configuración o que el tiempo de espera expire. En cada solicitud entrante, use isReady() como una protección no bloqueante antes de evaluar feature flags. Incluso si waitInit() falla, el SDK continúa reintentando la búsqueda de configuración en segundo plano, por lo que isReady() comienza a devolver true después de que un reintento se realiza correctamente.
Parámetros
Valor de retorno
Excepciones lanzadas

isReady()

isReady() comprueba si el SDK está listo para usar, lo que significa que su configuración se ha cargado correctamente. A diferencia de waitInit(), este método devuelve inmediatamente sin bloquear ni lanzar excepciones.
  • Una vez que el SDK está listo, sigue estando listo. Si una actualización de configuración posterior falla, el SDK continúa utilizando la configuración descargada anteriormente y no vuelve a un estado no listo.
  • Llame a waitInit() una vez al iniciar la aplicación para esperar hasta que el SDK haya cargado su configuración o que el tiempo de espera expire. En cada solicitud entrante, use isReady() como una protección no bloqueante antes de evaluar feature flags. Incluso si waitInit() falla, el SDK continúa reintentando la búsqueda de configuración en segundo plano, por lo que isReady() comienza a devolver true después de que un reintento se realiza correctamente.
Valor de retorno

Feature flags y variaciones

isFeatureActive()

  • 📨 Envía datos de seguimiento a Kameleoon (dependiendo del parámetro track)
Este método se llamaba anteriormente activeFeature, que fue eliminado en la versión 4.0.0 del SDK.
Llame a este método para comprobar si un feature flag debe estar activo para un usuario especificado. Este método toma un visitorCode y un featureKey como argumentos obligatorios para comprobar si la funcionalidad está activa para el usuario. Si el usuario nunca ha sido asociado con este feature flag, el SDK devuelve un valor booleano aleatorio (ya sea true para añadir al usuario a esta funcionalidad o false para excluirlo de la funcionalidad). Si un usuario con el visitorCode especificado ya está registrado en este feature flag, el SDK detecta el valor anterior del featureFlag. Asegúrese de capturar y gestionar las posibles excepciones. Si especifica un visitorCode, el método isFeatureActive() lo usa como identificador único del visitante, lo cual es útil para la experimentación entre dispositivos. Cuando especifica un visitorCode y establece el parámetro isUniqueIdentifier en true, el SDK vincula los datos vaciados con el visitante asociado al identificador especificado.
El parámetro isUniqueIdentifier está obsoleto. Utilice en su lugar UniqueIdentifier.isUniqueIdentifier puede ser útil en situaciones particulares; por ejemplo, si no puede acceder al visitorCode anónimo asignado a un visitante, pero puede usar un ID interno vinculado a ese visitante a través de la fusión de sesiones.
Parámetros
Valor de retorno
Excepciones lanzadas

getVariation()

  • 📨 Envía datos de seguimiento a Kameleoon (dependiendo del parámetro track)
Recupera la Variation asignada a un visitante dado para un feature flag específico. Este método toma un visitorCode y un featureKey como argumentos obligatorios. El argumento track es opcional y tiene por defecto true. Devuelve la Variation asignada al visitante. Si el visitante no está asociado con ninguna regla de feature flag, el método devuelve la Variation predeterminada para el feature flag dado. Asegúrese de implementar un manejo de errores adecuado en su código para gestionar las posibles excepciones.
La variación predeterminada se refiere a la variación asignada a un visitante cuando no coincide con ninguna regla de entrega predefinida para un feature flag. En otras palabras, es la variación alternativa aplicada a todos los usuarios que no son el objetivo de reglas específicas. Se representa como la variación en la sección “Then, for everyone else…” de la interfaz de administración.
Parámetros
Valor de retorno
Excepciones lanzadas

getVariations()

  • 📨 Envía datos de seguimiento a Kameleoon (dependiendo del parámetro track)
Recupera un map de objetos Variation asignados a un visitante dado para todos los feature flags. Este método itera sobre todos los feature flags disponibles y devuelve la Variation asignada para cada flag asociado con el visitante especificado. Toma visitorCode como un argumento obligatorio, mientras que onlyActive y track son opcionales.
  • Si onlyActive se establece en true, el método getVariations() devolverá las variaciones de los feature flags siempre que el usuario no esté asignado a la variación off.
  • El parámetro track controla si el método realizará el seguimiento de las asignaciones de variación. De forma predeterminada, se establece en true. Si se establece en false, el seguimiento estará deshabilitado.
El map devuelto consta de claves de feature flags como claves y su Variation correspondiente como valores. Si no se asigna ninguna variación para un feature flag, el método devuelve la Variation predeterminada para ese flag. Se debe implementar un manejo de errores adecuado para gestionar las posibles excepciones.
La variación predeterminada se refiere a la variación asignada a un visitante cuando no coincide con ninguna regla de entrega predefinida para un feature flag. En otras palabras, es la variación alternativa aplicada a todos los usuarios que no son el objetivo de reglas específicas. Se representa como la variación en la sección “Then, for everyone else…” de la interfaz de administración.
Parámetros
Valor de retorno
Excepciones lanzadas

setForcedVariation()

El método le permite asignar mediante programación una Variation específica a un usuario, omitiendo el proceso de evaluación estándar. Esto es especialmente valioso para experimentos controlados donde la lógica de evaluación habitual no es necesaria o debe omitirse. También puede ser útil en escenarios como depuración o pruebas personalizadas. Cuando se establece una variación forzada, esta anula la lógica de evaluación en tiempo real de Kameleoon. Se omiten procesos como la segmentación, las condiciones de orientación y los cálculos algorítmicos. Para preservar la segmentación y las condiciones de orientación durante un experimento, establezca forceTargeting=false en su lugar.
Las variaciones simuladas siempre tienen prioridad en el orden de ejecución. Si se activa un cálculo de variación simulada, se procesará y completará completamente primero.
Una variación forzada se trata igual que una variación evaluada. Se rastrea en análisis y se almacena en el contexto del usuario como cualquier variación evaluada estándar, asegurando consistencia en la generación de informes. El método puede lanzar excepciones bajo ciertas condiciones (por ejemplo, parámetros no válidos, contexto del usuario o problemas internos). El manejo adecuado de excepciones es esencial para garantizar que su aplicación permanezca estable y resiliente.
Es importante distinguir las variaciones forzadas de las variaciones simuladas:
  • Variaciones forzadas: Son específicas de un experimento individual.
  • Variaciones simuladas: Afectan el resultado general del feature flag.
Parámetros
Excepciones lanzadas
En la mayoría de los casos, solo es necesario gestionar el error básico KameleoonException, como se muestra en el ejemplo. Sin embargo, si diferentes tipos de errores requieren una respuesta, maneje cada uno por separado según los requisitos específicos. Además, para una mayor confiabilidad, los errores generales del lenguaje pueden manejarse incluyendo Exception.

evaluateAudiences()

  • 📨 Envía datos de seguimiento a Kameleoon
Este método evalúa a los visitantes con respecto a todos los segmentos disponibles de Audiences Explorer y realiza el seguimiento de los que coinciden. evaluateAudiences() debe llamarse después de que todos los datos relevantes del visitante se hayan establecido o actualizado, y justo antes de obtener una variación de funcionalidad o verificar un feature flag. Este enfoque garantiza que el visitante se evalúe con los datos más recientes disponibles, lo que permite una asignación precisa de audiencia basada en todos los criterios. Después de llamar a este método, puede realizar un análisis detallado del rendimiento de segmentos en Audiences Explorer.
Parámetros
Excepciones lanzadas
En la mayoría de los casos, solo es necesario gestionar el error básico KameleoonException, como se muestra en el ejemplo. Sin embargo, si diferentes tipos de errores requieren una respuesta, maneje cada uno por separado según los requisitos específicos. Además, para una mayor confiabilidad, los errores generales del lenguaje pueden manejarse incluyendo Exception.

getFeatureList()

Este método se llamaba anteriormente obtainFeatureList, que fue eliminado en la versión 4.0.0 del SDK.
Devuelve una lista de claves de feature flags disponibles actualmente en el SDK.
Valor de retorno

getDataFile()

Para evaluar todos los feature flags, use getVariations(). Este método es más eficiente que llamar a DataFile e iterar por los flags con getVariation().
Devuelve la configuración actual del SDK como un objeto DataFile.
Valor de retorno

Datos del visitante

getVisitorCode()

Este método se llamaba anteriormente obtainVisitorCode, que fue eliminado en la versión 4.0.0 del SDK.
Se debe llamar al método getVisitorCode() para obtener el visitorCode de Kameleoon del visitante actual. Este método es especialmente importante cuando se usa Kameleoon en un entorno mixto front-end y back-end, donde la consistencia de la identificación del usuario debe garantizarse. La lógica de implementación se describe a continuación:
  1. El SDK verifica si se puede encontrar una cookie kameleoonVisitorCode o un parámetro de consulta asociados con la solicitud HTTP actual. Si la encuentra, utiliza este kameleoonVisitorCode como el identificador del visitante.
  2. Si no se encuentra ninguna cookie o parámetro en la solicitud actual, el SDK genera aleatoriamente un nuevo identificador o utiliza el argumento defaultVisitorCode como identificador si se proporciona. Este proceso le permite utilizar sus propios identificadores como códigos de visitante, si lo desea. Esta flexibilidad tiene el beneficio adicional de hacer coincidir a los visitantes de Kameleoon con sus propios usuarios sin necesidad de búsquedas adicionales en una tabla de correspondencia.
  3. En cualquier caso, la cookie kameleoonVisitorCode del lado del servidor (a través del encabezado HTTP) se establece con el valor relevante. A continuación, el método devuelve este valor de identificador.
Para más información, consulte este artículo.
Si proporciona un visitorCode, su singularidad debe garantizarse por su parte—el SDK no puede verificarlo. Además, tenga en cuenta que la longitud de visitorCode está limitada a 255 caracteres. Los caracteres excedentes generarán una excepción.
El método getVisitorCode() le permite establecer variaciones simuladas para un visitante. Cuando las cookies (de una request o document) contienen la clave kameleoonSimulationFFData, se omite el proceso de evaluación estándar. En su lugar, el método devuelve directamente una Variation basada en los datos proporcionados.Puede aplicar simulaciones de dos formas:
  • Automáticamente (recomendado): Si utiliza Kameleoon Web Experimentation o el SDK en Modo híbrido, la cookie se crea automáticamente al simular la visualización de una variante usando el Panel de Simulación.
  • Manualmente: Establezca la cookie kameleoonSimulationFFData manualmente.
Es importante distinguir las variaciones simuladas de las variaciones forzadas:
  • Variaciones simuladas: Afectan el resultado general del feature flag.
  • Variaciones forzadas: Son específicas de un experimento individual.
⚙️ Manual setupAsegúrese de que la cookie kameleoonSimulationFFData siga este formato:
  • kameleoonSimulationFFData={"featureKey":{"expId":10,"varId":20}}: Simula la variación con varId del experimento expId para el featureKey indicado.
  • kameleoonSimulationFFData={"featureKey":{"expId":0}}: Simula la variación predeterminada (definida en la sección Luego, para todos los demás en Producción, servir) para el featureKey indicado.
⚠️ Para garantizar que el valor de la cookie funcione correctamente, codifíquelo como componente URI utilizando un método como encodeURIComponent.
Parámetros
Valor de retorno

addData()

El método addData() añade datos de segmentación al almacenamiento para que otros métodos puedan utilizar los datos para decidir si segmentar o no al visitante actual. El método addData() no devuelve ningún valor y no interactúa por sí mismo con los servidores backend de Kameleoon. En su lugar, todos los datos declarados se guardan para su transmisión futura mediante el método flush(). Este enfoque reduce el número de llamadas al servidor, ya que los datos se agrupan habitualmente en una única llamada al servidor que desencadena el flush(). El método trackConversion() también envía cualquier dato previamente asociado, al igual que flush(). Lo mismo es cierto para los métodos getVariation() y getVariations() si se activa una regla de experimentación.
Cada visitante solo puede tener una instancia de datos asociados para la mayoría de los tipos de datos. Sin embargo, CustomData es una excepción. Los visitantes pueden tener una instancia de CustomData asociada por índice.
Parámetros
Excepciones

flush()

  • 📨 Envía datos de seguimiento a Kameleoon
El método flush() recopila los datos de Kameleoon vinculados al visitante. Luego envía una solicitud de seguimiento, junto con todos los datos añadidos mediante el método addData que aún no se hayan enviado mediante uno de estos métodos. flush() no es bloqueante ya que la llamada al servidor se realiza de forma asíncrona. flush le permite controlar cuándo se envían a los servidores los datos asociados a un visitorCode determinado. Por ejemplo, si llama a addData() una docena de veces, sería ineficiente enviar datos al servidor cada vez que se invoque addData(). Así que, todo lo que tiene que hacer es llamar a flush() una vez. Si especifica un visitorCode, el método flush() utiliza este código como identificador único del visitante, lo cual es útil para la experimentación entre dispositivos. Cuando especifica un visitorCode y establece el parámetro isUniqueIdentifier en true, el SDK vincula los datos vaciados con el visitante asociado al identificador especificado.
El parámetro isUniqueIdentifier está obsoleto. Utilice en su lugar UniqueIdentifier.isUniqueIdentifier puede ser útil en situaciones particulares; por ejemplo, si no puede acceder al visitorCode anónimo asignado a un visitante, pero puede usar un ID interno vinculado a ese visitante a través de la fusión de sesiones.
Parámetros

getRemoteData()

Este método se llamaba anteriormente retrieveDataFromRemoteSource, que fue eliminado en la versión 4.0.0 del SDK.
El método getRemoteData() le permite recuperar datos (según una key pasada como argumento) para el siteCode especificado almacenados en el servidor de Kameleoon. El código del sitio se especifica en KameleoonClientFactory.create(). Normalmente, los datos se almacenan en los servidores remotos utilizando la Data API. Este método, junto con la disponibilidad de los servidores escalables, proporciona una forma conveniente de almacenar datos adicionales que puede recuperar posteriormente para su aplicación.
Parámetros
Valor de retorno

getRemoteVisitorData()

getRemoteVisitorData() es un método asíncrono para recuperar los datos de visitas de Kameleoon para el visitorCode desde la Data API de Kameleoon. El método añade los datos al almacenamiento para que otros métodos los utilicen al tomar decisiones de segmentación. Los datos obtenidos mediante este método desempeñan un papel importante cuando desea:
  • utilizar datos recopilados desde otros dispositivos.
  • acceder al historial de un usuario, como páginas visitadas anteriormente durante visitas pasadas.
  • utilizar datos a los que solo se puede acceder en el lado del cliente, como las variables del datalayer y los objetivos que convierten en el front-end.
Lee este artículo para una mejor comprensión de los posibles casos de uso.
De forma predeterminada, getRemoteVisitorData() recupera automáticamente los datos personalizados almacenados más recientemente con scope=Visitor y los adjunta al visitante sin necesidad de llamar al método addData(). Es particularmente útil para sincronizar datos personalizados entre varios dispositivos.
El parámetro isUniqueIdentifier está obsoleto. Utilice en su lugar UniqueIdentifier.isUniqueIdentifier puede ser útil en situaciones particulares; por ejemplo, si no puede acceder al visitorCode anónimo asignado a un visitante, pero puede usar un ID interno vinculado a ese visitante a través de la fusión de sesiones.
Parámetros
Valor de retorno
Uso de parámetros en getRemoteVisitorData()
El método getRemoteVisitorData() ofrece flexibilidad al permitirle definir varios parámetros al recuperar datos de los visitantes. Ya sea que esté dirigiéndose según objetivos, experimentos o variaciones, el mismo enfoque se aplica en todos los tipos de datos. Por ejemplo, supongamos que desea recuperar datos sobre visitantes que completaron un objetivo “Order transaction”. Puede especificar parámetros dentro del método getRemoteVisitorData() para refinar su orientación. Por ejemplo, si desea dirigirse solo a los usuarios que se convirtieron en el objetivo en sus últimas cinco visitas, puede establecer el parámetro previousVisitAmount a 5 y conversions a true. La flexibilidad mostrada en este ejemplo no se limita a los datos de objetivos. Puede usar parámetros dentro del método getRemoteVisitorData() para recuperar datos sobre una variedad de comportamientos del visitante.
A continuación se muestra la lista de opciones disponibles de kameleoon.types.RemoteVisitorDataFilter:

getVisitorWarehouseAudience()

Este método recupera todos los datos de audiencia asociados con el visitante en su almacén de datos utilizando el visitorCode y warehouseKey especificados. El warehouseKey es típicamente su ID de usuario interno. El parámetro customDataIndex corresponde a los datos personalizados de Kameleoon que Kameleoon utiliza para dirigirse a sus visitantes. Puede consultar la documentación de orientación del almacén para más detalles. El método pasa el resultado al futuro devuelto como un objeto CustomData, confirmando que los datos se han añadido al visitante y están disponibles para propósitos de orientación.
Parámetros
Valor de retorno
Excepciones lanzadas

setLegalConsent()

Debe utilizar este método para especificar si el visitante ha otorgado consentimiento legal para usar datos personales. Establecer el parámetro legalConsent en false limita los tipos de datos que puede incluir en las solicitudes de seguimiento. Este método le ayuda a cumplir con los requisitos legales y reglamentarios mientras gestiona responsablemente los datos del visitante. Puede encontrar más información sobre datos personales en la política de gestión del consentimiento.
Parámetros
Excepciones lanzadas
Comportamiento al revocar el consentimiento
Cuando llama a setLegalConsent() con legalConsent=false, el SDK no elimina la cookie kameleoonVisitorCode. En su lugar, deja de prorrogar la fecha de expiración de la cookie, permitiendo que esta persista hasta que expire de forma natural. Si sus requisitos de cumplimiento exigen la eliminación inmediata del archivo de cookie al revocar el consentimiento, debe eliminarlo manualmente utilizando los métodos nativos de gestión de cookies de su framework. El SDK no eliminará el archivo automáticamente.

Objetivos y analítica de terceros

trackConversion()

  • 📨 Envía datos de seguimiento a Kameleoon
Utilice este método para registrar una conversión para un objetivo específico y usuario. Este método requiere visitorCode y goalId. Además, este método también acepta argumentos opcionales revenue, negative y metadata. El visitorCode suele ser idéntico al que se utilizó al activar el experimento. El método trackConversion() no devuelve ningún valor. Este método no es bloqueante, ya que la llamada al servidor se realiza de forma asíncrona.
El parámetro isUniqueIdentifier está obsoleto. Utilice en su lugar UniqueIdentifier.isUniqueIdentifier también puede ser útil en otros escenarios excepcionales, como cuando no puede acceder al visitorCode anónimo asignado originalmente al visitante, pero sí tiene acceso a un ID interno conectado al visitante anónimo mediante la fusión de sesiones.
Parámetros
Los valores de metadatos son accesibles a través de exportaciones de datos sin procesar y la página de resultados.Si se proporciona el parámetro metadata, Kameleoon utilizará estos valores especificados para la conversión actual en lugar de lo recopilado previamente mediante el método addData(). Si se omite el parámetro, Kameleoon utilizará los últimos valores rastreados para esos CustomData antes de la conversión y dentro de la misma visita.Kameleoon solo considerará los valores de metadatos que se pasen explícitamente como parámetros al método trackConversion().En el siguiente ejemplo, Kameleoon asociará la conversión solo con el valor de datos personalizados proporcionado explícitamente como parámetro (aquí: índice 5 con el valor “Amex Credit Card”).
Excepciones

getEngineTrackingCode()

Kameleoon se integra con varias soluciones de análisis, incluidas Mixpanel, Google Analytics 4 y Segment. Para rastrear correctamente los experimentos del lado del servidor, llame al método getEngineTrackingCode() después de que el visitante desencadene un experimento. El SDK devuelve comandos de cola JavaScript para los experimentos que el visitante desencadenó durante los últimos cinco segundos. Cuando inserta este código en la página, Engine.js procesa los comandos y envía los eventos de exposición a través de la integración de análisis activa. Consulte experimentación híbrida para más información sobre cómo implementar este método.
  • Para utilizar esta función, implemente tanto el SDK de Java como Kameleoon Engine.js. Debido a que Engine.js se utiliza solo para seguimiento en este flujo, puede instalar la etiqueta asíncrona antes de la etiqueta de cierre </body>.
  • Si solo desea rastrear experimentos en Kameleoon y no necesita enviar eventos de exposición a herramientas de análisis de terceros, use el SDK de JavaScript / TypeScript. Esta opción funciona bien para plataformas de computación de borde sin servidor. El SDK de JavaScript / TypeScript rastrea automáticamente las variaciones cuando llama a getVisitorCode, siempre y cuando agregue las asignaciones de experimento correspondientes a window.kameleoonQueue.
  • Puede insertar el código de rastreo devuelto directamente en una etiqueta HTML <script>.
En este ejemplo, 123456 y 234567 son IDs de experimento, y 7890 y 8901 son IDs de variación. En su implementación, el SDK genera estos valores en el código de seguimiento devuelto.
Parámetros
Valor de retorno

Eventos

setEventHandler()

Utilice este método para registrar un handler para los eventos del SDK. El SDK llama al handler cuando ocurre el evento seleccionado. Registrar un nuevo handler para el mismo tipo de evento reemplaza al handler anterior. Pasar null como handler elimina el handler actual para el tipo de evento seleccionado.
DataFileUpdateEvent contiene información sobre una actualización del archivo de datos del SDK.
Parámetros

Tipos de datos

Esta sección enumera los tipos de datos admitidos por Kameleoon en com.kameleoon.Data. El SDK proporciona varios tipos de datos estándar así como el tipo CustomData que le permite definir tipos de datos personalizados.

Browser

El conjunto de datos Browser almacenado aquí puede utilizarse para filtrar los informes de experimentación y personalización por cualquier valor asociado a él.

Conversion

El conjunto de datos Conversion almacenado aquí puede utilizarse para filtrar los informes de experimentación y personalización por cualquier objetivo asociado a él.
  • Cada visitante puede tener múltiples objetos Conversion.
  • Puede encontrar goalId en la aplicación Kameleoon.
Cookie contiene información sobre la cookie almacenada en el dispositivo del visitante.
Cada visitante solo puede tener una Cookie. Agregar una segunda Cookie sobrescribe la primera.

Geolocation

Geolocation contiene los detalles de geolocalización del visitante.
  • Cada visitante solo puede tener una Geolocation. Agregar una segunda Geolocation sobrescribe la primera.

CustomData

CustomData permite la asociación de cualquier tipo de dato con cada visitante, lo que la convierte en una herramienta efectiva para las condiciones de orientación en segmentos. Además, se puede utilizar como un filtro o desglose en informes de experimentos. Para más información sobre los datos personalizados, consulte este artículo. Defina tipos de datos personalizados en la aplicación de Kameleoon o en la Data API y úselos desde el SDK.
  • Cada visitante tiene permitido solo un CustomData para cada index(name) único. Añadir otro CustomData con el mismo index(name) reemplazará el existente.
  • El ‘índice’ de datos personalizados se puede encontrar en el panel de datos personalizados en la columna “INDEX”.
  • Para evitar que el SDK envíe datos con el índice seleccionado a los servidores de Kameleoon por razones de privacidad, habilite la opción: Use this data only locally for targeting purposes al crear datos personalizados.
  • Agregar una instancia CustomData creada con un nombre cuando la instancia del SDK no está inicializada o el nombre no está registrado hará que los datos se ignoren.

Device

PageView

Almacenar eventos de vista de página.
El índice (ID) del referente está disponible en la aplicación de Kameleoon en la página de configuración del canal de adquisición. Tenga cuidado: este índice comienza en 0, por lo que el primer canal de adquisición que cree para el sitio especificado tendría el ID 0, no 1.

UserAgent

Los experimentos del lado del servidor tienen más probabilidad de verse afectados por tráfico de bots que los experimentos del lado del cliente. Kameleoon utiliza la lista de Arañas y Bots Internacionales de IAB/ABC para abordar este problema y reconocer bots y arañas conocidos. Kameleoon también utiliza el campo UserAgent para filtrar bots y otro tráfico no deseado que podría distorsionar sus métricas de conversión. Para más detalles, consulte el artículo de ayuda sobre filtrado de bots. Si utiliza bots internos, le sugerimos pasar el valor curl/8.0 del userAgent para excluirlos de nuestra analítica.

UniqueIdentifier

Si no añade UniqueIdentifier para un visitante, se utiliza visitorCode como identificador único del visitante, lo cual es útil para la experimentación entre dispositivos. Cuando añade UniqueIdentifier para un visitante, el SDK vincula los datos vaciados con el visitante asociado al identificador especificado. isUniqueIdentifier puede ser útil en situaciones particulares; por ejemplo, si no puede acceder al visitorCode anónimo asignado a un visitante, pero puede usar un ID interno vinculado a ese visitante a través de la fusión de sesiones.

OperatingSystem

OperatingSystem contiene información sobre el sistema operativo en el dispositivo del visitante.
Cada visitante puede tener solo un OperatingSystem. Añadir un segundo OperatingSystem sobrescribe el primero.

ApplicationVersion

ApplicationVersion representa el número de versión semántica de su aplicación.
Un visitante solo puede tener un ApplicationVersion. Agregar una segunda instancia sobrescribe la primera.

Tipos devueltos

DataFile

El DataFile contiene los detalles de configuración del SDK. Puede extenderse con información adicional si es requerido por los clientes. Si necesita más detalles, contacte con su Gestor de Éxito del Cliente.

FeatureFlag

FeatureFlag representa un conjunto de propiedades que definen un feature flag en sí—por ejemplo, sus Variations, Rules, estado del entorno y otros detalles relacionados. Puede extenderse con información adicional si es requerido por los clientes. Si necesita más detalles, contacte con su Gestor de Éxito del Cliente.

Rule

Rule representa un conjunto de propiedades que definen una regla en sí—por ejemplo, sus Variations. Puede extenderse con información adicional si es requerido por los clientes. Si necesita más detalles, contacte con su Gestor de Éxito del Cliente.

Variation

Variation contiene información sobre la variación asignada del visitante (o la variación predeterminada, si no existe asignación específica).
  • El objeto Variation proporciona detalles sobre la variación asignada y su experimento asociado, mientras que el objeto Variable contiene detalles específicos sobre cada variable dentro de una variación.
  • Asegúrese de que su código maneje el caso donde id o experimentId puede ser null, indicando una variación predeterminada.
  • El mapa variables puede estar vacío si no hay variables asociadas con la variación.

Variable

Variable contiene información sobre una variable asociada con la variación asignada.

Métodos obsoletos

Estos métodos están obsoletos y se eliminarán en la versión 5.0.0 del SDK.

getFeatureVariationKey()

  • 📨 Envía datos de seguimiento a Kameleoon
Utilice getVariation() en su lugar.
Llame a este método para obtener la clave de variación de funcionalidad para un usuario y una funcionalidad especificados. Este método toma un visitorCode y un featureKey como argumentos obligatorios para obtener la clave de variación para el usuario y la funcionalidad. Si el usuario nunca ha sido asociado con este feature flag, el SDK devuelve una clave de variación asignada aleatoriamente (según las reglas del feature flag). Si un usuario con el visitorCode especificado ya está registrado en este feature flag, el SDK detecta el valor anterior de la clave de variación. Si el usuario no coincide con ninguna de las reglas, se devuelve el valor predeterminado, que puede personalizar en la aplicación de Kameleoon. Asegúrese de capturar y gestionar las posibles excepciones. Si especifica un visitorCode, el método flush() lo usa como identificador único del visitante, lo cual es útil para la experimentación entre dispositivos. Cuando especifica un visitorCode y establece el parámetro isUniqueIdentifier en true, el SDK vincula los datos vaciados con el visitante asociado al identificador especificado.
El parámetro isUniqueIdentifier está obsoleto. Utilice en su lugar UniqueIdentifier.isUniqueIdentifier puede ser útil en situaciones particulares; por ejemplo, si no puede acceder al visitorCode anónimo asignado a un visitante, pero puede usar un ID interno vinculado a ese visitante a través de la fusión de sesiones.
Parámetros
Valor de retorno
Excepciones lanzadas

getActiveFeatures()

Utilice getVariations() en su lugar.
Este método toma un parámetro visitorCode único. El resultado contiene solo las funcionalidades activas para un visitante determinado.
Parámetros
Valor de retorno
Excepciones lanzadas

getActiveFeatureListForVisitorCode()

  • Utilice getVariations() en su lugar.
  • Este método anteriormente se llamaba obtainFeatureListForVisitorCode, que fue eliminado en la versión 4.0.0 del SDK.
Este método toma un parámetro visitorCode único. Devuelve solo los feature flags activos para el visitante especificado.
Parámetros
Valor de retorno

getFeatureVariable()

  • 📨 Envía datos de seguimiento a Kameleoon
Utilice getVariation() en su lugar.
Llame a este método para obtener el valor de la variación de funcionalidad asociado a un usuario. Este método toma un visitorCode, featureKey y variableKey como argumentos obligatorios para obtener la variable de la clave de variación para el usuario especificado. Si un usuario nunca ha sido asociado con este feature flag, el SDK devuelve un valor de variable asignado aleatoriamente para la clave de variación según las reglas del feature flag. Si un usuario con el visitorCode especificado ya está registrado en este feature flag, el SDK devuelve el valor de la variable para la variación previamente asociada. Si el usuario no coincide con ninguna de las reglas, se devuelve la variable predeterminada. Asegúrese de capturar y gestionar las posibles excepciones. Si especifica un visitorCode, el método getFeatureVariable() usa el código como identificador único del visitante, lo cual es útil para la experimentación entre dispositivos. Cuando especifica un visitorCode y establece el parámetro isUniqueIdentifier en true, el SDK vincula los datos vaciados con el visitante asociado al identificador especificado.
El parámetro isUniqueIdentifier está obsoleto. Utilice en su lugar UniqueIdentifier.isUniqueIdentifier puede ser útil en situaciones particulares; por ejemplo, si no puede acceder al visitorCode anónimo asignado a un visitante, pero puede usar un ID interno vinculado a ese visitante a través de la fusión de sesiones.
Parámetros
Valor de retorno
Excepciones lanzadas

getFeatureVariables()

  • 📨 Envía datos de seguimiento a Kameleoon
Utilice getVariation() en su lugar.
Este método recupera un mapa que contiene claves de variables y sus valores asignados según la variación a la que se asigna el visitante en el feature flag especificado. Las variables de funcionalidad se pueden modificar en la aplicación de Kameleoon. Si un usuario nunca ha sido asociado con este feature flag, el SDK devuelve un conjunto de valores de variables asignados aleatoriamente en la variación de acuerdo con las reglas del feature flag. Si un usuario con el visitorCode especificado ya está registrado con este feature flag, el SDK devuelve los valores de variables para la variación utilizada anteriormente. Si el usuario no coincide con ninguna de las reglas, se devuelven las variables predeterminadas. Asegúrese de capturar y gestionar las posibles excepciones.
Parámetros
Valor de retorno
Excepciones lanzadas

getFeatureVariationVariables()

  • Utilice getVariation() en su lugar.
  • Este método anteriormente se llamaba getFeatureAllVariables, que fue eliminado en la versión 4.0.0 del SDK.
Llame a este método para recuperar todas las variables de funcionalidad de una funcionalidad. Puede modificar las variables de funcionalidad en la aplicación Kameleoon. Este método toma dos parámetros de entrada: featureKey y variationKey. Devuelve los datos con el tipo Map<String, Object> como se define en la aplicación de Kameleoon. Genera una excepción (KameleoonException.FeatureNotFound) si la funcionalidad que solicita no se encuentra en la configuración interna del SDK.
Parámetros
Valor de retorno
Excepciones lanzadas

updateConfigurationHandler()

El método updateConfigurationHandler() le permite manejar el evento cuando la configuración ha actualizado datos. Toma un parámetro de entrada, handler. El handler que será llamado cuando la configuración se actualice usando un evento de configuración en tiempo real.
Parámetros