Udløste push-kampagner: Vejledning til kontekstuelle arbejdsgange

Det er anden uge af kvartalet, og dit fastholdelses-dashboard viser seks kørende "automatiserede" triggere, alle grønne. Cart-abandonment-triggeren udløses fortsat for abonnenter, der allerede har betalt. Win-back overlapper med pris-drop-alarmen for den samme forsvundne kunde. Velkomstserien sender notifikationer uafhængigt af den første-købs-nudge. Anmodningen om anmeldelse efter køb lander hos abonnenter, der returnerede ordren i går.

Hver af de seks udløste push-kampagner er en pipeline, der peger på den samme abonnentliste, og hver foregiver, at de andre fem ikke eksisterer. Gentagelseskøbsraten stoppede med at bevæge sig for tolv måneder siden, og ingen i teamet kan tilskrive omsætning pr. trigger, fordi triggerne ikke deler tilstand.

Dette er den operationelle virkelighed i de fleste mellemmarkedets fastholdelses-stacks. Problemet er ikke strategi. Strategien er fin. Problemet er arkitektur. En udløst notifikation i 2024 var en enkelt besked, der blev udløst af en enkelt begivenhed. I 2026 er den primitiv ikke nok. Rejsen skal huske, hvad abonnenten gjorde, forgrenes på det, og afsluttes, når de konverterer.

Denne artikel fremlægger det arkitektoniske argument. Den definerer grænsen mellem broadcast-, udløste og kontekstuelle push-notifikationer, gennemgår forskellen mellem begivenheds-triggere og publikums-triggere, navngiver de seks nodetyper, der forvandler en enkelt trigger til en kontekstuel arbejdsgang, og leverer tre migrationsmønstre, der konsoliderer seks selvstændige triggere til tre kontekstuelle rejser med delte exit-kriterier og per-workflow-analyse.

Kontekstuel, udløst, broadcast: tre primitiver, ikke én

Tre primitiver ligger til grund for ethvert push-notifikationsprogram. De fleste teams kollapser dem til én spand kaldet "kampagner", hvilket er der, hvor arkitekturproblemet starter.

Broadcast. Den samme notifikation sendes til hele det matchende publikum, planlagt. Lynsalg kl. middag. Ny kollektionsalarm på lanceringsdagen. Broadcast er den rigtige primitiv for tidsbegrænsede annonceringer, hvor alle modtagere får den samme nyttelast. Det er den forkerte primitiv for alt, der afhænger af abonnentens tilstand.

Udløst. En enkelt notifikation udløses, når en enkelt begivenhed udløses. Abonnent forlader en kurv, notifikationen om forladt kurv udløses. Abonnent ser en produktside, notifikationen om browsing udløses. Abonnent køber, notifikationen efter køb udløses. Udløseren har ingen hukommelse. Den ved ikke, hvad der skete for fem minutter siden, eller hvad der er planlagt til næste tirsdag. Hver udløser er en pipeline, der er uvidende om enhver anden udløser.

Kontekstuel. En arbejdsgang bruger udløseren som indgangspunkt og tilpasser sig derefter abonnentens tilstand. Den samme begivenhed om forladt kurv starter en rejse med flere trin: en times ventetid, en første påmindelse, 24 timers ventetid, en beslutning, der kontrollerer, om kurven stadig er åben, en anden påmindelse med rabat, 48 timers ventetid, en tredje påmindelse og en exit-regel, der annullerer arbejdsgangen i det øjeblik, abonnenten køber. Kampagnen er arbejdsgangen, ikke udløseren. Kontekstuelle push-notifikationer er, hvordan udløste beskeder opfører sig, når arkitekturen indhenter det.

De tre primitiver kortlægges rent til tre arbejdsbelastninger. Brug denne tabel, når du gennemgår din nuværende stak.

Kapabilitet	Broadcast	Udløst	Kontekstuel
Tilstand pr. abonnent	Nej	Nej	Ja
Forløb baseret på adfærd	Nej	Nej	Ja
Exit-kriterier	Nej	Nej	Ja
Flerkanals-routing inde i én kampagne	Nej	Nej	Ja
Indbygget A/B (sendetid, tekst, kanal)	Nej	Nej	Ja
Korrekt arbejdsbelastning	Flash-salg, lanceringsannonceringer	Engangs transaktionelle pings (lav volumen)	Livscyklus-rejser (velkomst, kurv, genvinding, fornyelse)

