Campanhas Push Acionadas: Guia de Fluxos de Trabalho Contextuais

It is the second week of the quarter and your retention dashboard shows six “automated” triggers running, all green. The cart-abandonment trigger keeps firing at subscribers who already paid. The win-back overlaps with the price-drop alert for the same lapsed customer. The welcome series ships notifications independently of the first-purchase nudge. The post-purchase review request lands on subscribers who returned the order yesterday.

Each of the six triggered push campaigns is a pipeline pointing at the same subscriber list, each pretending the other five do not exist. The repeat-purchase rate stopped moving twelve months ago and nobody on the team can attribute revenue per trigger because the triggers do not share state.

This is the operational reality in most mid-market retention stacks. The problem is not strategy. The strategy is fine. The problem is architecture. A triggered notification in 2024 was a single message that fired on a single event. In 2026, that primitive is not enough. The journey has to remember what the subscriber did, branch on it, and exit when they convert.

This article makes the architectural case. It defines the boundary between broadcast, triggered, and contextual push notifications, walks through the difference between event triggers and audience triggers, names the six node types that turn a single trigger into a contextual workflow, and ships three migration patterns that consolidate six standalone triggers into three contextual journeys with shared exit criteria and per-workflow analytics.

Contextual, triggered, broadcast: three primitives, not one

Three primitives sit underneath every push notification program. Most teams collapse them into one bucket called “campaigns,” which is where the architecture problem starts.

Broadcast. The same notification goes to the entire matching audience, scheduled. Flash sale at noon. New collection alert on launch day. Broadcast is the right primitive for time-bounded announcements where every recipient gets the same payload. It is the wrong primitive for anything that depends on subscriber state.

Triggered. A single notification fires when a single event fires. Subscriber abandons a cart, the cart-abandonment notification fires. Subscriber views a product page, the browse notification fires. Subscriber purchases, the post-purchase notification fires. The trigger has no memory. It does not know what happened five minutes ago or what is scheduled for next Tuesday. Each trigger is a pipeline ignorant of every other trigger.

Contextual. Um fluxo de trabalho utiliza o gatilho como ponto de entrada e, em seguida, adapta-se ao estado do assinante. O mesmo evento de abandono de carrinho inicia uma jornada de várias etapas: uma espera de uma hora, um primeiro lembrete, uma espera de 24 horas, uma decisão que verifica se o carrinho ainda está aberto, um segundo lembrete com um desconto, uma espera de 48 horas, um terceiro lembrete e uma regra de saída que cancela o fluxo de trabalho no momento em que o assinante compra. A campanha é o fluxo de trabalho, não o gatilho. As notificações push contextuais são como a mensagem acionada se comporta assim que a arquitetura se atualiza.

Os três primitivos mapeiam-se claramente para três cargas de trabalho. Utilize esta tabela ao auditar a sua pilha atual.

Capacidade	Difusão	Acionado	Contextual
Estado por assinante	Não	Não	Sim
Ramifica com base no comportamento	Não	Não	Sim
Critério de saída	Não	Não	Sim
Roteamento multicanal dentro de uma campanha	Não	Não	Sim
A/B incorporado (hora de envio, cópia, canal)	Não	Não	Sim
Carga de trabalho correta	Vendas flash, anúncios de lançamento	Pings transacionais únicos (baixo volume)	Jornadas de ciclo de vida (boas-vindas, carrinho, reconquista, renovação)

A maioria dos programas de ciclo de vida necessita de contextual. A maioria das equipas envia acionado. Essa lacuna é sobre o que este artigo trata. Os fluxos de trabalho de automação de marketing que enviam jornadas contextuais não se parecem com uma lista mais longa de gatilhos; parecem um conjunto menor de jornadas de várias etapas compostas a partir de um vocabulário partilhado. Os fluxos de trabalho de notificações push que realmente deseja são três jornadas contextuais, não nove gatilhos.

Event triggers and audience triggers behave very differently

