Condições de corrida

Uma condição de corrida ocorre quando um resultado depende da sequência ou do momento de vários eventos. Por exemplo, se a sequência desejada de eventos é “Evento A” e depois “Evento B”, mas às vezes “Evento A” vem primeiro e outras vezes “Evento B” vem primeiro — isso é uma condição de corrida. Isso pode levar a resultados inesperados ou erros, porque esses eventos competem para acessar recursos ou dados compartilhados.

Na Braze, condições de corrida podem ocorrer quando várias ações são disparadas ao mesmo tempo com base em dados ou eventos de usuários. Por exemplo, se um usuário dispara várias campanhas (como assinar uma newsletter ou fazer uma compra), ele pode não receber as mensagens na ordem correta.

Tipos de condições de corrida

Os tipos mais comuns de condições de corrida podem ocorrer quando você está fazendo o seguinte:

• Direcionando novos usuários
• Usando múltiplos endpoints de API
• Combinando gatilhos baseados em ação e filtros de público

Considere os cenários a seguir e implemente as práticas recomendadas para evitar essas condições de corrida.

Cenário 1: Direcionando novos usuários

Na Braze, uma das condições de corrida mais comuns ocorre com mensagens direcionadas a usuários recém-criados. A ordem esperada dos eventos é:

1. Um usuário é criado;
2. O mesmo usuário é imediatamente direcionado para uma mensagem, realiza um evento personalizado ou registra um atributo personalizado.

No entanto, em alguns casos, o segundo evento é disparado primeiro. Isso significa que uma mensagem tenta ser enviada a um usuário que ainda não existe. Como resultado, o usuário nunca a recebe. Isso também se aplica a eventos ou atributos, em que o evento ou atributo tenta ser registrado em um perfil de usuário que ainda não foi criado.

No caso de mensagens no app, a mensagem no app precisa ser carregada no dispositivo do usuário antes de ser disparada. Se o evento de gatilho faz parte do processo de integração, ou se o usuário sai do segmento para o evento personalizado como parte de sua primeira sessão, é provável que o usuário não veja a mensagem no app.

Mensagens no app

Com mensagens no app, a situação pode ser mais complexa. Uma mensagem no app precisa ser entregue e armazenada em cache no SDK — normalmente no início de uma sessão — antes de poder ser disparada. Se o evento de gatilho faz parte do processo de criação do usuário, ou se a campanha de mensagem no app é entregue antes de o usuário atender (ou depois de não mais atender) aos critérios de público durante sua primeira sessão, ele pode não ver a mensagem no app.

Práticas recomendadas

Introduza postergações

Depois que um novo usuário é criado, você pode adicionar uma postergação antes de enviar qualquer campanha ou Canvas direcionado. Essa postergação permite que o perfil do usuário seja criado e que quaisquer atributos relevantes sejam atualizados, o que pode determinar sua elegibilidade para receber a mensagem.

Por exemplo, depois que um usuário se registra no seu app, você pode enviar uma oferta promocional após 24 horas. Ou, se você está criando um usuário ou registrando um atributo personalizado, pode adicionar uma postergação de um minuto antes de prosseguir no seu processo para evitar essa condição de corrida.

Você também pode adicionar essa postergação no SDK da Braze para o evento personalizado específico que faz um novo usuário entrar em um Canvas.

Cenário 2: Usando múltiplos endpoints de API

Existem alguns cenários em que múltiplos endpoints de API também podem resultar nessa condição de corrida, como quando:

• Endpoints de API separados são usados para criar usuários e disparar Canvas ou campanhas
• Múltiplas chamadas separadas são feitas ao endpoint /users/track para atualizar atributos personalizados, eventos ou compras

Quando informações de usuários são enviadas à Braze usando o endpoint /users/track, pode levar alguns segundos para o processamento. Isso significa que, quando solicitações são feitas simultaneamente aos endpoints /users/track e de envio de mensagens como /campaign/trigger/send, não há garantia de que as informações do usuário sejam atualizadas antes de uma mensagem ser enviada.

Práticas recomendadas

Ao usar múltiplos endpoints, envie suas solicitações uma de cada vez

Se você está usando múltiplos endpoints, pode tentar escalonar suas solicitações para que cada uma seja concluída antes de a próxima começar. Isso pode reduzir a chance de uma condição de corrida. Por exemplo, se você precisa atualizar atributos de usuário e enviar uma mensagem, primeiro aguarde a atualização completa do perfil do usuário antes de enviar uma mensagem usando um endpoint.

Se você está enviando uma solicitação de API de mensagem agendada, essas solicitações devem ser separadas, e o usuário deve ser criado antes de enviar a solicitação de API agendada.

Inclua dados essenciais junto com o gatilho