De fleste livscyklus-programmer kræver kontekstuelle. De fleste teams leverer udløste. Det hul er, hvad denne artikel handler om. Marketingautomatiserings-arbejdsgangene, der leverer kontekstuelle rejser, ligner ikke en længere liste af udløsere; de ligner et mindre sæt af rejser med flere trin sammensat af et fælles ordforråd. De push-notifikations-arbejdsgange, du rent faktisk ønsker, er tre kontekstuelle rejser, ikke ni udløsere.

Begivenheds-triggere og publikums-triggere opfører sig meget forskelligt

Før nodens anatomi, et taksonomipunkt, som næsten alle artikler om dette emne tager fejl af. En "udløser" i push-notifikations-arbejdsgange er ikke en enkelt primitiv. Det er to primitiver, der ligner hinanden udefra og opfører sig meget forskelligt under overfladen.

Begivenhedsudløsere udløses pr. abonnent ved en reel begivenhed. De understøttede begivenheder i PushEngage Workflows inkluderer PushEngage.Subscriber.Added, PushEngage.Subscriber.AddSegment, PushEngage.Subscriber.RemoveSegment, PushEngage.Subscriber.UpdateField, PushEngage.Subscriber.UpdateAttribute, PushEngage.Goal.Tracked og PushEngage.CustomEvent. Når begivenheden udløses, evaluerer systemet aktive arbejdsgange, kontrollerer begivenhedsfilter-kriterier, kontrollerer exit-regler og sætter den matchende arbejdsgang i kø for den pågældende abonnent. Gabet mellem udløser og kø er sekunder. Begivenhedsudløsere er den rigtige primitiv for enhver reaktiv kampagne: forladt kurv, forladt browsing, opfølgning på køb, velkomst ved segment-tilmelding. Begivenhedsudløste push-kampagner er det dominerende tilfælde i e-handel, SaaS onboarding og ethvert program med realtids-signaler.

Målgruppetrigger udløser en filter på et planlagt tidspunkt. Filteret vælger abonnenter, der matcher specifikke kriterier, som last_active > 30 days, loyalty_tier = gold eller city = New York AND segments includes "vip". Scheduler poller henter det matchende abonnentsæt i batches på 1000, spreder udførelsen med 15 sekunder til 2 minutter og opretter én workflow-instans pr. abonnent. Målgruppetrigger er den rigtige primitiv til genengagement, fødselsdagskampagner, geografiske kampagner og ethvert program, hvor sættet er defineret af attribut snarere end af begivenhed.

Forskellene betyder noget operationelt, ikke kun konceptuelt:

Aspekt	Begivenhedstrigger	Målgruppetrigger
Initialisering	Realtid ved abonnentbegivenhed	Planlagt via poller
Hastighed	Inden for sekunder	Batchvis, 1-2 minutters forsinkelse
Abonnentvalg	Én abonnent pr. begivenhed	Bulkvalg kun ved workflow-starttidspunkt
Nye abonnenter efter start	Automatisk inkluderet ved næste begivenhed	IKKE auto-inkluderet efter workflow er startet
Filterændring efter start	N/A	Redigering af filteret tilføjer IKKE nye abonnenter
Begivenhedsdata tilgængelige	Ja (til variabel erstatning)	Nej

Den tredje række er faldgruben. Et målgruppebaseret workflow vælger sit abonnentsæt én gang, ved workflow-start. Abonnenter, der bliver inaktive, efter workflowet er startet, tilføjes ikke automatisk. Redigering af målgruppefilteret på et aktivt workflow trækker ikke nye kandidater ind. Et retention-team, der sender et "win-back for abonnenter inaktive 30+ dage" workflow ud og lader det køre i halvfems dage, vil se den samme faste kohorte over hele de halvfems dage, selvom nye abonnenter krydser 30-dages grænsen hver dag.