Antes da anatomia do nó, um ponto de taxonomia que quase todos os artigos sobre este tópico erram. Um "gatilho" em fluxos de trabalho de notificações push não é um único primitivo. São dois primitivos que parecem semelhantes por fora e comportam-se de forma muito diferente por baixo.

Gatilhos de eventos disparam por assinante num evento real. Os eventos suportados nos Fluxos de Trabalho PushEngage incluem PushEngage.Subscriber.Added, PushEngage.Subscriber.AddSegment, PushEngage.Subscriber.RemoveSegment, PushEngage.Subscriber.UpdateField, PushEngage.Subscriber.UpdateAttribute, PushEngage.Goal.Tracked e PushEngage.CustomEvent. Quando o evento dispara, o sistema avalia os fluxos de trabalho ativos, verifica os critérios do filtro de eventos, verifica as regras de saída e enfileira o fluxo de trabalho correspondente para esse assinante. A lacuna entre o gatilho e a fila é de segundos. Os gatilhos de eventos são o primitivo correto para qualquer campanha reativa: abandono de carrinho, abandono de navegação, acompanhamento de compra, boas-vindas de adesão a segmento. As campanhas push acionadas por eventos são o caso dominante em eCommerce, integração SaaS e qualquer programa com sinais em tempo real.

Gatilhos de audiência disparam num filtro a uma hora agendada. O filtro seleciona subscritores que correspondem a critérios específicos, como last_active > 30 dias, loyalty_tier = gold, ou city = New York AND segments includes "vip". O poller do agendador vai buscar o conjunto de subscritores correspondentes em lotes de 1000, espaça a execução em 15 segundos a 2 minutos, e cria uma instância de fluxo de trabalho por subscritor. Os gatilhos de audiência são a ferramenta certa para campanhas de reativação, campanhas de aniversário, promoções geográficas e qualquer programa onde o conjunto é definido por atributo em vez de por evento.

As diferenças importam operacionalmente, não apenas conceptualmente:

Aspeto	Gatilho de evento	Gatilho de audiência
Iniciação	Em tempo real com base no evento do subscritor	Agendado via poller
Velocidade	Em segundos	Em lotes, com atraso de 1-2 minutos
Seleção de subscritores	Um subscritor por evento	Seleção em massa apenas no momento do início do fluxo de trabalho
Novos subscritores após o início	Incluídos automaticamente no próximo evento	NÃO incluídos automaticamente após o início do fluxo de trabalho
Alteração do filtro após o início	N/A	A edição do filtro NÃO adiciona novos subscritores
Dados do evento disponíveis	Sim (para substituição de variáveis)	Não

A terceira linha é a armadilha. Um fluxo de trabalho baseado em audiência seleciona o seu conjunto de subscritores uma vez, no início do fluxo de trabalho. Subscritores que se tornam inativos após o início do fluxo de trabalho não são adicionados automaticamente. A edição do filtro de audiência num fluxo de trabalho ativo não atrai novos candidatos. Uma equipa de retenção que envia um fluxo de trabalho de “recuperação para subscritores inativos há mais de 30 dias” e o deixa a decorrer durante noventa dias verá a mesma coorte fixa durante os noventa dias inteiros, mesmo que novos subscritores ultrapassem o limite de 30 dias todos os dias.

A resposta arquitetónica é duplicar o fluxo de trabalho de audiência num agendamento recorrente, mensal ou semanal, para que cada duplicado capture os candidatos que ultrapassaram o limite desde a última execução. Esta é uma nota operacional de uma linha na documentação e uma fonte recorrente de tickets de suporte do tipo “porque é que este subscritor não recebeu a campanha?” em equipas que tratam os gatilhos de audiência como gatilhos de evento.

The six nodes that turn a trigger into a contextual campaign

Uma vez disparado o gatilho, o próprio fluxo de trabalho é composto por seis tipos de nós. O vocabulário é pequeno o suficiente para aprender em cinco minutos e grande o suficiente para compor qualquer campanha contextual que uma equipa de retenção alguma vez quis enviar.

