Skip to main content
Con el SDK de Android de Kameleoon, puede activar feature flags en aplicaciones móviles nativas de Android. El SDK de Android es compatible tanto con Kotlin como con Java. El SDK es sencillo de integrar en sus aplicaciones y su uso de memoria y red es bajo. El tamaño del SDK es de aproximadamente 0,15 a 0,3 MB comprimido y 0,2 a 0,5 MB instalado. Primeros pasos: Para obtener ayuda para comenzar, consulte la guía del desarrollador. Changelog: Última versión del SDK de Android: 4.24.0 Changelog Métodos del SDK: Para la documentación de referencia completa de los métodos del SDK de Android, consulte la sección referencia.

Guía del desarrollador

Siga esta sección para instalar y configurar el SDK de Android en su aplicación de Android y obtenga información sobre características avanzadas.

Primeros pasos

Siga estos pasos para instalar y configurar el SDK de Android de Kameleoon en su aplicación.

Instalación

Puede instalar el SDK de Android añadiendo la siguiente dependencia al archivo build.gradle de su aplicación Android:

Configuración adicional

Para personalizar el comportamiento del SDK, cree un archivo de configuración .properties. El nombre y la ubicación del archivo de propiedades son importantes:
  • Cree el archivo en el directorio assets/ de su aplicación.
  • Asigne al archivo el nombre kameleoon-client.properties.
También puede descargar un archivo de configuración de ejemplo. Estas son las propiedades disponibles que puede establecer:
Si especifica un visitorCode y establece el parámetro isUniqueIdentifier en true, los métodos del SDK utilizan el valor visitorCode como identificador único del visitante, lo que es útil para experimentación entre dispositivos. El SDK vincula los datos enviados al visitante que está asociado con el identificador especificado.isUniqueIdentifier 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.
Using activityTrackingIntervalMillisecond
El parámetro activityTrackingIntervalMillisecond ayuda a reducir el uso de red y el consumo de batería al controlar con qué frecuencia el SDK envía un evento de actividad para prolongar la sesión del visitante en la Data API. El valor por defecto y el valor mínimo permitido es 60 000 ms (60 segundos); cualquier valor menor distinto de cero se ignora y se aplica el valor por defecto. Los temporizadores se pausan cuando la aplicación está en segundo plano, por lo que el intervalo solo avanza efectivamente mientras la aplicación está en primer plano. Revise su impacto en las siguientes características:
  1. Elapsed time triggers
    • Si el tiempo transcurrido configurado es más corto que el intervalo de seguimiento, el disparador no se activará como se espera.
  2. Elapsed time segments
    • Si el tiempo transcurrido es más corto que el intervalo de seguimiento, es posible que los usuarios no se incluyan en el segmento como se pretendía.
  3. Time spent goals
    • Si el tiempo transcurrido es más corto que el intervalo de seguimiento, puede que nunca se alcance el objetivo.
  4. Tiempo transcurrido desde la última visita en la página de resultados
    • Las mediciones para “tiempo transcurrido desde la última visita” se vuelven menos precisas cuando el tiempo transcurrido es cercano o inferior al intervalo de seguimiento.
  5. Visits count
    • Se crea una nueva visita después de 30 minutos de inactividad. Si el intervalo de seguimiento es más largo que 30 minutos, se creará una nueva visita en cada intervalo de seguimiento.
Configurar activityTrackingIntervalMillisecond en 0 deshabilita completamente el seguimiento periódico de actividad. En esta configuración, solo se envía un único evento de actividad al inicio de la aplicación.

Inicializar el cliente de Kameleoon

