Utlösare för push-kampanjer: Guide till kontextuella arbetsflöden

Det är andra veckan på kvartalet och din kundbehållnings-instrumentpanel visar sex "automatiserade" utlösare som körs, alla gröna. Utlösaren för övergiven kundvagn fortsätter att skickas till prenumeranter som redan har betalat. Återaktiveringen överlappar med prisnedgångsvarningen för samma bortfallna kund. Välkomstserien skickar aviseringar oberoende av den första köp-påminnelsen. Begäran om recension efter köp landar hos prenumeranter som returnerade ordern igår.

Var och en av de sex utlösarna för push-kampanjer är en pipeline som pekar på samma prenumerantlista, var och en låtsas att de andra fem inte existerar. Andelen återkommande köp slutade röra sig för tolv månader sedan och ingen i teamet kan tillskriva intäkter per utlösare eftersom utlösarna inte delar tillstånd.

Detta är den operativa verkligheten i de flesta mellanstora kundbehållnings-stackar. Problemet är inte strategi. Strategin är bra. Problemet är arkitektur. En utlöst avisering år 2024 var ett enda meddelande som utlöstes av en enda händelse. År 2026 räcker inte den primitiva funktionen. Resan måste komma ihåg vad prenumeranten gjorde, förgrena sig baserat på det och avslutas när de konverterar.

Den här artikeln gör det arkitektoniska fallet. Den definierar gränsen mellan sändnings-, utlösar- och kontextuella push-aviseringar, går igenom skillnaden mellan händelseutlösare och publikutlösare, namnger de sex nodtyperna som förvandlar en enda utlösare till ett kontextuellt arbetsflöde och levererar tre migreringsmönster som konsoliderar sex fristående utlösare till tre kontextuella resor med delade avslutningskriterier och analys per arbetsflöde.

Kontextuella, utlösare, sändning: tre primitiva funktioner, inte en

Tre primitiva funktioner ligger till grund för varje push-aviseringprogram. De flesta team kollapsar dem till en enda hink som kallas "kampanjer", vilket är där arkitekturproblemet börjar.

Sändning. Samma avisering går till hela den matchande publiken, schemalagd. Flash-försäljning vid middagstid. Ny kollektionsvarning på lanseringsdagen. Sändning är den rätta primitiva funktionen för tidsbegränsade meddelanden där varje mottagare får samma nyttolast. Det är fel primitiv funktion för allt som beror på prenumerantens tillstånd.

Utlöst. En enskild avisering skickas när en enskild händelse inträffar. Prenumeranten överger en kundvagn, aviseringen om övergiven kundvagn skickas. Prenumeranten besöker en produktsida, aviseringen om webbläsning skickas. Prenumeranten gör ett köp, aviseringen efter köpet skickas. Utlösaren har inget minne. Den vet inte vad som hände för fem minuter sedan eller vad som är planerat till nästa tisdag. Varje utlösare är en pipeline som är ovetande om alla andra utlösare.

Kontextuell. En arbetsflöde använder utlösaren som ingångspunkt och anpassar sig sedan efter prenumerantens tillstånd. Samma händelse för övergiven kundvagn startar en resa i flera steg: en timmes väntan, en första påminnelse, en 24-timmars väntan, ett beslut som kontrollerar om kundvagnen fortfarande är öppen, en andra påminnelse med rabatt, en 48-timmars väntan, en tredje påminnelse och en avslutningsregel som avbryter arbetsflödet i det ögonblick prenumeranten köper. Kampanjen är arbetsflödet, inte utlösaren. Kontextuella push-aviseringar är hur utlösta meddelanden beter sig när arkitekturen har kommit ikapp.

De tre grundelementen mappas rent till tre arbetsbelastningar. Använd den här tabellen när du granskar din nuvarande stack.

Funktion	Sändning	Utlöst	Kontextuell
Tillstånd per prenumerant	Nej	Nej	Ja
Grenar baserat på beteende	Nej	Nej	Ja
Avslutningskriterier	Nej	Nej	Ja
Flerkanalsdirigering inom en kampanj	Nej	Nej	Ja
Inbyggd A/B-testning (sändningstid, kopia, kanal)	Nej	Nej	Ja
Rätt arbetsbelastning	Flashförsäljningar, lanseringsmeddelanden	Engångstransaktionella ping (låg volym)	Livscykelresor (välkomst, kundvagn, återvinning, förnyelse)

