Experimentación entre dispositivos

El recorrido de un cliente rara vez se limita a un único dispositivo. Desde smartphones a tablets, pasando por ordenadores de escritorio, los usuarios cambian regularmente de dispositivo. La experimentación entre dispositivos aborda este reto. Aunque cerrar la brecha entre dispositivos es un reto matizado y ninguna solución es perfecta, las herramientas adecuadas —como IDs de usuario fiables y prácticas de datos meditadas— permiten obtener información sobre la experiencia de los visitantes en todos los puntos de contacto.

​

Qué puede hacer la experimentación entre dispositivos de Kameleoon​

• Garantizar la coherencia de la variación: los usuarios autenticados siempre verán la misma variación en un experimento, independientemente del dispositivo que utilicen.
• Habilitar segmentación unificada: considerar todas las visitas y acciones de un mismo usuario, independientemente del dispositivo.
• Proporcionar reporting preciso: contar con exactitud los usuarios únicos entre dispositivos para comprender mejor su comportamiento.

​

Puntos críticos e información práctica​

• El tracking entre dispositivos depende en gran medida de la identificación de los usuarios. Si un usuario permanece anónimo entre dispositivos, fusionar sus datos es imposible. Ningún sistema puede sortear esta limitación.
• Un ID de usuario fiable (como el vinculado a un login) es esencial para vincular datos entre dispositivos. Sin un ID fiable, no es posible fusionar historiales de navegación o acciones.
• Las acciones realizadas en estado anónimo (por ejemplo, navegar sin iniciar sesión) no pueden vincularse a un usuario identificado hasta que se produzca un login. Una vez que el usuario inicia sesión, su historial se fusiona, pero solo hacia adelante.
  • No obstante, tenga en cuenta que para Web Experimentation, una vez que se proporcionan los datos personalizados, Kameleoon puede recuperarlos para todas las visitas posteriores en el mismo dispositivo, incluso si el usuario aún no ha iniciado sesión. Esta recuperación ocurre porque los datos se almacenan en local storage, lo cual no ocurre en feature experimentation.
• Aunque la experimentación entre dispositivos funciona para muchos casos de uso, no encajará en todos los experimentos. La experimentación entre dispositivos depende de su stack tecnológico, los recorridos de cliente y los objetivos.

​

Comprender los límites de identidad​

En el contexto de la experimentación entre dispositivos, los límites de identidad se refieren a cómo Kameleoon reconoce y gestiona a los usuarios en diferentes sesiones, dispositivos y estados de identificación. Estos límites son cruciales para determinar si Kameleoon puede vincular los datos del usuario entre experiencias. Kameleoon distingue principalmente entre dos tipos de identidad de usuario:

• Usuarios anónimos: se trata de usuarios que no han iniciado sesión y que se identifican mediante un identificador temporal basado en el dispositivo (visitorCode). Los identificadores anónimos son únicos para el dispositivo y el navegador y no persisten entre dispositivos.
• Usuarios identificados: se trata de usuarios que inician sesión, proporcionando identificadores únicos y coherentes (como un user ID). Este identificador está vinculado al usuario individual, lo que permite a Kameleoon fusionar sus acciones e historial entre dispositivos y sesiones.

​

Activar la reconciliación de historial entre dispositivos​

Para usar la reconciliación de historial entre dispositivos, cree una nueva entrada de datos personalizados en Kameleoon y active la opción Use this custom data as a unique identifier for cross-device matching. Cuando esté activada, Kameleoon tratará estos datos personalizados como un identificador único para los visitantes, lo que asocia varias visitas de Kameleoon a un único usuario. También debe establecer el valor del dato personalizado con un identificador único, como un user ID, utilizando alguno de los métodos de adquisición, como el método addData() del SDK o la Activation API.

​

Reconciliación de historial entre dispositivos para la coherencia en la asignación de variaciones​