Em vez de usar múltiplos endpoints, você pode incluir os atributos de usuário e as propriedades de gatilho em uma única chamada de API usando o endpoint campaign/trigger/send.

Quando esses objetos são incluídos com o gatilho, os atributos são processados primeiro, antes de a mensagem ser disparada, eliminando possíveis condições de corrida. As propriedades de gatilho não atualizam o perfil do usuário, mas são usadas apenas no contexto da mensagem.

Use o endpoint POST: Rastrear usuários (síncrono)

Use o endpoint /users/track/sync/ para registrar eventos personalizados e compras e atualizar atributos do perfil de usuário de forma síncrona. Usar esse endpoint para atualizar perfis de usuários ao mesmo tempo e em uma única chamada pode ajudar a evitar possíveis condições de corrida.

Cenário 3: Combinando gatilhos baseados em ação e filtros de público

Outra condição de corrida comum pode ocorrer se você configurar uma campanha ou Canvas baseado em ação com o mesmo gatilho do filtro de público (como um atributo alterado ou um evento personalizado realizado). O usuário pode não estar no público no momento em que realiza o evento de gatilho, o que significa que ele não receberá a campanha nem entrará no Canvas.

Práticas recomendadas

Verifique seu público após uma postergação

Para evitar o uso de filtros de público que contenham os critérios de gatilho, recomendamos verificar seu público antes da entrega. Por exemplo, você pode usar validações de entrega nas etapas de Mensagem do Canvas como uma verificação adicional para confirmar que seu público atende aos critérios de entrega no momento do envio da mensagem. Você também pode aproveitar os critérios de saída do Canvas para remover qualquer usuário em qualquer ponto da jornada se ele atender aos seus critérios.

Para campanhas, você pode usar eventos de saída para permitir que campanhas com um evento de gatilho cancelem mensagens para usuários que realizem o evento de saída enquanto estiverem na postergação.

Use filtros exclusivos com o evento de gatilho

Ao configurar seus filtros, você pode querer adicionar um filtro redundante “por precaução”. No entanto, essa redundância pode causar mais problemas. Em vez disso, evite usar qualquer filtro que contenha o gatilho quando possível. Essa é a rota mais segura para evitar uma condição de corrida.

Por exemplo, se o gatilho da sua campanha é “Fez uma compra” e seu filtro de público é “Fez qualquer compra”, essa redundância pode causar uma condição de corrida.

Evite filtros de público que assumam que o evento de gatilho foi atualizado

Essa prática recomendada é semelhante a evitar filtros redundantes com o evento de gatilho. Normalmente, um filtro que assume que o evento de gatilho foi atualizado no perfil do usuário falha.

Use aborts de Liquid (somente atributos)

Em campanhas e etapas do Canvas, use aborts de Liquid para evitar o uso de filtros de público que contenham os atributos de gatilho no cronograma de entrada. Por exemplo, digamos que você tenha um atributo de array “cores favoritas” e queira direcionar qualquer usuário que atualize o array de atributos com qualquer valor e que também tenha a cor “azul” no array após a conclusão da atualização. Se você usar os filtros de público neste exemplo, encontrará uma condição de corrida e perderá usuários que estão adicionando “azul” no array pela primeira vez.

Nesse caso, você pode implementar uma postergação de gatilho em uma campanha ou usar uma etapa de postergação no Canvas para permitir que o perfil do usuário seja atualizado por um período de tempo, e então usar a seguinte lógica de abort de Liquid:

1
2
3
4
{%assign colors={{custom_attribute.$(Favorite Color)|split:”,”}}%}
{%unless colors contains ‘Blue’%}
{%abort_message(Blue not present)%}
{%endunless%}

Confirme como os dados de usuários estão sendo gerenciados

Se houver uma condição de corrida durante a avaliação de entrada do Canvas, os usuários podem entrar em um Canvas no qual não deveriam entrar. Por exemplo, o perfil do usuário pode estar configurado para ser incluído no público e, em seguida, ser atualizado após o Canvas ter enfileirado os usuários para não serem mais elegíveis no público.

Se um usuário dispara o evento de entrada do Canvas várias vezes dentro do mesmo segundo, a Braze permite apenas uma entrada para aquele segundo (mesmo que a reentrada esteja ativada). Isso evita entradas duplicadas, então o número total de entradas no Canvas pode ser menor do que o total de eventos de gatilho.

Recomendamos confirmar como os dados de usuários são gerenciados e atualizados, especificamente quando e como atributos específicos são atualizados, como por SDK, API, API em lote e outros métodos. Isso pode ajudar a identificar e esclarecer por que um usuário entrou em uma campanha ou Canvas em comparação com quando o perfil do usuário foi atualizado.