De flesta livscykelprogram behöver kontextuella. De flesta team levererar utlösta. Det gapet är vad den här artikeln handlar om. Marknadsföringsautomationsarbetsflöden som levererar kontextuella resor ser inte ut som en längre lista med utlösare; de ser ut som en mindre uppsättning resor i flera steg som är sammansatta av ett delat vokabulär. Push-aviseringarbetsflödena du faktiskt vill ha är tre kontextuella resor, inte nio utlösare.

Händelseutlösare och publikutlösare beter sig mycket olika

Före nodanatomin, en taxonomipunkt som nästan alla artiklar om detta ämne får fel. En "utlösare" i push-aviseringarbetsflöden är inte ett enda grundelement. Det är två grundelement som ser likadana ut utifrån och beter sig mycket olika under ytan.

Händelseutlösare skickas per prenumerant vid en verklig händelse. De stödda händelserna i PushEngage Workflows inkluderar PushEngage.Subscriber.Added, PushEngage.Subscriber.AddSegment, PushEngage.Subscriber.RemoveSegment, PushEngage.Subscriber.UpdateField, PushEngage.Subscriber.UpdateAttribute, PushEngage.Goal.Tracked och PushEngage.CustomEvent. När händelsen inträffar utvärderar systemet aktiva arbetsflöden, kontrollerar kriterier för händelsefilter, kontrollerar avslutningsregler och köar det matchande arbetsflödet för den prenumeranten. Gapet mellan utlösare och kö är sekunder. Händelseutlösare är rätt grundelement för alla reaktiva kampanjer: övergiven kundvagn, övergiven webbläsning, uppföljning av köp, välkomnanden vid segmentanslutning. Händelseutlösta push-kampanjer är det dominerande fallet inom e-handel, SaaS-onboarding och alla program med realtidssignaler.

Målgruppsutlösare startar ett filter vid en schemalagd tidpunkt. Filtret väljer prenumeranter som matchar specifika kriterier, som last_active > 30 days, loyalty_tier = gold, eller city = New York AND segments includes "vip". Schemaläggningspoller hämtar den matchande prenumerantuppsättningen i batcher om 1000, fördröjer exekvering med 15 sekunder till 2 minuter och skapar en arbetsflödesinstans per prenumerant. Målgruppsutlösare är den rätta primitiva för återengagemang, födelsedagskampanjer, geografiska kampanjer och alla program där uppsättningen definieras av attribut snarare än av händelse.

Skillnaderna spelar roll operationellt, inte bara konceptuellt:

Aspekt	Händelseutlösare	Målgruppsutlösare
Initiering	Realtid vid prenumeranthändelse	Schemalagd via poller
Hastighet	Inom sekunder	Batchad, 1-2 minuters fördröjning
Val av prenumerant	En prenumerant per händelse	Massval endast vid start av arbetsflöde
Nya prenumeranter efter start	Automatiskt inkluderade vid nästa händelse	INTE automatiskt inkluderade efter att arbetsflödet har startat
Filterändring efter start	Ej tillämpligt	Att redigera filtret lägger INTE till nya prenumeranter
Händelsedata tillgänglig	Ja (för variabelersättning)	Nej

Den tredje raden är knepet. Ett målgruppsbaserat arbetsflöde väljer sin prenumerantuppsättning en gång, vid start av arbetsflödet. Prenumeranter som blir inaktiva efter att arbetsflödet har startat läggs inte till automatiskt. Att redigera målgruppsfiltret för ett aktivt arbetsflöde drar inte in nya kandidater. Ett retentionsteam som skickar ett arbetsflöde för "återaktivering av prenumeranter inaktiva 30+ dagar" och låter det köras i nittio dagar kommer att se samma fasta kohort under hela nittio dagar, även om nya prenumeranter passerar 30-dagarsgränsen varje dag.