INÍCIO. O ponto de entrada. Um nó INÍCIO define o gatilho (baseado em evento ou baseado em audiência) e os critérios do filtro. Um fluxo de trabalho tem exatamente um INÍCIO. O ponto de entrada determina a taxonomia do gatilho da secção anterior e define o contexto de dados do evento que os nós a jusante podem ler.

ESPERAR. Um atraso. Um nó ESPERAR retém o assinante por um período especificado (minutos, horas, dias) ou até uma hora específica do calendário. As esperas são a forma como um fluxo de trabalho respeita o estado do assinante e o fuso horário do assinante. O fluxo de trabalho pode esperar uma hora por um lembrete de abandono de carrinho, três dias por um destaque de funcionalidade numa série de boas-vindas, ou até às 10h de terça-feira no fuso horário local do assinante para um envio em horário comercial. As esperas também permitem compor um gotejamento de várias etapas sem disparar todas as mensagens nos primeiros sessenta segundos.

DECISÃO. Um ramal de duas vias. Um nó DECISÃO verifica um filtro de evento ou um filtro de audiência e encaminha o assinante pelo caminho SIM ou pelo caminho NÃO. O assinante comprou? Eles ainda estão no segmento de abandono de carrinho? O nível de fidelidade deles mudou? Os nós de decisão são a forma como as notificações push comportamentais param de tratar todos os assinantes da mesma forma e começam a adaptar-se ao que cada assinante realmente fez. Os operadores suportados incluem igual a, diferente de, em, não em, maior que, menor que e existe, o que é suficiente para expressar qualquer lógica de decisão que uma equipa de retenção necessite.

DIVIDIR_CAMINHO. Um garfo baseado em percentagem para testes A/B. Um nó DIVIDIR_CAMINHO encaminha os assinantes por dois ou mais caminhos com base em percentagens configuradas: 50/50 para um teste bidirecional, 33/33/34 para um teste de tempo de envio tridirecional, 90/10 para um grupo de exclusão. O sistema utiliza um algoritmo de balanceamento de carga que encaminha cada novo assinante para o caminho mais subutilizado, o que mantém a distribuição precisa mesmo em amostras pequenas. Assim que o teste atingir significância, defina winner_edge_id e o fluxo de trabalho promoverá 100% do tráfego para a variante vencedora sem reconstruir o fluxo de trabalho.

AÇÃO. O trabalho em si. Os nós AÇÃO fazem mais do que enviar uma notificação push. Os Fluxos de Trabalho PushEngage suportam onze tipos de ação: SendPushNotification, AddSegment, RemoveSegment, UpdateField, UpdateAttribute, Update (combinado), HttpRequest, CustomEvent.Send, SendTriggerCampaignEvent, Workflow.Start e Workflow.Stop. Os quatro mais comuns em programas de retenção são SendPushNotification, AddSegment (marcar o assinante como convertido, integrado ou em risco de abandono), UpdateAttribute (incrementar um contador de fidelidade ou definir uma data de última compra) e HttpRequest (sincronizar estado com um CRM, disparar um alerta Slack para um lead de alto valor ou chamar um serviço downstream).

FIM / SAÍDA. O terminal. Os nós FIM e SAÍDA marcam o fluxo de trabalho como concluído e atualizam as análises. FIM é a conclusão natural. SAÍDA é tipicamente colocada no caminho NÃO de uma decisão quando o assinante não se qualifica, ou num ramo de caminho dividido concebido como grupo de controlo. O sistema também suporta critérios de saída a nível de fluxo de trabalho: um audience_filter ou trigger_event que cancela o fluxo de trabalho ativo antes de cada nó ser executado. A regra de saída é acionada independentemente do nó em que o assinante se encontra atualmente. É isto que impede que o fluxo de trabalho de abandono de carrinho envie lembretes a assinantes que já compraram.

