Campagne Push Attivate: Guida ai flussi di lavoro contestuali

È la seconda settimana del trimestre e la tua dashboard di retention mostra sei trigger "automatizzati" in esecuzione, tutti verdi. Il trigger di abbandono del carrello continua a essere attivato per gli iscritti che hanno già pagato. Il ripristino si sovrappone all'avviso di riduzione del prezzo per lo stesso cliente perso. La serie di benvenuto invia notifiche indipendentemente dal suggerimento del primo acquisto. La richiesta di recensione post-acquisto arriva agli iscritti che hanno restituito l'ordine ieri.

Ognuna delle sei campagne push attivate è una pipeline che punta alla stessa lista di iscritti, ognuna fingendo che le altre cinque non esistano. Il tasso di acquisto ripetuto ha smesso di muoversi dodici mesi fa e nessuno nel team è in grado di attribuire ricavi per trigger perché i trigger non condividono lo stato.

Questa è la realtà operativa nella maggior parte degli stack di retention di medie dimensioni. Il problema non è la strategia. La strategia va bene. Il problema è l'architettura. Una notifica attivata nel 2024 era un singolo messaggio che veniva attivato da un singolo evento. Nel 2026, quella primitiva non è sufficiente. Il percorso deve ricordare ciò che ha fatto l'iscritto, ramificarsi su di esso e uscire quando converte.

Questo articolo presenta il caso architetturale. Definisce il confine tra notifiche push broadcast, attivate e contestuali, illustra la differenza tra trigger di eventi e trigger di pubblico, nomina i sei tipi di nodi che trasformano un singolo trigger in un flusso di lavoro contestuale e presenta tre modelli di migrazione che consolidano sei trigger autonomi in tre percorsi contestuali con criteri di uscita condivisi e analisi per flusso di lavoro.

Contestuale, attivato, broadcast: tre primitive, non una

Tre primitive sono alla base di ogni programma di notifiche push. La maggior parte dei team le raggruppa in un unico contenitore chiamato "campagne", che è dove inizia il problema architetturale.

Broadcast. La stessa notifica viene inviata all'intero pubblico corrispondente, in programma. Saldi lampo a mezzogiorno. Avviso nuova collezione il giorno del lancio. Broadcast è la primitiva giusta per annunci a tempo limitato in cui ogni destinatario riceve lo stesso payload. È la primitiva sbagliata per qualsiasi cosa dipenda dallo stato dell'iscritto.

Attivato. Una singola notifica viene attivata quando un singolo evento viene attivato. L'iscritto abbandona un carrello, viene attivata la notifica di abbandono del carrello. L'iscritto visualizza una pagina prodotto, viene attivata la notifica di navigazione. L'iscritto acquista, viene attivata la notifica post-acquisto. Il trigger non ha memoria. Non sa cosa è successo cinque minuti fa o cosa è programmato per martedì prossimo. Ogni trigger è una pipeline ignara di ogni altro trigger.

Contestuale. Un flusso di lavoro utilizza il trigger come punto di ingresso e quindi si adatta allo stato dell'iscritto. Lo stesso evento di abbandono del carrello avvia un percorso multi-step: un'attesa di un'ora, un primo promemoria, un'attesa di 24 ore, una decisione che verifica se il carrello è ancora aperto, un secondo promemoria con uno sconto, un'attesa di 48 ore, un terzo promemoria e una regola di uscita che annulla il flusso di lavoro nel momento in cui l'iscritto acquista. La campagna è il flusso di lavoro, non il trigger. Le notifiche push contestuali sono il modo in cui i messaggi attivati si comportano una volta che l'architettura si è aggiornata.

I tre primitivi si mappano chiaramente a tre carichi di lavoro. Utilizza questa tabella quando esamini il tuo stack attuale.

Funzionalità	Trasmissione	Attivato	Contestuale
Stato per iscritto	No	No	Sì
Rami basati sul comportamento	No	No	Sì
Criteri di uscita	No	No	Sì
Routing multicanale all'interno di una campagna	No	No	Sì
A/B integrato (ora di invio, copia, canale)	No	No	Sì
Carico di lavoro corretto	Vendite flash, annunci di lancio	Ping transazionali una tantum (basso volume)	Percorsi del ciclo di vita (benvenuto, carrello, recupero, rinnovo)