Det arkitektoniske svar er at duplikere målgruppeworkflowet på en tilbagevendende tidsplan, månedligt eller ugentligt, så hver duplikat fanger de kandidater, der krydsede tærsklen siden sidste kørsel. Dette er en en-linjes operationel note i dokumentationen og en tilbagevendende kilde til supportbilletter af typen "hvorfor fik denne abonnent ikke kampagnen?" i teams, der behandler målgruppetrigger som begivenhedstrigger.

De seks noder, der forvandler en trigger til en kontekstuel kampagne

Når triggeren udløses, er selve workflowet sammensat af seks nodetyper. Ordforrådet er lille nok til at lære på fem minutter og stort nok til at sammensætte enhver kontekstuel kampagne, et retention-team nogensinde har ønsket at sende ud.

START. Indgangspunktet. En START-node definerer triggeren (begivenhedsbaseret eller målgruppebaseret) og filterkriterierne. Et workflow har præcis én START. Indgangspunktet bestemmer trigger-taksonomien fra det foregående afsnit og indstiller event-data-konteksten, som nedstrøms noder kan læse.

VENT. En forsinkelse. En VENT-knude holder abonnenten i en specificeret varighed (minutter, timer, dage) eller indtil et bestemt kalendertidspunkt. Vent er, hvordan en arbejdsgang respekterer abonnentens tilstand og abonnentens tidszone. Arbejdsgangen kan vente en time på en påmindelse om forladt indkøbskurv, tre dage på et funktionsfremhæv i en velkomstserie eller indtil tirsdag kl. 10 i abonnentens lokale tidszone for en afsendelse i arbejdstiden. Vent giver dig også mulighed for at komponere en dryp-kampagne med flere trin uden at sende alle beskeder inden for de første tres sekunder.

BESLUTNING. En tovejsforgrening. En BESLUTNING-knude kontrollerer et hændelsesfilter eller et publikumsfilter og dirigerer abonnenten ned ad JA-stien eller NEJ-stien. Har abonnenten købt? Er de stadig i segmentet for forladt indkøbskurv? Har deres loyalitetsniveau ændret sig? Beslutningsknuder er, hvordan adfærdsbaserede push-meddelelser holder op med at behandle alle abonnenter ens og begynder at tilpasse sig, hvad hver abonnent faktisk har gjort. De understøttede operatorer inkluderer lig med, ikke lig med, i, ikke i, større end, mindre end og eksisterer, hvilket er nok til at udtrykke enhver beslutningslogik, et fastholdelsesteam har brug for.

SPLIT_PATH. En procentbaseret forgrening til A/B-test. En SPLIT_PATH-knude dirigerer abonnenter på tværs af to eller flere stier baseret på konfigurerede procenter: 50/50 til en tovejs test, 33/33/34 til en trevejs afsendelsestidstest, 90/10 til en holdout-gruppe. Systemet bruger en belastningsbalanceringsalgoritme, der dirigerer hver ny abonnent til den mest underudnyttede sti, hvilket holder distributionen nøjagtig, selv ved små stikprøvestørrelser. Når testen når signifikans, indstilles winner_edge_id, og arbejdsgangen promoverer 100 % af trafikken til den vindende variant uden at genopbygge arbejdsgangen.

HANDLING. Selve arbejdet. HANDLING-knuder gør mere end blot at sende en push-meddelelse. PushEngage Workflows understøtter elleve handlingstyper: SendPushNotification, AddSegment, RemoveSegment, UpdateField, UpdateAttribute, Update (kombineret), HttpRequest, CustomEvent.Send, SendTriggerCampaignEvent, Workflow.Start og Workflow.Stop. De fire mest almindelige i fastholdelsesprogrammer er SendPushNotification, AddSegment (tag abonnenten som konverteret, onboardet eller med risiko for churn), UpdateAttribute (forøg en loyalitetstæller eller indstil en dato for sidste køb) og HttpRequest (synkroniser tilstand til et CRM, udløs en Slack-advarsel for en værdifuld kundeemne eller kald en downstream-tjeneste).