Cada campanha contextual neste artigo é composta por estas seis partes. Os padrões de migração abaixo são lidos rapidamente assim que o vocabulário é partilhado.

Three migration patterns: six standalone triggers become three contextual workflows

A maioria das pilhas de retenção para o mercado médio tem entre quatro e oito gatilhos autónomos em execução. O padrão é consistente: notificação de boas-vindas, incentivo à primeira compra, abandono de carrinho, abandono de navegação, pedido de avaliação pós-compra, recuperação, reativação, VIP inativo. Cada um destes é um gatilho separado com a sua própria cópia, o seu próprio proprietário e as suas próprias análises. Nenhum deles sabe sobre os outros. Os mesmos três fluxos de trabalho contextuais podem gerar a mesma receita com um terço da área de superfície.

Pattern 1 — Onboarding consolidation

Colapsar a série de boas-vindas e o incentivo à primeira compra num único fluxo de trabalho com uma decisão sobre o estado da compra.

• INÍCIO: Evento PushEngage.Subscriber.Added
• Tipo de execução: Único (cooldown de 90 dias após a conclusão)
• Fluxo: ESPERAR 1 dia → AÇÃO enviar notificação de boas-vindas → ESPERAR 3 dias → DECISÃO: o assinante comprou? → caminho SIM: AÇÃO enviar agradecimento + AÇÃO AddSegment para customers + FIM → caminho NÃO: AÇÃO enviar incentivo de primeira compra com 10% de desconto → ESPERAR 4 dias → DECISÃO: o assinante comprou? → caminho SIM: AÇÃO enviar agradecimento + FIM → caminho NÃO: AÇÃO enviar incentivo final + FIM
• Critérios de saída: Nenhum a nível de fluxo de trabalho; os ramos de decisão tratam do assinante convertido
• Substitui: Gatilho de boas-vindas + gatilho de primeira compra (2 gatilhos → 1 fluxo de trabalho)

O estado partilhado é o ponto principal. A terceira notificação só é enviada para assinantes que não converteram até ao quarto dia. O gatilho de primeira compra na arquitetura antiga era acionado para todos os novos assinantes, incluindo aqueles que compraram na sua primeira sessão. O fluxo de trabalho deixa de os incomodar.

Pattern 2 — Cart-to-review chain

Colapsar a recuperação de abandono de carrinho e o pedido de avaliação pós-compra num único fluxo de trabalho com uma passagem de encadeamento de fluxo de trabalho.

• INÍCIO: Evento personalizado cart_abandoned
• Tipo de execução: Múltiplos Paralelos (cada carrinho abandonado é a sua própria instância)
• Fluxo: ESPERAR 1 hora → AÇÃO lembrete nº 1 → ESPERAR 24 horas → DECISÃO: carrinho ainda abandonado? → caminho SIM: AÇÃO lembrete nº 2 com 10% → ESPERAR 48 horas → DECISÃO: carrinho ainda abandonado? → caminho SIM: AÇÃO lembrete final com 20% → FIM
• Critérios de saída (nível do fluxo de trabalho): Goal.Tracked = purchase correspondendo ao cart_id do evento de gatilho. No momento em que o assinante compra, o fluxo de trabalho é cancelado.
• Transferência: Na saída devido a compra, o sistema dispara PushEngage.Workflow.Start visando o fluxo de trabalho de solicitação de avaliação. O fluxo de trabalho de avaliação só começa para assinantes que realmente compraram. O caminho de saída por não compra ignora a transferência completamente.
• Substitui: Gatilho de carrinho + gatilho de avaliação pós-compra + o ticket de suporte de solicitações de avaliação que chegam a assinantes que nunca compraram (3 problemas → 1 fluxo de trabalho)

A ligação através de Workflow.Start é a resposta arquitetónica para a progressão do ciclo de vida. Em vez de dois gatilhos a disparar independentemente e a sobrepor-se nos mesmos assinantes, a saída por compra do fluxo de trabalho do carrinho é o que inicia o fluxo de trabalho de avaliação. A avaliação só dispara para assinantes convertidos. O carrinho nunca dispara após a conversão. A transferência é imposta pelo motor.