Después de instalar el SDK en su aplicación y configurar las propiedades de la aplicación, debe crear el Cliente de Kameleoon. Un Cliente es un objeto singleton que actúa como puente entre su aplicación y la plataforma de Kameleoon. Incluye todos los métodos y propiedades que necesita para ejecutar un feature flag.
Durante KameleoonClientFactory.create(), el cliente comienza la inicialización pero no está inmediatamente listo para usar. El Cliente de Kameleoon debe recuperar la configuración actual de feature flags (junto con su asignación de tráfico) de un servidor remoto de Kameleoon. Esta recuperación requiere acceso a la red, que no siempre está disponible. Hasta que el Cliente de Kameleoon esté completamente listo, no debe intentar ejecutar otros métodos en el SDK de Android de Kameleoon. Tenga en cuenta que una vez que se obtiene la primera configuración de feature flags, se actualiza periódicamente, pero incluso si la actualización falla por cualquier motivo, el cliente de Kameleoon continuará funcionando con la configuración anterior. Puede usar el método isReady() para comprobar si la inicialización del cliente Kameleoon ha finalizado. Alternativamente, un callback auxiliar puede encapsular la lógica del activador de feature flags e implementación de variaciones. El mejor enfoque (isReady() o callback) depende de las preferencias y el caso de uso exacto. Se recomienda usar isReady() cuando se espera que el SDK esté listo para usar pronto. Por ejemplo, isReady() es apropiado cuando se ejecuta un feature flag en un diálogo que es probable que los usuarios no accedan durante los primeros segundos o minutos de navegación en la aplicación. Se recomienda un callback cuando hay una alta probabilidad de que el SDK aún se esté inicializando. Por ejemplo, un feature flag que aparece en pantalla al inicio de la aplicación debe usar un callback que haga que la aplicación espere hasta que el SDK esté listo o haya expirado un tiempo de espera especificado.
Es su responsabilidad como desarrollador de aplicaciones asegurar que la lógica de su código de aplicación sea correcta en el contexto de pruebas A/B usando Kameleoon. Una buena práctica es asumir siempre que el usuario de la aplicación puede quedar excluido del feature flag cuando el cliente de Kameleoon aún no esté listo. Esta exclusión es fácil de implementar porque corresponde a la implementación de la lógica de variación predeterminada o de referencia. Los ejemplos de código en el siguiente párrafo muestran ejemplos de este enfoque.
Ahora está listo para implementar la gestión de características y feature flags. Consulte la sección Referencia para obtener detalles sobre métodos adicionales.

Mejores prácticas para inicialización y uso

  • Se recomienda inicializar KameleoonClient como singleton lo antes posible después de que inicie la aplicación, ya que la inicialización puede llevar algún tiempo. Dado que la inicialización es asincrónica, no bloquea ni retrasa el proceso de inicio de la aplicación.
  • Antes de usar KameleoonClient, verifique que esté inicializado llamando al método runWhenReady. De lo contrario, los intentos de usar el cliente antes de que esté listo resultarán en errores.
  • ⚠️ La mayoría de los métodos clave pueden lanzar excepciones, por lo que se requiere un manejo de excepciones adecuado. Asegúrese de revisar la documentación de cada método que use para comprender sus posibles excepciones.

Activación de un feature flag

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, use el método getRemoteVisitorData(). Este método obtiene datos de los servidores de forma asincrónica. Es importante llamar a getRemoteVisitorData() antes de recuperar la variación o comprobar si el feature flag está activo, ya que estos datos podrían ser necesarios para asignar 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 agregue al perfil del visitante estarán disponibles al analizar sus experimentos, lo que le permitirá filtrar y desglosar sus resultados por factores como el dispositivo. 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.
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 el parámetro requerido 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.

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 isUniqueIdentifier=true pasado a KameleoonClientConfig - para recuperar datos de todos los visitantes vinculados.
  • trackConversion() o flush() con isUniqueIdentifier=true pasado a KameleoonClientConfig - para realizar seguimiento de algunos datos para un visitante específico que está 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 visitante anónimo generado automáticamente por el SDK. El visitor code puede recuperarse con 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.

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.

Gestión de errores

Todos los métodos del Kameleoon SDK pueden lanzar únicamente KameleoonException o sus excepciones heredadas documentadas (enumeradas en la sección Excepciones lanzadas de cada método). Estas excepciones son comportamiento esperado del SDK. Si desea manejar escenarios específicos de manera diferente, puede capturar excepciones heredadas individuales; de lo contrario, capturar KameleoonException manejará todos los errores relacionados con el SDK. Aunque nuestras pruebas unitarias e integración confirman que el SDK nunca lanza Exception o RuntimeException, entendemos que los parches de versiones del SDK en Android pueden ser difíciles, y pueden surgir problemas inesperados de librerías de terceros que podrían lanzar una RuntimeException. Para evitar que su aplicación se bloquee en esos casos excepcionales raros, recomendamos que también capture Exception (o RuntimeException) como salvaguarda adicional. Esto es estrictamente una precaución y no es un comportamiento esperado del SDK. Por ejemplo:

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.