SLUT / AFS LUTNING. Terminalen. SLUT- og AFS LUTNING-knudepunkter markerer, at arbejdsgangen er fuldført, og opdaterer analyser. SLUT er den naturlige afslutning. AFS LUTNING placeres typisk på NEJ-stien i en beslutning, når abonnenten ikke kvalificerer sig, eller på en opdelt gren designet som en kontrolgruppe. Systemet understøtter også kriterier for afslutning på arbejdsgangsniveau: et audience_filter eller trigger_event, der annullerer den aktive arbejdsgang, før hver knude køres. Afslutningsreglen udløses uanset, hvilken knude abonnenten befinder sig ved. Dette er, hvad der forhindrer påmindelser om arbejdsgange for forladte indkøbskurve i at blive sendt til abonnenter, der allerede har købt.

Hver kontekstuel kampagne i denne artikel er sammensat af disse seks dele. Migrationsmønstrene herunder læses hurtigt, når ordforrådet er delt.

Tre migrationsmønstre: seks selvstændige triggere bliver tre kontekstuelle arbejdsgange

De fleste mellemmarkeds-retentionsstakke har mellem fire og otte separate udløsere kørende. Mønsteret er konsekvent: velkomstmeddelelse, første-købs-skub, forladt indkøbskurv, forladt browsing, anmodning om anmeldelse efter køb, genvinding, genaktivering, inaktiv VIP. Hver af disse er en separat udløser med sin egen tekst, sin egen ejer og sine egne analyser. Ingen af dem kender til hinanden. De samme tre kontekstuelle arbejdsgange kan levere den samme omsætning med en tredjedel af overfladearealet.

Mønster 1 — Konsolidering af onboarding

Kollaps velkomstserien og første-købs-skubbet til én arbejdsgang med en beslutning om købsstatus.

• START: Begivenhed PushEngage.Subscriber.Added
• Kørselstype: Enkel (90-dages nedkøling efter fuldførelse)
• Flow: VENT 1 dag → HANDLING send velkomstmeddelelse → VENT 3 dage → BESLUTNING: har abonnenten købt? → JA-sti: HANDLING send tak + HANDLING AddSegment til customers + SLUT → NEJ-sti: HANDLING send 10% rabat på første køb → VENT 4 dage → BESLUTNING: har abonnenten købt? → JA-sti: HANDLING send tak + SLUT → NEJ-sti: HANDLING send sidste skub + SLUT
• Afslutningskriterier: Ingen på arbejdsgangsniveau; beslutningsgrenene håndterer den konverterede abonnent
• Erstatter: Velkomst-udløser + første-købs-udløser (2 udløsere → 1 arbejdsgang)

Den delte tilstand er hele pointen. Den tredje meddelelse udløses kun for abonnenter, der ikke er konverteret inden dag fire. Første-købs-udløseren i den gamle arkitektur udløstes for enhver ny abonnent, inklusive dem, der købte i deres første session. Arbejdsgangen generer dem ikke længere.

Mønster 2 — Indkøbskurv-til-anmeldelse-kæde

Kollaps genopretning af forladt indkøbskurv og anmodning om anmeldelse efter køb til én arbejdsgang med en arbejdsgangskæde-overdragelse.

• START: Brugerdefineret begivenhed cart_abandoned
• Kørselstype: Flere parallelle (hver forladt indkøbskurv er sin egen instans)
• Flow: VENT 1 time → HANDLING påmindelse #1 → VENT 24 timer → BESLUTNING: er indkøbskurven stadig forladt? → JA-sti: HANDLING påmindelse #2 med 10% → VENT 48 timer → BESLUTNING: er indkøbskurven stadig forladt? → JA-sti: HANDLING sidste påmindelse med 20% → SLUT
• Afslutningskriterier (workflow-niveau): Goal.Tracked = purchase der matcher cart_id fra trigger-begivenheden. I det øjeblik abonnenten køber, annulleres workflowet.
• Overdragelse: Ved afslutning på grund af køb, udløser systemet PushEngage.Workflow.Start rettet mod anmeldelses-anmodnings-workflowet. Anmeldelses-workflowet starter kun for abonnenter, der rent faktisk har købt. Stien for afslutning på grund af manglende køb springer overdragelsen helt over.
• Erstatter: Kurv-trigger + efterkøbs-anmeldelses-trigger + support-ticketen fra anmeldelses-anmodninger, der lander på abonnenter, som aldrig har købt (3 problemer → 1 workflow)

