Jornadas — condições, decisões, esperas e progressão

Depois que uma pessoa entra numa jornada, sua instância percorre as etapas da versão publicada. Algumas etapas escolhem um caminho, outras aguardam um momento ou acontecimento e outras executam uma ação.

O desenho da jornada precisa responder duas perguntas com clareza:

1. por que a instância seguiu este caminho?
2. em qual momento os dados usados nessa decisão foram lidos?

Como uma instância progride

A instância começa no gatilho e segue pelas conexões do fluxo. Etapas simples, como condições, switches e testes A/B, podem ser resolvidas em sequência. Uma ação, uma coleta de dados, um wait ou um goal pode interromper essa sequência enquanto aguarda outro processamento.

Cada avanço fica ligado à instância e à versão em que ela entrou. Se uma nova versão for publicada, a instância continua percorrendo o desenho original.

Três formas de escolher um caminho

Condição, switch e teste A/B criam ramificações, mas resolvem problemas diferentes.

Condição: verdadeiro ou falso

Uma condição combina regras e envia a instância para uma de duas saídas.

Ela pode avaliar, por exemplo:

• traits atuais do perfil;
• identidades associadas à pessoa;
• o último evento de um tipo, com filtros e janela de tempo;
• a resposta de um webhook do próprio cliente.

As regras podem exigir que todas sejam verdadeiras ou que ao menos uma delas seja verdadeira. Grupos permitem representar decisões mais completas sem transformar cada comparação num novo nó.

Exemplo

Uma jornada de recuperação pode perguntar:

A pessoa continua no plano gratuito e realizou uma tentativa de compra nas últimas 24 horas?

Se a resposta for verdadeira, ela segue para uma oferta. Se for falsa, pode seguir para outra abordagem ou terminar.

Uma condição sempre chega a uma resposta binária. Quando o negócio possui três ou mais categorias de saída, um switch costuma representar melhor a intenção.

Switch: vários caminhos a partir de um valor

O switch lê um valor e compara esse resultado com os casos configurados. Cada caso pode aceitar um ou mais valores. Quando nenhum deles combina, a instância segue pelo caminho padrão.

O valor pode vir de um trait, de uma propriedade do último evento ou de uma variável configurada na jornada.

Exemplo por plano

Uma empresa quer personalizar o próximo passo de acordo com o trait plano_atual:

• FREE segue por um caminho de apresentação dos recursos pagos;
• PRO segue por um caminho de orientação sobre recursos avançados;
• ENTERPRISE segue por um caminho de acompanhamento dedicado;
• qualquer outro valor segue pelo caminho padrão.

Também é possível colocar mais de um valor no mesmo caso. FREE e TRIAL, por exemplo, poderiam compartilhar o caminho de apresentação dos recursos pagos.

Use switch quando existe um valor central e os caminhos representam suas categorias. Use condição quando a decisão depende de uma expressão que só precisa responder sim ou não.

Teste A/B: distribuição por percentuais

O teste A/B não avalia se uma regra de negócio é verdadeira. Ele separa as instâncias entre variações de acordo com os percentuais configurados.

Os pesos são livres, desde que completem 100%. Você pode criar:

• dois caminhos com 50% para cada um;
• três caminhos com 50%, 25% e 25%;
• um grupo de 70% que recebe uma ação e outro de 30% que termina sem recebê-la.

O último exemplo cria um grupo de controle. Depois, o time pode comparar o resultado das pessoas que receberam a ação com aquelas que não receberam.

A separação é estável dentro da instância. Reprocessar a mesma etapa não troca aquela instância de grupo. Se a pessoa entrar novamente e ganhar outra instância, ela participa de uma nova distribuição.

Valor atual e contexto de entrada

Condições e switches podem usar variáveis, mas o contrato completo dessas fontes será apresentado no guia de ações e personalização, onde elas são usadas com mais frequência.

Para entender uma decisão, a diferença essencial é:

• Trait e Identidade: leem o estado atual do perfil quando a instância alcança a etapa;
• Contexto: usa o retrato preservado no início da jornada;
• Dados coletados: usam a resposta guardada por uma etapa anterior de coleta.

Valor atual, contexto de entrada e resposta coletada em outro momento podem produzir decisões diferentes. Escolha a fonte de acordo com a pergunta de negócio.

Quando os dados são avaliados

Condições e switches são avaliados quando a instância alcança o nó.

Imagine que uma pessoa entrou às 9h com plano_atual = basic, esperou duas horas e teve o plano alterado para premium às 10h:

• uma variável de Trait encontra premium às 11h;
• uma variável de Contexto ainda encontra basic, o valor preservado na entrada.

