Saltar al contenido principal
Coordine los SDKs de Kameleoon entre sitios web, aplicaciones móviles y servidores backend para mantener una identidad de visitante unificada. Esta coordinación garantiza un tratamiento coherente de los experimentos y un flujo de datos consistente en todas las plataformas. Utilice esta guía si un proyecto implementa varios SDKs de Kameleoon:
  • El JavaScript SDK o engine.js para entornos web.
  • El SDK móvil para aplicaciones Android o iOS.
  • SDKs del lado del servidor para integraciones de backend y lógica de decisión.

​
Descripción general de la arquitectura

Una configuración típica multi-entorno incluye los siguientes componentes:
  • Sitio web: utiliza el JavaScript SDK o engine.js para ejecutar experimentos y campañas de personalización del lado del cliente.
  • Aplicación móvil: utiliza un SDK móvil para mostrar las variaciones y hacer seguimiento de las conversiones.
  • Servidor backend: utiliza un SDK del lado del servidor para tomar decisiones de variación centralizadas o sincronizar los datos del visitante.

​
Flujo de datos y de visitor code

  • El visitor code identifica a los usuarios de forma consistente en todos los entornos.
  • El SDK del lado del servidor coordina las decisiones de variación cuando es necesario.
  • Cada SDK envía los datos de analítica y tracking directamente a la plataforma Kameleoon.

​
Visitor code y gestión cross-device

​
Generar y compartir los visitor codes

Cada visitante único debe tener un visitor code consistente en todas las plataformas. Este código permite a Kameleoon unificar las decisiones de experimento y el tracking. Siga este flujo multiplataforma:
  1. El engine, el web SDK, el SDK del lado del servidor o la aplicación móvil genera el visitor code.
  2. El backend recupera el visitor code existente cuando el usuario inicia sesión en una nueva plataforma.
  3. El sistema pasa el visitor code a los SDKs móvil, del lado del servidor y web. Esto garantiza que todas las plataformas evalúen al mismo usuario de forma consistente.

​
Sincronizar los visitor codes

  • Almacene el visitor code de forma segura en el backend o la base de datos de usuarios y vincúlelo al ID de usuario.
  • Siga estos pasos cuando un usuario inicie sesión en otra plataforma:
    • Aplicación móvil: solicite el visitor code al backend.
    • SDK del lado del servidor: utilice el mismo visitor code para todas las llamadas de variación y tracking.
    • Web SDK: establezca el visitor code utilizando la API de JavaScript:
kameleoon.API.Visitor.setVisitorCode(visitorCode);
El web SDK y el SDK del lado del servidor se comunican automáticamente a través de la cookie kameleoonVisitorCode. No necesita realizar pasos adicionales para vincularlos.

​
Buenas prácticas

  • Asocie el identificador de usuario existente (como userId) a un único visitor code de Kameleoon en todas las plataformas.
  • Mantenga el backend como la fuente de verdad de los visitor codes.
  • Evite que los SDKs sobrescriban los visitor codes existentes para usuarios conocidos.
La identificación unificada garantiza que cada acción del usuario, conversión y decisión de variación se vincule al mismo visitante en Kameleoon.

​
Gestión de experimentos entre entornos

Coordine las decisiones y la visualización de variaciones para los experimentos que abarcan varios entornos, como móvil y backend.

​
Escenario de ejemplo

En este escenario:
  • La aplicación móvil muestra la variación.
  • El servidor backend determina la variación asignada.

​
Opciones de implementación

Opción 1: lógica de decisión en el lado del servidor
  1. La aplicación móvil envía el visitor code al backend.
  2. El SDK del lado del servidor llama a getVariation() (o su equivalente) para recuperar la variación asignada.
  3. El backend devuelve el ID o nombre de la variación a la aplicación móvil.
  4. La aplicación móvil muestra la variación y registra la exposición.
  5. Tanto los SDKs móvil como del servidor utilizan el mismo visitor code para los eventos de tracking.
Ventajas:
  • Centraliza la lógica de variación y garantiza decisiones consistentes.
  • Soporta experimentos que afectan tanto a la lógica del backend como a los elementos de UI.
Opción 2: lógica de decisión en el lado del cliente (móvil)
  1. El SDK móvil recupera la asignación de variación utilizando el visitor code.
  2. La aplicación móvil aplica la variación localmente y registra la exposición directamente.
  3. (Opcional) Si el backend también participa en el tracking o la validación, el SDK del lado del servidor reutiliza el mismo visitor code para garantizar la coherencia de los informes.
Ventajas:
  • Proporciona una decisión síncrona y de latencia cero.
  • Reduce la latencia al evitar un round trip al servidor.
  • Optimiza los experimentos centrados en la UI que no dependen de la lógica del backend.

​
Elegir la configuración adecuada

Caso de usoCapa de decisiónOrigen del visitor codeNotas
Experimento de UI móvilSDK móvilBackendGestiona la variación localmente
Backend o impulsado por APISDK del lado del servidorAplicación o sitio webLógica de decisión centralizada
Coherencia cross-deviceCualquieraBackendGarantiza un tracking unificado

​
Ejemplos de código: pasar el visitor code entre capas

const visitorCode = kameleoon.API.Visitor.code;
fetch("/api/syncVisitor", {
  method: "POST",
  body: JSON.stringify({ visitorCode }),
});
Para gestionar la implementación de SDKs en distintas capas:
  • Asigne un único visitor code por usuario en todas las plataformas.
  • Gestione y distribuya los visitor codes desde el backend.
  • Seleccione la capa de lógica de variación según el tipo de experimento (servidor para la lógica centralizada, lado del cliente para la UI impulsada por la aplicación).
  • Mantenga datos coherentes y cross-device haciendo seguimiento de toda la actividad del usuario con el mismo visitor code.