Den arkitektoniska lösningen är att duplicera målgruppsarbetsflödet på ett återkommande schema, månadsvis eller veckovis, så att varje kopia fångar de kandidater som passerade tröskeln sedan den senaste körningen. Detta är en enradig operationell notering i dokumentationen och en återkommande källa till supportärenden om "varför fick inte den här prenumeranten kampanjen?" i team som behandlar målgruppsutlösare som händelseutlösare.

De sex noderna som förvandlar en utlösare till en kontextuell kampanj

När utlösaren väl har aktiverats, består själva arbetsflödet av sex nodtyper. Vokabulären är tillräckligt litet för att lära sig på fem minuter och tillräckligt stort för att komponera alla kontextuella kampanjer som ett retentionsteam någonsin har velat leverera.

START. Ingångspunkten. En START-nod definierar utlösaren (händelsebaserad eller målgruppsbaserad) och filterkriterierna. Ett arbetsflöde har exakt en START. Ingångspunkten bestämmer utlösarens taxonomi från föregående avsnitt och ställer in händelsedatakontexten som nedströmsnoder kan läsa.

VÄNTA. En fördröjning. En VÄNTA-nod håller prenumeranten under en specificerad tid (minuter, timmar, dagar) eller tills en specifik kalendertid. Väntetider är hur ett arbetsflöde respekterar prenumerantens status och tidszon. Arbetsflödet kan vänta en timme på en påminnelse om övergiven kundvagn, tre dagar på en funktionsintroduktion i en välkomstserie, eller tills tisdag kl. 10.00 i prenumerantens lokala tidszon för ett utskick under kontorstid. Väntetider låter dig också skapa en flerstegs-droppe utan att skicka alla meddelanden under de första sextio sekunderna.

BESLUT. En tvåvägsförgrening. En BESLUT-nod kontrollerar ett händelsefilter eller ett publikfilter och dirigerar prenumeranten antingen till JA-vägen eller NEJ-vägen. Har prenumeranten köpt? Är de fortfarande i segmentet för övergiven kundvagn? Har deras lojalitetsnivå ändrats? Beslutsnoder är hur beteendebaserade push-meddelanden slutar behandla alla prenumeranter lika och börjar anpassa sig till vad varje prenumerant faktiskt har gjort. De stödda operatorerna inkluderar lika med, inte lika med, i, inte i, större än, mindre än och finns, vilket är tillräckligt för att uttrycka all beslutlogik som ett retentionsteam behöver.

DELA_VÄG. En procentbaserad förgrening för A/B-testning. En DELA_VÄG-nod dirigerar prenumeranter över två eller flera vägar baserat på konfigurerade procentandelar: 50/50 för ett tvåvägs test, 33/33/34 för ett trevägs utskickstidstest, 90/10 för en utelämna-grupp. Systemet använder en lastbalanseringsalgoritm som dirigerar varje ny prenumerant till den mest underutnyttjade vägen, vilket håller distributionen korrekt även vid små urvalsstorlekar. När testet når signifikans, ställ in winner_edge_id och arbetsflödet främjar 100 % av trafiken till den vinnande varianten utan att bygga om arbetsflödet.

ÅTGÄRD. Själva arbetet. ÅTGÄRD-noder gör mer än att skicka ett push-meddelande. PushEngage Workflows stöder elva åtgärdstyper: SendPushNotification, AddSegment, RemoveSegment, UpdateField, UpdateAttribute, Update (kombinerad), HttpRequest, CustomEvent.Send, SendTriggerCampaignEvent, Workflow.Start och Workflow.Stop. De fyra vanligaste i retentionprogram är SendPushNotification, AddSegment (tagga prenumeranten som konverterad, onboardad eller risk för churn), UpdateAttribute (öka en lojalitetsräknare eller ställa in ett datum för senaste köp) och HttpRequest (synkronisera status till ett CRM, skicka en Slack-varning för en högkvalitativ lead eller anropa en nedströms tjänst).

SLUT / AVSLUT. Terminalen. SLUT- och AVSLUT-noder markerar att arbetsflödet är slutfört och uppdaterar analysdata. SLUT är den naturliga avslutningen. AVSLUT placeras vanligtvis på NEJ-sidan av ett beslut när prenumeranten inte kvalificerar sig, eller på en gren av en delad sökväg som är utformad som en kontrollgrupp. Systemet stöder också kriterier för avslutning på arbetsflödesnivå: ett audience_filter eller trigger_event som avbryter det aktiva arbetsflödet innan varje nod körs. Avslutningsregeln utlöses oavsett vilken nod prenumeranten för närvarande befinner sig vid. Detta är vad som hindrar påminnelser från att skickas ut i arbetsflödet för övergivna kundvagnar till prenumeranter som redan har köpt.

