Geactiveerde Pushcampagnes: Gids voor contextuele workflows

Het is de tweede week van het kwartaal en je retentiedashboard toont zes “geautomatiseerde” triggers die actief zijn, allemaal groen. De trigger voor winkelwagenverlating blijft afgaan bij abonnees die al betaald hebben. De win-back overlapt met de prijsverlagingsmelding voor dezelfde vervallen klant. De welkomstreeks verzendt meldingen onafhankelijk van de eerste-aankoop-stimulans.

Elke van de zes getriggerde pushcampagnes is een pijplijn die naar dezelfde abonneelijst wijst, waarbij elke campagne doet alsof de andere vijf niet bestaan. Het percentage herhaalaankopen is twaalf maanden geleden gestopt met bewegen en niemand in het team kan inkomsten per trigger toeschrijven omdat de triggers geen status delen.

Dit is de operationele realiteit in de meeste mid-market retentiestacks. Het probleem is niet strategie. De strategie is prima. Het probleem is architectuur. Een getriggerde melding in 2024 was een enkele boodschap die werd geactiveerd door een enkele gebeurtenis. In 2026 is die primitieve niet genoeg. De reis moet onthouden wat de abonnee deed, daarop vertakken en afsluiten wanneer ze converteren.

Dit artikel maakt de architecturale case. Het definieert de grens tussen broadcast-, getriggerde en contextuele pushmeldingen, loopt door het verschil tussen gebeurtenistriggers en audiotriggers, benoemt de zes knooppunttypen die een enkele trigger omzetten in een contextuele workflow, en levert drie migratiepatronen die zes zelfstandige triggers consolideren tot drie contextuele reizen met gedeelde exitcriteria en per-workflow-analyses.

Contextueel, getriggerd, broadcast: drie primitieven, niet één

Drie primitieven liggen ten grondslag aan elk pushmeldingsprogramma. De meeste teams laten ze samenvallen in één bak genaamd “campagnes”, waar het architectuurprobleem begint.

Broadcast. Dezelfde melding gaat naar het gehele overeenkomende publiek, gepland. Flash sale om twaalf uur. Nieuwe collectie melding op de lanceringsdag. Broadcast is de juiste primitief voor tijdsgebonden aankondigingen waarbij elke ontvanger dezelfde payload krijgt. Het is de verkeerde primitief voor alles wat afhangt van de status van de abonnee.

Getriggerd. Een enkele melding wordt geactiveerd wanneer een enkele gebeurtenis plaatsvindt. Abonnee verlaat een winkelwagen, de melding voor winkelwagenverlating wordt geactiveerd. Abonnee bekijkt een productpagina, de melding voor browsen wordt geactiveerd. Abonnee koopt, de melding na aankoop wordt geactiveerd. De trigger heeft geen geheugen. Hij weet niet wat er vijf minuten geleden is gebeurd of wat er volgende dinsdag gepland staat. Elke trigger is een pijplijn die onwetend is van elke andere trigger.

Contextueel. Een workflow gebruikt de trigger als het ingangspunt en past zich vervolgens aan de status van de abonnee aan. Dezelfde winkelwagen-verlatingsgebeurtenis start een reis met meerdere stappen: een wachttijd van een uur, een eerste herinnering, een wachttijd van 24 uur, een beslissing die controleert of de winkelwagen nog open is, een tweede herinnering met korting, een wachttijd van 48 uur, een derde herinnering en een exitregel die de workflow annuleert op het moment dat de abonnee koopt. De campagne is de workflow, niet de trigger. Contextuele pushmeldingen zijn hoe getriggerde berichten werken zodra de architectuur is bijgewerkt.

De drie primitieven komen goed overeen met drie workloads. Gebruik deze tabel wanneer u uw huidige stack auditeert.

Mogelijkheid	Uitzending	Getriggerd	Contextueel
Status per abonnee	Nee	Nee	Ja
Vertakkingen op gedrag	Nee	Nee	Ja
Exit-criterium	Nee	Nee	Ja
Multichannel routering binnen één campagne	Nee	Nee	Ja
Ingebouwde A/B (verzendingstijd, tekst, kanaal)	Nee	Nee	Ja
Juiste workload	Flash-verkopen, aankondigingen van lanceringen	Eenmalige transactionele pings (laag volume)	Levenscyclusreizen (welkom, winkelwagen, win-back, vernieuwing)