Pattern 3 — Re-engagement consolidation

Colapsar as campanhas de recuperação, reativação e VIP inativo num único fluxo de trabalho com um gatilho de audiência e três ramos de decisão.

• INÍCIO: Filtro de audiência last_active > 30 days
• Tipo de execução: Único (uma tentativa de reengajamento por assinante por janela de 90 dias)
• Fluxo: DECISÃO: nível de fidelidade? → Ramo Gold: AÇÃO enviar “sentimos a sua falta, VIP” com oferta de 20% → Ramo Silver: AÇÃO enviar “sentimos a sua falta” com oferta de 10% → Ramo sem nível: AÇÃO enviar “sentimos a sua falta” padrão com oferta de frete grátis → ESPERAR 5 dias → DECISÃO (por ramo): o assinante interagiu ou visitou o site? → Caminho SIM: AÇÃO AddSegment para re-engaged + FIM → Caminho NÃO: AÇÃO enviar “última chance” com oferta mais profunda + FIM
• Critérios de saída (nível do fluxo de trabalho): Filtro de audiência last_active < 7 days. O assinante tornou-se ativo por conta própria e o trabalho do fluxo de trabalho está concluído.
• Substitui: Gatilho de recuperação + gatilho de reativação + gatilho de VIP inativo (3 gatilhos → 1 fluxo de trabalho)
• Nota operacional: Conforme a armadilha do gatilho de audiência na secção anterior, este fluxo de trabalho não inclui automaticamente assinantes que cruzam o limiar de 30 dias após o início do fluxo de trabalho. Duplique o fluxo de trabalho mensalmente para que cada duplicado capture os novos candidatos. Um único fluxo de trabalho de audiência de longa duração é a primitiva errada aqui.

Após estas três migrações, a equipa de retenção gere três jornadas contextuais em vez de seis (ou oito) gatilhos independentes. O volume total de mensagens push permanece aproximadamente o mesmo. A sobrecarga de mensagens desaparece, porque critérios de saída partilhados e ramos de decisão param o fluxo de trabalho quando o estado do assinante já não corresponde. A fragmentação da análise de “seis painéis que não consigo reconciliar” para “três funis que posso defender”. É assim que as campanhas push acionadas por eventos parecem quando crescem.

What contextual workflows do that standalone triggers cannot

Existem quatro capacidades dentro de um fluxo de trabalho contextual que não podem ser compostas entre acionadores independentes. Cada uma é uma fonte real de receita ou poupança.

Critérios de saída entre fluxos de trabalho. Um acionador independente é acionado quando o evento ocorre, ponto final. Dentro de um fluxo de trabalho, a regra de saída é acionada independentemente do nó em que o assinante se encontra. O fluxo de trabalho de abandono de carrinho termina com a compra. O de recuperação termina com a reativação. O fluxo de trabalho de renovação termina com a renovação antecipada. O acionador que ninguém instruiu a parar é o fluxo de trabalho que define uma regra de saída.

Roteamento multicanal dentro de um fluxo de trabalho. Com ferramentas separadas de canal único, "enviar push da web, recorrer ao e-mail, escalar para o WhatsApp" requer três logins de fornecedor, dois motores de segmentação e pelo menos um fluxo Zapier. Dentro de um motor de fluxo de trabalho, são três nós de AÇÃO com dois nós de DECISÃO entre eles, partilhando uma identidade de assinante e um conjunto de critérios de saída. Para um tratamento mais aprofundado, consulte a publicação sobre orquestração multicanal de push e e-mail.

