Condiciones de carrera
Una condición de carrera se produce cuando un resultado depende de la secuencia o la sincronización de varios eventos. Por ejemplo, si la secuencia deseada de eventos es “Evento A” y luego “Evento B”, pero a veces “Evento A” llega primero y otras veces “Evento B” llega primero, eso se conoce como condición de carrera. Esto puede provocar resultados inesperados o errores, porque estos eventos compiten por acceder a recursos o datos compartidos.
En Braze, pueden darse condiciones de carrera cuando se desencadenan varias acciones al mismo tiempo basándose en datos de usuario o eventos. Por ejemplo, si un usuario desencadena varias campañas (como registrarse en un boletín o realizar una compra), puede que no reciba los mensajes en el orden correcto.
Tipos de condiciones de carrera
Los tipos más comunes de condiciones de carrera pueden ocurrir cuando haces lo siguiente:
- Segmentar usuarios nuevos
- Usar múltiples endpoints de API
- Hacer coincidir desencadenantes basados en acciones y filtros de audiencia
- Usar el desencadenante “Interactuar con paso”
Considera los siguientes escenarios e implementa las mejores prácticas para evitar estas condiciones de carrera.
Escenario 1: Segmentación de usuarios nuevos
En Braze, una de las condiciones de carrera más comunes ocurre con los mensajes dirigidos a usuarios recién creados. El orden de eventos esperado es:
- Se crea un usuario;
- Ese mismo usuario es inmediatamente segmentado para un mensaje, realiza un evento personalizado o registra un atributo personalizado.
Sin embargo, en algunos casos, el segundo evento se desencadena primero. Esto significa que se intenta enviar un mensaje a un usuario que aún no existe. Como resultado, el usuario nunca lo recibe. Esto también aplica a los eventos o atributos, donde el evento o atributo intenta registrarse en un perfil de usuario que aún no se ha creado.
En el caso de los mensajes dentro de la aplicación, el mensaje dentro de la aplicación debe cargarse en el dispositivo del usuario antes de ser desencadenado. Si el evento desencadenante es parte del proceso de incorporación, o el usuario sale del Segment para el evento personalizado como parte de su primera sesión, es probable que el usuario no vea el mensaje dentro de la aplicación.
Mensajes dentro de la aplicación
Con los mensajes dentro de la aplicación, la situación puede tener más matices. Un mensaje dentro de la aplicación debe entregarse y almacenarse en caché en el SDK, normalmente al inicio de una sesión, antes de poder ser desencadenado. Si el evento desencadenante es parte del proceso de creación del usuario, o si la Campaign de mensajes dentro de la aplicación se entrega antes de que el usuario cumpla (o después de que ya no cumpla) los criterios de audiencia durante su primera sesión, es posible que no vea el mensaje dentro de la aplicación.
Mejores prácticas
Introducir retrasos
Después de crear un nuevo usuario, puedes agregar un retraso antes de enviar cualquier Campaign o Canvas dirigido. Este retraso de tiempo permite que se cree el perfil de usuario y que se actualicen los atributos relevantes que puedan determinar su elegibilidad para recibir el mensaje.
Por ejemplo, después de que un usuario se registra en tu aplicación, puedes enviar una oferta promocional después de 24 horas. O, si estás creando un usuario o registrando un atributo personalizado, puedes agregar un retraso de un minuto antes de continuar con tu proceso para evitar esta condición de carrera.
También puedes agregar este retraso en el SDK de Braze para el evento personalizado específico que desencadena que un nuevo usuario entre en un Canvas.
Escenario 2: Uso de múltiples endpoints de API
Utilizamos procesamiento asíncrono para maximizar la velocidad y la flexibilidad. Esto significa que cuando las llamadas a la API se nos envían por separado, no podemos garantizar que se procesen en el orden en que fueron enviadas.
Hay algunos escenarios en los que múltiples endpoints de API también pueden dar lugar a esta condición de carrera, como cuando:
- Se usan endpoints de API independientes para crear usuarios y desencadenar Canvas o Campaigns
- Se realizan múltiples llamadas separadas al endpoint
/users/trackpara actualizar atributos personalizados, eventos o compras
Cuando la información de usuario se envía a Braze mediante el endpoint /users/track, ocasionalmente puede tardar unos segundos en procesarse. Esto significa que cuando se realizan solicitudes simultáneamente a los endpoints /users/track y de mensajería como /campaign/trigger/send, no hay garantía de que la información del usuario se actualice antes de que se envíe un mensaje.
Si los atributos y eventos de usuario se envían en la misma solicitud (ya sea desde /users/track o desde el SDK), Braze procesa los atributos antes que los eventos o antes de intentar enviar cualquier mensaje.
Prácticas recomendadas
Cuando uses múltiples endpoints, envía tus solicitudes una a la vez
Si estás utilizando múltiples endpoints, puedes intentar escalonar tus solicitudes para que cada una se complete antes de que comience la siguiente. Esto puede reducir la probabilidad de una condición de carrera. Por ejemplo, si necesitas actualizar atributos de usuario y enviar un mensaje, primero espera a que el perfil de usuario se actualice completamente antes de enviar un mensaje utilizando un endpoint.
Si estás enviando una solicitud de API de mensaje programado, estas solicitudes deben ser independientes, y el usuario debe ser creado antes de enviar la solicitud de API programada.
Incluye datos clave con el desencadenador
En lugar de usar múltiples endpoints, puedes incluir los atributos de usuario y las propiedades del desencadenador en una sola llamada a la API utilizando el endpoint campaign/trigger/send.
Cuando estos objetos se incluyen con el desencadenador, los atributos se procesan primero, antes de que se desencadene el mensaje, lo que elimina posibles condiciones de carrera. Ten en cuenta que las propiedades del desencadenador no actualizan el perfil de usuario, sino que se usan únicamente en el contexto del mensaje.
Usa el endpoint POST: Rastrear usuarios (síncrono)
Usa el endpoint /users/track/sync/ para registrar eventos personalizados y compras, y actualizar atributos de perfil de usuario de forma síncrona. Utilizar este endpoint para actualizar perfiles de usuario al mismo tiempo y en una sola llamada puede ayudar a prevenir posibles condiciones de carrera.
This endpoint se encuentra actualmente en fase beta. Ponte en contacto con tu director de cuentas de Braze si te interesa participar en la beta.
Escenario 3: Coincidencia de desencadenantes basados en acciones y filtros de audiencia
Otra condición de carrera común puede ocurrir si configuras una Campaign o Canvas basados en acciones con el mismo desencadenante que el filtro de audiencia (como un atributo modificado o un evento personalizado realizado). Es posible que el usuario no esté en la audiencia en el momento en que realiza el evento desencadenante, lo que significa que no recibirá la Campaign ni entrará en el Canvas.
Mejores prácticas
Comprueba tu audiencia después de un retraso
Para evitar usar filtros de audiencia que contengan los criterios del desencadenante, recomendamos comprobar tu audiencia antes de la entrega. Por ejemplo, puedes usar validaciones de entrega en los pasos de mensaje de Canvas como una comprobación adicional para confirmar que tu audiencia cumple los criterios de entrega en el momento del envío del mensaje. También puedes aprovechar los criterios de salida de Canvas para que cualquier usuario salga en cualquier momento del recorrido del usuario si cumple tus criterios.
Para Campaigns, puedes usar eventos de salida para permitir que las Campaigns con un evento desencadenante cancelen los mensajes a los usuarios que realicen el evento de salida mientras están en el retraso.
Usa filtros únicos con el evento desencadenante
Al configurar tus filtros, puede que quieras añadir un filtro redundante “por si acaso”. Sin embargo, esta redundancia puede causar más problemas. En su lugar, evita usar cualquier filtro que contenga el desencadenante cuando sea posible. Esta es la ruta más segura para evitar una condición de carrera.
Por ejemplo, si el desencadenante de tu Campaign es “Ha realizado una compra” y tu filtro de audiencia es “Ha realizado alguna compra”, esta redundancia puede causar una condición de carrera.
Evita filtros de audiencia que asuman que el evento desencadenante se ha actualizado
Esta mejor práctica es similar a evitar filtros redundantes con el evento desencadenante. Normalmente, un filtro que asume que el evento desencadenante está actualizado en el perfil de usuario falla.
Usa cancelaciones con Liquid (solo atributos)
En Campaigns y pasos en Canvas, usa cancelaciones con Liquid para evitar usar filtros de audiencia que contengan los atributos desencadenantes en la programación de entrada. Por ejemplo, supongamos que tienes un atributo de array “colores favoritos” y quieres dirigirte a cualquier usuario que actualice el array del atributo con cualquier valor, y que también tenga el color “azul” en el array después de que se haya completado la actualización. Si usas los filtros de audiencia en este ejemplo, encontrarás una condición de carrera y perderás a los usuarios que añadan “azul” en el array por primera vez.
En este caso, puedes implementar un retraso del desencadenante en una Campaign o usar un paso de retraso en Canvas para permitir que el perfil de usuario se actualice durante un período de tiempo, y luego usar la siguiente lógica de cancelación con Liquid:
{%assign colors={{custom_attribute.$(Favorite Color)|split:”,”}}%}
{%unless colors contains ‘Blue’%}
{%abort_message(Blue not present)%}
{%endunless%}
Confirma cómo se gestionan los datos de usuario
Si hay una condición de carrera durante la evaluación de entrada del Canvas, los usuarios pueden entrar en un Canvas en el que no debían entrar. Por ejemplo, el perfil del usuario podría estar configurado para ser incluido en la audiencia y, posteriormente, actualizarse después de que el Canvas haya puesto en cola a los usuarios para que ya no sean elegibles en la audiencia.
Si un usuario desencadena el evento de entrada del Canvas varias veces dentro del mismo segundo, Braze solo permite una entrada para ese segundo (incluso si la reentrada está habilitada). Esto evita entradas duplicadas, por lo que el número total de entradas al Canvas puede ser menor que el total de eventos desencadenantes.
Recomendamos confirmar cómo se gestionan y actualizan los datos de usuario, específicamente cuándo y cómo se actualizan atributos específicos, por ejemplo, mediante SDK, API, API por lotes y otros métodos. Esto puede ayudar a identificar y aclarar por qué un usuario ha entrado en una Campaign o Canvas en comparación con cuándo se actualizó el perfil de un usuario.
Escenario 4: Uso del desencadenante “Interactuar con paso”
En un Canvas, cuando un paso de mensaje va seguido inmediatamente de un paso de Rutas de Acción que utiliza el desencadenante “Interactuar con paso”, puede producirse una condición de carrera. Dado que los usuarios pueden interactuar con un mensaje en cuanto se entrega, es posible que un usuario complete la acción rastreada antes de entrar oficialmente en el paso de Rutas de Acción.
En este caso, el paso de Rutas de Acción no registra la interacción, ya que solo evalúa los eventos que ocurren después de la entrada en el paso, lo que significa que el usuario puede ser dirigido por una ruta no deseada.
Un Canvas envía una notificación push en un paso de mensaje, seguido de un paso de Rutas de Acción que comprueba si el usuario abre esa notificación push. Si un usuario abre la notificación push inmediatamente después de recibirla (antes de entrar en el paso de Rutas de Acción), el evento de apertura puede no ser capturado. El usuario podría entonces ser dirigido incorrectamente por la ruta “no abrió”, aunque sí interactuó con el mensaje.
Buenas prácticas
Rastrea la participación mediante un evento personalizado
Evita depender de “Interactuar con paso” inmediatamente después de un paso de mensaje cuando se espera que las interacciones de los usuarios ocurran rápidamente. En su lugar, rastrea la participación mediante un evento personalizado (por ejemplo, desencadenado desde la aplicación o el sitio web después de la interacción) y evalúa ese evento en un paso posterior. Esto asegura que el evento se registre después de que el usuario haya entrado en el paso.
Evita ramas que dependan de la interacción
Diseña tu Canvas de modo que la ausencia de una interacción inmediata no afecte la experiencia del usuario. Por ejemplo, evita decisiones de ramificación críticas que dependan únicamente de si la interacción se captura en el siguiente paso, o añade lógica de seguimiento que pueda corregir las rutas de los usuarios.