El objetivo de la reconciliación de historial entre dispositivos para la asignación de variaciones es garantizar que los visitantes asignados a un experimento vean de forma consistente la misma variación, independientemente del dispositivo que utilicen para acceder al sitio web. No obstante, es importante reconocer que mantener esta coherencia puede ser un reto en ciertos escenarios. Por ejemplo, si un usuario visita el sitio web en su dispositivo inicial, inicia sesión y dispara un experimento, Kameleoon puede asignarle la variación V1. Si después el mismo usuario visita el sitio web en otro dispositivo y dispara el mismo experimento antes de iniciar sesión, el sistema podría asignarle la variación V2. Esta inconsistencia se produce porque el sistema aún no ha reconocido al usuario entre dispositivos. Kameleoon, intencionadamente, no sobrescribe la asignación de variación durante una única visita para no interrumpir la experiencia del usuario. Para mitigar este problema y garantizar la coherencia, identifique a los visitantes con la mayor brevedad posible a lo largo de su recorrido en el sitio web. Identificar a los visitantes pronto cuando acceden al sitio web desde diferentes dispositivos garantiza que se les asigne de forma consistente la misma variación. Este enfoque permite a Kameleoon proporcionar una experiencia de testing fluida y coherente.

​

Kameleoon Web Experimentation​

La solución Kameleoon Web Experimentation utiliza principalmente mecanismos de almacenamiento en el cliente para gestionar la asignación de variaciones (bucketing). La asignación de variación de los usuarios se almacena inicialmente en local storage cuando participan en un experimento. Este almacenamiento garantiza que un usuario vea de forma coherente la misma variación en el mismo dispositivo, incluso si el cliente actualiza la asignación de tráfico del experimento. Si el mismo usuario inicia sesión en un dispositivo distinto, Kameleoon recupera del backend la información de la variación previamente asignada. Si el mismo experimento se dispara después de este paso, Kameleoon asigna al usuario la misma variación. Esta sincronización garantiza que una variación se aplica de forma coherente entre dispositivos sin reasignar una nueva variación mediante bucketing.

​

Experimentación entre dispositivos para feature experimentation​

La feature experimentation ocurre en entornos donde los datos se almacenan en memoria durante la duración de una sesión (por defecto, 30 minutos), lo que la convierte en un almacenamiento poco fiable para la asignación de variación con caducidad. Los SDKs resuelven dinámicamente las variaciones en tiempo de ejecución, lo que introduce complejidades únicas para la coherencia entre dispositivos.

​

Rol de los SDKs​

Los SDKs son esenciales para la feature experimentation, ya que:

• Resuelven dinámicamente las asignaciones de variación en función de la identidad del usuario (visitorCode, generado aleatoriamente por el SDK, o su propio user ID) cuando se produce la segmentación.
• Utilizan la resolución de identidad para recuperar datos previamente recopilados en diferentes dispositivos, garantizando una asignación de variación coherente cuando el usuario cambia de dispositivo.

​

Retos y consideraciones​

• Sin local storage: a diferencia de Kameleoon Web Experimentation, las variaciones no se almacenan de forma persistente; se recalculan en tiempo de ejecución según la identidad del usuario.
• Sesiones anónimas: garantizar la coherencia cuando los usuarios comienzan como anónimos y luego inician sesión puede ser complejo.
• Resolución de identidad entre dispositivos: atribuir con precisión las variaciones del experimento entre dispositivos depende de una resolución de identidad robusta.

​

Ejemplos de casos de uso​

Los siguientes casos de uso representan los escenarios más comunes al implementar la experimentación entre dispositivos. Estos ejemplos destacan retos y soluciones típicos para garantizar experiencias de usuario coherentes y una atribución de variación precisa en varios dispositivos.

​

Caso de uso 1 (mismo dispositivo)​

En la primera sesión, un usuario anónimo es segmentado por un experimento y luego inicia sesión. En la segunda sesión, el visitante está autenticado y es segmentado por el mismo experimento.

• Web experimentation: la variación se mantiene coherente con la variación asignada durante la sesión inicial porque Kameleoon recupera la variación previamente asignada de local storage.
• Feature experimentation: si ha asociado el ID de visitante anónimo al user ID utilizando datos personalizados, se devolverá la misma variación cuando se llame a getVariation() con el ID anónimo o el user ID. Sin embargo, se asignará una nueva variación si se llama a getVariation() cuando se utilice el user ID en el método y no exista un mapeo entre el user ID y el ID anónimo.

