Automazione delle notifiche push per l'eCommerce: 5 modelli di flusso di lavoro

È il terzo venerdì del trimestre e stai guardando la tua dashboard di fidelizzazione. La sequenza del carrello abbandonato è attiva. Il trigger di abbandono della navigazione è attivo. La richiesta di recensione post-acquisto è attiva. L'avviso di riduzione del prezzo è attivo. Le notifiche di benvenuto vengono inviate a ogni iscrizione. Sei "notifiche push automatizzate". Sei trigger collegati negli ultimi diciotto mesi. Il tuo tasso di riacquisto ha smesso di muoversi dodici mesi fa.

Questo è ciò che l'automazione delle notifiche push per l'eCommerce sembra nella maggior parte degli stack di fidelizzazione di medie dimensioni: sei trigger disconnessi, ognuno dei quali invia copie da un diverso proprietario di campagna, nessuno dei quali è consapevole degli altri. La serie di abbandono del carrello continua a inviare notifiche agli iscritti che hanno già acquistato. La campagna di recupero si sovrappone all'avviso di riduzione del prezzo per lo stesso cliente. Non c'è logica condivisa, nessun criterio di uscita condiviso, nessuna identità condivisa. Solo sei canali separati, ognuno puntato alla stessa lista di iscritti, ognuno fingendo che gli altri cinque non esistano.

L'automazione delle notifiche push per l'eCommerce non dovrebbe funzionare in questo modo. Dovrebbe funzionare come un'unica architettura di flusso di lavoro: un set di percorsi multi-nodo con trigger condivisi, logica decisionale condivisa e criteri di uscita condivisi, che funzionano su notifiche push web, push app, WhatsApp e chat dal vivo da un'unica identità di iscritto. Questo articolo illustra come appare tale architettura, fornisce cinque blueprint completi di flussi di lavoro che puoi adottare e mostra come leggere l'imbuto per flusso di lavoro in modo che la voce di bilancio sia difendibile nei confronti del reparto finanziario.

La maggior parte delle "notifiche push automatizzate" non sono realmente automatizzate

La parola automazione ha svolto un ruolo eccessivo nel circuito dei blog sull'eCommerce. Quando la maggior parte degli articoli parla di "notifiche push automatizzate", ciò che intendono sono "notifiche push attivate": notifiche singole che vengono inviate quando si verifica un evento, senza ulteriori stati, attese, diramazioni o condizioni di uscita. Un iscritto abbandona un carrello, viene inviata la notifica di abbandono del carrello. Un iscritto visualizza un prodotto, viene inviata la notifica di navigazione. Un iscritto acquista, viene inviata la notifica post-acquisto. Ogni trigger è una propria pipeline, ignara di ogni altro trigger.

Un flusso di lavoro è qualcosa di diverso. Un flusso di lavoro è un percorso multi-fase con uno stato. Sa dove è entrato l'iscritto, dove si trova attualmente, a che ora è entrato in ogni nodo e quali condizioni annullano il percorso. Il flusso di lavoro di abbandono del carrello non invia solo una notifica all'ora, ma attende un giorno, verifica se il carrello è ancora abbandonato, invia un secondo contatto con uno sconto, attende altri due giorni, invia un ultimo contatto ed esce dal flusso di lavoro nel momento in cui l'iscritto acquista, indipendentemente dalla fase in cui si trovava.

Quella clausola finale fa la differenza. Il trigger non ha memoria. Il workflow sì. Se la tua “automazione del carrello abbandonato” continua a inviare promemoria dopo che il cliente ha già pagato, non hai un'automazione. Hai un trigger a cui nessuno ha detto di fermarsi.