Pasar el código del visitante a un WebView

En algunos casos, es posible que deba pasar el código del visitante de la aplicación nativa a un WebView que use Engine.js o los SDKs de web JavaScript o React. El siguiente ejemplo demuestra la forma recomendada de lograrlo:

Referencia

Esta es la documentación de referencia completa para el SDK de Android de Kameleoon.

Inicialización

Una vez que haya instalado el SDK en su aplicación, el primer paso es inicializar Kameleoon. Todas las interacciones de su aplicación con el SDK, como activar un experimento, se realizan usando este objeto cliente de Kameleoon.

create()

Llame a este método antes que a cualquier otro para inicializar el SDK. Este método se encuentra en com.kameleoon.KameleoonClientFactory. Su aplicación realiza todas las interacciones con el SDK utilizando el objeto KameleoonClient resultante que este método crea. Puede personalizar el comportamiento del SDK (por ejemplo, el entorno, las credenciales, etc.) proporcionando un objeto de configuración. De lo contrario, el SDK intentará encontrar y usar su archivo de configuración.
Parámetros
Valor de retorno
Excepciones lanzadas

isReady()

Para SDKs móviles, el Cliente de Kameleoon no puede inicializarse inmediatamente, ya que debe realizar una llamada al servidor para recuperar la configuración actual de los feature flags activos. Llame a isReady() antes de activar feature flags para comprobar si el SDK está listo. Alternativamente, puede usar un callback (consulte el método runWhenReady() para obtener detalles).
Valor de retorno

runWhenReady()

  • 🔄 Realiza una solicitud asincrónica (si la configuración está obsoleta o falta)
Para SDKs móviles, el KameleoonClient no puede inicializarse inmediatamente, ya que debe realizar una llamada al servidor para recuperar la configuración actual de todos los feature flags. Use el método runWhenReady() para manejar el tiempo hasta que el cliente esté listo para usar. Además, puede establecer un período de tiempo de espera máximo para controlar cuánto tiempo esperará el cliente antes de que esté listo. Si result.getOrThrow()=true, el KameleoonClient está inicializado y listo, y los feature flags se activarán con sus respectivas variaciones. Si el resultado es false o se agota el tiempo de espera, la inicialización no se completará correctamente. El callback o el código basado en corutinas debe incluir lógica para aplicar la variación de referencia, ya que el usuario será excluido del feature flag si se produce un timeout.
Dado que la configuración inicial puede requerir una llamada al servidor, este mecanismo es asincrónico. Por lo tanto, debe:
  • Proporcionar un callback completion como argumento del método para asegurar que se le notifique cuando el KameleoonClient esté completamente inicializado y listo para usar.
  • Usar corrutinas para manejar operaciones asincrónicas.
Parámetros

Feature flags y variaciones

isFeatureActive()

  • 📨 Envía datos de seguimiento a Kameleoon (dependiendo del parámetro track)