​

Caso de uso 2 (mismo dispositivo)​

Un usuario inicia sesión y es segmentado por un experimento durante una sesión. En una sesión posterior, el usuario cierra sesión, queda anónimo y es segmentado por el mismo experimento.

• Web experimentation: la variación se mantiene coherente con la variación asignada durante la sesión inicial porque Kameleoon recupera la variación previamente asignada de local storage, garantizando la continuidad entre sesiones.
• Feature experimentation:
  • Si, durante la sesión 1, el usuario pasó de un estado anónimo (anonymous1) a un estado identificado (userId) y el ID anónimo se mapeó al user ID, en la sesión 2 Kameleoon reutilizará anonymous1 para asignar al usuario la misma variación.
  • No obstante, si no se gestionó ningún estado anónimo en la sesión 1 (llamando al método getVisitorCode()), se generará un nuevo visitorCode (anonymous2) para la sesión 2, dando lugar a una nueva asignación de variación.

​

Caso de uso 3 (diferentes dispositivos)​

Un usuario anónimo inicia sesión en un dispositivo y es segmentado por un experimento durante la misma sesión. En una sesión posterior en un dispositivo distinto, el usuario comienza de forma anónima, es segmentado por el mismo experimento e inicia sesión.

• Web experimentation: en este escenario, el usuario puede recibir dos variaciones diferentes porque Kameleoon no reconoce al usuario en el segundo dispositivo al tomar una decisión de segmentación. La asignación de variación en el segundo dispositivo se produce antes de que el usuario inicie sesión, dando lugar a una falta de sincronización entre dispositivos.
• Feature experimentation: al igual que en web experimentation, el usuario puede recibir dos variaciones diferentes porque Kameleoon no reconoce al usuario en el segundo dispositivo al tomar una decisión de segmentación. En este caso, la asignación de variación en el segundo dispositivo ocurre antes de que el usuario inicie sesión, lo que significa que no hay sincronización entre dispositivos.

​

Caso de uso 4 (diferentes dispositivos)​

Un usuario anónimo inicia sesión en el primer dispositivo y es segmentado por un experimento. Más tarde, en un segundo dispositivo, el usuario inicia sesión antes de ser segmentado por el mismo experimento.

• Web experimentation: la variación se mantiene coherente entre dispositivos. Como el usuario inicia sesión antes de que se reevalúe el experimento, el sistema alinea la variación con la asignada en el primer dispositivo.
• Feature experimentation: Kameleoon determina la asignación de variación basándose en el mapeo del user ID al ID anónimo más reciente generado para el visitante.
  • En Dispositivo 1, un visitante anónimo (anonymous1) se evalúa para el experimento y recibe una variación (var1). Al iniciar sesión, Kameleoon crea un mapeo entre userId y anonymous1.
  • En Dispositivo 2, si la sesión comienza directamente con el userId (sin llamada a getVisitorCode() que genere un ID anónimo), llamar a getRemoteVisitorData(userId) permite a Kameleoon recuperar el mapeo del visitante anónimo más reciente (anonymous1). En consecuencia, al llamar a getRemoteVisitorData() y getVariation() para el experimento, el usuario recibirá la variación (var1) asignada a anonymous1. No obstante, si la sesión comienza en estado anónimo, podría asignarse una nueva variación, ya que el bucketing utilizará la clave de bucketing recién generada.

​

Caso de uso 5 (diferentes dispositivos)​

Un usuario anónimo es segmentado por un experimento en un dispositivo e inicia sesión. En un segundo dispositivo, el usuario inicia sesión y es segmentado por el mismo experimento.

• Web experimentation: la variación se mantiene coherente entre dispositivos. Una vez que el usuario inicia sesión, el sistema puede atribuir la misma variación al usuario.
• Feature experimentation: la variación se mantiene coherente solo si se llama a getRemoteVisitorData(). Sin esta llamada, el sistema puede no asociar las dos sesiones, lo que podría dar lugar a una atribución de variación diferente entre dispositivos.