La maggior parte dei programmi del ciclo di vita necessita di contestualità. La maggior parte dei team spedisce messaggi attivati. Questo divario è l'argomento di questo articolo. I flussi di lavoro di automazione del marketing che spediscono percorsi contestuali non assomigliano a un elenco più lungo di trigger; assomigliano a un insieme più piccolo di percorsi multi-step composti da un vocabolario condiviso. I flussi di lavoro di notifiche push che desideri realmente sono tre percorsi contestuali, non nove trigger.

I trigger di eventi e i trigger di pubblico si comportano in modo molto diverso

Prima dell'anatomia del nodo, un punto tassonomico che quasi ogni articolo su questo argomento sbaglia. Un "trigger" nei flussi di lavoro di notifiche push non è un singolo primitivo. Sono due primitivi che dall'esterno sembrano simili e si comportano in modo molto diverso all'interno.

I trigger di eventi vengono attivati per iscritto in base a un evento reale. Gli eventi supportati in PushEngage Workflows includono PushEngage.Subscriber.Added, PushEngage.Subscriber.AddSegment, PushEngage.Subscriber.RemoveSegment, PushEngage.Subscriber.UpdateField, PushEngage.Subscriber.UpdateAttribute, PushEngage.Goal.Tracked e PushEngage.CustomEvent. Quando l'evento viene attivato, il sistema valuta i flussi di lavoro attivi, controlla i criteri del filtro eventi, controlla le regole di uscita e accoda il flusso di lavoro corrispondente per quell'iscritto. Il divario tra trigger e accodamento è di secondi. I trigger di eventi sono il primitivo giusto per qualsiasi campagna reattiva: abbandono del carrello, abbandono della navigazione, follow-up acquisto, benvenuto all'iscrizione al segmento. Le campagne push attivate da eventi sono il caso dominante nell'eCommerce, nell'onboarding SaaS e in qualsiasi programma con segnali in tempo reale.

I trigger basati sul pubblico attivano un filtro in un orario programmato. Il filtro seleziona gli iscritti che corrispondono a criteri specifici, come last_active > 30 days, loyalty_tier = gold, o city = New York AND segments includes "vip". Il poller di pianificazione recupera il set di iscritti corrispondenti in batch da 1000, scaglionando l'esecuzione da 15 secondi a 2 minuti, e crea un'istanza di workflow per ogni iscritto. I trigger basati sul pubblico sono lo strumento giusto per campagne di riattivazione, campagne di compleanno, promozioni geografiche e qualsiasi programma in cui il set è definito da attributi piuttosto che da eventi.

Le differenze contano operativamente, non solo concettualmente:

Aspetto	Trigger basato su eventi	Trigger basato sul pubblico
Inizio	In tempo reale all'evento dell'iscritto	Programmato tramite poller
Velocità	Entro pochi secondi	In batch, ritardo di 1-2 minuti
Selezione iscritti	Un iscritto per evento	Selezione in blocco solo all'avvio del workflow
Nuovi iscritti dopo l'avvio	Inclusi automaticamente al prossimo evento	NON inclusi automaticamente dopo l'avvio del workflow
Modifica del filtro dopo l'avvio	N/D	La modifica del filtro NON aggiunge nuovi iscritti
Dati evento disponibili	Sì (per sostituzione variabile)	No

La terza riga è l'insidia. Un workflow basato sul pubblico seleziona il suo set di iscritti una sola volta, all'avvio del workflow. Gli iscritti che diventano inattivi dopo l'avvio del workflow non vengono aggiunti automaticamente. La modifica del filtro del pubblico su un workflow attivo non attira nuovi candidati. Un team di fidelizzazione che invia un workflow "recupero per iscritti inattivi da oltre 30 giorni" e lo lascia in esecuzione per novanta giorni vedrà lo stesso gruppo fisso per tutti i novanta giorni, anche se ogni giorno nuovi iscritti superano la soglia dei 30 giorni.