Este método se llamaba anteriormente activateFeature, que fue removido en la versión 4.0.0 del SDK.
Llame a este método para activar un feature toggle. Este método acepta un featureKey como argumento obligatorio para comprobar si la funcionalidad especificada estará activa para un visitante. Si el visitante nunca ha sido asociado con este feature flag, el método devuelve un valor booleano aleatorio (true si el visitante debe ver esta característica, de lo contrario false). Si el visitante ya está registrado con este feature flag, este método devuelve el valor anterior de featureFlag. Asegúrese de configurar adecuadamente el manejo de errores como se muestra en el código de ejemplo para capturar posibles excepciones.
Kameleoon usa el seguimiento para contar sesiones y visitantes cuando llamas a ciertos métodos, como isFeatureActive(), getVariation() o getVariations().Use el valor predeterminado true para el parámetro track cuando exponga a los visitantes a una variación y necesite contarlos. Establezca el parámetro track en false solo si llama a estos métodos antes de exponer a los visitantes.Por ejemplo, si llama a getVariations() para recuperar todas las variaciones antes de exponer visitantes, establezca el parámetro track en false. Esta configuración evita que Kameleoon cuente una sesión prematuramente. Luego puede activar el seguimiento más tarde cuando expone explícitamente al visitante.Kameleoon envía datos de seguimiento cada segundo de forma predeterminada. Puede configurar este intervalo hasta cinco segundos utilizando la opción de configuración del intervalo de seguimiento. Kameleoon agrupa los eventos de seguimiento en una sola sesión siempre que el intervalo entre eventos sea menor a 30 minutos. Si transcurren más de 30 minutos entre eventos de seguimiento, Kameleoon cuenta los eventos como sesiones separadas. Una visita aparece en sus informes 30 minutos después del último evento registrado en la sesión.
El método isFeatureActive() evalúa la variante servida, no el estado del flag maestro. Si excluyes reglas, el método usa el estado predeterminado Entonces, para todos los demás servir. Si seleccionas Apagado para este estado predeterminado, el método siempre devuelve false incluso cuando el feature flag maestro está Encendido.
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 featureKey como argumentos obligatorios. El argumento track es opcional y por defecto es 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 de respuesta que se aplica a todos los usuarios que no son segmentados por reglas específicas. Se representa como la variación en la sección “Entonces, para todos los demás servir…” en una interfaz de gestió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 onlyActive y track como argumentos 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. Por defecto, 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 de respuesta que se aplica a todos los usuarios que no son segmentados por reglas específicas. Se representa como la variación en la sección “Entonces, para todos los demás servir…” en una interfaz de gestió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, anula la lógica de evaluación en tiempo real de Kameleoon. Se omiten procesos como segmentación, condiciones de segmentación y cálculos algorítmicos. Para preservar la segmentación y las condiciones de segmentación durante un experimento, establece forceTargeting=false en su lugar. 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.
Parámetros
Excepciones lanzadas
En la mayoría de los casos, solo es necesario gestionar el error básico KameleoonException, como se demuestra en el ejemplo. Sin embargo, si diferentes tipos de errores requieren una respuesta, maneja cada uno por separado según requisitos específicos. Además, para 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 de visitante relevantes 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, permitiendo 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.
Excepciones lanzadas
En la mayoría de los casos, solo es necesario gestionar el error básico KameleoonException, como se demuestra en el ejemplo. Sin embargo, si diferentes tipos de errores requieren una respuesta, maneja cada uno por separado según requisitos específicos. Además, para mayor confiabilidad, los errores generales del lenguaje pueden manejarse incluyendo Exception.

getDataFile()

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

Goals

trackConversion()

  • 📨 Envía datos de seguimiento a Kameleoon
Use este método para realizar el seguimiento de conversiones. Este método requiere goalId para hacer seguimiento de la conversión en este objetivo en particular. Además, este método también acepta los argumentos revenue, metadata y negative. 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.
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”).

Eventos

setEventHandler()

Utilice este método para registrar un handler para eventos del SDK. El SDK llama al handler cuando ocurre el evento seleccionado. El registro de un nuevo handler para el mismo tipo de evento reemplaza el handler anterior. Pasar null como el 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

Datos del visitante

getVisitorCode()

Devuelve el código de visitante único utilizado en el SDK.
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, 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

flush()

  • 📨 Envía datos de seguimiento a Kameleoon
flush() toma los datos de Kameleoon asociados con un visitante y envía una solicitud de seguimiento junto con todos los datos que se agregaron previamente usando el método addData() que aún no se han enviado al llamar uno de estos métodos. flush() no es bloqueante, ya que la llamada del servidor se realiza de forma asincrónica. flush() proporciona control sobre cuándo se envían los datos asociados con un visitante a los servidores. Por ejemplo, si addData() se llama una docena de veces, enviar datos al servidor después de cada invocación de addData() sería ineficiente. Llame a flush() una sola vez al final. El método flush() usa visitorCode como identificador único del visitante, lo cual es útil para la experimentación entre dispositivos. Si establece el parámetro de configuración isUniqueIdentifier en true, el SDK vincula los datos vaciados con el visitante asociado al identificador especificado.
Parámetros

getRemoteData()

  • 🔄 Realiza una solicitud asincrónica