O mesmo raciocínio vale para o último evento: a consulta acontece no momento da decisão e pode encontrar um evento recebido depois da entrada.

Valores fixos, funções, defaults, placeholders e todas as formas de usar variáveis serão aprofundados no guia de ações e personalização.

Quando um dado não existe

Uma comparação comum não considera um campo ausente como se ele possuísse outro valor. Se a regra precisa diferenciar ausência, use os operadores de existência disponíveis no editor.

Isso evita uma armadilha como interpretar “não possui plano premium” da mesma forma que “o perfil ainda não possui informação de plano”. São situações de negócio diferentes.

No switch, valor ausente ou sem correspondência segue pelo caminho padrão. Dê a esse caminho um destino consciente; não o trate apenas como uma sobra do desenho.

Tipos de espera

Waits interrompem a progressão até que o tempo ou o acontecimento configurado permita continuar.

Esperar por uma duração

A instância aguarda uma quantidade de minutos, horas ou dias.

Exemplo: esperar duas horas depois de uma compra antes de pedir uma avaliação.

Esperar até uma data e horário

A instância aguarda uma data e horário exatos. O fuso precisa representar a operação desejada.

Exemplo: continuar às 9h do dia de lançamento, independentemente do momento em que cada pessoa entrou.

Esperar por um evento

A instância aguarda um evento específico até o tempo limite.

Essa espera possui duas saídas:

• Evento recebido: o evento chegou dentro do prazo;
• Tempo limite: o prazo terminou antes do evento.

Uma recuperação de carrinho pode esperar sete dias por COMPRA_FINALIZADA@1. Se a compra chegar, a jornada evita uma cobrança desnecessária. Se o prazo terminar, pode seguir para uma última tentativa ou encerrar.

Esperar por uma condição

A instância aguarda até uma expressão se tornar verdadeira. Mudanças em traits e identidades podem provocar uma nova avaliação. O PrismaFlow também reavalia essas esperas periodicamente.

Exemplo: aguardar até que o cadastro esteja completo e o perfil possua a identidade necessária para uma integração.

Essa espera possui tempo limite. Se a condição nunca for satisfeita, a instância expira em vez de permanecer esperando para sempre.

Esperar por entrada ou saída de segmento

A instância aguarda até a pessoa entrar ou sair do segmento selecionado.

Exemplo: depois de uma comunicação, aguardar a entrada no segmento “clientes que concluíram a configuração inicial”.

O tempo limite também protege essa espera. A pessoa continuar no mesmo estado não é uma nova mudança de membership.

Esperar por uma janela operacional

A instância só continua dentro dos dias, horários e fuso configurados. Se já estiver dentro da janela, ela pode seguir imediatamente. Caso contrário, aguarda a próxima abertura.

Exemplo: uma etapa que depende do time comercial pode continuar apenas de segunda a sexta-feira, entre 9h e 18h no fuso da operação.

Modelando waits com segurança

1. Defina o acontecimento exato que libera a instância.
2. Escolha um tempo limite coerente com o caso de negócio.
3. Decida o que acontece quando um evento chega e quando o prazo termina.
4. Confirme nome e versão dos eventos usados.
5. Em segmentos, escolha explicitamente entrada ou saída.
6. Em datas e janelas, revise o fuso.
7. Depois do wait, avalie novamente dados que podem ter mudado durante a espera.

Um exemplo completo

Considere uma jornada iniciada depois que uma pessoa visualiza um produto:

1. espera até 24 horas por uma compra;
2. se a compra chegar, termina sem enviar uma oferta;
3. se o prazo terminar, usa um switch para ler o trait plano_atual;
4. no caminho de FREE e TRIAL, um teste A/B envia uma oferta para 70% das instâncias;
5. os outros 30% terminam como grupo de controle;
6. os demais planos seguem por caminhos próprios;
7. uma condição posterior pode verificar o estado atual do perfil antes de executar outra ação.

Cada etapa responde a uma pergunta diferente. A espera observa o tempo e o evento, o switch escolhe um caminho pelo plano atual, o teste A/B cria o experimento e a condição protege a ação final.

Assuntos relacionados

• Jornadas — ações, variáveis e personalização [blocked]
• Jornadas — fundamentos, autoria, versões e publicação [blocked]
• Jornadas — entradas, gatilhos, audiências e agendamento [blocked]
• Traits e evolução do perfil
• Segmentos — avaliação, membership e operação

Revisão editorial

• Estado: Em revisão
• Fatos confirmados em: engine de progressão, DSL e editor atuais
• Walkthrough: conhecimento operacional fornecido pelo Darlysson na PF-1373 em 15/08/2026
• Lacunas conhecidas: roteamento do tempo limite e reação imediata de waits condicionais a eventos precisam ser conciliados no backend