La risposta architetturale è duplicare il workflow del pubblico con una pianificazione ricorrente, mensile o settimanale, in modo che ogni duplicato catturi i candidati che hanno superato la soglia dall'ultima esecuzione. Questa è una nota operativa di una riga nella documentazione e una fonte ricorrente di ticket di supporto "perché questo iscritto non ha ricevuto la campagna?" nei team che trattano i trigger del pubblico come trigger di eventi.

I sei nodi che trasformano un trigger in una campagna contestuale

Una volta che il trigger si attiva, il workflow stesso è composto da sei tipi di nodi. Il vocabolario è abbastanza piccolo da imparare in cinque minuti e abbastanza grande da comporre qualsiasi campagna contestuale che un team di fidelizzazione abbia mai voluto spedire.

START. Il punto di ingresso. Un nodo START definisce il trigger (basato su eventi o basato sul pubblico) e i criteri del filtro. Un workflow ha esattamente un START. Il punto di ingresso determina la tassonomia del trigger dalla sezione precedente e imposta il contesto dei dati evento che i nodi downstream possono leggere.

ATTENDI. Un ritardo. Un nodo ATTENDI trattiene l'iscritto per un periodo di tempo specificato (minuti, ore, giorni) o fino a un'ora specifica del calendario. Le attese sono il modo in cui un flusso di lavoro rispetta lo stato dell'iscritto e il fuso orario dell'iscritto. Il flusso di lavoro può attendere un'ora per un promemoria di carrello abbandonato, tre giorni per una presentazione di funzionalità in una serie di benvenuto, o fino alle 10:00 di martedì nel fuso orario locale dell'iscritto per un invio durante l'orario di lavoro. Le attese consentono anche di comporre un flusso a più passaggi senza inviare ogni messaggio nei primi sessanta secondi.

DECISIONE. Una biforcazione a due vie. Un nodo DECISIONE controlla un filtro evento o un filtro pubblico e instrada l'iscritto lungo il percorso SÌ o il percorso NO. L'iscritto ha acquistato? È ancora nel segmento degli abbandoni del carrello? Il suo livello di fedeltà è cambiato? I nodi DECISIONE sono il modo in cui le notifiche push comportamentali smettono di trattare ogni iscritto allo stesso modo e iniziano ad adattarsi a ciò che ogni iscritto ha effettivamente fatto. Gli operatori supportati includono uguale, diverso da, in, non in, maggiore di, minore di, ed esiste, che è sufficiente per esprimere qualsiasi logica decisionale di cui un team di fidelizzazione ha bisogno.

SPLIT_PATH. Una diramazione basata su percentuali per test A/B. Un nodo SPLIT_PATH instrada gli iscritti attraverso due o più percorsi in base a percentuali configurate: 50/50 per un test a due vie, 33/33/34 per un test di orario di invio a tre vie, 90/10 per un gruppo di esclusione. Il sistema utilizza un algoritmo di bilanciamento del carico che instrada ogni nuovo iscritto al percorso meno utilizzato, mantenendo la distribuzione accurata anche con campioni di piccole dimensioni. Una volta che il test raggiunge la significatività, imposta winner_edge_id e il flusso di lavoro promuove il 100% del traffico alla variante vincente senza ricostruire il flusso di lavoro.

AZIONE. Il lavoro vero e proprio. I nodi AZIONE fanno più che inviare una notifica push. I flussi di lavoro PushEngage supportano undici tipi di azione: SendPushNotification, AddSegment, RemoveSegment, UpdateField, UpdateAttribute, Update (combinato), HttpRequest, CustomEvent.Send, SendTriggerCampaignEvent, Workflow.Start e Workflow.Stop. I quattro più comuni nei programmi di fidelizzazione sono SendPushNotification, AddSegment (etichettare l'iscritto come convertito, onboardato o a rischio di abbandono), UpdateAttribute (incrementare un contatore di fedeltà o impostare una data dell'ultimo acquisto) e HttpRequest (sincronizzare lo stato con un CRM, attivare un avviso Slack per un lead di alto valore o chiamare un servizio downstream).