Este método se llamaba anteriormente retrieveDataFromRemoteSource, que fue eliminado en la versión 4.0.0 del SDK.
Use este método para recuperar datos de un servidor remoto de Kameleoon basado en el siteCode activo y el argumento key (o el visitorCode activo si se omite la key). El visitorCode y siteCode se especifican en KameleoonClientFactory.create(). Los datos se pueden almacenar rápida y convenientemente en servidores altamente escalables mediante la API de Datos de Kameleoon. La aplicación puede recuperar los datos usando este método.
Dado que se requiere una llamada al servidor, este mecanismo es asincrónico. Por lo tanto, debe:
  • Proporcionar un callback completion como argumento del método para asegurar que se le notifique cuando los datos se hayan obtenido correctamente.
  • Usar corrutinas para manejar operaciones asincrónicas.
Parámetros

getRemoteVisitorData()

  • 🔄 Realiza una solicitud asincrónica
getRemoteVisitorData() es un método asincrónico para recuperar Datos de Visitas de Kameleoon para el visitante desde la API de Datos de Kameleoon. El método agrega datos al almacenamiento para que otros métodos los usen al tomar decisiones de orientació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 datos personalizados recopilados durante visitas anteriores.
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 más recientes almacenados con scope=Visitor y los adjunta al visitante sin tener que llamar al método addData(). Es particularmente útil para sincronizar datos personalizados entre varios dispositivos.Se recomienda verificar solo los resultados fallidos. Sin embargo, si es necesario, se puede verificar que los datos se hayan agregado al visitante y estén disponibles para propósitos de orientación (o para depuración, aunque usar registro es mejor para depuración). Además, los datos se pueden gestionar manualmente si se pasa el parámetro shouldAddData=false.
Dado que se requiere una llamada al servidor, este mecanismo es asincrónico. Por lo tanto, debe:
  • Proporcionar un callback completion como argumento del método para asegurar que se le notifique cuando los datos se hayan obtenido correctamente y se hayan agregado al visitante.
  • Usar corrutinas para manejar operaciones asincrónicas.
Parámetros
Usar parámetros de RemoteVisitorDataFilter
El método getRemoteVisitorData() ofrece flexibilidad al permitirle definir varios parámetros al recuperar datos de los visitantes. Ya sea que esté segmentando en función de objetivos, experimentos o variaciones, el mismo enfoque se aplica a todos los tipos de datos. Por ejemplo, suponga que desea recuperar datos sobre visitantes que completaron un objetivo “Order transaction” (Transacción de pedido). Puede especificar parámetros dentro del método getRemoteVisitorData() para refinar su orientación. Por ejemplo, si desea orientarse solo a usuarios que se convirtieron en el objetivo en sus últimas cinco visitas, puede establecer el parámetro previousVisitAmount en 5 y conversions en 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.
Aquí está la lista de opciones RemoteVisitorDataFilter disponibles:

getVisitorWarehouseAudience()

  • 🔄 Realiza una solicitud asincrónica
Recupera todos los datos de audiencia asociados con el visitante en su data warehouse. El parámetro warehouseKey opcional es típicamente su ID de usuario interno. El parámetro customDataIndex corresponde a los datos personalizados de Kameleoon que Kameleoon utiliza para segmentar a sus visitantes. Puede consultar la documentación de segmentación de warehouse para más detalles.
Como se requiere una llamada al servidor, este mecanismo es asincrónico. Por lo tanto, debería:
  • Proporcionar una devolución de llamada completion como argumento del método para asegurarse de que se le notifique cuando los datos se hayan recuperado exitosamente y se hayan añadido al visitante.
  • Utilizar corrutinas para el manejo asincrónico.
Se recomienda comprobar solo los resultados fallidos. Sin embargo, si es necesario, se puede verificar que los datos se han añadido al visitante y están disponibles para fines de segmentación (o para depuración, aunque usar registro es mejor para depuración).
Parámetros

setLegalConsent()

Debe utilizar este método para especificar si el visitante ha dado su consentimiento legal para el uso de sus datos personales. Establecer el parámetro legalConsent en false limita los tipos de datos que puede incluir en solicitudes de seguimiento. Este método le ayuda a cumplir con 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 de consentimiento.
Parámetros

Tipos de datos

Esta sección enumera los tipos com.Kameleoon.Data soportados por Kameleoon. Se proporcionan varios tipos de datos estándar, así como el tipo CustomData para definir tipos de datos personalizados.

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.

Device

Desde Android SDK 4.13.0, el Device se detecta automáticamente en función del android.content.Context. Sin embargo, aún puede anularlo manualmente si es necesario.
Almacene información sobre el dispositivo del usuario.

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