Kædningen via Workflow.Start er det arkitektoniske svar på livscyklusprogression. I stedet for at to triggere udløses uafhængigt og overlapper på de samme abonnenter, er kurv-workflowets afslutning ved køb det, der starter anmeldelses-workflowet. Anmeldelsen udløses kun for konverterede abonnenter. Kurven udløses aldrig efter konvertering. Overdragelsen håndhæves af motoren.

Mønster 3 — Konsolidering af genaktivering

Sammenfold win-back, reaktivering og lapsed-VIP-kampagnerne til ét workflow med en publikumstrigger og tre beslutningsgrene.

• START: Publikumfilter last_active > 30 days
• Kørselstype: Enkel (et genoptagelsesforsøg pr. abonnent pr. 90-dages vindue)
• Flow: BESLUTNING: loyalitetsniveau? → Guld-gren: HANDLING send “vi savner dig, VIP” med 20% tilbud → Sølv-gren: HANDLING send “vi savner dig” med 10% tilbud → Ingen-niveau-gren: HANDLING send standard “vi savner dig” med gratis fragt-tilbud → VENT 5 dage → BESLUTNING (pr. gren): har abonnenten interageret eller besøgt siden? → JA-sti: HANDLING AddSegment til re-engaged + AFSLUT → NEJ-sti: HANDLING send “sidste chance” med dybere tilbud + AFSLUT
• Afslutningskriterier (workflow-niveau): Publikumfilter last_active < 7 days. Abonnenten blev aktiv af sig selv, og workflowets opgave er fuldført.
• Erstatter: Win-back trigger + reaktiveringstrigger + lapsed-VIP-trigger (3 triggere → 1 workflow)
• Driftsmæssig bemærkning: I henhold til publikumstrigger-problemet i det foregående afsnit inkluderer dette workflow ikke automatisk abonnenter, der krydser 30-dages-grænsen, efter workflowet er startet. Dupliker workflowet månedligt, så hver duplikat fanger de nye kandidater. Et enkelt, langvarigt publikums-workflow er den forkerte primitiv her.

Efter disse tre migreringer ejer retention-teamet tre kontekstuelle rejser i stedet for seks (eller otte) selvstændige triggere. Den samlede mængde push-beskeder forbliver nogenlunde den samme. Over-messaging forsvinder, fordi fælles afslutningskriterier og beslutningsgrene stopper workflowet, når abonnentens tilstand ikke længere matcher. Analytikken fragmenteres fra “seks dashboards, jeg ikke kan forene” til “tre tragte, jeg kan forsvare”. Sådan ser begivenhedsudløste push-kampagner ud, når de bliver voksne.

Hvad kontekstuelle arbejdsgange kan, som selvstændige triggere ikke kan

Fire funktioner findes inde i en kontekstuel arbejdsgang og kan ikke sammensættes på tværs af selvstændige udløsere. Hver enkelt er en reel kilde til indtægt eller besparelser.

Afslutningskriterier på tværs af arbejdsgange. En selvstændig udløser afgives, når begivenheden afgives, punktum. Inde i en arbejdsgang afgives afslutningsreglen uanset hvilken knude abonnenten befinder sig på. Arbejdsgangen for forladte indkøbskurve afsluttes ved køb. Genaktiveringsarbejdsgangen afsluttes ved genaktivering. Fornyelsesarbejdsgangen afsluttes ved tidlig fornyelse. Udløseren, som ingen fortalte at stoppe, er arbejdsgangen, der definerer en afslutningsregel.

Flerkanalsrouting inde i én arbejdsgang. Med separate enkeltkanalsværktøjer kræver "afgiv push til web, fald tilbage til e-mail, eskaler til WhatsApp" tre leverandørlogins, to segmenteringsmotorer og mindst ét Zapier-flow. Inde i én arbejdsgangsmotor er det tre HANDLINGs-knuder med to BESLUTNINGs-knuder imellem, der deler én abonnentidentitet og ét sæt afslutningskriterier. For en dybere behandling, se indlægget om flerkanals push- og e-mail-orkestrering.