Varje kontextuell kampanj i den här artikeln består av dessa sex delar. Migrationsmönstren nedan läses snabbt när vokabulären är delad.

Tre migreringsmönster: sex fristående utlösare blir tre kontextuella arbetsflöden

De flesta mellanstora retentionsstackar har mellan fyra och åtta fristående utlösare igång. Mönstret är konsekvent: välkomstmeddelande, första köp-uppmaning, övergiven kundvagn, övergiven webbläsning, begäran om recension efter köp, återaktivering, återaktivering, inaktiv VIP. Var och en av dessa är en separat utlösare med sin egen text, sin egen ägare och sin egen analys. Ingen av dem vet om varandra. Samma tre kontextuella arbetsflöden kan leverera samma intäkter med en tredjedel av ytan.

Mönster 1 — Konsolidering av onboarding

Slå samman välkomstserien och den första köp-uppmaningen till ett arbetsflöde med ett beslut om köpstatus.

• START: Händelse PushEngage.Subscriber.Added
• Körningstyp: Enkel (90 dagars nedkylning efter slutförande)
• Flöde: VÄNTA 1 dag → ÅTGÄRD skicka välkomstmeddelande → VÄNTA 3 dagar → BESLUT: har prenumeranten köpt? → JA-sökväg: ÅTGÄRD skicka tack + ÅTGÄRD AddSegment till customers + SLUT → NEJ-sökväg: ÅTGÄRD skicka första köp 10% rabatt → VÄNTA 4 dagar → BESLUT: har prenumeranten köpt? → JA-sökväg: ÅTGÄRD skicka tack + SLUT → NEJ-sökväg: ÅTGÄRD skicka slutlig uppmaning + SLUT
• Avslutningskriterier: Inga på arbetsflödesnivå; beslutsgrenarna hanterar den konverterade prenumeranten
• Ersätter: Välkomstutlösare + första köp-utlösare (2 utlösare → 1 arbetsflöde)

Det delade tillståndet är hela poängen. Det tredje meddelandet skickas bara till prenumeranter som inte har konverterat vid dag fyra. Den första köp-utlösaren i den gamla arkitekturen utlöstes för varje ny prenumerant, inklusive de som köpte i sin första session. Arbetsflödet slutar besvära dem.

Mönster 2 — Kundvagn till recensionskedja

Slå samman återhämtning av övergiven kundvagn och begäran om recension efter köp till ett arbetsflöde med en överlämning via arbetsflödeskedja.

• START: Anpassad händelse cart_abandoned
• Körningstyp: Flera parallella (varje övergiven kundvagn är sin egen instans)
• Flöde: VÄNTA 1 timme → ÅTGÄRD påminnelse #1 → VÄNTA 24 timmar → BESLUT: är kundvagnen fortfarande övergiven? → JA-sökväg: ÅTGÄRD påminnelse #2 med 10% → VÄNTA 48 timmar → BESLUT: är kundvagnen fortfarande övergiven? → JA-sökväg: ÅTGÄRD slutlig påminnelse med 20% → SLUT
• Avslutningskriterier (arbetsflödesnivå): Goal.Tracked = purchase som matchar cart_id från utlösarhändelsen. I samma ögonblick som prenumeranten köper, avbryts arbetsflödet.
• Överlämning: Vid avslutning på grund av köp, utlöser systemet PushEngage.Workflow.Start som riktar sig mot arbetsflödet för recensionsförfrågningar. Arbetsflödet för recensioner startar endast för prenumeranter som faktiskt har köpt. Sökvägen för avslutning på grund av uteblivet köp hoppar över överlämningen helt.
• Ersätter: Kundvagnsutlösare + utlösare för recension efter köp + supportärendet från recensionsförfrågningar som landar hos prenumeranter som aldrig köpte (3 problem → 1 arbetsflöde)