Per un team di fidelizzazione clienti di medie dimensioni nell'e-commerce, questa distinzione è la differenza tra un tasso di acquisti ripetuti che cresce esponenzialmente e uno che si arresta. Sei trigger in esecuzione parallela producono sei canali di rumore. Cinque workflow in esecuzione coordinata producono un percorso per abbonato, ramificato e delimitato. La maggior parte dei risultati di ricerca di prima pagina per questa parola chiave inquadra il problema come “quali tipi di notifiche inviare” e risponde con un elenco di nove, dodici o quindici modelli. Questa non è la domanda. La domanda è come comporre il percorso.

L'anatomia di un workflow di notifiche push

Prima dei progetti, il vocabolario. Un workflow di notifiche push è costruito da sei tipi di nodi. Una volta che sai cosa fa ognuno, ogni progetto in questo articolo si legge come un diagramma, non una descrizione.

START. Il punto di ingresso. Un nodo START definisce come viene attivato il workflow, sia tramite un evento dell'abbonato (carrello abbandonato, pagina visualizzata, segmento aggiunto, obiettivo di acquisto tracciato) sia tramite un filtro del pubblico che seleziona gli abbonati che corrispondono a criteri specifici in un orario programmato. Un workflow ha esattamente un START.

WAIT. Un ritardo. Un nodo WAIT trattiene l'abbonato in questo punto per una durata specificata (minuti, ore, giorni) o fino a un'ora specifica del calendario (martedì alle 10:00 nel fuso orario dell'abbonato, 15 dicembre alle 20:00 ora del sito). I WAIT sono il modo in cui un workflow impara a non essere un invio unico.

DECISION. Un bivio. Un nodo DECISION controlla una condizione (l'abbonato ha acquistato, è ancora nel segmento degli abbandoni del carrello, il suo livello di fedeltà è “oro”) e lo instrada lungo il percorso SÌ o il percorso NO. Le Decisioni sono il modo in cui un workflow smette di trattare ogni abbonato allo stesso modo.

SPLIT_PATH. Una biforcazione basata sulla percentuale. I nodi SPLIT_PATH instradano gli abbonati attraverso percorsi multipli in base a percentuali configurate: 50/50 per un test A/B, 33/33/34 per un test di orario di invio a tre vie. Una volta che hai un vincitore, promuovi il percorso vincente al 100% e il workflow continua a funzionare sulla variante comprovata.

ACTION. Il lavoro vero e proprio. I nodi ACTION inviano una notifica push, aggiungono l'abbonato a un segmento, aggiornano i suoi attributi, attivano un webhook, avviano un altro workflow o ne interrompono uno. PushEngage Workflows supporta undici tipi di azione. I più comuni nell'e-commerce sono SendPushNotification, AddSegment, UpdateAttribute e HttpRequest.

END / EXIT. Il terminale. I nodi END ed EXIT segnano il completamento del workflow e aggiornano le analisi. END è la conclusione naturale. EXIT viene tipicamente utilizzato per terminare anticipatamente: sul percorso NO di un nodo Decision quando l'abbonato non è idoneo, o su un ramo Split Path progettato come gruppo di controllo.

Ogni workflow sottostante è composto da questi sei elementi. Una volta condiviso il vocabolario, i blueprint si leggono velocemente.

Cinque blueprint di workflow per l'eCommerce

Questi non sono "esempi". Sono blueprint funzionanti. Ognuno elenca il proprio trigger, il proprio tipo di esecuzione, la propria sequenza di nodi, i propri criteri di uscita e la propria metrica di retention prevista. Puoi caricarli direttamente nel builder di Workflow di PushEngage e averli in esecuzione in meno di un'ora.

Blueprint 1 — Serie di benvenuto

• Trigger (START): Evento PushEngage.Subscriber.Added
• Tipo di esecuzione: Singolo (un percorso di benvenuto per iscritto, con un periodo di cooldown di 90 giorni prima del reinserimento)
• Flusso: Notifica di benvenuto (immediata) → ATTENDI 2 giorni → notifica di evidenziazione funzionalità → ATTENDI 3 giorni → DECISIONE: l'iscritto ha effettuato un acquisto? → Percorso SÌ: invia una notifica di ringraziamento e aggiungi al segmento customers → Percorso NO: invia uno sconto sul primo acquisto → FINE
• Criteri di uscita: Nessuno. Il percorso è abbastanza breve da far sì che ogni iscritto lo completi.
• Metrica di retention: Tempo al primo acquisto. I nuovi iscritti che completano la serie di benvenuto acquistano più velocemente di quelli che non la completano, perché il terzo contatto avviene nel momento in cui l'intenzione di primo acquisto si è materializzata o è in stallo.

Blueprint 2 — Abbandono della navigazione

• Trigger (START): Evento personalizzato page_view filtrato per pagine di dettaglio prodotto in cui l'iscritto non ha attivato anche add_to_cart entro 30 minuti
• Tipo di esecuzione: Multiplo Parallelo (un iscritto può abbandonare la navigazione di più prodotti in una sessione, e ognuno ottiene la propria istanza di workflow)
• Flusso: ATTENDI 30 minuti → DECISIONE: l'iscritto sta ancora navigando sul sito? → Percorso SÌ: ESCI (non interrompere una sessione attiva) → Percorso NO: invia una notifica di promemoria con il prodotto visualizzato → ATTENDI 24 ore → DECISIONE: ha aggiunto al carrello? → Percorso SÌ: ESCI (il workflow di abbandono del carrello subentra da qui) → Percorso NO: invia un secondo contatto con una raccomandazione di prodotti correlati → FINE
• Criteri di uscita: Obiettivo add_to_cart (il workflow del carrello eredita il percorso) o obiettivo purchase (non sono necessari ulteriori messaggi)
• Metrica di retention: Tasso di conversione da navigazione a carrello per prodotti visualizzati in precedenza. Il post di PushEngage sulle campagne di abbandono della navigazione copre il lavoro di segmentazione che questo blueprint eredita.

Blueprint 3 — Escalation carrello abbandonato

• Trigger (START): Evento personalizzato cart_abandoned
• Tipo di esecuzione: Multiplo Parallelo (ogni carrello abbandonato è un percorso a sé stante, quindi un iscritto che abbandona un secondo carrello mentre il primo è ancora attivo ottiene una seconda istanza concorrente)
• Flusso: ATTENDI 1 ora → promemoria n. 1 (nessuno sconto, tono amichevole) → ATTENDI 24 ore → DECISIONE: il carrello è ancora abbandonato? → Percorso SÌ: promemoria n. 2 con uno sconto del 10% → ATTENDI 48 ore → DECISIONE: il carrello è ancora abbandonato? → Percorso SÌ: promemoria finale con uno sconto del 20% e inquadratura di urgenza → FINE
• Criteri di uscita: Obiettivo purchase corrispondente al cart_id dall'evento trigger. Nel momento in cui l'iscritto acquista, il workflow si annulla per quel carrello, indipendentemente da dove si trovi attualmente.
• Metrica di retention: Valore del carrello recuperato per carrello abbandonato, per canale. Questo è il workflow di maggior impatto nella pagina e il più facile da difendere su un conto economico. Per una copertura più approfondita della sequenza di recupero del carrello abbandonato in particolare, il playbook di recupero carrello abbandonato di PushEngage illustra come la cadenza viene ottimizzata per il comportamento della piattaforma (i flussi di checkout di Shopify Plus differiscono da WooCommerce in modi che influiscono sulla prima attesa).

Blueprint 4 — Richiesta di recensione post-acquisto

• Trigger (START): Evento PushEngage.Goal.Tracked dove goal_name = purchase
• Tipo di esecuzione: Sequenziale multiplo (un solo percorso di richiesta di recensione attivo alla volta per iscritto, ma il prossimo acquisto attiva una nuova istanza)
• Flusso: ATTENDI 7 giorni (abbastanza tempo per ricevere il prodotto e formarsi un'opinione) → DIVIDI_PERCORSO 50/50: invio mattutino (ore 9:00 ora locale dell'iscritto) contro invio serale (ore 19:00 ora locale dell'iscritto) → notifica di richiesta di recensione → AZIONE: richiesta HTTP al CRM che registra l'invio della richiesta di recensione → FINE
• Ore di silenzio: dalle 22:00 alle 8:00 nel fuso orario dell'iscritto, fallback reschedule. Le notifiche push che atterrebbero durante la notte attendono fino alle 8:01 piuttosto che essere inviate. L'impostazione reschedule è l'impostazione predefinita corretta per questo workflow perché skip elimina silenziosamente le notifiche e le lascia fuori dalle analisi, cosa che la maggior parte dei team di retention non desidera.
• Criteri di uscita: Obiettivo review_submitted
• Metrica di retention: Tasso di invio recensioni per variante di orario di invio. Il percorso diviso rende il test A/B parte del workflow, non un ripensamento allegato a un report di campagna.

Blueprint 5 — Riattivazione

• Trigger (START): Filtro pubblico last_active > 30 days
• Tipo di esecuzione: Singolo (un tentativo di riattivazione per iscritto ogni finestra di 90 giorni)
• Flusso: Notifica “Ci manchi” → ATTENDI 3 giorni → DECISIONE: l'iscritto ha interagito con la notifica o ha visitato il sito? → Percorso SÌ: aggiungi al segmento ri-engaged, invia un ringraziamento e uno sconto, FINE → Percorso NO: invia un'offerta più forte con uno sconto maggiore → ATTENDI 5 giorni → DECISIONE: ancora inattivo? → Percorso SÌ: notifica finale “ultima possibilità” → FINE
• Criteri di uscita: Filtro pubblico last_active < 7 days. L'iscritto è diventato attivo da solo e il lavoro del workflow è terminato.
• Metrica di retention: tasso di riattivazione a 60 giorni dall'ingresso nel workflow.

Una parola sul trigger. Questo è l'unico blueprint in questo articolo che utilizza un trigger basato sul pubblico anziché un trigger basato su eventi. I trigger basati sul pubblico in PushEngage Workflows elaborano in batch il set di iscritti corrispondenti solo al momento dell'avvio del workflow. Gli iscritti che diventano inattivi dopo l'avvio del workflow non vengono inclusi automaticamente e la modifica del filtro del pubblico su un workflow attivo non aggiunge nuovi iscritti. Se desideri un programma di riattivazione continuo, duplica il workflow con una pianificazione ricorrente (mensile o trimestrale) anziché aspettarti che un workflow basato sul pubblico a lunga esecuzione continui a raccogliere nuovi candidati. Questa è una fonte reale di ticket di supporto del tipo "perché questo iscritto non ha ricevuto il win-back?" nei team che non comprendono il tipo di trigger.

Segmentazione, test A/B e criteri di uscita all'interno del workflow

Il modello dominante nei risultati di ricerca della pagina uno per questa parola chiave è elencare la segmentazione, i test A/B e le ore di silenzio come "best practice": proiettili generici alla fine dell'articolo, separati dalla campagna che li utilizza. Questa è la cornice sbagliata. Queste non sono best practice che siedono accanto al workflow. Sono il workflow.

Ecco lo stesso insieme di concetti, inquadrati come best practice rispetto a inquadrati come nodi del workflow:

Concetto	Inquadramento best practice (sbagliato)	Inquadramento nodo-flusso (corretto)
Segmentazione RFM	“Segmenta la tua lista prima di inviare”	Un nodo DECISIONE che controlla la recenza, la frequenza e il valore monetario, quindi instrada gli iscritti ad alto RFM su un percorso diverso rispetto a quelli a basso RFM. Il post sulla segmentazione di PushEngage copre le definizioni dei bucket RFM che alimentano questo nodo.
Test A/B	“Testa sempre il tuo testo A/B”	Un nodo SPLIT_PATH con allocazione percentuale 50/50, iscritti bilanciati per percorso e un campo winner_edge_id che promuove il vincitore al 100% una volta che il test raggiunge la significatività
Ore di silenzio	“Non inviare alle 3 del mattino”	Un'opzione a livello di workflow con start_at, end_at, timezone e un'impostazione fallback che skipa l'invio o lo reschedulea a un minuto dopo la fine delle ore di silenzio
Criteri di uscita	“Smetti di inviare a chi ha acquistato”	Una regola a livello di workflow che controlla l'iscritto rispetto a un filtro del pubblico o a un obiettivo attivato prima di ogni nodo e annulla il workflow se corrisponde

La differenza è importante perché le proiettili di best practice sono facili da approvare e difficili da applicare. I nodi del workflow vengono applicati dal motore stesso. La DECISIONE viene eseguita ogni volta. Lo SPLIT_PATH bilancia ogni iscritto. Il fallback delle ore di silenzio si attiva senza che nessuno si ricordi di controllare l'ora. La regola di uscita annulla il workflow indipendentemente dal fatto che il proprietario della campagna presti attenzione o meno.

Per il blueprint di abbandono del carrello sopra, ciò significa che nel momento in cui un iscritto acquista gli articoli abbandonati, la regola di uscita si attiva, il workflow viene annullato per quell'iscritto e i promemoria secondo e terzo non vengono più inviati. Nessun ticket di supporto, nessuna email dalle finanze, nessuna campagna di scuse. Il workflow si è interrotto perché il motore aveva una regola che gli diceva di fermarsi.

Orchestrazione multicanale: un flusso di lavoro, quattro canali

La maggior parte delle piattaforme di notifiche push sono strumenti a canale singolo. Alcuni sono a due canali. La domanda a cui non possono rispondere bene è quella a cui un team di retention di medie dimensioni deve effettivamente rispondere: dato lo stato di questo abbonato, quale canale dovrebbe essere attivato? Web push se ha acconsentito. Email se ha rifiutato il web push. WhatsApp se il valore del carrello è superiore a $ 200. Live chat se l'abbonato è attualmente sul sito.

Quell'albero decisionale è un singolo flusso di lavoro di automazione delle notifiche push multicanale, non quattro campagne in quattro strumenti. Con i flussi di lavoro di PushEngage, un percorso di abbandono del carrello può essere composto in questo modo:

• INIZIO: evento cart_abandoned
• ATTENDI: 1 ora
• NODO DECISIONALE 1: l'abbonato è iscritto al web push?
  • Percorso SÌ: AZIONE, invia promemoria web push
  • Percorso NO: continua alla prossima decisione
• ATTENDI: 30 minuti dopo il web push (o immediatamente, se non è stato inviato alcun push)
• NODO DECISIONALE 2: l'abbonato ha cliccato sul web push, o non è iscritto al web push?
  • Se il web push è stato inviato ed è stato cliccato: ESCI (lascia che il flusso del carrello finisca)
  • Se il web push è stato inviato e non è stato cliccato, o nessun web push: continua
• NODO DECISIONALE 3: valore del carrello superiore a $ 200?
  • Percorso SÌ: AZIONE, invia messaggio WhatsApp tramite l'azione SendPushNotification sul canale WhatsApp
  • Percorso NO: AZIONE, invia email tramite una richiesta HTTP al tuo ESP
• ESCI all'obiettivo purchase

Quattro canali, un flusso di lavoro, un set di criteri di uscita, un'identità di abbonato. Lo stesso responsabile della retention che in precedenza non poteva orchestrare questo senza tre accessi a fornitori e un flusso Zapier ora può comporlo all'interno di un unico flusso di lavoro che il motore applica.

Fare la stessa cosa su strumenti separati significa sei sincronizzazioni tra piattaforme, due motori di segmentazione che non concordano su chi conta come "abbonato VIP", e nessuna singola attribuzione dei ricavi perché ogni strumento riporta le proprie conversioni. Farlo all'interno di un unico motore di flusso di lavoro significa un'identità di abbonato, un set di logica decisionale e un report del funnel. Per saperne di più su come push ed email lavorano insieme all'interno di un unico piano di retention, vedi orchestrazione multicanale push ed email.

Questo è il differenziatore che non ha un analogo nei risultati dominanti della prima pagina. Nessuno dei primi quindici risultati per questa parola chiave descrive un flusso di lavoro cross-channel come un singolo oggetto. Trattano tutti il push come argomento e l'email come confronto.

La matematica della retention: ricavi per flusso di lavoro, per canale, per notifica

Un flusso di lavoro che non puoi difendere alla prossima revisione del P&L è un flusso di lavoro che viene eliminato. Il lavoro del responsabile della retention è mostrare, in dollari, cosa ha prodotto ogni voce. La maggior parte degli articoli "notifiche push automatiche per l'e-commerce" si ferma al tasso di clic. Non è abbastanza. La metrica corretta sono i ricavi recuperati per abbonato, per flusso di lavoro, per canale.

I flussi di lavoro di PushEngage tracciano tre numeri in ogni nodo:

• Utenti in coda: iscritti in attesa in questo nodo (tipicamente un WAIT o un riprogrammazione per orari di silenzio)
• Utenti completati: iscritti che hanno superato questo nodo
• Utenti usciti: iscritti che hanno abbandonato il flusso di lavoro in questo nodo, perché i criteri di uscita sono stati soddisfatti o perché si sono disiscritti

Ecco come appaiono le analisi a livello di nodo per un flusso di lavoro attivo di carrello abbandonato (numeri illustrativi, tratti da un elenco realistico di 200.000 iscritti):

Nodo	In coda	Completato	Uscito	Note
START (carrello_abbandonato)	0	12,400	320	320 iscritti hanno soddisfatto i criteri di uscita all'inizio del flusso di lavoro (acquistato tra l'evento del carrello e la scansione del flusso di lavoro)
ATTENDI 1 ora	180	11,900	320	Profondità normale della coda
AZIONE: promemoria n. 1	0	11,900	0	Notifica inviata
ATTENDI 24 ore	240	9,800	1,860	Alto numero di uscite: 1.860 iscritti hanno acquistato dopo il promemoria n. 1
DECISIONE: carrello ancora abbandonato	0	9,800	0	Tutti gli iscritti rimanenti hanno ancora il carrello aperto
AZIONE: promemoria n. 2 (sconto 10%)	0	9,800	0	Notifica inviata con sconto
ATTENDI 48 ore	90	6,300	3,410	Altri 3.410 acquisti hanno innescato l'uscita
AZIONE: promemoria finale (sconto 20%)	0	6,300	0	Notifica finale
FINE	n.d.	6,300	n.d.	6.300 iscritti non hanno acquistato

In questo funnel, 5.270 iscritti (1.860 + 3.410) hanno acquistato mentre erano all'interno del flusso di lavoro, un tasso di recupero carrello del 42,5%. Le due attese (24h e 48h) sono i nodi con il maggior numero di uscite nel funnel, che è il modello previsto: le decisioni di tempo per l'acquisto avvengono nelle finestre di attesa, non nelle finestre di azione. Se il tuo flusso di lavoro mostra il modello inverso, con alte uscite nei nodi di azione e basse uscite nei nodi di attesa, la tua tempistica è sbagliata e le attese dovrebbero essere accorciate.

La matematica della retention deve anche affrontare i costi. Le notifiche push non costano nulla per invio una volta che l'iscritto ha dato il consenso. I costi delle email dipendono dal tuo ESP, ma con un elenco di 200.000 iscritti con una configurazione tipica di Klaviyo o Bloomreach, un singolo invio di carrello abbandonato costa diverse centinaia di dollari in utilizzo misurato (si applicano i termini del tuo contratto).

Un'automazione di notifiche push per carrello abbandonato push-first che recupera carrelli al 42% può raggiungere lo stesso numero di entrate recuperate di un flusso di lavoro push e email al 38%, a un costo materialmente inferiore. Esegui i calcoli sulla tua dimensione dell'elenco e sul contratto ESP. Il punto è che push, app push e WhatsApp non comportano il costo per invio che ha l'email, e il compito del flusso di lavoro è utilizzare il canale più economico per primo ogni volta che lo stato dell'iscritto lo consente.

Quando la voce di riga è difendibile (questo flusso di lavoro ha recuperato X $ in carrelli a un costo totale di Y $), la conversazione sul budget è breve.

Crealo in PushEngage Workflows

Ogni blueprint in questo articolo corrisponde direttamente ai componenti di PushEngage Workflows. Ecco la corrispondenza per i cinque blueprint sopra:

Progetto	Tipi di nodo utilizzati	Tipi di azione utilizzati	Opzione del flusso di lavoro
Serie di benvenuto	AVVIO, ATTENDI, DECISIONE, AZIONE, FINE	SendPushNotification, AddSegment	Tipo di esecuzione: Singolo
Abbandono della navigazione	INIZIO, ATTENDI, DECISIONE, AZIONE, USCITA	SendPushNotification	Tipo di esecuzione: Multiplo Parallelo
Escalation abbandono carrello	AVVIO, ATTENDI, DECISIONE, AZIONE, FINE	SendPushNotification	Tipo di esecuzione: Multiplo Parallelo; esci al raggiungimento dell'obiettivo acquisto
Richiesta di recensione post-acquisto	INIZIO, ATTENDI, DIVIDI_PERCORSO, AZIONE, FINE	SendPushNotification, HttpRequest	Tipo di esecuzione: Multiplo Sequenziale; orario di silenzio dalle 22:00 alle 8:00, riprogrammazione fallback
Recupero clienti	INIZIO, AZIONE, ATTENDI, DECISIONE, FINE	SendPushNotification, AddSegment	Tipo di esecuzione: Singolo; trigger basato sul pubblico

Il motore Workflows include oltre 60 modelli predefiniti che coprono ciascuno di questi flussi. Ogni modello è un punto di partenza. Ogni blueprint sopra può essere installato in meno di cinque minuti su Shopify, Shopify Plus, WooCommerce, BigCommerce o Magento all'interno del costruttore di flussi di lavoro per notifiche push di PushEngage.

La funzionalità Workflows copre anche la logica decisionale e i passaggi di personalizzazione che rendono possibile il routing multicanale nella sezione precedente e supporta gli undici tipi di azione che ti consentono di fare più che inviare una notifica: aggiornare gli attributi degli iscritti, attivare webhook al tuo CRM, avviare flussi di lavoro downstream o interromperne di conflittuali.

Per una visione più ampia di come questi flussi di lavoro si inseriscono in un programma completo di fidelizzazione e-commerce, il post hub delle notifiche push e-commerce copre i tipi di campagna che questi blueprint implementano.

Il piano gratuito ti offre 200 iscritti, tutti e quattro i canali (web push, app push, WhatsApp e live chat) e il motore Workflows completo fin dal primo giorno. Questo è sufficiente per provare il canale prima di inserirlo in una linea di budget.

Cosa cambia questo

Se prendi una cosa da questo articolo, prendi questa: l'automazione delle notifiche push per l'e-commerce è architettura del flusso di lavoro, non un insieme di campagne attivate. Il percorso di abbandono del carrello che termina con l'acquisto, la serie di benvenuto che si ramifica in base al comportamento del primo acquisto e l'orchestrazione cross-channel che sceglie il canale più economico e valido per ogni iscritto hanno tutti la stessa forma.

Un START, alcuni WAIT, alcune DECISIONI, alcune AZIONI, un EXIT. Sei trigger standalone non possono farlo. Un motore di flusso di lavoro può. La matematica della fidelizzazione si accumula da lì.

Inizia con il piano gratuito per implementare il primo blueprint in meno di un'ora.