Condições de corrida

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

Na Braze, as condições de corrida podem ocorrer quando várias ações são disparadas ao mesmo tempo com base em dados de usuários ou eventos. Por exemplo, se um usuário disparar várias campanhas (como inscrever-se em um boletim informativo ou fazer uma compra), ele poderá 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 filtros de público e disparos baseados em ação
• Usando o disparo “Interact with Step”

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

Cenário 1: Direcionamento para 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-gatilho faz parte do processo de integração ou se o usuário sai do Segment para o evento personalizado durante 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-gatilho faz parte do processo de criação do usuário, ou se a Campaign 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

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

Por exemplo, após um usuário se registrar no seu app, você pode enviar uma oferta promocional após 24 horas. Ou, se estiver criando um usuário ou registrando um atributo personalizado, você pode adicionar uma postergação de um minuto antes de prosseguir no 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 dispara a entrada de um novo usuário em um Canvas.

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

Importante

Usamos processamento assíncrono para maximizar velocidade e flexibilidade. Isso significa que, quando chamadas de API são enviadas separadamente, não podemos garantir que elas serão processadas na ordem em que foram enviadas.

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 Campaigns
• 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 ocasionalmente levar alguns segundos para processar. Isso significa que, quando requisições são feitas simultaneamente para o /users/track e endpoints de envio de mensagens como /campaign/trigger/send, não há garantia de que as informações do usuário serão atualizadas antes de uma mensagem ser enviada.

Nota

Se atributos de usuário e eventos forem enviados na mesma requisição (seja pelo /users/track ou pelo SDK), a Braze processa os atributos antes dos eventos ou de tentar enviar qualquer mensagem.

Melhores práticas

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

Se você está usando múltiplos endpoints, pode tentar escalonar suas requisições para que cada uma seja concluída antes da 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 espere o perfil de usuário ser completamente atualizado antes de enviar uma mensagem usando um endpoint.

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

Inclua dados-chave com o disparo

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

Quando esses objetos são incluídos com o disparo, os atributos são processados primeiro, antes da mensagem ser disparada, eliminando potenciais condições de corrida. Observe que as propriedades de disparo não atualizam o perfil de 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 de perfil de usuário de forma síncrona. Usar esse endpoint para atualizar perfis de usuário ao mesmo tempo e em uma única chamada pode ajudar a prevenir potenciais condições de corrida.

Importante

This endpoint está atualmente em beta. Fale com o seu Braze account manager se tiver interesse em participar da versão beta.

Cenário 3: Correspondência de disparos 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 disparo do filtro de público (como uma alteração de atributo ou execução de um evento personalizado). O usuário pode não estar no público no momento em que realiza o evento-gatilho, o que significa que 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 do disparo, 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 alavancar critérios de saída do Canvas para retirar qualquer usuário em qualquer ponto da jornada do usuário, caso ele atenda aos seus critérios.

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

Use filtros exclusivos com o evento-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 disparo quando possível. Essa é a rota mais segura para evitar uma condição de corrida.

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

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

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

Use interrupções Liquid (somente atributos)

Em Campaigns e etapas do Canvas, use interrupções Liquid para evitar o uso de filtros de público que contenham os atributos do disparo 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 do atributo com qualquer valor, e que também tenha a cor “azul” no array após a atualização ser concluída. 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 do disparo em uma campanha ou usar uma etapa de postergação no Canvas para permitir que o perfil de usuário seja atualizado por um período de tempo, e então usar a seguinte lógica de interrupção 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 ter entrado. 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 que não sejam 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-gatilho.

Recomendamos confirmar como os dados de usuários são gerenciados e atualizados, especificamente quando e como atributos específicos são atualizados, por exemplo, via 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.

Cenário 4: Usando o disparador “Interagir com etapa”

Em um Canvas, quando uma etapa de Mensagem é imediatamente seguida por uma etapa de jornadas de ação que usa o disparador “Interagir com etapa”, uma condição de corrida pode ocorrer. Como os usuários podem interagir com uma mensagem assim que ela é entregue, é possível que um usuário conclua a ação rastreada antes de entrar oficialmente na etapa de jornadas de ação.

Nesse caso, a etapa de jornadas de ação não registra a interação, pois ela só avalia eventos que ocorrem após a entrada na etapa, o que significa que o usuário pode ser direcionado por uma jornada não intencional.

Um Canvas envia uma notificação por push em uma etapa de Mensagem, seguida por uma etapa de jornadas de ação que verifica se o usuário abriu essa notificação por push. Se o usuário abrir a notificação por push imediatamente ao recebê-la (antes de entrar na etapa de jornadas de ação), o evento de abertura pode não ser capturado. O usuário poderia então ser incorretamente direcionado pela jornada “não abriu”, mesmo tendo interagido com a mensagem.

Práticas recomendadas

Rastrear engajamento usando um evento personalizado

Evite depender de “Interagir com etapa” imediatamente após uma etapa de Mensagem quando as interações dos usuários devem ocorrer rapidamente. Em vez disso, rastreie o engajamento usando um evento personalizado (por exemplo, disparado a partir do app ou website após a interação) e avalie esse evento em uma etapa posterior. Isso garante que o evento seja registrado após o usuário ter entrado na etapa.

Evitar ramificações que dependem de interação

Projete seu Canvas de modo que a falta de uma interação imediata não comprometa a experiência do usuário. Por exemplo, evite decisões críticas de ramificação que dependam exclusivamente de a interação ser capturada na próxima etapa, ou adicione uma lógica de acompanhamento que possa corrigir as jornadas dos usuários.