Kedjningen via Workflow.Start är det arkitektoniska svaret på livscykelprogression. Istället för att två utlösare avfyras oberoende och överlappar samma prenumeranter, är kundvagnsarbetsflödets avslutning vid köp det som startar recensionsarbetsflödet. Recensionen avfyras endast för konverterade prenumeranter. Kundvagnen avfyras aldrig efter konvertering. Överlämningen tvingas fram av motorn.

Mönster 3 — Konsolidering av återengagemang

Kollapsa kampanjerna för återvinning, återaktivering och inaktiva VIP-kunder till ett arbetsflöde med en publikutlösare och tre beslutsgrenar.

• START: Publikfilter last_active > 30 days
• Körningstyp: Enkel (ett återengagemangsförsök per prenumerant per 90-dagarsperiod)
• Flöde: BESLUT: lojalitetsnivå? → Guldgren: ÅTGÄRD skicka "vi saknar dig, VIP" med 20% erbjudande → Silvergren: ÅTGÄRD skicka "vi saknar dig" med 10% erbjudande → Ingen nivå-gren: ÅTGÄRD skicka standard "vi saknar dig" med gratis frakterbjudande → VÄNTA 5 dagar → BESLUT (per gren): har prenumeranten engagerat sig eller besökt webbplatsen? → JA-sökväg: ÅTGÄRD AddSegment till re-engaged + SLUT → NEJ-sökväg: ÅTGÄRD skicka "sista chansen" med djupare erbjudande + SLUT
• Avslutningskriterier (arbetsflödesnivå): Publikfilter last_active < 7 days. Prenumeranten blev aktiv på egen hand och arbetsflödets uppgift är slutförd.
• Ersätter: Återvinningsutlösare + återaktiveringsutlösare + inaktiv VIP-utlösare (3 utlösare → 1 arbetsflöde)
• Driftsanmärkning: Enligt publikutlösarens fallgrop i föregående avsnitt inkluderar detta arbetsflöde inte automatiskt prenumeranter som passerar 30-dagarsgränsen efter att arbetsflödet startat. Duplicera arbetsflödet månadsvis så att varje kopia fångar de nya kandidaterna. Ett enda långvarigt publikarbetsflöde är fel primitiv här.

Efter dessa tre migreringar äger retentionsteamet tre kontextuella resor istället för sex (eller åtta) fristående utlösare. Den totala volymen av push-meddelanden förblir ungefär densamma. Överdriven meddelandehantering försvinner, eftersom delade avslutningskriterier och beslutsgrenar stoppar arbetsflödet när prenumerantens tillstånd inte längre matchar. Analytiken fragmenteras från "sex instrumentpaneler jag inte kan förena" till "tre trattar jag kan försvara". Det här är hur händelsestyrda push-kampanjer ser ut när de mognar.

Vad kontextuella arbetsflöden gör som fristående utlösare inte kan

Fyra funktioner finns inuti en kontextuell arbetsflöde och kan inte kombineras över fristående utlösare. Var och en är en verklig källa till intäkter eller besparingar.

Avslutningskriterier för flera arbetsflöden. En fristående utlösare aktiveras när händelsen inträffar, punkt slut. Inuti ett arbetsflöde aktiveras avslutningsregeln oavsett vilken nod prenumeranten befinner sig på. Arbetsflödet för övergivna kundvagnar avslutas vid köp. Återvinningsarbetsflödet avslutas vid återaktivering. Förnyelsearbetsflödet avslutas vid tidig förnyelse. Utlösaren som ingen bad att sluta är arbetsflödet som definierar en avslutningsregel.

Flertalet kanaler inom ett arbetsflöde. Med separata verktyg för enskilda kanaler kräver ”skicka webb-push, återgå till e-post, eskalera till WhatsApp” tre leverantörsinloggningar, två segmenteringsmotorer och minst en Zapier-flöde. Inom en arbetsflödesmotor är det tre ACTION-noder med två DECISION-noder mellan dem, som delar en prenumerantidentitet och en uppsättning avslutningskriterier. För en djupare behandling, se inlägget om orkestrering av push-meddelanden och e-post via flera kanaler.