FINE / USCITA. Il terminale. I nodi FINE ed USCITA segnano il completamento del workflow e aggiornano le analisi. FINE è la conclusione naturale. USCITA è tipicamente posizionato sul percorso NO di una decisione quando l'iscritto non è idoneo, o su un ramo di percorso diviso progettato come gruppo di controllo. Il sistema supporta anche criteri di uscita a livello di workflow: un audience_filter o trigger_event che annulla il workflow attivo prima che ogni nodo venga eseguito. La regola di uscita si attiva indipendentemente dal nodo in cui si trova attualmente l'iscritto. Questo è ciò che impedisce al workflow di abbandono del carrello di inviare promemoria agli iscritti che hanno già acquistato.

Ogni campagna contestuale in questo articolo è composta da questi sei elementi. I modelli di migrazione sottostanti si leggono velocemente una volta condiviso il vocabolario.

Tre modelli di migrazione: sei trigger autonomi diventano tre flussi di lavoro contestuali

La maggior parte degli stack di retention per il mercato medio ha tra quattro e otto trigger standalone in esecuzione. Il modello è coerente: notifica di benvenuto, spinta al primo acquisto, abbandono del carrello, abbandono della navigazione, richiesta di recensione post-acquisto, recupero, riattivazione, VIP inattivo. Ognuno di questi è un trigger separato con la propria copia, il proprio proprietario e le proprie analisi. Nessuno di loro è a conoscenza degli altri. Gli stessi tre workflow contestuali possono generare lo stesso fatturato con un terzo dello spazio.

Modello 1 — Consolidamento dell'onboarding

Accorpa la serie di benvenuto e la spinta al primo acquisto in un unico workflow con una decisione sullo stato dell'acquisto.

• INIZIO: Evento PushEngage.Subscriber.Added
• Tipo di esecuzione: Singolo (cooldown di 90 giorni dopo il completamento)
• Flusso: ATTENDI 1 giorno → AZIONE invia notifica di benvenuto → ATTENDI 3 giorni → DECISIONE: l'iscritto ha acquistato? → percorso SÌ: AZIONE invia ringraziamento + AZIONE AddSegment a customers + FINE → percorso NO: AZIONE invia sconto del 10% per il primo acquisto → ATTENDI 4 giorni → DECISIONE: l'iscritto ha acquistato? → percorso SÌ: AZIONE invia ringraziamento + FINE → percorso NO: AZIONE invia spinta finale + FINE
• Criteri di uscita: Nessuno a livello di workflow; i rami decisionali gestiscono l'iscritto convertito
• Sostituisce: Trigger di benvenuto + trigger di primo acquisto (2 trigger → 1 workflow)

Lo stato condiviso è l'intero punto. La terza notifica viene inviata solo agli iscritti che non si sono convertiti entro il quarto giorno. Il trigger del primo acquisto nell'architettura precedente veniva attivato per ogni nuovo iscritto, inclusi quelli che acquistavano nella loro prima sessione. Il workflow smette di infastidirli.

Modello 2 — Catena carrello-recensione

Accorpa il recupero dell'abbandono del carrello e la richiesta di recensione post-acquisto in un unico workflow con un passaggio di concatenamento del workflow.

• INIZIO: Evento personalizzato cart_abandoned
• Tipo di esecuzione: Multiplo Parallelo (ogni carrello abbandonato è la sua istanza)
• Flusso: ATTENDI 1 ora → AZIONE promemoria n. 1 → ATTENDI 24 ore → DECISIONE: carrello ancora abbandonato? → percorso SÌ: AZIONE promemoria n. 2 con 10% → ATTENDI 48 ore → DECISIONE: carrello ancora abbandonato? → percorso SÌ: AZIONE promemoria finale con 20% → FINE
• Criteri di uscita (livello workflow): Goal.Tracked = purchase corrispondente a cart_id dall'evento trigger. Nel momento in cui l'abbonato acquista, il workflow viene annullato.
• Passaggio di consegne: All'uscita a causa di un acquisto, il sistema attiva PushEngage.Workflow.Start rivolto al workflow di richiesta recensione. Il workflow di recensione si avvia solo per gli abbonati che hanno effettivamente acquistato. Il percorso di uscita per mancato acquisto salta completamente il passaggio di consegne.
• Sostituisce: Trigger carrello + trigger post-acquisto recensione + ticket di supporto per richieste di recensione che raggiungono abbonati che non hanno mai acquistato (3 problemi → 1 workflow)