De meeste levenscyclusprogramma's hebben contextuele nodig. De meeste teams leveren getriggerde. Dat gat is waar dit artikel over gaat. De marketingautomatiseringsworkflows die contextuele reizen leveren, lijken niet op een langere lijst met triggers; ze lijken op een kleinere set reizen met meerdere stappen, samengesteld uit een gedeelde woordenschat. De pushmeldingworkflows die u daadwerkelijk wilt, zijn drie contextuele reizen, niet negen triggers.

Gebeurtenistriggers en audiotriggers gedragen zich heel verschillend

Vóór de knooppuntanatomie, een taxonomiepunt dat bijna elk artikel over dit onderwerp verkeerd krijgt. Een 'trigger' in pushmeldingworkflows is geen enkele primitieve. Het zijn twee primitieven die er van buitenaf hetzelfde uitzien en intern heel anders presteren.

Event triggers vuren per abonnee op een echte gebeurtenis. De ondersteunde gebeurtenissen in PushEngage Workflows omvatten PushEngage.Subscriber.Added, PushEngage.Subscriber.AddSegment, PushEngage.Subscriber.RemoveSegment, PushEngage.Subscriber.UpdateField, PushEngage.Subscriber.UpdateAttribute, PushEngage.Goal.Tracked en PushEngage.CustomEvent. Wanneer de gebeurtenis plaatsvindt, evalueert het systeem actieve workflows, controleert het gebeurtenisfiltercriteria, controleert het exitregels en plaatst het de overeenkomende workflow voor die abonnee in de wachtrij. De kloof tussen trigger en wachtrij is seconden. Event triggers zijn de juiste primitieve voor elke reactieve campagne: winkelwagenverlating, browseverlating, aankoopfollow-up, segment-join-welkomsten. Op gebeurtenissen getriggerde pushcampagnes zijn het dominante geval in e-commerce, SaaS-onboarding en elk programma met realtime signalen.

Publiekstriggers worden op een gepland tijdstip geactiveerd op basis van een filter. Het filter selecteert abonnees die voldoen aan specifieke criteria, zoals laatste_actief > 30 dagen, loyaliteit_niveau = goud, of stad = Amsterdam EN segmenten bevat "vip". De scheduler poller haalt de overeenkomende abonneesets in batches van 1000 op, spreidt de uitvoering met 15 seconden tot 2 minuten, en creëert één workflow-instantie per abonnee. Publiekstriggers zijn het juiste middel voor herbetrokkenheid, verjaardagscampagnes, geografische promoties en elk programma waarbij de set wordt gedefinieerd door attributen in plaats van gebeurtenissen.

De verschillen zijn operationeel belangrijk, niet alleen conceptueel:

Aspect	Gebeurtenis-trigger	Publiekstrigger
Initiatie	Real-time op basis van abonneegebeurtenis	Gepland via poller
Snelheid	Binnen enkele seconden	In batches, 1-2 minuten vertraging
Selectie van abonnees	Eén abonnee per gebeurtenis	Bulkselectie alleen bij workflow start
Nieuwe abonnees na start	Automatisch inbegrepen bij volgende gebeurtenis	NIET automatisch inbegrepen na start van workflow
Filterwijziging na start	N.v.t.	Het bewerken van het filter voegt GEEN nieuwe abonnees toe
Gebeurtenisgegevens beschikbaar	Ja (voor variabele vervanging)	Nee

De derde rij is de valkuil. Een op publiek gebaseerde workflow selecteert zijn abonneeset één keer, bij de start van de workflow. Abonnees die inactief worden nadat de workflow is gestart, worden niet automatisch toegevoegd. Het bewerken van het publieksfilter van een actieve workflow trekt geen nieuwe kandidaten aan. Een retentieteam dat een workflow voor "win-back voor abonnees die 30+ dagen inactief zijn" verzendt en deze negentig dagen laat lopen, zal gedurende de gehele negentig dagen dezelfde vaste groep zien, ook al bereiken dagelijks nieuwe abonnees de drempel van 30 dagen.