Horário de silêncio com fallback reschedule. Notificações push que chegariam às 3 da manhã no fuso horário local do assinante são retidas até às 8:01 se o horário de silêncio for configurado com reschedule como fallback. A alternativa, skip, descarta silenciosamente a notificação e não atualiza as análises de notificação para a ação ignorada. Para a maioria das equipas de retenção, reschedule é a predefinição correta porque análises perdidas significam atribuição de receita perdida. As notificações push contextuais que uma equipa de retenção realmente deseja enviar respeitam os fusos horários dos assinantes sem desaparecer do funil.

Encadeamento de fluxos de trabalho. As ações Workflow.Start e Workflow.Stop tornam a progressão do ciclo de vida uma arquitetura real. O fluxo de trabalho de boas-vindas termina, o que inicia o fluxo de trabalho de engajamento. O fluxo de trabalho do carrinho termina com a compra, o que inicia o fluxo de trabalho de revisão. Comparado a uma pasta de acionadores que disparam independentemente, esta é uma máquina de estados: um grafo de fluxos de trabalho, cada um com sua condição de entrada, condição de saída e passagem para o próximo estágio. Os acionadores não se conhecem. Os fluxos de trabalho sim.

Per-workflow analytics: how to read the funnel

Um fluxo de trabalho que não se consegue defender na próxima revisão de P&L é um fluxo de trabalho que é eliminado. O PushEngage Workflows rastreia três números em cada nó (queued_users, completed_users, exited_users) mais totais a nível de fluxo de trabalho para total-entrado, atualmente-ativo, concluído e saído. O trabalho do gestor de retenção é ler este funil e dizer às finanças o que cada item produziu.

Aqui estão as análises a nível de nó para a cadeia de carrinho para revisão do Padrão 2 acima. Números ilustrativos, retirados de uma lista realista de 200.000 assinantes com uma taxa mensal de abandono de carrinho de 6%.

Nó	Enfileirado	Concluído	Saído	Notas
INÍCIO (carrinho_abandonado)	0	12,400	320	320 assinantes corresponderam aos critérios de saída no início do fluxo de trabalho (compraram entre o evento do carrinho e a varredura do fluxo de trabalho)
ESPERA 1 hora	180	11,900	320	Profundidade normal da fila
AÇÃO: lembrete nº 1	0	11,900	0	Enviado
AGUARDAR 24 horas	240	9,800	1,860	1.860 assinantes compraram após o lembrete nº 1 (saída no objetivo purchase)
DECISÃO: carrinho ainda abandonado	0	9,800	0	Ramo avaliado
AÇÃO: lembrete #2 (10%)	0	9,800	0	Enviado
ESPERAR 48 horas	90	6,300	3,410	3.410 assinantes compraram após o lembrete #2
AÇÃO: lembrete final (20%)	0	6,300	0	Enviado
FIM	n/d	6,300	n/d	6.300 assinantes não compraram; o fluxo de revisão não está encadeado para estes
Workflow.Start → fluxo de revisão	n/d	5,270	n/d	Disparado para os 5.270 assinantes (1.860 + 3.410) que compraram

Os 5.270 handoffs encadeados são a nova métrica que esta arquitetura expõe. O fluxo do carrinho recuperou uma taxa de carrinho de 42,5% (5.270 de 12.400 iniciados) e apenas esses 5.270 assinantes recebem o fluxo de solicitação de revisão. A arquitetura antiga enviava a solicitação de revisão para todos que já haviam comprado, incluindo assinantes que nunca abandonaram um carrinho, assinantes que devolveram o pedido e assinantes que já haviam enviado uma avaliação. A correção arquitetônica é pequena. As economias com a sobrecarga de mensagens são grandes.

Dois padrões de gargalo valem a pena conhecer. Um nó de saída alta (como os dois nós WAIT acima) é o fluxo a fazer o seu trabalho: os assinantes compram durante as janelas de espera, os critérios de saída são disparados, o próximo lembrete nunca é enviado. O padrão inverso, saídas altas em nós de ação combinadas com saídas baixas em nós de espera, significa que o tempo está errado e as esperas devem ser encurtadas. Um nó de fila alta significa uma paralisação em horário de silêncio, uma longa espera ou um atraso no poller downstream; verifique a configuração de tempo antes de assumir que o fluxo está quebrado.