La concatenazione tramite Workflow.Start è la risposta architetturale alla progressione del ciclo di vita. Invece di due trigger che si attivano indipendentemente e si sovrappongono sugli stessi abbonati, l'uscita all'acquisto del workflow del carrello è ciò che avvia il workflow di recensione. La recensione viene attivata solo per gli abbonati convertiti. Il carrello non viene mai attivato dopo la conversione. Il passaggio di consegne è imposto dal motore.

Modello 3 — Consolidamento del ripristino del coinvolgimento

Accorpa le campagne di recupero, riattivazione e VIP inattivi in un unico workflow con un trigger di pubblico e tre rami decisionali.

• AVVIO: Filtro pubblico last_active > 30 giorni
• Tipo di esecuzione: Singolo (un tentativo di riattivazione per abbonato per finestra di 90 giorni)
• Flusso: DECISIONE: livello fedeltà? → Ramo Gold: AZIONE invia "ci manchi, VIP" con offerta del 20% → Ramo Silver: AZIONE invia "ci manchi" con offerta del 10% → Ramo senza livello: AZIONE invia standard "ci manchi" con offerta di spedizione gratuita → ATTENDI 5 giorni → DECISIONE (per ramo): l'abbonato ha interagito o visitato il sito? → Percorso SÌ: AZIONE AddSegment a re-engaged + FINE → Percorso NO: AZIONE invia "ultima possibilità" con offerta più vantaggiosa + FINE
• Criteri di uscita (livello workflow): Filtro pubblico last_active < 7 giorni. L'abbonato è diventato attivo autonomamente e il lavoro del workflow è terminato.
• Sostituisce: Trigger di recupero + trigger di riattivazione + trigger VIP inattivi (3 trigger → 1 workflow)
• Nota operativa: Come da insidia del trigger di pubblico nella sezione precedente, questo workflow non include automaticamente gli abbonati che superano la soglia dei 30 giorni dopo l'avvio del workflow. Duplica il workflow mensilmente in modo che ogni duplicato catturi i nuovi candidati. Un singolo workflow di pubblico a lunga esecuzione è il primitivo errato qui.

Dopo queste tre migrazioni, il team di fidelizzazione gestisce tre percorsi contestuali invece di sei (o otto) trigger autonomi. Il volume totale dei messaggi push rimane approssimativamente lo stesso. L'eccesso di messaggistica scompare, poiché i criteri di uscita condivisi e i rami decisionali interrompono il workflow quando lo stato dell'abbonato non corrisponde più. L'analisi passa da "sei dashboard che non riesco a conciliare" a "tre funnel che posso difendere". Questo è l'aspetto delle campagne push attivate da eventi quando crescono.

Cosa fanno i flussi di lavoro contestuali che i trigger autonomi non possono fare

Quattro funzionalità esistono all'interno di un flusso di lavoro contestuale e non possono essere composte tra trigger standalone. Ognuna è una vera fonte di entrate o risparmi.

Criteri di uscita cross-workflow. Un trigger standalone si attiva quando l'evento si verifica, punto. All'interno di un flusso di lavoro, la regola di uscita si attiva indipendentemente dal nodo in cui si trova l'abbonato. Il flusso di lavoro di abbandono del carrello esce all'acquisto. Il flusso di recupero esce alla riattivazione. Il flusso di rinnovo esce al rinnovo anticipato. Il trigger a cui nessuno ha detto di fermarsi è il flusso di lavoro che definisce una regola di uscita.

Instradamento multicanale all'interno di un unico flusso di lavoro. Con strumenti separati a canale singolo, "invia push web, passa all'email, scala a WhatsApp" richiede tre accessi a fornitori, due motori di segmentazione e almeno un flusso Zapier. All'interno di un unico motore di flusso di lavoro, si tratta di tre nodi AZIONE con due nodi DECISIONE tra di essi, che condividono un'unica identità di abbonato e un unico set di criteri di uscita. Per un approfondimento, vedere il post sull'orchestrazione push e email multicanale.