Het architecturale antwoord is om de publieksworkflow te dupliceren op een terugkerend schema, maandelijks of wekelijks, zodat elke duplicatie de kandidaten vastlegt die de drempel hebben overschreden sinds de laatste uitvoering. Dit is een operationele opmerking van één regel in de documentatie en een terugkerende bron van supporttickets "waarom kreeg deze abonnee de campagne niet?" in teams die publiekstriggers behandelen als gebeurtenistriggers.

De zes knooppunten die een trigger omzetten in een contextuele campagne

Zodra de trigger is geactiveerd, is de workflow zelf samengesteld uit zes knooppunttypen. Het vocabulaire is klein genoeg om in vijf minuten te leren en groot genoeg om elke contextuele campagne samen te stellen die een retentieteam ooit heeft willen verzenden.

START. Het ingangspunt. Een START-knooppunt definieert de trigger (gebeurtenis- of publieksgebaseerd) en de filtercriteria. Een workflow heeft precies één START. Het ingangspunt bepaalt de trigger-taxonomie uit de vorige sectie en stelt de gebeurtenis-data context in die downstream knooppunten kunnen lezen.

WACHTEN. Een vertraging. Een WAIT-node houdt de abonnee voor een bepaalde duur (minuten, uren, dagen) of tot een specifieke kalendertijd vast. Wachtacties zijn hoe een workflow de status en tijdzone van de abonnee respecteert. De workflow kan een uur wachten op een herinnering voor een verlaten winkelwagen, drie dagen op een functie-highlight in een welkomstreeks, of tot dinsdag 10.00 uur in de lokale tijdzone van de abonnee voor een verzending tijdens kantooruren. Wachtacties laten u ook een meerstaps-drip samenstellen zonder elke melding in de eerste zestig seconden te verzenden.

BESLISSING. Een tweerichtingsvertakking. Een DECISION-node controleert een gebeurtenisfilter of een doelgroepfilter en stuurt de abonnee via het JA-pad of het NEE-pad. Heeft de abonnee gekocht? Zitten ze nog in het segment van verlaten winkelwagens? Is hun loyaliteitsniveau veranderd? Beslissingsnodes zijn hoe gedragsgerichte pushmeldingen stoppen met het gelijk behandelen van elke abonnee en beginnen met aanpassen aan wat elke abonnee daadwerkelijk heeft gedaan. De ondersteunde operatoren omvatten gelijk aan, niet gelijk aan, in, niet in, groter dan, kleiner dan, en bestaat, wat voldoende is om elke beslissingslogica uit te drukken die een retentieteam nodig heeft.

SPLIT_PATH. Een op percentages gebaseerde splitsing voor A/B-testen. Een SPLIT_PATH-node stuurt abonnees over twee of meer paden op basis van geconfigureerde percentages: 50/50 voor een tweerichtings-test, 33/33/34 voor een drieweg verzendtijd-test, 90/10 voor een holdout-groep. Het systeem gebruikt een load-balancing-algoritme dat elke nieuwe abonnee naar het minst benutte pad stuurt, wat de distributie nauwkeurig houdt, zelfs bij kleine steekproefgroottes. Zodra de test significantie bereikt, stelt u winner_edge_id in en promoot de workflow 100% van het verkeer naar de winnende variant zonder de workflow opnieuw op te bouwen.

ACTIE. Het eigenlijke werk. ACTION-nodes doen meer dan alleen een pushmelding verzenden. PushEngage Workflows ondersteunt elf actietypen: SendPushNotification, AddSegment, RemoveSegment, UpdateField, UpdateAttribute, Update (gecombineerd), HttpRequest, CustomEvent.Send, SendTriggerCampaignEvent, Workflow.Start en Workflow.Stop. De vier meest voorkomende in retentieprogramma's zijn SendPushNotification, AddSegment (tag de abonnee als geconverteerd, onboarded of churn-risico), UpdateAttribute (verhoog een loyaliteitsteller of stel een laatste-aankoopdatum in), en HttpRequest (synchroniseer status met een CRM, vuur een Slack-waarschuwing af voor een hoogwaardige lead, of roep een downstream service aan).