Stilletid med reschedule fallback. Push-meddelelser, der ville lande kl. 3 om natten i abonnentens lokale tidszone, holdes indtil kl. 8:01, hvis der er konfigureret stilletid med reschedule som fallback. Alternativet, skip, dropper lydløst meddelelsen og opdaterer ikke meddelelsesanalyser for den springede handling. For de fleste retention-teams er reschedule den rigtige standard, fordi droppede analyser betyder tabt indtægtsattribution. De kontekstuelle push-meddelelser, et retention-team faktisk ønsker at sende, respekterer abonnentens tidszoner uden at forsvinde fra tragten.

Arbejdsgangskædning. Workflow.Start og Workflow.Stop handlingerne gør livscyklusprogression til en reel arkitektur. Velkomst-arbejdsgangen slutter, hvilket starter engagement-arbejdsgangen. Indkøbskurv-arbejdsgangen afsluttes ved køb, hvilket starter anmeldelses-arbejdsgangen. Sammenlignet med en mappe af udløsere, der alle afgives uafhængigt, er dette en tilstandsmaskine: en graf af arbejdsgange, hver med sin egen indgangsbetingelse, afslutningsbetingelse og overlevering til næste trin. Udløsere kender ikke til hinanden. Arbejdsgange gør.

Per-workflow-analyse: hvordan man læser tragten

En arbejdsgang, du ikke kan forsvare ved den næste P&L-gennemgang, er en arbejdsgang, der bliver dræbt. PushEngage Workflows sporer tre tal ved hver knude (queued_users, completed_users, exited_users) plus arbejdsgang-niveau totaler for totalt-indtastede, aktuelt-aktive, afsluttede og afsluttede. Retention-managerens job er at læse denne tragt og fortælle finansafdelingen, hvad hver enkelt post producerede.

Her er, hvordan knude-niveau analyser ser ud for indkøbskurv-til-anmeldelse kæden fra Mønster 2 ovenfor. Illustrative tal, trukket fra en realistisk liste med 200.000 abonnenter med en månedlig rate for forladte indkøbskurve på 6%.

Knude	Køet	Gennemført	Afsluttet	Noter
START (cart_abandoned)	0	12,400	320	320 abonnenter matchede afslutningskriterier ved arbejdsgangens start (købt mellem indkøbskurv-begivenheden og arbejdsgang-scanningen)
VENT 1 time	180	11,900	320	Normal kødybde
HANDLING: påmindelse #1	0	11,900	0	Sendt
VENT 24 timer	240	9,800	1,860	1.860 abonnenter købte efter påmindelse #1 (afslut ved mål køb)
BESLUTNING: kurv stadig forladt	0	9,800	0	Gren evalueret
HANDLING: påmindelse #2 (10%)	0	9,800	0	Sendt
VENT 48 timer	90	6,300	3,410	3.410 abonnenter købte efter påmindelse #2
HANDLING: sidste påmindelse (20%)	0	6,300	0	Sendt
SLUT	ikke relevant	6,300	ikke relevant	6.300 abonnenter købte ikke; gennemgangsarbejde er ikke kædet for disse
Workflow.Start → gennemgangsarbejde	ikke relevant	5,270	ikke relevant	Udløst for de 5.270 abonnenter (1.860 + 3.410), der købte

De 5.270 kædede overleveringer er den nye metrik, denne arkitektur viser. Kurvarbejdet genvandt en kurvraterate på 42,5% (5.270 ud af 12.400 indtastet), og kun disse 5.270 abonnenter modtager anmodningsarbejdet om gennemgang. Den gamle arkitektur sendte anmodningen om gennemgang til alle, der nogensinde havde købt, inklusive abonnenter, der aldrig forlod en kurv, abonnenter, der returnerede ordren, og abonnenter, der allerede havde indsendt en gennemgang. Den arkitektoniske løsning er lille. Besparelserne på overbeskededer er store.

To flaskehalsmønstre er værd at kende. En knude med høj afslutning (som de to VENT-knuder ovenfor) er arbejdet, der gør sit job: abonnenter køber i ventevinduerne, afslutningskriteriet udløses, den næste påmindelse sendes aldrig. Det omvendte mønster, høje afslutninger ved handlingsknuder parret med lave afslutninger ved venteknuder, betyder, at timingen er forkert, og ventetiderne bør forkortes. En knude med høj kø betyder en stilstand i stille timer, en lang ventetid eller en forsinkelse i en downstream-poller; tjek timingkonfigurationen, før du antager, at arbejdet er brudt.