Orari di silenzio con fallback reschedule. Le notifiche push che atterrebbero alle 3 del mattino nel fuso orario locale dell'abbonato verranno trattenute fino alle 8:01 se gli orari di silenzio sono configurati con reschedule come fallback. L'alternativa, skip, elimina silenziosamente la notifica e non aggiorna le statistiche delle notifiche per l'azione saltata. Per la maggior parte dei team di retention, reschedule è l'impostazione predefinita corretta perché le statistiche perse significano attribuzione delle entrate perse. Le notifiche push contestuali che un team di retention desidera effettivamente inviare rispettano i fusi orari degli abbonati senza scomparire dal funnel.

Concatenamento di flussi di lavoro. Le azioni Workflow.Start e Workflow.Stop rendono la progressione del ciclo di vita un'architettura reale. Il flusso di lavoro di benvenuto termina, il che avvia il flusso di lavoro di coinvolgimento. Il flusso di lavoro del carrello esce all'acquisto, il che avvia il flusso di lavoro di revisione. Rispetto a una cartella di trigger che si attivano tutti indipendentemente, questa è una macchina a stati: un grafo di flussi di lavoro, ognuno con la propria condizione di ingresso, condizione di uscita e passaggio alla fase successiva. I trigger non si conoscono a vicenda. I flussi di lavoro sì.

Analisi per flusso di lavoro: come leggere l'imbuto

Un flusso di lavoro che non puoi difendere alla prossima revisione del conto economico verrà eliminato. PushEngage Workflows traccia tre numeri per ogni nodo (queued_users, completed_users, exited_users) più i totali a livello di flusso di lavoro per totali entrati, attivi al momento, completati ed usciti. Il compito del responsabile della retention è leggere questo funnel e comunicare alla finanza cosa ha prodotto ogni voce.

Ecco come appaiono le analisi a livello di nodo per la catena carrello-revisione dal Modello 2 sopra. Numeri illustrativi, tratti da un elenco realistico di 200.000 abbonati con un tasso di abbandono del carrello del 6% mensile.