EINDE / EXIT. De terminal. END- en EXIT-knooppunten markeren de voltooiing van de workflow en werken analyses bij. END is de natuurlijke conclusie. EXIT wordt doorgaans geplaatst op het NEE-pad van een beslissing wanneer de abonnee niet in aanmerking komt, of op een vertakkingssegment dat is ontworpen als controlegroep. Het systeem ondersteunt ook workflow-brede exitcriteria: een audience_filter of trigger_event die de actieve workflow annuleert voordat elke knoop wordt uitgevoerd. De exitregel wordt geactiveerd, ongeacht bij welke knoop de abonnee zich momenteel bevindt. Dit is wat voorkomt dat de workflow voor verlaten winkelwagens herinneringen stuurt naar abonnees die al hebben gekocht.

Elke contextuele campagne in dit artikel is samengesteld uit deze zes onderdelen. De onderstaande migratiepatronen lezen snel als het vocabulaire gedeeld is.

Drie migratiepatronen: zes zelfstandige triggers worden drie contextuele workflows

De meeste retentiestacks voor de mid-market hebben tussen de vier en acht zelfstandige triggers actief. Het patroon is consistent: welkomstmelding, eerste-aankoop-duwtje, verlaten winkelwagen, verlaten browse, verzoek om beoordeling na aankoop, win-back, reactivering, verlopen VIP. Elk hiervan is een aparte trigger met zijn eigen tekst, zijn eigen eigenaar en zijn eigen analyses. Geen van hen weet van elkaar. Dezelfde drie contextuele workflows kunnen dezelfde omzet genereren met een derde van de oppervlakte.

Patroon 1 — Onboarding consolidatie

Voeg de welkomstreeks en het eerste-aankoop-duwtje samen in één workflow met een beslissing over de aankoopstatus.

• START: Gebeurtenis PushEngage.Subscriber.Added
• Run type: Enkel (90 dagen cooldown na voltooiing)
• Flow: WACHT 1 dag → ACTIE stuur welkomstmelding → WACHT 3 dagen → BESLISSING: heeft de abonnee gekocht? → JA-pad: ACTIE stuur bedankje + ACTIE AddSegment naar customers + EINDE → NEE-pad: ACTIE stuur eerste-aankoop 10% korting → WACHT 4 dagen → BESLISSING: heeft de abonnee gekocht? → JA-pad: ACTIE stuur bedankje + EINDE → NEE-pad: ACTIE stuur laatste duwtje + EINDE
• Exitcriteria: Geen op workflow-niveau; de beslissingsvertakkingen regelen de geconverteerde abonnee
• Vervangt: Welkomsttrigger + eerste-aankoop-trigger (2 triggers → 1 workflow)

De gedeelde status is het hele punt. De derde melding wordt alleen geactiveerd voor abonnees die op dag vier nog niet zijn geconverteerd. De eerste-aankoop-trigger in de oude architectuur werd geactiveerd voor elke nieuwe abonnee, inclusief degenen die in hun eerste sessie kochten. De workflow blijft hen niet lastigvallen.

Patroon 2 — Winkelwagen-naar-beoordeling keten

Voeg de herstelworkflow voor verlaten winkelwagens en het verzoek om beoordeling na aankoop samen in één workflow met een workflow-chaining-overdracht.

• START: Aangepaste gebeurtenis cart_abandoned
• Run type: Meerdere parallelle (elke verlaten winkelwagen is zijn eigen instantie)
• Flow: WACHT 1 uur → ACTIE herinnering #1 → WACHT 24 uur → BESLISSING: winkelwagen nog steeds verlaten? → JA-pad: ACTIE herinnering #2 met 10% → WACHT 48 uur → BESLISSING: winkelwagen nog steeds verlaten? → JA-pad: ACTIE laatste herinnering met 20% → EINDE
• Exit criteria (workflow level): Goal.Tracked = purchase die overeenkomt met de cart_id van de triggergebeurtenis. Op het moment dat de abonnee koopt, wordt de workflow geannuleerd.
• Handoff: Bij afsluiting vanwege aankoop, vuurt het systeem PushEngage.Workflow.Start gericht op de review-request workflow. De review workflow start alleen voor abonnees die daadwerkelijk hebben gekocht. Het pad voor afsluiting vanwege niet-kopen slaat de handoff volledig over.
• Vervangt: Cart trigger + post-purchase review trigger + het support ticket van reviewverzoeken dat terechtkomt bij abonnees die nooit hebben gekocht (3 problemen → 1 workflow)