Para um tratamento mais aprofundado e específico de eCommerce desses padrões, a publicação complementar sobre cinco fluxos de notificações push para eCommerce aborda carrinho, navegação, pós-compra, boas-vindas e recuperação como jornadas independentes. O hub de notificações push de eCommerce cobre o cenário mais amplo de tipos de campanha, a sequência de recuperação de abandono de carrinho detalha o ajuste de cadência por plataforma, e a visão geral notificações push automatizadas apresenta a lista mais antiga de tipos de automação ao lado desta arquitetura de fluxo.

A mesma forma de análise funciona em todos os setores. SaaS tem um funil de renovação e conversão de teste para pago. Editores têm um funil de engajamento de artigos e reentrada no arquivo. Viagens têm um funil de reservas e fluxo de alerta de queda de preço. As notificações push comportamentais que uma equipe de SaaS usa para impulsionar de teste para pago parecem estruturalmente idênticas às que uma equipe de eCommerce usa para impulsionar de carrinho para compra: um START em um evento em tempo real, três ou quatro etapas com ramificações de decisão, critérios de saída na conversão, entrega opcional para o próximo fluxo. O setor muda os nomes dos gatilhos e a cópia da oferta. A arquitetura permanece.

Construa-o nos Fluxos de Trabalho PushEngage

Cada um dos três padrões de migração acima mapeia diretamente para os componentes dos Fluxos do PushEngage.

Padrão	Tipos de nós utilizados	Tipos de ação utilizados	Opção de fluxo	Ponto de partida de modelo sugerido
Consolidação de integração	INÍCIO, ESPERA, DECISÃO, AÇÃO, FIM	SendPushNotification, AddSegment	Tipo de execução: Único	“Série de boas-vindas com ramificação de primeira compra”
Cadeia de carrinho para revisão	INÍCIO, ESPERA, DECISÃO, AÇÃO, FIM	SendPushNotification, Workflow.Start	Tipo de execução: Múltiplo Paralelo; critério de saída Goal.Tracked = purchase	“Escalada de abandono de carrinho”
Consolidação de reengajamento	START (audiência), DECISION, ACTION, WAIT, END	SendPushNotification, AddSegment	Tipo de execução: Único; gatilho de audiência; duplicado mensalmente	“Reengajamento com oferta baseada em nível”

O motor Workflows inclui mais de 60 modelos pré-configurados que cobrem cada padrão de migração acima. Cada modelo é um ponto de partida. Os padrões instalam em menos de cinco minutos no Shopify, Shopify Plus, WooCommerce, BigCommerce e Magento dentro do construtor Workflows da PushEngage, ou em qualquer stack SaaS, publisher ou de viagens através do SDK JavaScript e da API de eventos.

O plano gratuito oferece 200 assinantes, todos os canais (web push, app push, WhatsApp e chat ao vivo) e o motor Workflows completo desde o primeiro dia. Isso é suficiente para migrar um dos três padrões da sua stack de triggers atual e provar a arquitetura antes de solicitar orçamento. Comece com o plano gratuito e implemente o primeiro workflow contextual em menos de uma hora.

Se retirar uma coisa deste artigo, retire isto: uma campanha de push com trigger já não é a notificação. É o workflow. Seis triggers independentes a correr desconectados são seis pipelines apontados para a mesma lista de assinantes, cada um ignorante dos outros.

Três workflows contextuais a correr com estado partilhado, ramos de decisão, critérios de saída e transferências encadeadas são uma jornada por assinante, ramificada e limitada. Os workflows de automação de marketing que produzem um funil defensável por workflow e uma taxa de recompra que se compõe não são uma lista mais longa de triggers; são um conjunto menor e mais preciso de jornadas contextuais. A arquitetura é a campanha. O trigger é a porta.