Nodo	In coda	Completato	Uscito	Note
START (carrello_abbandonato)	0	12,400	320	320 abbonati hanno soddisfatto i criteri di uscita all'inizio del flusso di lavoro (acquistato tra l'evento 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	Inviato
ATTENDI 24 ore	240	9,800	1,860	1.860 abbonati hanno acquistato dopo il promemoria n. 1 (uscita all'obiettivo acquisto)
DECISIONE: carrello ancora abbandonato	0	9,800	0	Ramo valutato
AZIONE: promemoria n. 2 (10%)	0	9,800	0	Inviato
ATTENDI 48 ore	90	6,300	3,410	3.410 iscritti acquistati dopo il promemoria n. 2
AZIONE: promemoria finale (20%)	0	6,300	0	Inviato
FINE	n.d.	6,300	n.d.	6.300 iscritti non hanno acquistato; il flusso di revisione non è concatenato per questi
Workflow.Start → flusso di revisione	n.d.	5,270	n.d.	Attivato per i 5.270 iscritti (1.860 + 3.410) che hanno acquistato

I 5.270 passaggi concatenati sono la nuova metrica che questa architettura rivela. Il flusso del carrello ha recuperato un tasso di carrello del 42,5% (5.270 su 12.400 inseriti) e solo quei 5.270 iscritti ricevono il flusso di richiesta di revisione. La vecchia architettura inviava la richiesta di revisione a tutti coloro che avevano acquistato, inclusi iscritti che non avevano mai abbandonato un carrello, iscritti che avevano restituito l'ordine e iscritti che avevano già inviato una recensione. La correzione architetturale è piccola. I risparmi sulla sovra-messaggistica sono grandi.

Due pattern di collo di bottiglia vale la pena conoscere. Un nodo ad alta uscita (come i due nodi WAIT sopra) è il flusso che fa il suo lavoro: gli iscritti acquistano durante le finestre di attesa, i criteri di uscita si attivano, il promemoria successivo non viene mai inviato. Il pattern inverso, alte uscite sui nodi di azione abbinate a basse uscite sui nodi di attesa, significa che la tempistica è sbagliata e le attese dovrebbero essere accorciate. Un nodo ad alta coda significa un blocco per le ore tranquille, un'attesa lunga o un ritardo del poller downstream; controllare la configurazione della tempistica prima di presumere che il flusso sia rotto.

Per un trattamento più approfondito specifico per l'eCommerce di questi pattern, il post di accompagnamento su cinque flussi di notifiche push per l'eCommerce illustra carrello, navigazione, post-acquisto, benvenuto e recupero come percorsi autonomi. L'hub delle notifiche push per l'eCommerce copre il panorama più ampio dei tipi di campagna, la sequenza di recupero dell'abbandono del carrello illustra la regolazione della cadenza per piattaforma e la panoramica delle notifiche push automatizzate presenta il vecchio elenco di tipi di automazione accanto a questa architettura di flusso.

La stessa forma analitica funziona in tutti i settori. SaaS ha un funnel di rinnovo e una conversione da prova a pagamento. Gli editori hanno un funnel di coinvolgimento degli articoli e un rientro nell'archivio. Il settore dei viaggi ha un funnel di prenotazione e un flusso di avviso di calo prezzi. Le notifiche push comportamentali che un team SaaS utilizza per guidare la conversione da prova a pagamento sembrano strutturalmente identiche a quelle che un team di eCommerce utilizza per guidare la conversione da carrello a acquisto: un START su un evento in tempo reale, tre o quattro passaggi con rami decisionali, criteri di uscita sulla conversione, passaggio opzionale al flusso successivo. Il settore cambia i nomi dei trigger e il testo dell'offerta. L'architettura rimane.

Crealo in PushEngage Workflows

Ognuno dei tre pattern di migrazione sopra descritti si mappa direttamente ai componenti di PushEngage Workflows.

Pattern	Tipi di nodo utilizzati	Tipi di azione utilizzati	Opzione del flusso di lavoro	Punto di partenza del modello suggerito
Consolidamento onboarding	AVVIO, ATTENDI, DECISIONE, AZIONE, FINE	SendPushNotification, AddSegment	Tipo di esecuzione: Singolo	“Serie di benvenuto con ramo primo acquisto”
Catena carrello-revisione	AVVIO, ATTENDI, DECISIONE, AZIONE, FINE	SendPushNotification, Workflow.Start	Tipo di esecuzione: Multiplo Parallelo; criteri di uscita Goal.Tracked = purchase	“Escalation abbandono carrello”
Consolidamento riattivazione	START (pubblico), DECISIONE, AZIONE, ATTESA, FINE	SendPushNotification, AddSegment	Tipo di esecuzione: Singolo; trigger pubblico; duplicato mensile	“Riattivazione con offerta basata su livelli”

Il motore Workflows include oltre 60 modelli predefiniti che coprono ogni modello di migrazione sopra descritto. Ogni modello è un punto di partenza. I modelli vengono installati in meno di cinque minuti su Shopify, Shopify Plus, WooCommerce, BigCommerce e Magento all'interno del costruttore Workflows di PushEngage, o su qualsiasi stack SaaS, publisher o travel tramite l'SDK JavaScript e l'API degli eventi.

Il piano gratuito ti offre 200 iscritti, tutti i canali (web push, app push, WhatsApp e live chat) e il motore Workflows completo fin dal primo giorno. Questo è sufficiente per migrare uno dei tre modelli dal tuo attuale stack di trigger e dimostrare l'architettura prima di richiedere un budget. Inizia con il piano gratuito e implementa il primo workflow contestuale in meno di un'ora.

Se prendi una cosa da questo articolo, prendi questa: una campagna push attivata non è più la notifica. È il workflow. Sei trigger autonomi che funzionano in modo disconnesso sono sei pipeline puntate alla stessa lista di iscritti, ognuna ignara delle altre.

Tre workflow contestuali che funzionano con stato condiviso, rami decisionali, criteri di uscita e passaggi concatenati sono un percorso per iscritto, ramificato e delimitato. I workflow di marketing automation che producono un funnel difendibile per workflow e un tasso di riacquisto che si accumula non sono un elenco più lungo di trigger; sono un set più piccolo e più mirato di percorsi contestuali. L'architettura è la campagna. Il trigger è la porta.