Het koppelen via Workflow.Start is het architecturale antwoord op levenscyclusprogressie. In plaats van twee triggers die onafhankelijk vuren en overlappen op dezelfde abonnees, is de exit-on-purchase van de cart workflow degene die de review workflow start. De review vuurt alleen voor geconverteerde abonnees. De cart vuurt nooit na conversie. De handoff wordt afgedwongen door de engine.

Patroon 3 — Herbetrokkenheid consolidatie

Voeg de win-back, de reactivatie en de lapsed-VIP campagnes samen in één workflow met een audience trigger en drie beslissingstakken.

• START: Doelgroepfilter last_active > 30 days
• Run type: Single (één re-engagement poging per abonnee per 90-dagen venster)
• Flow: BESLISSING: loyalty tier? → Gold branch: ACTIE stuur “we miss you, VIP” met 20% aanbieding → Silver branch: ACTIE stuur “we miss you” met 10% aanbieding → No-tier branch: ACTIE stuur standaard “we miss you” met gratis verzending aanbieding → WAIT 5 dagen → BESLISSING (per branch): heeft de abonnee interactie gehad of de site bezocht? → YES path: ACTIE AddSegment naar re-engaged + END → NO path: ACTIE stuur “last chance” met diepere aanbieding + END
• Exit criteria (workflow level): Audience filter last_active < 7 days. De abonnee is zelf actief geworden en de taak van de workflow is voltooid.
• Vervangt: Win-back trigger + reactivatie trigger + lapsed-VIP trigger (3 triggers → 1 workflow)
• Operationele opmerking: Volgens de audience-trigger valkuil in de vorige sectie, neemt deze workflow geen abonnees mee die de 30-dagen drempel overschrijden nadat de workflow is gestart. Dupliceer de workflow maandelijks zodat elke duplicaat de nieuwe kandidaten vastlegt. Een enkele langlopende audience workflow is hier de verkeerde primitieve.

Na deze drie migraties beheert het retentieteam drie contextuele reizen in plaats van zes (of acht) standalone triggers. Het totale volume van pushberichten blijft ongeveer hetzelfde. De over-messaging verdwijnt, omdat gedeelde exit criteria en beslissingstakken de workflow stoppen wanneer de status van de abonnee niet meer overeenkomt. De analytics fragmentatie gaat van “zes dashboards die ik niet kan rijmen” naar “drie funnels die ik kan verdedigen.” Zo zien event-triggered pushcampagnes eruit als ze volwassen worden.

Wat contextuele workflows doen wat zelfstandige triggers niet kunnen

Vier mogelijkheden bestaan binnen een contextuele workflow en kunnen niet worden samengesteld over zelfstandige triggers. Elk van hen is een echte bron van inkomsten of besparingen.

Cross-workflow exit criteria. Een zelfstandige trigger wordt geactiveerd wanneer de gebeurtenis plaatsvindt, punt uit. Binnen een workflow wordt de exit-regel geactiveerd, ongeacht op welk knooppunt de abonnee zich bevindt. De workflow voor verlaten winkelwagens eindigt bij aankoop. De win-back eindigt bij heractivering. De vernieuwingsworkflow eindigt bij vroege vernieuwing. De trigger waar niemand heeft gezegd te stoppen, is de workflow die een exit-regel definieert.

Multi-channel routing binnen één workflow. Met afzonderlijke single-channel tools vereist “push via web, terugvallen op e-mail, escaleren naar WhatsApp” drie leverancierslogins, twee segmentatie-engines en ten minste één Zapier-stroom. Binnen één workflow-engine zijn het drie ACTIE-knooppunten met twee BESLISSINGS-knooppunten ertussen, die één abonneejidentiteit en één set exit-criteria delen. Voor een diepere behandeling, zie de multi-channel push- en e-mailorkestratie post.

Stille uren met reschedule fallback. Pushmeldingen die om 3 uur 's nachts in de lokale tijdzone van de abonnee zouden landen, worden vastgehouden tot 8:01 uur als stille uren zijn geconfigureerd met reschedule als fallback. Het alternatief, skip, verwijdert de melding stilzwijgend en werkt de notificatie-analyses voor de overgeslagen actie niet bij. Voor de meeste retentieteams is reschedule de juiste standaard, omdat dropped analytics betekenen dropped revenue attribution. De contextuele pushmeldingen die een retentieteam daadwerkelijk wil verzenden, respecteren de tijdzones van de abonnee zonder uit de funnel te verdwijnen.

