Guía del desarrollador
Primeros pasos
Esta guía le ayuda a integrar el SDK y a comenzar a ejecutar experimentos en aplicaciones Flutter. Este tutorial explica la configuración de una prueba A/B sencilla para cambiar el número de productos recomendados en función de distintas variaciones.Instalar el cliente Flutter
Para instalar el cliente Flutter de Kameleoon, declare una dependencia en su archivopubspec.yaml:
Inicializar el cliente Kameleoon
Tras instalar el SDK en su aplicación y configurar un experimento en el lado del servidor en la aplicación Kameleoon, el siguiente paso es crear el cliente Kameleoon. UnKameleoonClient es un objeto singleton (por siteCode) 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.
KameleoonClientFactory.create() inicializa el cliente, pero este no está listo para usarse de inmediato, ya que el cliente Kameleoon debe recuperar la configuración actual de los feature flags (junto con su distribución de tráfico) desde un servidor remoto de Kameleoon. Esta recuperación requiere acceso a la red, que no siempre está disponible. Hasta que el cliente Kameleoon esté totalmente listo, no debe intentar ejecutar otros métodos del SDK de Android de Kameleoon. Tenga en cuenta que, una vez obtenida la primera configuración de feature flags, esta se actualiza periódicamente, pero incluso si la actualización falla por cualquier motivo, el cliente Kameleoon seguirá funcionando con la configuración anterior.
Puede utilizar el método isReadyAsync() para comprobar si ha finalizado la inicialización del cliente Kameleoon.
Como alternativa, un callback auxiliar puede encapsular la lógica de activación de feature flags y la implementación de las variaciones. El mejor enfoque (isReadyAsync() o callback) depende de las preferencias y del caso de uso concreto. Utilice isReadyAsync() cuando se espere que el SDK esté listo para utilizarse pronto. Por ejemplo, isReadyAsync() resulta apropiado al ejecutar un feature flag en un diálogo al que probablemente los usuarios no accedan durante los primeros segundos o minutos de navegación por la aplicación. Se recomienda usar un callback cuando exista una alta probabilidad de que el SDK todavía se esté inicializando. Por ejemplo, un feature flag que aparezca en pantalla en el lanzamiento de la aplicación debería utilizar un callback que haga que la aplicación espere hasta que el SDK esté listo o hasta que expire un tiempo de espera especificado.
Es responsabilidad suya, como desarrollador de la aplicación, asegurarse de que la lógica del código de su aplicación sea correcta en el contexto de los tests A/B con Kameleoon. Una buena práctica consiste en asumir siempre que el usuario de la aplicación puede quedar excluido del feature flag cuando el cliente Kameleoon aún no está listo. Esta exclusión es fácil de implementar, ya que se corresponde con la implementación de la variación por defecto o de referencia. Los ejemplos de código del siguiente apartado muestran ejemplos de este enfoque.
Activación de un feature flag
Recuperar la configuración de un flag
Para implementar un feature flag en su código, primero debe crear un feature flag en su cuenta Kameleoon. Para determinar si un feature flag está activo para un usuario específico, debe recuperar su configuración. Utilice el métodogetFeatureVariationKey() o isFeatureActive() para recuperar la configuración según el featureKey.
Utilice el método isFeatureActive() si desea recuperar la configuración de un feature flag simple que solo tiene un estado ON u OFF, en lugar de feature flags más complejos con varias variaciones u opciones de segmentación.
El método getFeatureVariationKey() recupera la configuración de un experimento de funcionalidad con varias variaciones. Puede utilizar el método para obtener una clave de variación para un usuario determinado proporcionando visitorCode y featureKey como argumentos obligatorios.
Los feature flags pueden tener variables asociadas que se utilizan para personalizar su comportamiento. Para recuperar estas variables, utilice el método getFeatureVariationVariables() después de llamar a getFeatureVariationKey(), ya que debe obtener el variationKey del usuario.
Para comprobar si un feature flag está activo, solo necesita utilizar un método. Elija
isFeatureFlagActive si desea saber si un feature flag está activado o desactivado. Para escenarios más complejos, como cambiar dinámicamente el comportamiento de la funcionalidad, utilice getFeatureFlagVariables.Añadir puntos de datos para segmentar un usuario o filtrar / desglosar visitas en los 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 de comprobar si el flag está activo. Utilice el métodoaddData() para añadir estos puntos de datos al perfil del usuario.
Para recuperar puntos de datos recopilados en otros dispositivos o para acceder a datos pasados del usuario (recopilados del lado del cliente al utilizar Kameleoon en modo híbrido), utilice el método getRemoteVisitorData(). Este método obtiene datos de forma asíncrona desde los servidores. Llame a getRemoteVisitorData() antes de recuperar la variación o de comprobar si el feature flag está activo, ya que es posible que estos datos sean necesarios para asignar a un usuario a una variación determinada de un feature flag.
Para obtener más información sobre las condiciones de segmentación disponibles, consulte el artículo detallado sobre el tema.
Además, los puntos de datos que añada al perfil del visitante estarán disponibles al analizar sus experimentos, lo que le permitirá filtrar y desglosar los resultados por factores como el dispositivo y el navegador. Recuerde llamar al método flush() para enviar los datos almacenados a los servidores de Kameleoon.
Si necesita rastrear puntos de datos adicionales más allá de lo que se recopila automáticamente, puede utilizar la funcionalidad de Datos Personalizados de Kameleoon. Los datos personalizados le permiten 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 la exposición a flags y de las conversiones de objetivos
Kameleoon rastreará automáticamente la exposición de los visitantes a los flags en cuanto llame a uno de estos métodos:getFeatureVariationKey()getFeatureVariable()isFeatureActive()
trackConversion() e indicar los parámetros visitorCode y goalId.
Uso de una clave de bucketing personalizada
De forma predeterminada, Kameleoon utiliza un ID único y anónimo del visitante (visitorCode) para asignar a los usuarios a las variaciones de los feature flags. Este ID se genera y se almacena normalmente en el dispositivo del usuario (en una cookie del navegador para los SDKs cliente y servidor, en almacenamiento persistente para los SDKs móviles). Sin embargo, en determinados escenarios es posible que necesite garantizar que todos los usuarios de una misma organización vean la misma variante de un feature flag.
La opción Clave de bucketing personalizada 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 especifique en lugar del visitorCode predeterminado.
Casos de uso
Utilizar una clave de bucketing personalizada es esencial para mantener la coherencia y la precisión en las asignaciones de feature flags, especialmente en estas situaciones:- Experimentos a nivel de cuenta u organización: para productos B2B o escenarios en los que quiera asignar a todos los usuarios de la misma organización a la misma variación, puede usar un identificador como
accountId. Las claves de bucketing personalizadas son cruciales para los tests A/B de funcionalidades que afectan a todo un equipo o empresa.
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: proporciona su identificador personalizado al SDK de Kameleoon mediante el método
addData(). En este método pasará la clave de bucketing personalizada elegida como objetoCustomData. Aquí,newVisitorCodese refiere al identificador que desea utilizar para su bucketing (por ejemplo, el nuevouserIdoaccountId).
- Lógica de bucketing: una vez proporcionada la clave de bucketing personalizada mediante el método
addData(), todos los cálculos de hash para asignar usuarios a variaciones utilizarán estenewVisitorCode(su clave personalizada) en lugar delvisitorCodepredeterminado. El uso denewVisitorCodesignifica que la decisión de bucketing se vincula a su identificador personalizado, garantizando asignaciones coherentes en distintos contextos en los que esté presente dicho identificador. - Seguimiento de datos y analítica: es crucial tener en cuenta que, aunque se utiliza
newVisitorCode(su clave personalizada) para las decisiones de bucketing, todos los datos posteriores (eventos de seguimiento y conversiones, por ejemplo) se envían y se asocian con elvisitorCodeoriginal. Esta separación garantiza que sus analíticas reflejen 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 de visitante permanecen intactos para informes completos.
Requisitos técnicos
Para utilizar eficazmente una clave de bucketing personalizada:- La clave debe ser una
String. - Debe ser única para la entidad que tenga la intención de bucketizar (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 el 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 utilizar para segmentar a los usuarios en sus campañas. Para conocer la lista de condiciones que admite este SDK, consulte usar el historial de visitas para segmentar usuarios. También puede utilizar sus propios datos externos para segmentar a los usuarios.Logging
El SDK genera registros (logs) para reflejar diversos procesos e incidencias internos.Niveles de log
El SDK admite la configuración del logging limitándolo por nivel de log.Gestión personalizada de los logs
De forma predeterminada, el SDK escribe sus logs en la salida de consola. Este comportamiento puede sobrescribirse.La limitación del logging por nivel de log se realiza independientemente de la lógica de gestión de los logs.
Manejo de errores
Manejar los errores se considera una buena práctica para hacer su aplicación más estable y evitar problemas técnicos. La mayoría de los métodos deKameleoonClient pueden lanzar un error KameleoonException.
Dado que puede resultar difícil aplicar parches a la versión del SDK en el lado del cliente Android, se recomienda envolver cada método del SDK en una cláusula try que capture el KameleoonException y el tipo de error Throwable para prevenir otros errores fatales.
Por ejemplo:
Referencia
Esta es la documentación de referencia completa del SDK de Flutter.Inicialización
Una vez que haya instalado el SDK en su aplicación, debe inicializar Kameleoon. Todas las interacciones de su aplicación con el SDK, como la activación de un experimento, se realizan a través de este objeto cliente Kameleoon.create()
Llame a este método antes que a cualquier otro para inicializar el SDK. Este método pertenece aKameleoonClientFactory. Su aplicación realiza todas las interacciones con el SDK utilizando el objeto KameleoonClient resultante que crea este método.
Puede personalizar el comportamiento del SDK (por ejemplo, el entorno, las credenciales, etc.) proporcionando un objeto de configuración. De lo contrario, el SDK intenta encontrar su archivo de configuración y lo utiliza en su lugar.
Argumentos
Valor devuelto
Excepciones lanzadas
isReadyAsync()
Para los SDKs móviles, el cliente Kameleoon no puede inicializarse de inmediato porque debe realizar una llamada al servidor para recuperar la configuración actual de los feature flags activos. UtiliceisReadyAsync() para comprobar si el SDK está listo, llamando a este método antes de activar cualquier feature flag.
Como alternativa, puede utilizar un callback (consulte el método runWhenReady() para más detalles).
Valor devuelto
runWhenReady()
Para los SDKs móviles, el cliente Kameleoon no puede inicializarse de inmediato porque debe realizar una llamada al servidor para recuperar la configuración actual de todos los feature flags activos. Utilice el métodorunWhenReady() de la clase KameleoonClient para pasar un callback que se ejecutará en cuanto el SDK esté listo para usarse. También puede establecer un tiempo de espera.
El callback indicado como primer argumento de este método debe ser una instancia de un tipo Function(bool ready). Si ready es true, el cliente Kameleoon está listo y debería contener el código que activa un feature flag e implementa las variaciones. De lo contrario, se habrá producido el tiempo de espera especificado antes de que se inicialice el cliente. El callback debería contener el código que implementa la variación de referencia, ya que el usuario quedará excluido del feature flag si se produce un timeout.
Argumentos
Feature flags y variaciones
isFeatureActive()
- 📨 Envía datos de seguimiento a Kameleoon
featureKey como argumento obligatorio para comprobar si la funcionalidad especificada estará activa para un visitante.
Si el visitante nunca ha estado asociado a este feature flag, el método devuelve un valor booleano aleatorio (true si se debe mostrar esta funcionalidad al visitante, false en caso contrario). Si el visitante ya está registrado con este feature flag, este método devuelve el valor previo del feature flag.
Asegúrese de configurar un manejo de errores adecuado, tal como se muestra en el código de ejemplo, para capturar las posibles excepciones.
Kameleoon utiliza el seguimiento para contabilizar sesiones y visitantes cuando se llaman determinados métodos como
isFeatureActive(), getVariation() o getVariations().Utilice el valor predeterminado true para el parámetro track cuando exponga a los visitantes a una variación y necesite contabilizarlos. Establezca el parámetro track a false únicamente 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 a los visitantes, establezca el parámetro track en false. Esta configuración evita que Kameleoon contabilice prematuramente una sesión. Posteriormente podrá activar el seguimiento cuando exponga explícitamente al visitante.Kameleoon envía los datos de seguimiento cada segundo por defecto. Puede configurar este intervalo hasta cinco segundos mediante la opción de configuración del intervalo de seguimiento. Kameleoon agrupa los eventos de seguimiento en una única sesión siempre que el intervalo entre eventos sea inferior a 30 minutos. Si transcurren más de 30 minutos entre eventos de seguimiento, Kameleoon los cuenta como sesiones separadas. Una visita aparece en sus informes 30 minutos después del último evento registrado en la sesión.Argumentos
Valor devuelto
Excepciones lanzadas
getVariation()
- 📨 Envía datos de seguimiento a Kameleoon (según el parámetro
track)
Variation asignada a un visitante determinado para un feature flag específico.
Este método toma visitorCode y featureKey como argumentos obligatorios. El argumento track es opcional y su valor predeterminado es true.
Devuelve la Variation asignada al visitante. Si el visitante no está asociado a ninguna regla de feature flag, el método devuelve la Variation por defecto para el feature flag indicado.
Asegúrese de que su código implementa un manejo de errores adecuado para gestionar las posibles excepciones.
La variación por defecto se refiere a la variación asignada a un visitante cuando este no coincide con ninguna regla de entrega predefinida para un feature flag. Dicho de otro modo, es la variación de respaldo que se aplica a todos los usuarios que no son segmentados por reglas específicas. Está representada por la variación de la sección “Entonces, para todos los demás…” en una interfaz de gestión.
Argumentos
Valor devuelto
Excepciones lanzadas
getVariations()
- 📨 Envía datos de seguimiento a Kameleoon (según el parámetro
track)
Variation asignados a un visitante determinado en todos los feature flags.
Este método itera sobre todos los feature flags disponibles y devuelve la Variation asignada para cada flag asociado al visitante especificado. Toma onlyActive y track como argumentos opcionales.
- Si
onlyActivese establece entrue, el métodogetVariations()devolverá las variaciones de los feature flags siempre que el usuario no esté bucketizado en la variaciónoff. - El parámetro
trackcontrola si el método rastrea o no las asignaciones de variaciones. Por defecto, está establecido entrue. Si se establece enfalse, el seguimiento se desactivará.
Variation correspondiente como valores. Si no hay variación asignada para un feature flag, el método devuelve la Variation por defecto para ese flag.
Debe implementarse un manejo de errores adecuado para gestionar las posibles excepciones.
La variación por defecto se refiere a la variación asignada a un visitante cuando este no coincide con ninguna regla de entrega predefinida para un feature flag. Dicho de otro modo, es la variación de respaldo que se aplica a todos los usuarios que no son segmentados por reglas específicas. Está representada por la variación de la sección “Entonces, para todos los demás…” en una interfaz de gestión.
Argumentos
Valor devuelto
Excepciones lanzadas
getFeatureList()
Devuelve una lista de claves de feature flags actualmente disponibles para el SDK.Valor devuelto
getDataFile()
Devuelve la configuración actual del SDK como un objetoDataFile.
Valor devuelto
Errores lanzados
setForcedVariation()
El método le permite asignar de forma programática unaVariation específica a un usuario, omitiendo el proceso de evaluación estándar. Esto resulta especialmente valioso en experimentos controlados en los que no se requiere la lógica habitual de evaluación o debe omitirse. También puede ser útil en escenarios como la depuración o las 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 targeting y los cálculos algorítmicos. Para conservar la segmentación y las condiciones de targeting durante un experimento, establezca forceTargeting=false en su lugar.
Una variación forzada se trata igual que una variación evaluada. Se rastrea en la analítica y se almacena en el contexto del usuario como cualquier variación estándar evaluada, garantizando la coherencia en los informes.
El método puede lanzar excepciones en determinadas condiciones (por ejemplo, parámetros no válidos, contexto del usuario o problemas internos). Es esencial un manejo adecuado de las excepciones para garantizar que su aplicación siga siendo estable y resiliente.
Argumentos
Errores lanzados
En la mayoría de los casos, solo es necesario manejar el error básico,
KameleoonException, como se muestra en el ejemplo. Sin embargo, si distintos tipos de errores requieren una respuesta, gestione cada uno por separado en función de los requisitos específicos. Además, para mayor fiabilidad, pueden manejarse los errores generales del lenguaje incluyendo Exception.evaluateAudiences()
- 📨 Envía datos de seguimiento a Kameleoon
evaluateAudiences() debe llamarse después de que se hayan establecido o actualizado todos los datos relevantes del visitante, y justo antes de obtener una variación de funcionalidad o comprobar un feature flag. Este enfoque garantiza que el visitante sea evaluado con los datos más actuales disponibles, lo que permite una asignación precisa de audiencias en función de todos los criterios.
Tras llamar a este método, puede realizar un análisis detallado del rendimiento de los segmentos en Audiences Explorer.
Errores lanzados
En la mayoría de los casos, solo es necesario manejar el error básico,
KameleoonException, como se muestra en el ejemplo. Sin embargo, si distintos tipos de errores requieren una respuesta, gestione cada uno por separado en función de los requisitos específicos. Además, para mayor fiabilidad, pueden manejarse los errores generales del lenguaje incluyendo Exception.Objetivos
trackConversion()
- 📨 Envía datos de seguimiento a Kameleoon
goalId para rastrear 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.
Argumentos
Los valores de los metadatos son accesibles a través de las exportaciones de datos sin procesar y de 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 que se haya recopilado previamente con 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 ejemplo siguiente, Kameleoon asociará la conversión únicamente con el valor del custom data proporcionado explícitamente como parámetro (aquí: índice 5 con el valor ‘Amex Credit Card’).Eventos
onUpdateConfiguration()
Este método se llamaba anteriormente
updateConfigurationHandler y se eliminó en la versión 3.0.0 del SDK.onUpdateConfiguration() le permite gestionar el evento cuando la configuración ha actualizado los datos. Recibe un parámetro de entrada, handler. El handler que se llamará cuando se actualice la configuración mediante un evento de configuración en tiempo real.
Argumentos
Datos del visitante
getVisitorCode()
Devuelve el código único de visitante utilizado en el SDK.Valor devuelto
addData()
El métodoaddData() añade datos de segmentación al almacenamiento para que otros métodos puedan usar 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í solo con los servidores back-end 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 realizadas, ya que los datos se suelen agrupar en una única llamada al servidor que se desencadena con flush().
El método trackConversion() también envía cualquier dato previamente asociado, igual que flush(). Lo mismo ocurre con los métodos getVariation() y getVariations() si se activa una regla de experimentación.
Argumentos
Excepciones
flush()
- 📨 Envía datos de seguimiento a Kameleoon
addData() no se envían al servidor de inmediato. Se almacenan y acumulan hasta que se envían automáticamente con el método trackConversion(), o manualmente llamando al método flush(), lo que le permite controlar exactamente cuándo se vuelcan los datos a los servidores. Por ejemplo, si se llama al método addData() una docena de veces, enviar datos al servidor tras cada invocación de addData() desperdiciaría recursos. Llame a flush() una sola vez al final.
El método flush() no devuelve ningún valor. Este método no es bloqueante, ya que la llamada al servidor se realiza de forma asíncrona.
Excepciones lanzadas
getRemoteData()
Este método se llamaba anteriormente
retrieveDataFromRemoteSource y se eliminó en la versión 3.0.0 del SDK.siteCode activo y el argumento key (o el visitorCode activo si se omite key). El visitorCode y siteCode se especifican en KameleoonClientFactory.create(). Los datos pueden almacenarse de forma rápida y cómoda en servidores remotos altamente escalables mediante la API de datos de Kameleoon. La aplicación puede entonces recuperar los datos utilizando este método.
Tenga en cuenta que, dado que se requiere una llamada al servidor, este mecanismo es asíncrono.
Argumentos
Valor devuelto
getRemoteVisitorData()
getRemoteVisitorData() es un método asíncrono para recuperar los Datos de Visitas de Kameleoon para el visitorCode desde la API de datos de Kameleoon. Este 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 datos personalizados recopilados durante visitas anteriores.
Argumentos
Valor devuelto
Excepciones lanzadas
Uso de parámetros en getRemoteVisitorData()
El métodogetRemoteVisitorData() ofrece flexibilidad al permitirle definir varios parámetros al recuperar datos sobre visitantes. Tanto si segmenta basándose en objetivos, experimentos o variaciones, se aplica el mismo enfoque a todos los tipos de datos.
Por ejemplo, supongamos que desea recuperar datos sobre visitantes que han completado un objetivo “Transacción de pedido”. Puede especificar parámetros dentro del método getRemoteVisitorData() para afinar su segmentación. Por ejemplo, si solo desea segmentar a los usuarios que convirtieron en el objetivo durante 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.
A continuación se enumeran las opciones disponibles de
RemoteVisitorDataFilter:getVisitorWarehouseAudience()
Recupera todos los datos de audiencia asociados al visitante en su data warehouse. El parámetro opcionalwarehouseKey suele ser su ID de usuario interno. El parámetro customDataIndex corresponde al custom data de Kameleoon que Kameleoon utiliza para segmentar a sus visitantes. Puede consultar la documentación sobre targeting de warehouse para obtener más detalles. El método devuelve el resultado como un objeto CustomData, confirmando que los datos se han añadido al visitante y están disponibles con fines de segmentación.
Dado que se requiere una llamada al servidor, este mecanismo es asíncrono.
Argumentos
Valor devuelto
Excepciones lanzadas
setLegalConsent()
Debe utilizar este método para especificar si el visitante ha dado su consentimiento legal para usar sus datos personales. Establecer el parámetroconsent en false limita los tipos de datos que puede incluir en las solicitudes de seguimiento. Este método le ayuda a cumplir los requisitos legales y normativos al tiempo que gestiona los datos del visitante de forma responsable. Puede encontrar más información sobre datos personales en la política de gestión del consentimiento.
Argumentos
Excepciones lanzadas
Comportamiento de la revocación del consentimiento
Esto solo se aplica al SDK de Flutter Web.
setLegalConsent() con consent=false, el SDK no elimina la cookie kameleoonVisitorCode. En su lugar, deja de prolongar la fecha de expiración de la cookie, permitiendo que persista hasta que expire de forma natural.
Si sus requisitos de cumplimiento exigen la eliminación inmediata del archivo de cookie tras la exclusión, debe eliminarlo manualmente utilizando los métodos nativos de gestión de cookies de su framework. El SDK no eliminará el archivo automáticamente.
Tipos de datos
Esta sección enumera los tiposData admitidos 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 datosConversion aquí almacenado puede utilizarse para filtrar informes de experimentos y personalización por cualquier objetivo asociado a él.
CustomData
Este tipo de datos está disponible para ambos tipos de SDKs: Móvil y Web.
CustomData permite asociar fácilmente cualquier tipo de datos a cada visitante. CustomData puede entonces utilizarse como condición de segmentación en los segmentos o como filtro/desglose en los informes de experimentos.
Para obtener más información sobre los datos personalizados, consulte este artículo.
- Cada visitante solo puede tener un
CustomDatapara cadaindexúnico. Añadir otroCustomDatacon el mismoindexsustituirá alCustomDataexistente. - El
indexdel custom data se puede encontrar en el panel de Custom Data en la columna “INDEX”. - Para evitar que el SDK envíe datos con el índice seleccionado a los servidores de Kameleoon por motivos de privacidad, active la opción Usar estos datos solo localmente con fines de segmentación al crear el custom data.
- Añadir una instancia de
CustomDatacreada con un nombre cuando la configuración de la instancia del SDK no está actualizada o cuando el nombre no está registrado provocará que los datos se ignoren.
Device
Este tipo de datos está disponible para ambos tipos de SDKs: Móvil y Web.
Geolocation
Este tipo de datos está disponible para ambos tipos de SDKs: Móvil y Web.
Geolocation contiene los detalles de geolocalización del visitante.
Browser
El tipo de datos solo está disponible para el SDK Web
Browser aquí almacenado puede utilizarse para filtrar los informes de experimentos y personalización por cualquier valor asociado a él.
PageView
Este tipo de datos solo está disponible para los SDKs Web.
El índice (ID) del referrer está disponible en la página de configuración del canal de adquisición de la aplicación Kameleoon. Tenga cuidado: este índice empieza en 0, por lo que el primer canal de adquisición que cree para un sitio determinado tendrá el ID 0, no 1.
OperatingSystem
Este tipo de datos solo está disponible para los SDKs Web.
OperatingSystem contiene información sobre el sistema operativo del dispositivo del visitante.
Cookie
Este tipo de datos solo está disponible para los SDKs Web.
Cookie contiene información sobre la cookie almacenada en el dispositivo del visitante.
Tipos devueltos
DataFile
ElDataFile contiene los detalles de configuración del SDK.
Puede ampliarse con información adicional si los clientes lo requieren. Si necesita más detalles, póngase en contacto con su Customer Success Manager.
FeatureFlag
FeatureFlag representa un conjunto de propiedades que definen un feature flag en sí mismo, por ejemplo, sus Variations, Rules, estado del entorno y otros detalles relacionados.
Puede ampliarse con información adicional si los clientes lo requieren. Si necesita más detalles, póngase en contacto con su Customer Success Manager.
Rule
Rule representa un conjunto de propiedades que definen una regla en sí misma, por ejemplo, sus Variations.
Puede ampliarse con información adicional si los clientes lo requieren. Si necesita más detalles, póngase en contacto con su Customer Success Manager.
Variation
Variation contiene información sobre la variación asignada al visitante (o la variación por defecto, si no existe una asignación específica).
- El objeto
Variationproporciona detalles sobre la variación asignada y su experimento asociado, mientras que el objetoVariablecontiene detalles específicos sobre cada variable dentro de una variación. - Asegúrese de que su código maneja el caso en el que
idoexperimentIdpuedan ser-1, indicando una variación por defecto. - El mapa
variablespuede estar vacío si no hay variables asociadas a la variación.
Variable
Variable contiene información sobre una variable asociada a la variación asignada.
Métodos obsoletos
isReady()
Para los SDKs móviles, el cliente Kameleoon no puede inicializarse de inmediato porque debe realizar una llamada al servidor para recuperar la configuración actual de los feature flags activos. UtiliceisReady() para comprobar si el SDK está listo, llamando a este método antes de activar cualquier feature flag.
Como alternativa, puede utilizar un callback (consulte el método runWhenReady() para más detalles).
Valor devuelto
getFeatureVariationKey()
- 📨 Envía datos de seguimiento a Kameleoon
Utilice
getVariation() en su lugar.featureKey como argumento obligatorio para recuperar la clave de variación del usuario especificado.
Si el visitante nunca ha estado asociado a 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 la variación anterior. Si el usuario no coincide con ninguna de las reglas, se devolverá el valor por defecto, definido en la cuenta de su cliente.
Asegúrese de configurar un manejo de errores adecuado, tal como se muestra en el código de ejemplo, para capturar las posibles excepciones.
Argumentos
Valor devuelto
Excepciones lanzadas
getActiveFeatures()
- Utilice
getVariations()en su lugar. - Anteriormente llamado
getFeatureListForVisitorCode, eliminado en la versión4.0.0del SDK.
getActiveFeatures recupera información sobre los feature flags activos disponibles para el visitante.
Valor devuelto
getFeatureVariable()
- 📨 Envía datos de seguimiento a Kameleoon
- Utilice
getVariation()en su lugar. - Este método se llamaba anteriormente
obtainFeatureVariabley se eliminó en la versión3.0.0del SDK.
featureKey y variableKey como argumentos obligatorios.
Si el visitante nunca ha estado asociado a 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, este método devuelve el valor de la variable para la variación previamente registrada. Si el usuario no coincide con ninguna de las reglas, se devuelve el valor de variable por defecto.
Asegúrese de configurar un manejo de errores adecuado, tal como se muestra en el código de ejemplo, para capturar las posibles excepciones.
Argumentos
Valor devuelto
Excepciones lanzadas
getFeatureVariationVariables()
- Utilice
getVariation()en su lugar. - Este método se llamaba anteriormente
getFeatureAllVariables, eliminado en la versión4.0.0del SDK.
featureKey. Devuelve los datos como un tipo Map<String, Object>, según se define en la aplicación Kameleoon. Lanza una excepción (FeatureNotFound) si la funcionalidad solicitada no se ha encontrado en la configuración interna del SDK.