For en dybere e-handels-specifik behandling af disse mønstre, gennemgår det ledsagende indlæg om fem push-notifikations-workflows til e-handel kurv, browsing, efter køb, velkomst og genvinding som selvstændige rejser. E-handels push-notifikations-hubben dækker det bredere landskab af kampagnetyper, sekvensen til genvinding af forladte kurve gennemgår kadencejustering efter platform, og oversigten over automatiserede push-notifikationer viser den ældre liste over automationstyper sammen med denne workflow-arkitektur.

Den samme analyseform fungerer på tværs af brancher. SaaS har en fornyelses-funnel og en konvertering fra prøve til betalt. Udgivere har en artikel-engagement-funnel og arkiv-genindtræden. Rejser har en booking-funnel og en pris-drop-alarm-flow. De adfærdsmæssige push-notifikationer, som et SaaS-team bruger til at drive konvertering fra prøve til betalt, ser strukturelt identiske ud med dem, et e-handelsteam bruger til at drive konvertering fra kurv til køb: én START på en realtidsbegivenhed, tre eller fire trin med beslutningsgrene, afslutningskriterier ved konvertering, valgfri overlevering til det næste workflow. Branchen ændrer trigger-navne og tilbuds-teksten. Arkitekturen forbliver.

Byg det i PushEngage Workflows

Hvert af de tre migrationsmønstre ovenfor svarer direkte til PushEngage Workflows-komponenter.

Mønster	Brugte knudepunkttyper	Brugte handlingstyper	Arbejdsgangsindstilling	Foreslået skabelon startpunkt
Konsolidering af onboarding	START, VENT, BESLUTNING, HANDLING, SLUT	SendPushNotification, AddSegment	Kørselstype: Enkel	“Velkomstserie med første-købs-gren”
Kæde fra kurv til gennemgang	START, VENT, BESLUTNING, HANDLING, SLUT	SendPushNotification, Workflow.Start	Kørselstype: Flere parallelle; afslutningskriterier Goal.Tracked = purchase	“Eskalering af forladt kurv”
Konsolidering af genaktivering	START (publikum), BESLUTNING, HANDLING, VENT, SLUT	SendPushNotification, AddSegment	Kørselstype: Enkelt; publikumsudløser; dupliker månedligt	“Genengagement med tilbud baseret på niveau”

Workflows-motoren leveres med 60+ leverede skabeloner, der dækker hvert af ovenstående migrationsmønstre. Hver skabelon er et udgangspunkt. Mønstrene installeres på under fem minutter på Shopify, Shopify Plus, WooCommerce, BigCommerce og Magento inde i PushEngage Workflows-byggeren, eller på enhver SaaS-, udgiver- eller rejse-stack via JavaScript SDK'en og events API'en.

Den gratis plan giver dig 200 abonnenter, alle kanaler (web push, app push, WhatsApp og live chat) og hele Workflows-motoren fra dag ét. Det er nok til at migrere et af de tre mønstre fra din nuværende udløser-stack og bevise arkitekturen, før du anmoder om budget. Start på den gratis plan og implementer den første kontekstuelle workflow på under en time.

Hvis du tager én ting med fra denne artikel, så tag denne: en udløst push-kampagne er ikke længere notifikationen. Det er workflowet. Seks selvstændige triggere, der kører frakoblet, er seks pipelines rettet mod den samme abonnentliste, hver uvidende om de andre.

Tre kontekstuelle workflows, der kører med delt tilstand, beslutningsforgreninger, exit-kriterier og kædede overgange, er én rejse pr. abonnent, forgrenet og afgrænset. Marketingautomatiseringsworkflows, der producerer en forsvarlig per-workflow-funnel og en gentagelseskøbsrate, der sammensættes, er ikke en længere liste af udløsere; de er et mindre, skarpere sæt af kontekstuelle rejser. Arkitekturen er kampagnen. Udløseren er døren.