Workflow chaining. De acties Workflow.Start en Workflow.Stop maken levenscyclusprogressie een echte architectuur. De welkomstworkflow eindigt, wat de engagement-workflow start. De winkelwagen-workflow eindigt bij aankoop, wat de review-workflow start. Vergeleken met een map met triggers die allemaal onafhankelijk worden geactiveerd, is dit een state machine: een graaf van workflows, elk met zijn eigen ingangsconditie, uitgangsconditie en overdracht naar de volgende fase. Triggers kennen elkaar niet. Workflows wel.

Per-workflow-analyses: hoe de trechter te lezen

Een workflow die je niet kunt verdedigen bij de volgende P&L-review is een workflow die wordt stopgezet. PushEngage Workflows volgt drie getallen bij elk knooppunt (queued_users, completed_users, exited_users) plus workflow-brede totalen voor totaal-ingevoerd, momenteel-actief, voltooid en geëxiteerd. De taak van de retentiemanager is om deze funnel te lezen en de financiële afdeling te vertellen wat elk onderdeel heeft opgeleverd.

Hier ziet u hoe de analyses op knooppuntniveau eruitzien voor de winkelwagen-naar-review-keten uit Patroon 2 hierboven. Illustratieve cijfers, gebaseerd op een realistische lijst van 200.000 abonnees met een maandelijkse winkelwagen-afhaakpercentage van 6%.

Knooppunt	In wachtrij	Voltooid	Verlaten	Opmerkingen
START (winkelwagen_verlaten)	0	12,400	320	320 abonnees voldeden aan de exit-criteria bij workflow-start (gekocht tussen de winkelwagen-gebeurtenis en de workflow-scan)
WACHT 1 uur	180	11,900	320	Normale wachtrijdiepte
ACTIE: herinnering #1	0	11,900	0	Verzonden
WACHTEN 24 uur	240	9,800	1,860	1.860 abonnees kochten na herinnering #1 (afsluiten bij doel aankoop)
BESLISSING: winkelwagen nog steeds verlaten	0	9,800	0	Vertakking geëvalueerd
ACTIE: herinnering #2 (10%)	0	9,800	0	Verzonden
WACHT 48 uur	90	6,300	3,410	3.410 abonnees kochten na herinnering #2
ACTIE: laatste herinnering (20%)	0	6,300	0	Verzonden
EINDE	n.v.t.	6,300	n.v.t.	6.300 abonnees kochten niet; workflow voor beoordeling niet gekoppeld voor deze
Workflow.Start → workflow voor beoordeling	n.v.t.	5,270	n.v.t.	Geactiveerd voor de 5.270 abonnees (1.860 + 3.410) die kochten

De 5.270 gekoppelde overdrachten zijn de nieuwe metriek die deze architectuur naar voren brengt. De winkelwagenworkflow herstelde een winkelwagentarief van 42,5% (5.270 van de 12.400 ingevoerd) en alleen die 5.270 abonnees ontvangen de workflow voor beoordelingsverzoeken. De oude architectuur stuurde het beoordelingsverzoek naar iedereen die ooit had gekocht, inclusief abonnees die nooit een winkelwagen hadden achtergelaten, abonnees die de bestelling hadden geretourneerd en abonnees die al een beoordeling hadden ingediend. De architecturale oplossing is klein. De besparingen op overmatige berichten zijn groot.

Twee knelpunttypen zijn het weten waard. Een knooppunt met veel afslagen (zoals de twee WAIT-knooppunten hierboven) is de workflow die zijn werk doet: abonnees kopen tijdens de wachtvensters, de afsluitcriteria worden geactiveerd, de volgende herinnering wordt nooit verzonden. Het omgekeerde patroon, veel afslagen bij actieknooppunten in combinatie met weinig afslagen bij wachtknooppunten, betekent dat de timing verkeerd is en de wachttijden moeten worden verkort. Een knooppunt met veel wachtrijen betekent een pauze tijdens rustige uren, een lange wachttijd of een vertraging van een downstream poller; controleer de timingconfiguratie voordat u aanneemt dat de workflow defect is.

