É a terceira sexta-feira do trimestre e está a analisar o seu painel de retenção. A sequência de carrinho abandonado está em execução. O gatilho de abandono de navegação está em execução. O pedido de avaliação pós-compra está em execução. O alerta de redução de preço está em execução. As notificações de boas-vindas são enviadas a cada registo. Seis notificações push “automatizadas”. Seis gatilhos ligados nos últimos dezoito meses. A sua taxa de recompra parou de aumentar há doze meses.
É assim que a automação de notificações push para eCommerce se parece na maioria das pilhas de retenção de mercado intermédio: seis gatilhos desconectados, cada um enviando cópias de um proprietário de campanha diferente, nenhum deles ciente dos outros. A série de abandono de carrinho continua a enviar notificações a assinantes que já compraram. A campanha de recuperação sobrepõe-se ao alerta de redução de preço para o mesmo cliente. Não há lógica partilhada, nem critérios de saída partilhados, nem identidade partilhada. Apenas seis canais separados, cada um apontado para a mesma lista de assinantes, cada um fingindo que os outros cinco não existem.
A automação de notificações push para eCommerce não deve funcionar assim. Deve funcionar como uma arquitetura de fluxo de trabalho única: um conjunto de jornadas com vários nós e gatilhos partilhados, lógica de decisão partilhada e critérios de saída partilhados, executados em notificações push web, push de app, WhatsApp e chat ao vivo a partir de uma única identidade de assinante. Este artigo descreve como é essa arquitetura, fornece cinco modelos completos de fluxo de trabalho que pode adotar e mostra como ler o funil por fluxo de trabalho para que o item da linha seja defensável perante as finanças.
A maioria das “notificações push automatizadas” não são realmente automatizadas
A palavra automação tem sido muito utilizada no circuito de blogs de eCommerce sem justificação. Quando a maioria dos artigos diz “notificações push automatizadas”, o que querem dizer é “notificações push acionadas”: notificações únicas que são enviadas quando um evento acontece, sem estado adicional, sem esperas, sem ramificações, sem condições de saída. Um assinante abandona um carrinho, a notificação de abandono de carrinho é enviada. Um assinante vê um produto, a notificação de navegação é enviada. Um assinante compra, a notificação pós-compra é enviada. Cada gatilho é o seu próprio pipeline, ignorante de todos os outros gatilhos.
Um fluxo de trabalho é algo diferente. Um fluxo de trabalho é uma jornada de vários passos com estado. Sabe onde o assinante entrou, onde se encontra atualmente, a que horas entrou em cada nó e quais as condições que cancelam a jornada. O fluxo de trabalho de abandono de carrinho não envia apenas uma notificação na marca de uma hora. Envia à uma hora, espera um dia, verifica se o carrinho ainda está abandonado, envia um segundo contacto com um desconto, espera mais dois dias, envia um contacto final e sai do fluxo de trabalho no momento em que o assinante compra, independentemente do passo em que se encontrava.
Essa última cláusula é a diferença. O gatilho não tem memória. O fluxo de trabalho tem. Se a sua “automação de carrinho abandonado” continuar a enviar lembretes depois de o cliente já ter pago, não tem uma automação. Tem um gatilho que ninguém mandou parar.
Para uma equipa de retenção de eCommerce de mercado médio, esta distinção é a diferença entre uma taxa de compra repetida que se compõe e uma que estagna. Seis gatilhos a funcionar em paralelo produzem seis canais de ruído. Cinco fluxos de trabalho a funcionar em coordenação produzem uma jornada por assinante, ramificada e limitada. A maioria dos resultados de pesquisa da página um para esta palavra-chave enquadra o problema como “que tipos de notificações enviar” e responde com uma lista de nove, doze ou quinze modelos. Essa não é a questão. A questão é como compor a jornada.
A anatomia de um fluxo de trabalho de notificação push
Antes dos projetos, o vocabulário. Um fluxo de trabalho de notificação push é construído a partir de seis tipos de nós. Assim que souber o que cada um faz, cada projeto neste artigo será lido como um diagrama, não como uma descrição.
INÍCIO. O ponto de entrada. Um nó INÍCIO define como o fluxo de trabalho é acionado, seja por um evento do assinante (carrinho abandonado, página visitada, segmento ingressado, objetivo de compra rastreado) ou por um filtro de audiência que seleciona assinantes que correspondem a critérios específicos num horário agendado. Um fluxo de trabalho tem exatamente um INÍCIO.
ESPERAR. Um atraso. Um nó ESPERAR retém o assinante neste ponto por uma duração especificada (minutos, horas, dias) ou até uma hora específica do calendário (terça-feira às 10h no fuso horário do assinante, 15 de dezembro às 20h no horário do site). As esperas são a forma como um fluxo de trabalho aprende a não ser um envio único.
DECISÃO. Uma ramificação de duas vias. Um nó DECISÃO verifica uma condição (o assinante comprou, ainda está no segmento de abandono de carrinho, o seu nível de fidelidade é “ouro”) e encaminha-o pelo caminho SIM ou pelo caminho NÃO. As decisões são a forma como um fluxo de trabalho para de tratar todos os assinantes da mesma maneira.
DIVIDIR_CAMINHO. Uma bifurcação baseada em percentagem. Os nós DIVIDIR_CAMINHO encaminham os assinantes por vários caminhos com base em percentagens configuradas: 50/50 para um teste A/B, 33/33/34 para um teste de tempo de envio de três vias. Assim que tiver um vencedor, promove o caminho vencedor para 100% e o fluxo de trabalho continua a funcionar na variante comprovada.
AÇÃO. O trabalho em si. Os nós AÇÃO enviam uma notificação push, adicionam o assinante a um segmento, atualizam os seus atributos, disparam um webhook, iniciam outro fluxo de trabalho ou param um. Os fluxos de trabalho PushEngage suportam onze tipos de ação. Os mais comuns no eCommerce são EnviarNotificaçãoPush, AdicionarSegmento, AtualizarAtributo e HttpRequest.
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 usada para terminar antecipadamente: no caminho NÃO de um nó Decisão quando o assinante não se qualifica, ou num ramo Dividir Caminho projetado como um grupo de controlo.
Cada fluxo de trabalho abaixo é composto por estas seis peças. Assim que o vocabulário for partilhado, os projetos leem-se rapidamente.
Cinco projetos de fluxo de trabalho para eCommerce
Estes não são “exemplos”. São projetos funcionais. Cada um lista o seu gatilho, o seu tipo de execução, a sua sequência de nós, os seus critérios de saída e a sua métrica de retenção pretendida. Pode importar cada um diretamente para o construtor de Fluxos de Trabalho do PushEngage e tê-lo a funcionar em menos de uma hora.
Projeto 1 — Série de boas-vindas
- Gatilho (INÍCIO): Evento
PushEngage.Subscriber.Added - Tipo de execução: Único (uma jornada de boas-vindas por subscritor, com um período de espera de 90 dias antes de reentrada)
- Fluxo: Notificação de boas-vindas (imediata) → ESPERAR 2 dias → notificação de destaque de funcionalidades → ESPERAR 3 dias → DECISÃO: o subscritor efetuou uma compra? → caminho SIM: enviar notificação de agradecimento e adicionar ao segmento
clientes→ caminho NÃO: enviar desconto de primeira compra → FIM - Critérios de saída: Nenhum. A jornada é curta o suficiente para que todos os subscritores a completem.
- Métrica de retenção: Tempo até à primeira compra. Novos subscritores que completam a série de boas-vindas compram mais rapidamente do que aqueles que não o fazem, porque o terceiro contacto ocorre no momento em que a intenção de primeira compra se materializou ou estagnou.
Projeto 2 — Abandono de navegação
- Gatilho (INÍCIO): Evento personalizado
page_viewfiltrado para páginas de detalhes de produtos onde o subscritor não disparou tambémadd_to_cartdentro de 30 minutos - Tipo de execução: Múltiplos Paralelos (um subscritor pode abandonar a navegação de múltiplos produtos numa sessão, e cada um obtém a sua própria instância de fluxo de trabalho)
- Fluxo: ESPERAR 30 minutos → DECISÃO: o subscritor ainda está a navegar no site? → caminho SIM: SAIR (não interromper uma sessão ativa) → caminho NÃO: enviar notificação de lembrete com o produto que visualizou → ESPERAR 24 horas → DECISÃO: adicionou ao carrinho? → caminho SIM: SAIR (o fluxo de trabalho de abandono de carrinho assume a partir daqui) → caminho NÃO: enviar um segundo contacto com recomendação de produtos relacionados → FIM
- Critérios de saída: Objetivo
add_to_cart(o fluxo de trabalho do carrinho herda a jornada) ou objetivopurchase(não é necessária mais nenhuma mensagem) - Métrica de retenção: Taxa de conversão de navegação para carrinho em produtos visualizados anteriormente. A publicação do PushEngage sobre campanhas de abandono de navegação cobre o trabalho de segmentação que este projeto herda.
Projeto 3 — Escalonamento de carrinho abandonado
- Gatilho (INÍCIO): Evento personalizado
cart_abandoned - Tipo de execução: Múltiplos Paralelos (cada carrinho abandonado é a sua própria jornada, pelo que um subscritor que abandone um segundo carrinho enquanto o primeiro ainda está ativo recebe uma segunda instância concorrente)
- Fluxo: ESPERAR 1 hora → lembrete n.º 1 (sem desconto, tom amigável) → ESPERAR 24 horas → DECISÃO: o carrinho ainda está abandonado? → caminho SIM: lembrete n.º 2 com um desconto de 10% → ESPERAR 48 horas → DECISÃO: o carrinho ainda está abandonado? → caminho SIM: lembrete final com um desconto de 20% e enquadramento de urgência → FIM
- Critérios de saída: Objetivo
purchasecorrespondente aocart_iddo evento de gatilho. No momento em que o assinante compra, o fluxo de trabalho é cancelado para esse carrinho, independentemente de onde eles se encontram atualmente. - Métrica de retenção: Valor do carrinho recuperado por carrinho abandonado, por canal. Este é o fluxo de trabalho de maior impacto na página e o mais fácil de defender numa demonstração de resultados (P&L). Para uma cobertura mais aprofundada da sequência de recuperação de abandono de carrinho especificamente, o guia de recuperação de abandono de carrinho da PushEngage detalha como a cadência é ajustada ao comportamento da plataforma (os fluxos de checkout da Shopify Plus diferem do WooCommerce de maneiras que afetam a primeira espera).
Blueprint 4 — Pedido de avaliação pós-compra
- Gatilho (INÍCIO): Evento
PushEngage.Goal.Trackedondegoal_name = purchase - Tipo de execução: Múltiplos Sequenciais (uma jornada ativa de pedido de avaliação de cada vez por assinante, mas a próxima compra dispara uma nova instância)
- Fluxo: ESPERAR 7 dias (tempo suficiente para receber o produto e formar uma opinião) → DIVIDIR CAMINHO 50/50: envio matinal (9h, hora local do assinante) versus envio noturno (19h, hora local do assinante) → notificação de pedido de avaliação → AÇÃO: pedido HTTP para o CRM registando o envio do pedido de avaliação → FIM
- Horário de silêncio: das 22h às 8h no fuso horário do assinante, com
reschedulecomo fallback. As notificações push que deveriam ser enviadas durante a noite esperam até às 8h01 em vez de serem entregues. A configuraçãorescheduleé o padrão correto para este fluxo de trabalho porqueskipignora silenciosamente as notificações e deixa-as fora das análises, o que a maioria das equipas de retenção não deseja. - Critérios de saída: Objetivo
review_submitted - Métrica de retenção: Taxa de envio de avaliações por variante de hora de envio. O caminho dividido torna o teste A/B parte do fluxo de trabalho, não um pensamento posterior anexado a um relatório de campanha.
Blueprint 5 — Reativação
- Gatilho (INÍCIO): Filtro de audiência
last_active > 30 days - Tipo de execução: Único (uma tentativa de reativação por assinante por janela de 90 dias)
- Fluxo: Notificação “Sentimos a sua falta” → ESPERAR 3 dias → DECISÃO: o assinante interagiu com a notificação ou visitou o site? → caminho SIM: adicionar ao segmento
re-engaged, enviar um agradecimento e um desconto, FIM → caminho NÃO: enviar uma oferta mais forte com um desconto maior → ESPERAR 5 dias → DECISÃO: ainda inativo? → caminho SIM: notificação final “última oportunidade” → FIM - Critérios de saída: Filtro de audiência
last_active < 7 days. O assinante ficou ativo por conta própria e o trabalho do fluxo de trabalho está concluído. - Métrica de retenção: Taxa de reativação 60 dias após a entrada no fluxo de trabalho.
Uma palavra sobre o gatilho. Este é o único blueprint neste artigo que usa um gatilho baseado em audiência em vez de um gatilho baseado em evento. Gatilhos de audiência nos Fluxos do PushEngage processam em lote o conjunto de assinantes correspondentes apenas no momento do início do fluxo. Assinantes que se tornam inativos após o início do fluxo não são incluídos automaticamente, e a edição do filtro de audiência num fluxo ativo não adiciona novos assinantes. Se desejar um programa de reativação contínuo, duplique o fluxo num agendamento recorrente (mensal ou trimestral) em vez de esperar que um fluxo de audiência de longa duração continue a ingerir novos candidatos. Esta é uma fonte real de tickets de suporte do tipo “por que este assinante não recebeu o win-back?” em equipas que não compreendem o tipo de gatilho.
Segmentação, testes A/B e critérios de saída vivem dentro do fluxo
O padrão dominante nos resultados de pesquisa da página um para esta palavra-chave é listar segmentação, testes A/B e horas de silêncio como “melhores práticas”: marcadores genéricos no final do artigo, divorciados da campanha que os utiliza. Essa é a moldura errada. Estas não são melhores práticas que ficam ao lado do fluxo. Elas são o fluxo.
Aqui está o mesmo conjunto de conceitos, enquadrado como melhores práticas versus enquadrado como nós de fluxo:
| Conceito | Moldura de melhores práticas (errada) | Moldura de nós de fluxo de trabalho (correta) |
|---|---|---|
| Segmentação RFM | “Segmente a sua lista antes de enviar” | Um nó DECISÃO que verifica a recência, frequência e valor monetário, e depois encaminha assinantes de RFM alto para um caminho diferente dos de RFM baixo. A publicação sobre segmentação do PushEngage cobre as definições de buckets RFM que alimentam este nó. |
| Testes A/B | “Teste sempre o seu texto A/B” | Um nó SPLIT_PATH com alocação de percentagem 50/50, assinantes balanceados por caminho, e um campo winner_edge_id que promove o vencedor para 100% assim que o teste atinge significância |
| Horas de silêncio | “Não envie às 3 da manhã” | Uma opção a nível de fluxo com start_at, end_at, timezone, e uma configuração fallback que ou skip o envio ou o reschedule para um minuto após o fim das horas de silêncio |
| Critério de saída | “Pare de enviar para pessoas que compraram” | Uma regra a nível de fluxo que verifica o assinante contra um filtro de audiência ou um objetivo acionado antes de cada nó, e cancela o fluxo se correspondido |
A diferença importa porque os marcadores de melhores práticas são fáceis de concordar e difíceis de impor. Os nós de fluxo são impostos pelo próprio motor. A DECISÃO é executada sempre. A SPLIT_PATH balanceia cada assinante. O fallback de horas de silêncio é ativado sem que ninguém se lembre de verificar a hora. A regra de saída cancela o fluxo, quer o proprietário da campanha esteja atento ou não.
Para o blueprint de abandono de carrinho acima, isto significa que no momento em que um assinante compra os itens abandonados, a regra de saída é acionada, o fluxo é cancelado para esse assinante, e os segundo e terceiro lembretes nunca são enviados. Nenhum ticket de suporte, nenhum e-mail do departamento financeiro, nenhuma campanha de desculpas. O fluxo parou porque o motor tinha uma regra que lhe dizia para parar.
Orquestração multicanal: um fluxo, quatro canais
A maioria das plataformas de notificações push são ferramentas de um único canal. Algumas são de dois canais. A pergunta que não conseguem responder bem é aquela que uma equipa de retenção de mercado intermédio realmente precisa de responder: dado o estado deste assinante, qual canal deve ser acionado? Web push se ele optou por receber. Email se ele optou por não receber web push. WhatsApp se o valor do carrinho for superior a 200 $. Chat ao vivo se o assinante estiver atualmente no site.
Essa árvore de decisão é um único fluxo de automação de notificações push multicanal, não quatro campanhas em quatro ferramentas. Com os Fluxos do PushEngage, uma jornada de abandono de carrinho pode ser composta da seguinte forma:
- INÍCIO: evento
cart_abandoned - AGUARDAR: 1 hora
- Nó de DECISÃO 1: o assinante está inscrito para web push?
- Caminho SIM: AÇÃO, enviar lembrete de web push
- Caminho NÃO: continuar para a próxima decisão
- AGUARDAR: 30 minutos após o web push (ou imediatamente, se nenhum push foi acionado)
- Nó de DECISÃO 2: o assinante clicou no web push, ou não está inscrito para web push?
- Se o web push foi acionado e clicado: SAIR (deixar o fluxo do carrinho terminar)
- Se o web push foi acionado e não foi clicado, ou nenhum web push: continuar
- Nó de DECISÃO 3: valor do carrinho superior a 200 $?
- Caminho SIM: AÇÃO, acionar mensagem WhatsApp através da ação SendPushNotification no canal WhatsApp
- Caminho NÃO: AÇÃO, acionar email através de um pedido HTTP para o seu ESP
- SAIR no objetivo
purchase
Quatro canais, um fluxo, um conjunto de critérios de saída, uma identidade de assinante. O mesmo gestor de retenção que anteriormente não conseguia orquestrar isto sem três logins de fornecedor e um fluxo Zapier, agora pode compô-lo dentro de um único fluxo que o motor impõe.
Fazer a mesma coisa em ferramentas separadas significa seis sincronizações entre plataformas, dois motores de segmentação que discordam sobre quem conta como um “assinante VIP”, e nenhuma atribuição de receita única porque cada ferramenta reporta as suas próprias conversões. Fazer isto dentro de um único motor de fluxo significa uma identidade de assinante, um conjunto de lógica de decisão e um relatório de funil. Para mais informações sobre como push e email trabalham juntos dentro de um único plano de retenção, veja orquestração multicanal de push e email.
Este é o diferenciador que não tem um análogo nos resultados dominantes da primeira página. Nenhum dos quinze primeiros resultados para esta palavra-chave descreve um fluxo de trabalho entre canais como um único objeto. Todos tratam push como o tópico e email como a comparação.
A matemática da retenção: receita por fluxo, por canal, por notificação
Um fluxo de trabalho que não consegue defender na próxima revisão de P&L é um fluxo de trabalho que é eliminado. O trabalho do gestor de retenção é mostrar, em dólares, o que cada item produziu. A maioria dos artigos sobre “notificações push automatizadas para ecommerce” para na taxa de cliques. Isso não é suficiente. A métrica correta é receita recuperada por assinante, por fluxo, por canal.
PushEngage Workflows rastreia três números em cada nó:
- Utilizadores em fila: assinantes atualmente à espera neste nó (tipicamente um WAIT ou um reagendamento fora do horário de silêncio)
- Utilizadores concluídos: assinantes que passaram por este nó
- Utilizadores saídos: assinantes que saíram do fluxo de trabalho neste nó, quer porque os critérios de saída corresponderam quer porque se desinscreveram
Eis como se apresentam as análises a nível de nó para um fluxo de trabalho ativo de abandono de carrinho (números ilustrativos, retirados de uma lista realista de 200.000 subscritores):
| Nó | Enfileirado | Concluído | Saído | Notas |
|---|---|---|---|---|
| INÍCIO (carrinho_abandonado) | 0 | 12,400 | 320 | 320 subscritores corresponderam aos critérios de saída no início do fluxo de trabalho (compraram entre o evento do carrinho e a análise do fluxo de trabalho) |
| ESPERA 1 hora | 180 | 11,900 | 320 | Profundidade normal da fila |
| AÇÃO: lembrete nº 1 | 0 | 11,900 | 0 | Notificação enviada |
| AGUARDAR 24 horas | 240 | 9,800 | 1,860 | Elevada contagem de saídas: 1.860 subscritores compraram após o lembrete nº 1 |
| DECISÃO: carrinho ainda abandonado | 0 | 9,800 | 0 | Todos os subscritores restantes ainda têm o carrinho aberto |
| AÇÃO: lembrete nº 2 (10% de desconto) | 0 | 9,800 | 0 | Notificação enviada com desconto |
| ESPERAR 48 horas | 90 | 6,300 | 3,410 | Mais 3.410 compras desencadearam a saída |
| AÇÃO: lembrete final (20% de desconto) | 0 | 6,300 | 0 | Notificação final |
| FIM | n/d | 6,300 | n/d | 6.300 subscritores não compraram |
Neste funil, 5.270 subscritores (1.860 + 3.410) compraram enquanto estavam dentro do fluxo de trabalho, uma taxa de recuperação de carrinho de 42,5%. As duas esperas (24h e 48h) são os nós de maior saída no funil, o que é o padrão esperado: as decisões de tempo para compra ocorrem nas janelas de espera, não nas janelas de ação. Se o seu fluxo de trabalho mostrar o padrão inverso, com saídas elevadas em nós de ação e saídas baixas em nós de espera, o seu tempo está incorreto e as esperas devem ser encurtadas.
A matemática da retenção também tem de abordar o custo. As notificações push não custam nada por envio depois de o subscritor ter optado por recebê-las. Os custos de e-mail dependem do seu ESP, mas com uma lista de 200.000 subscritores e uma configuração típica de Klaviyo ou Bloomreach, um único envio de abandono de carrinho custa várias centenas de dólares em uso medido (aplicam-se os termos do seu contrato).
Uma automação de notificação push de abandono de carrinho push-first que recupera carrinhos a 42% pode atingir o mesmo número de receita recuperada que um fluxo de trabalho push e e-mail a 38%, a um custo materialmente inferior. Faça as contas com o tamanho da sua própria lista e contrato de ESP. O ponto é que push, push de app e WhatsApp não incorrem no custo por envio que o e-mail tem, e o trabalho do fluxo de trabalho é usar o canal mais barato primeiro sempre que o estado do subscritor o permitir.
Quando o item de linha é defensável (este fluxo de trabalho recuperou $X em carrinhos a um custo total de $Y), a conversa sobre o orçamento é curta.
Construa-o nos Fluxos de Trabalho PushEngage
Cada blueprint neste artigo mapeia diretamente para os componentes do PushEngage Workflows. Aqui está o mapeamento para os cinco blueprints acima:
| Modelo | Tipos de nós utilizados | Tipos de ação utilizados | Opção de fluxo |
|---|---|---|---|
| Série de boas-vindas | INÍCIO, ESPERA, DECISÃO, AÇÃO, FIM | SendPushNotification, AddSegment | Tipo de execução: Único |
| Abandono de navegação | INÍCIO, ESPERA, DECISÃO, AÇÃO, SAÍDA | SendPushNotification | Tipo de execução: Múltiplos Paralelos |
| Escalada de abandono de carrinho | INÍCIO, ESPERA, DECISÃO, AÇÃO, FIM | SendPushNotification | Tipo de execução: Múltiplos Paralelos; sair no objetivo purchase |
| Pedido de revisão pós-compra | INÍCIO, ESPERA, DIVIDIR_CAMINHO, AÇÃO, FIM | SendPushNotification, HttpRequest | Tipo de execução: Múltiplos Sequenciais; horas de silêncio das 22h às 8h, fallback de reagendamento |
| Reativação | INÍCIO, AÇÃO, ESPERA, DECISÃO, FIM | SendPushNotification, AddSegment | Tipo de execução: Único; gatilho baseado em audiência |
O motor Workflows vem com mais de 60 modelos enviados cobrindo cada um destes fluxos. Cada modelo é um ponto de partida. Cada blueprint acima pode ser instalado em menos de cinco minutos no Shopify, Shopify Plus, WooCommerce, BigCommerce ou Magento dentro do construtor de fluxos de trabalho de notificações push do PushEngage.
A funcionalidade Workflows abrange também a lógica de decisão e os passos de personalização que tornam possível o encaminhamento multicanal descrito na secção anterior, e suporta os onze tipos de ações que permitem fazer mais do que apenas enviar uma notificação: atualizar atributos de subscritores, disparar webhooks para o seu CRM, iniciar fluxos de trabalho a jusante ou parar outros conflitos.
Para uma visão mais abrangente de como estes fluxos de trabalho se encaixam num programa completo de retenção de eCommerce, o artigo do hub de notificações push de eCommerce aborda os tipos de campanhas que estes modelos implementam.
O plano gratuito oferece 200 subscritores, todos os quatro canais (notificações push web, push de app, WhatsApp e chat ao vivo) e o motor Workflows completo desde o primeiro dia. Isto é suficiente para provar o canal antes de o incluir numa linha orçamental.
O que isto muda
Se retirar uma coisa deste artigo, retire esta: a automação de notificações push para eCommerce é arquitetura de fluxo de trabalho, não um conjunto de campanhas acionadas. A jornada de abandono de carrinho que termina com a compra, a série de boas-vindas que se ramifica com base no comportamento da primeira compra e a orquestração multicanal que escolhe o canal viável mais barato para cada subscritor têm todos a mesma forma.
Um START, alguns WAITs, algumas DECISIONs, algumas ACTIONs, um EXIT. Seis gatilhos independentes não conseguem fazer isto. Um motor de fluxo de trabalho consegue. A matemática da retenção aumenta a partir daí.
Comece no plano gratuito para implementar o primeiro modelo em menos de uma hora.