Defina sus propios tipos de datos personalizados en la aplicación de Kameleoon o en la API de Datos y utilícelos desde el SDK.
  • El índice de los datos personalizados está disponible en la página Configuración de datos personalizados de la aplicación de Kameleoon. Tenga cuidado: este índice comienza en 0, por lo que el primer dato personalizado que cree para un sitio determinado tendría el índice 0, no 1.
  • Añadir una instancia CustomData creada con un nombre cuando la configuración de instancia del SDK no está actualizada o el nombre no está registrado resultará en que los datos se ignoren.

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 al visitante (o la variación predeterminada, si no existe una 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.
Use este método para obtener la clave de variación de funcionalidad para un visitante. Este método toma un featureKey como argumento obligatorio para recuperar la clave de variación para el usuario especificado. Si el visitante 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 el visitante ya está registrado con este feature flag, este método devuelve la clave de variación anterior. Si el usuario no coincide con ninguna de las reglas, se devolverá el valor predeterminado, que se define en la cuenta de su cliente. Asegúrese de configurar el manejo adecuado de errores como se muestra en el código de ejemplo para capturar posibles excepciones.

getFeatureVariationKey()

  • 📨 Envía datos de seguimiento a Kameleoon
Utilice getVariation() en su lugar.
Use este método para obtener la clave de variación de funcionalidad para un visitante. Este método toma un featureKey como argumento obligatorio para recuperar la clave de variación para el usuario especificado. Si el visitante 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 el visitante ya está registrado con este feature flag, este método devuelve la clave de variación anterior. Si el usuario no coincide con ninguna de las reglas, se devolverá el valor predeterminado, que se define en la cuenta de su cliente. Asegúrese de configurar el manejo adecuado de errores como se muestra en el código de ejemplo para capturar posibles excepciones.

getActiveFeatures()

  • Utilice getVariations() en su lugar.
  • Anteriormente llamado getFeatureListForVisitorCode, que fue eliminado en la versión SDK 4.0.0.
El método getActiveFeatures recupera información sobre los feature flags activos que están disponibles para el visitante.
Valor de retorno

getFeatureVariable()

  • 📨 Envía datos de seguimiento a Kameleoon
Utilice getVariation() en su lugar.
Este método obtiene el valor de variable de una clave de variación para un usuario específico. Toma un featureKey y un variableKey como argumentos obligatorios. Si el visitante nunca ha sido asociado con featureKey, el SDK devuelve un valor de variable asignado aleatoriamente para la clave de variación especificada (según las reglas del feature flag). Si el visitante ya está registrado con este feature flag, el método devuelve el valor de variable para la variación registrada anteriormente. Si el usuario no coincide con ninguna de las reglas, se devuelve el valor de variable predeterminado. Asegúrese de configurar el manejo adecuado de errores como se muestra en el código de ejemplo para capturar posibles excepciones.
Parámetros
Valor de retorno
Excepciones lanzadas

getFeatureVariationVariables()

  • Utilice getVariation() en su lugar.
  • Este método fue llamado anteriormente getFeatureAllVariables, que fue eliminado en la versión SDK 4.0.0.
Para recuperar todas las variables de un feature, llame a este método. Puede modificar sus variables de feature en la aplicación de Kameleoon. Este método toma un parámetro de entrada: featureKey. Devuelve los datos como un tipo Map<String, Object>, según se define en la aplicación de Kameleoon. Lanza una excepción (FeatureNotFound) si el feature solicitado no se encontró en la configuración interna del SDK.
Parámetros
Valor de retorno
Excepciones lanzadas

getFeatureList()

Si desea iterar sobre todos los feature flags y llamar a getVariation() en cada uno, utilice el método getVariations() en su lugar.
Devuelve una lista de claves de feature flags disponibles actualmente en el SDK.
Valor de retorno

onUpdateConfiguration()

Este método se llamaba anteriormente updateConfigurationHandler, que se eliminó en la versión 4.0.0 del SDK.
El método onUpdateConfiguration() permite manejar el evento cuando la configuración tiene datos actualizados. Toma un parámetro de entrada, completion. La finalización que se llamará cuando la configuración se actualice mediante un evento de configuración en tiempo real.
Parámetros