Voor een diepere, op eCommerce gerichte behandeling van deze patronen, gaat het begeleidende artikel over vijf pushmeldingworkflows voor eCommerce in op winkelwagen, browse, na aankoop, welkomstberichten en terugwinning als zelfstandige reizen. De eCommerce pushmeldingen hub behandelt het bredere landschap van campagnetypen, de winkelwagenverlating herstelreeks gaat in op de afstemming van de cadans per platform, en het overzicht van geautomatiseerde pushmeldingen toont de oudere lijst met automatiseringssoorten naast deze workflowarchitectuur.

Dezelfde analysevorm werkt in verschillende sectoren. SaaS heeft een vernieuwingsfunnel en een conversie van proefversie naar betaald. Uitgevers hebben een artikelbetrokkenheidsfunnel en een herintrede in het archief. Reizen heeft een boekingsfunnel en een prijsdalerwaarschuwingsstroom. De gedragsgerichte pushmeldingen die een SaaS-team gebruikt om de conversie van proefversie naar betaald te stimuleren, zien er structureel identiek uit aan die welke een eCommerce-team gebruikt om de conversie van winkelwagen naar aankoop te stimuleren: één START op een realtime gebeurtenis, drie of vier stappen met beslissingsvertakkingen, afsluitcriteria op conversie, optionele overdracht naar de volgende workflow. De sector verandert de trigger-namen en de aanbiedingstekst. De architectuur blijft.

Bouw het in PushEngage Workflows

Elk van de drie migratiepatronen hierboven komt rechtstreeks overeen met PushEngage Workflows-componenten.

Patroon	Gebruikte knooppunttypen	Gebruikte actietypen	Workflowoptie	Voorgesteld sjabloon startpunt
Onboarding consolidatie	START, WACHT, BESLISSING, ACTIE, EINDE	SendPushNotification, AddSegment	Run type: Enkel	“Welkomstreeks met eerste aankoopvertakking”
Winkelwagen-naar-beoordeling keten	START, WACHT, BESLISSING, ACTIE, EINDE	SendPushNotification, Workflow.Start	Run type: Meerdere parallelle; afsluitcriteria Goal.Tracked = purchase	“Escalatie bij verlaten winkelwagen”
Herbetrokkenheidsconsolidatie	START (publiek), BESLISSING, ACTIE, WACHT, EINDE	SendPushNotification, AddSegment	Run type: Enkel; publiekstrigger; maandelijks dupliceren	“Herbetrokkenheid met aanbieding op basis van niveau”

De Workflows-engine wordt geleverd met 60+ meegeleverde sjablonen die elk van de bovenstaande migratiepatronen dekken. Elk sjabloon is een startpunt. De patronen worden in minder dan vijf minuten geïnstalleerd op Shopify, Shopify Plus, WooCommerce, BigCommerce en Magento binnen de PushEngage Workflows-builder, of op elke SaaS-, uitgever- of reisstack via de JavaScript SDK en de events API.

Het gratis abonnement geeft je 200 abonnees, elk kanaal (web push, app push, WhatsApp en livechat) en de volledige Workflows-engine vanaf dag één. Dat is genoeg om een van de drie patronen van je huidige triggerstack te migreren en de architectuur te bewijzen voordat je budget aanvraagt. Begin met het gratis abonnement en implementeer de eerste contextuele workflow in minder dan een uur.

Als je één ding uit dit artikel meeneemt, neem dit dan mee: een getriggerde pushcampagne is niet langer de melding. Het is de workflow. Zes afzonderlijke triggers die los van elkaar draaien, zijn zes pijplijnen gericht op dezelfde abonneelijst, elk onbewust van de andere.

Drie contextuele workflows die draaien met gedeelde status, beslissingstakken, exitcriteria en gekoppelde overdrachten zijn één reis per abonnee, vertakt en begrensd. De marketingautomatiseringsworkflows die een verdedigbare per-workflow trechter en een herhaalaankoopratio die zich opstapelt produceren, zijn geen langere lijst met triggers; het zijn een kleinere, scherpere set contextuele reizen. De architectuur is de campagne. De trigger is de deur.