Tystnadstimmar med reschedule som återfall. Push-meddelanden som skulle landa kl. 03:00 i prenumerantens lokala tidszon hålls till kl. 08:01 om tystnadstimmar konfigureras med reschedule som återfall. Alternativet, skip, tar tyst bort meddelandet och uppdaterar inte meddelandeanalysen för den hoppade åtgärden. För de flesta retentionsteam är reschedule rätt standardinställning eftersom borttagna analyser innebär borttagen intäktsattribution. De kontextuella push-meddelandena som ett retentionsteam faktiskt vill skicka respekterar prenumerantens tidszoner utan att försvinna från tratten.

Kedjning av arbetsflöden. Åtgärderna Workflow.Start och Workflow.Stop gör livscykelförloppet till en verklig arkitektur. Välkomstarbetsflödet avslutas, vilket startar engagemangsarbetsflödet. Kundvagnsarbetsflödet avslutas vid köp, vilket startar granskningsarbetsflödet. Jämfört med en mapp med utlösare som alla aktiveras oberoende, är detta en tillståndsmaskin: en graf av arbetsflöden, var och en med sin egen ingångsbetingelse, avslutningsbetingelse och överlämning till nästa steg. Utlösare känner inte till varandra. Arbetsflöden gör det.

Analys per arbetsflöde: hur man läser tratten

Ett arbetsflöde som du inte kan försvara vid nästa resultat- och förlustgranskning är ett arbetsflöde som dödas. PushEngage Workflows spårar tre siffror vid varje nod (queued_users, completed_users, exited_users) plus arbetsflödesnivåer för totalt inträdda, aktivt, slutfört och avslutat. Retention managerens jobb är att läsa denna tratt och tala om för ekonomiavdelningen vad varje post har producerat.

Här är hur nodnivåanalyser ser ut för kedjan från kundvagn till granskning från Mönster 2 ovan. Illustrativa siffror, hämtade från en realistisk lista med 200 000 prenumeranter med en månatlig övergiven kundvagnsfrekvens på 6 %.

Nod	Köad	Slutförd	Avslutad	Anteckningar
START (cart_abandoned)	0	12,400	320	320 prenumeranter matchade avslutningskriterier vid arbetsflödets start (köpte mellan kundvagns-händelsen och arbetsflödes-skanningen)
VÄNTA 1 timme	180	11,900	320	Normal ködjup
ÅTGÄRD: påminnelse #1	0	11,900	0	Skickat
VÄNTA 24 timmar	240	9,800	1,860	1 860 prenumeranter köpte efter påminnelse nr 1 (avslut vid mål purchase)
BESLUT: kundvagnen fortfarande övergiven	0	9,800	0	Gren utvärderad
ÅTGÄRD: påminnelse nr 2 (10%)	0	9,800	0	Skickat
VÄNTA 48 timmar	90	6,300	3,410	3 410 prenumeranter köpte efter påminnelse nr 2
ÅTGÄRD: slutlig påminnelse (20%)	0	6,300	0	Skickat
SLUT	ej	6,300	ej	6 300 prenumeranter köpte inte; granskningsarbetsflöde inte länkat för dessa
Workflow.Start → granskningsarbetsflöde	ej	5,270	ej	Utlöst för de 5 270 prenumeranterna (1 860 + 3 410) som köpte

De 5 270 länkade överlämningarna är den nya metrik som denna arkitektur exponerar. Kundvagnsarbetsflödet återhämtade en kundvagnsfrekvens på 42,5 % (5 270 av 12 400 påbörjade) och endast dessa 5 270 prenumeranter får arbetsflödet för granskningsbegäran. Den gamla arkitekturen skickade granskningsbegäran till alla som någonsin hade köpt, inklusive prenumeranter som aldrig övergav en kundvagn, prenumeranter som returnerade ordern och prenumeranter som redan hade skickat en recension. Den arkitektoniska lösningen är liten. Besparingarna från överdriven meddelandehantering är stora.

Två flaskhalsmönster är värda att känna till. En nod med hög avslutning (som de två WAIT-noderna ovan) är arbetsflödet som gör sitt jobb: prenumeranter köper under väntetiderna, avslutningskriterierna utlöses, nästa påminnelse skickas aldrig. Det omvända mönstret, hög avslutning vid åtgärdsnoder i kombination med låg avslutning vid väntnoder, innebär att tidpunkten är fel och väntetiderna bör förkortas. En nod med hög kö innebär en paus under tysta timmar, en lång väntan eller en fördröjning hos en nedströms poller; kontrollera tidskonfigurationen innan du antar att arbetsflödet är trasigt.