​

Reconciliación de historial entre dispositivos para la segmentación​

Kameleoon descarga automáticamente una lista de visitas de otros dispositivos y almacena esta información en el almacenamiento del dispositivo actual cuando se inicia una nueva sesión y se establece el dato personalizado con un valor. No obstante, si el dato personalizado está vacío, no se realizará la reconciliación al inicio de la sesión. La reconciliación se dispara solo cuando se pasa el dato personalizado y la segmentación se reevalúa para todos los experimentos y personalizaciones activos. Esto ocurre normalmente cuando un usuario inicia sesión en su sitio y proporciona su user ID, correo electrónico u otro identificador único. Es importante señalar que, una vez proporcionado el dato personalizado, Kameleoon puede recuperarlo para todas las visitas posteriores en el mismo dispositivo, incluso si el usuario aún no ha iniciado sesión. La reconciliación se produce al comienzo de cada visita posterior, garantizando capacidades coherentes de tracking y segmentación.

​

Datos afectados por la reconciliación de historial entre dispositivos​

La funcionalidad de reconciliación de historial añade la lista de todas las visitas anteriores que aún no se conocen en el dispositivo actual. Esto incluye información típica como

• Número de visitas y páginas vistas
• Duración de la sesión
• Canales de adquisición y referrers
• Datos personalizados (nota: los datos personalizados proporcionados en otras sesiones con ámbito de visitante se fusionarán en la sesión actual).

Puede utilizar los segmentos de segmentación como de costumbre y funcionarán como se espera. Por ejemplo, una condición de segmentación basada en el número de visitas anteriores considerará con precisión todas las visitas, al igual que una condición basada en la duración de la visita anterior.

​

Reconciliación de historial entre dispositivos para analítica​

La reconciliación de historial afecta solo a la vista de visitor en el reporting de Kameleoon; la vista de visit no se ve afectada. En el modelo de visitor, en lugar de agrupar varias sesiones en un único registro de visitante utilizando el valor estándar del visitorCode de Kameleoon (lo cual solo es posible para visitantes que regresan en el mismo dispositivo), el sistema las fusiona en función del valor del dato personalizado. Si el dato personalizado está vacío o no se proporciona, se utiliza en su lugar el valor del visitorCode. Este enfoque garantiza que las métricas de visitante único sigan siendo precisas, incluso si el usuario aún no está identificado en el sistema del cliente (aunque esta lógica se aplica únicamente a los visitantes que regresan en el mismo dispositivo). Como resultado, la vista de visitor muestra correctamente las métricas en todos los dispositivos para los usuarios identificados. Por ejemplo, un único cliente con tres sesiones en dos dispositivos distintos se contabiliza como un único visitor. Sin la reconciliación de historial, el mismo cliente se contabiliza como dos visitantes distintos (uno por dispositivo).

​

Usar datos personalizados para la fusión de sesiones​

Utilizar datos personalizados como identificador único para la fusión de sesiones solo es posible para las sesiones guardadas después de que Kameleoon haya identificado qué dato personalizado usar. Por lo tanto, Kameleoon recomienda encarecidamente seleccionar el dato personalizado durante la instalación y configuración iniciales para evitar cambiarlo más tarde. Por ejemplo, si Kameleoon se ejecuta durante un mes sin habilitar la reconciliación de historial entre dispositivos y luego se activa en el segundo mes, un único usuario que haya visitado dos veces (una en cada mes) se contabiliza como dos visitantes distintos. Esta discrepancia se produce porque la fusión de sesiones en el primer mes usa el visitorCode como clave, mientras que en el segundo mes usa el dato personalizado con un valor distinto, incluso si el usuario inició sesión en ambas visitas usando el mismo dispositivo. Cualquier modificación de la configuración del dato personalizado responsable de la reconciliación de historial afectará temporalmente a la precisión de las métricas basadas en el visitor, a medida que la mayoría de los visitantes inicien sesión, dependiendo de la frecuencia con la que regresen al sitio y se autentiquen.