För en djupare e-handelspecifik behandling av dessa mönster, går det kompletterande inlägget om fem push-meddelandearbetsflöden för e-handel igenom kundvagn, surfning, efterköp, välkomstmeddelanden och återaktivering som fristående resor. Hubben för e-handelspushmeddelanden täcker det bredare landskapet av kampanjtyper, sekvensen för återhämtning av övergiven kundvagn går igenom kadensjustering per plattform, och översikten automatiserade pushmeddelanden visar den äldre listan över automationstyper tillsammans med denna arbetsflödesarkitektur.

Samma analysform fungerar över olika vertikaler. SaaS har en förnyelsefunnel och konvertering från test till betald. Publicister har en artikelengagemangfunnel och återinträde i arkivet. Resor har en bokningsfunnel och ett flöde för prisuppdateringar. De beteendebaserade pushmeddelandena som ett SaaS-team använder för att driva konvertering från test till betald ser strukturellt identiska ut med de som ett e-handelsteam använder för att driva konvertering från kundvagn till köp: en START vid en händelse i realtid, tre eller fyra steg med beslutsgrenar, avslutningskriterier vid konvertering, valfri överlämning till nästa arbetsflöde. Vertikalen ändrar triggerns namn och erbjudandets text. Arkitekturen består.

Bygg det i PushEngage Workflows

Var och en av de tre migreringsmönstren ovan motsvarar direkt PushEngage Workflows-komponenter.

Mönster	Nodtyper som används	Åtgärdstyper som används	Arbetsflödesalternativ	Föreslagen mall som utgångspunkt
Konsolidering av onboarding	START, VÄNTA, BESLUT, HANDLING, SLUT	SendPushNotification, AddSegment	Körningstyp: Enkel	”Välkomstserie med gren för första köp”
Kundvagn-till-recensionskedja	START, VÄNTA, BESLUT, HANDLING, SLUT	SendPushNotification, Workflow.Start	Körningstyp: Flera parallella; avslutningskriterier Goal.Tracked = purchase	”Eskalering av övergiven kundvagn”
Konsolidering av återengagemang	START (publik), BESLUT, HANDLING, VÄNTA, SLUT	SendPushNotification, AddSegment	Körningstyp: Enkel; publikutlösare; duplicera månadsvis	”Återengagemang med nivåbaserat erbjudande”

Workflows-motorn levereras med 60+ färdiga mallar som täcker varje migrationsmönster ovan. Varje mall är en utgångspunkt. Mönstren installeras på under fem minuter på Shopify, Shopify Plus, WooCommerce, BigCommerce och Magento inuti PushEngage Workflows-byggaren, eller på vilken SaaS-, utgivare- eller rese-stack som helst via JavaScript SDK och händelse-API:et.

Gratisplanen ger dig 200 prenumeranter, alla kanaler (webb push, app push, WhatsApp och livechatt) och hela Workflows-motorn från dag ett. Det räcker för att migrera ett av de tre mönstren från din nuvarande utlösarstack och bevisa arkitekturen innan du begär budget. Börja med gratisplanen och driftsätt den första kontextuella arbetsflödet på under en timme.

Om du tar med dig en sak från den här artikeln, ta med dig detta: en utlöst push-kampanj är inte längre notifikationen. Det är arbetsflödet. Sex fristående utlösare som körs frånkopplade är sex pipelines som pekar på samma prenumerantlista, var och en ovetande om de andra.

Tre kontextuella arbetsflöden som körs med delad status, beslutsförgreningar, avslutningskriterier och kedjade överlämningar är en resa per prenumerant, förgrenad och avgränsad. Marknadsföringsautomatiseringsarbetsflödena som producerar en försvarbar per-arbetsflödes-funnel och en återköpsfrekvens som växer är inte en längre lista med utlösare; de är en mindre, skarpare uppsättning kontextuella resor. Arkitekturen är kampanjen. Utlösaren är dörren.