Push-notifikationsautomatisering til e-handel: 5 arbejdsgangs-skabeloner

Det er den tredje fredag i kvartalet, og du kigger på dit fastholdelsesdashboard. Sekvensen for forladte indkøbskurve kører. Udløseren for forladte browsing kører. Anmodningen om anmeldelse efter køb kører. Advarslen om prisnedsættelse kører. Velkomstmeddelelser sendes ud ved hver tilmelding. Seks “automatiserede” push-meddelelser. Seks udløsere forbundet over de sidste atten måneder. Din gentagne købsrate stoppede med at bevæge sig for tolv måneder siden.

Sådan ser push-meddelelsesautomatisering til e-handel ud i de fleste mellemmarkedets fastholdelsessystemer: seks usammenhængende udløsere, der hver sender tekst fra en anden kampagneejer, ingen af dem bevidste om de andre. Serien for forladte indkøbskurve bliver ved med at sende meddelelser til abonnenter, der allerede har købt. Kampagnen for genaktivering overlapper med advarslen om prisnedsættelse for den samme kunde. Der er ingen delt logik, ingen delte exit-kriterier, ingen delt identitet. Bare seks separate rør, der hver peger på den samme abonnentliste, og hver foregiver, at de andre fem ikke eksisterer.

Push-meddelelsesautomatisering til e-handel bør ikke fungere sådan. Den bør fungere som én arbejdsgangsarkitektur: et sæt rejser med flere noder og delte udløsere, delt beslutningslogik og delte exit-kriterier, der kører på tværs af web push, app push, WhatsApp og live chat fra en enkelt abonnentidentitet. Denne artikel gennemgår, hvordan den arkitektur ser ud, leverer fem komplette arbejdsgangsblåtryk, du kan bruge, og viser, hvordan man læser den pr. arbejdsgangs tragt, så posten kan forsvares over for økonomiafdelingen.

De fleste “automatiserede push-meddelelser” er ikke rigtig automatiserede

Ordet automatisering har udført meget ufortjent arbejde på e-handelsblogkredsløbet. Når de fleste artikler siger “automatiserede push-meddelelser”, mener de “udløste push-meddelelser”: enkelte meddelelser, der sendes, når en begivenhed sker, uden yderligere tilstand, ingen ventetid, ingen forgreningsmuligheder, ingen exit-betingelser. En abonnent forlader en indkøbskurv, meddelelsen om forladt indkøbskurv sendes. En abonnent ser et produkt, meddelelsen om forladt browsing sendes. En abonnent køber, meddelelsen efter køb sendes. Hver udløser er sin egen pipeline, uvidende om enhver anden udløser.

En arbejdsgang er noget andet. En arbejdsgang er en rejse med flere trin og tilstand. Den ved, hvor abonnenten kom ind, hvor de er lige nu, hvornår de kom ind i hver node, og hvilke betingelser der annullerer rejsen. Arbejdsgangen for forladt indkøbskurv sender ikke bare én meddelelse efter en time. Den sender efter en time, venter en dag, tjekker, om indkøbskurven stadig er forladt, sender en anden kontakt med en rabat, venter yderligere to dage, sender en sidste kontakt og afslutter arbejdsgangen i det øjeblik, abonnenten køber, uanset hvilket trin de var på.

Den sidste klausul er forskellen. Udløseren har ingen hukommelse. Arbejdsgangen har. Hvis din “automatisering af forladte indkøbskurve” fortsætter med at sende påmindelser, efter at kunden allerede har betalt, har du ikke en automatisering. Du har en udløser, som ingen har fortalt at stoppe.

For et mellemstort e-handels fastholdelsesteam er denne skelnen forskellen mellem en gentagelseskøbsrate, der sammensættes, og en, der stagnerer. Seks triggere, der kører parallelt, producerer seks kanaler af støj. Fem arbejdsgange, der kører i koordination, producerer én rejse pr. abonnent, forgrenet og afgrænset. De fleste af side ét søgeresultater for dette nøgleord indrammer problemet som “hvilke slags notifikationer skal sendes” og besvarer med en liste med ni, tolv eller femten skabeloner. Det er ikke spørgsmålet. Spørgsmålet er, hvordan man sammensætter rejsen.

Anatomien af en push-notifikationsarbejdsgang

Før tegningerne, vokabularet. En push-notifikationsarbejdsgang er bygget af seks nodetyper. Når du ved, hvad hver enkelt gør, læses hver tegning i denne artikel som et diagram, ikke en beskrivelse.

START. Indgangspunktet. En START-node definerer, hvordan arbejdsgangen udløses, enten ved en abonnentbegivenhed (forladt indkøbskurv, vist side, tilmeldt segment, sporet købsmål) eller ved et publikumsfilter, der vælger abonnenter, der matcher specifikke kriterier på et planlagt tidspunkt. En arbejdsgang har præcis én START.

VENT. En forsinkelse. En VENT-node holder abonnenten på dette punkt i en specificeret varighed (minutter, timer, dage) eller indtil et specifikt kalendertidspunkt (tirsdag kl. 10 i abonnentens tidszone, 15. december kl. 20 webstedstid). Vent er, hvordan en arbejdsgang lærer ikke at være en engangs-udsendelse.

BESLUTNING. En tovejsforgrening. En BESLUTNING-node kontrollerer en betingelse (har abonnenten købt, er de stadig i segmentet for dem, der har forladt indkøbskurven, er deres loyalitetsniveau “guld”) og ruter dem ned ad JA-stien eller NEJ-stien. Beslutninger er, hvordan en arbejdsgang holder op med at behandle alle abonnenter ens.

SPLIT_PATH. En procentbaseret forgrening. SPLIT_PATH-noder ruter abonnenter på tværs af flere stier baseret på konfigurerede procenter: 50/50 til en A/B-test, 33/33/34 til en trevejs sendetidstest. Når du har en vinder, promoverer du den vindende sti til 100%, og arbejdsgangen fortsætter med at køre på den beviste variant.

HANDLING. Selve arbejdet. HANDLING-noder sender en push-notifikation, tilføjer abonnenten til et segment, opdaterer deres attributter, udløser en webhook, starter en anden arbejdsgang eller stopper en. PushEngage Workflows understøtter elleve handlingstyper. De mest almindelige inden for e-handel er SendPushNotification, AddSegment, UpdateAttribute og HttpRequest.

SLUT / EXIT. Terminalen. SLUT- og EXIT-noder markerer arbejdsgangen som fuldført og opdaterer analyser. SLUT er den naturlige konklusion. EXIT bruges typisk til at afslutte tidligt: på NEJ-stien af en Beslutningsnode, når abonnenten ikke kvalificerer sig, eller på en Split Path-gren designet som en kontrolgruppe.

Hver arbejdsgang nedenfor er sammensat af disse seks dele. Når vokabularet er delt, læses tegningerne hurtigt.

Fem arbejdsgangstegninger til e-handel

Disse er ikke “eksempler.” De er fungerende skabeloner. Hver enkelt angiver dens udløser, dens kørselstype, dens node-sekvens, dens exit-kriterier og dens tilsigtede fastholdelsesmetrik. Du kan overføre hver enkelt direkte til PushEngage Workflows-byggeren og få den kørende på under en time.

Skabelon 1 — Velkomstserie

• Udløser (START): Hændelse PushEngage.Subscriber.Added
• Kørselstype: Enkel (én velkomstrejse pr. abonnent, med en 90-dages nedkølingsperiode før genindtræden)
• Flow: Velkomstmeddelelse (øjeblikkelig) → VENT 2 dage → funktionsfremhævende meddelelse → VENT 3 dage → BESLUTNING: har abonnenten foretaget et køb? → JA-sti: send en takke-meddelelse og tilføj til kunder-segmentet → NEJ-sti: send en rabat på første køb → SLUT
• Exit-kriterier: Ingen. Rejsen er kort nok til, at alle abonnenter bør gennemføre den.
• Fastholdelsesmetrik: Tid til første køb. Nye abonnenter, der gennemfører velkomstserien, køber hurtigere end dem, der ikke gør, fordi det tredje kontaktpunkt lander i det øjeblik, hvor hensigten om første køb enten er materialiseret sig eller er gået i stå.

Skabelon 2 — Gennemse-afvisning

• Udløser (START): Brugerdefineret hændelse page_view filtreret til produktdetaljesider, hvor abonnenten heller ikke udløste add_to_cart inden for 30 minutter
• Kørselstype: Flere parallelle (en abonnent kan afvise flere produkter i en session, og hver enkelt får sin egen workflow-instans)
• Flow: VENT 30 minutter → BESLUTNING: browser abonnenten stadig på siden? → JA-sti: SLUT (afbryd ikke en aktiv session) → NEJ-sti: send en påmindelsesmeddelelse med det produkt, de så → VENT 24 timer → BESLUTNING: tilføjede de til kurven? → JA-sti: SLUT (workflowet for forladt kurv overtager herfra) → NEJ-sti: send en anden kontakt med en anbefaling af relaterede produkter → SLUT
• Exit-kriterier: Mål add_to_cart (kurv-workflowet overtager rejsen) eller mål purchase (ingen yderligere meddelelser nødvendig)
• Fastholdelsesmetrik: Konverteringsrate fra gennemse til kurv på tidligere sete produkter. PushEngage-indlægget om kampagner for gennemse-afvisning dækker segmenteringsarbejdet, som denne skabelon arver.

Skabelon 3 — Eskalering af forladt kurv

• Udløser (START): Brugerdefineret hændelse cart_abandoned
• Kørselstype: Flere parallelle (hver forladt kurv er sin egen rejse, så en abonnent, der efterlader en anden kurv, mens den første stadig er aktiv, får en anden samtidig instans)
• Flow: VENT 1 time → påmindelse #1 (ingen rabat, venlig tone) → VENT 24 timer → BESLUTNING: er kurven stadig forladt? → JA-sti: påmindelse #2 med 10% rabat → VENT 48 timer → BESLUTNING: er kurven stadig forladt? → JA-sti: sidste påmindelse med 20% rabat og ramme om hastværk → SLUT
• Afslutningskriterier: Mål purchase, der matcher cart_id fra trigger-begivenheden. I det øjeblik abonnenten køber, annulleres arbejdsgangen for den pågældende indkøbskurv, uanset hvor de aktuelt befinder sig.
• Fastholdelsesmetrik: Genvundet indkøbskurvsværdi pr. forladt indkøbskurv, pr. kanal. Dette er den arbejdsgang med størst indvirkning på siden og den nemmeste at forsvare på en resultatopgørelse. For dybere dækning af selve genoprettelsessekvensen for forladte indkøbskurve, gennemgår PushEngage-playbook for forladte indkøbskurve, hvordan kadencen er afstemt efter platformens adfærd (Shopify Plus-checkoutflows adskiller sig fra WooCommerce på måder, der påvirker den første ventetid).

Blueprint 4 — Anmodning om anmeldelse efter køb

• Trigger (START): Begivenhed PushEngage.Goal.Tracked, hvor goal_name = purchase
• Kørselstype: Flere sekventielle (én aktiv anmodningsrejse ad gangen pr. abonnent, men det næste køb udløser en ny instans)
• Flow: VENT 7 dage (længe nok til at modtage produktet og danne sig en mening) → SPLIT_PATH 50/50: morgenafsendelse (kl. 9 abonnent-lokal tid) versus aftenafsendelse (kl. 19 abonnent-lokal tid) → anmodning om anmeldelsesnotifikation → HANDLING: HTTP-anmodning til CRM'en, der logger afsendelsen af anmodningen om anmeldelse → SLUT
• Stilletid: kl. 22 til kl. 8 i abonnentens tidszone, fallback reschedule. Push-notifikationer, der ville blive leveret natten over, venter til kl. 8:01 i stedet for at blive afvist. reschedule-indstillingen er den rigtige standard for denne arbejdsgang, fordi skip lydløst afviser notifikationer og udelader dem fra analyser, hvilket de fleste fastholdelsesteams ikke ønsker.
• Afslutningskriterier: Mål review_submitted
• Fastholdelsesmetrik: Rate for indsendelse af anmeldelser efter afsendelsestidsvariant. Split-stien gør A/B-testen til en del af arbejdsgangen, ikke en eftertanke knyttet til en kampagnerapport.

Blueprint 5 — Genkøb

• Trigger (START): Målgruppefilter last_active > 30 days
• Kørselstype: Enkelt (ét win-back-forsøg pr. abonnent pr. 90-dages vindue)
• Flow: “Vi savner dig”-notifikation → VENT 3 dage → BESLUTNING: engagerede abonnenten sig med notifikationen eller besøgte webstedet? → JA-sti: tilføj til re-engaged-segment, send en tak og en rabat, SLUT → NEJ-sti: send et stærkere tilbud med en dybere rabat → VENT 5 dage → BESLUTNING: stadig inaktiv? → JA-sti: endelig “sidste chance”-notifikation → SLUT
• Afslutningskriterier: Målgruppefilter last_active < 7 days. Abonnenten blev aktiv af sig selv, og arbejdsgangens opgave er fuldført.
• Fastholdelsesmetrik: Genaktiveringsrate 60 dage efter arbejdsgangens start.

Et ord om udløseren. Dette er den eneste skabelon i denne artikel, der bruger en publikumsbaseret udløser i stedet for en hændelsesbaseret udløser. Publikumsudløsere i PushEngage Workflows behandler det matchende abonnentdatasæt i batch på starttidspunktet for arbejdsgangen. Abonnenter, der bliver inaktive, efter at arbejdsgangen er startet, inkluderes ikke automatisk, og redigering af publikumsfilteret på en aktiv arbejdsgang tilføjer ikke nye abonnenter. Hvis du ønsker et løbende genengagementprogram, skal du duplikere arbejdsgangen med jævne mellemrum (månedligt eller kvartalsvis) i stedet for at forvente, at en langvarig publikumsarbejdsgang fortsat indtager nye kandidater. Dette er en reel kilde til supportbilletter af typen "hvorfor fik denne abonnent ikke genvundet?" i teams, der misforstår udløsertypen.

Segmentering, A/B-test og exit-kriterier lever inde i arbejdsgangen

Det dominerende mønster på tværs af søgeresultaterne på side et for dette nøgleord er at liste segmentering, A/B-test og stille timer som "bedste praksis": generiske punkter i slutningen af artiklen, adskilt fra kampagnen, der bruger dem. Det er den forkerte ramme. Dette er ikke bedste praksis, der sidder ved siden af arbejdsgangen. De er arbejdsgangen.

Her er det samme sæt af koncepter, indrammet som bedste praksis versus indrammet som arbejdsgangsnoder:

Koncept	Bedste praksis-indramning (forkert)	Workflow-node-indramning (korrekt)
RFM-segmentering	"Segmenter din liste, før du sender"	En BESLUTNING-node, der kontrollerer recency, frequency og monetary value, og derefter ruter abonnenter med høj RFM til en anden sti end dem med lav RFM. PushEngage-indlægget om segmentering dækker RFM-bucket-definitionerne, der føder denne node.
A/B-test	"Test altid din tekst med A/B-test"	En SPLIT_PATH-node med 50/50 procentallokering, belastningsbalanceret abonnenter pr. sti og et winner_edge_id-felt, der promoverer vinderen til 100%, når testen når signifikans
Stille timer	"Send ikke kl. 3 om natten"	En arbejdsgangsindstilling med start_at, end_at, timezone og en fallback-indstilling, der enten skiper afsendelsen eller rescheduler den til et minut efter, at de stille timer slutter
Exit-kriterier	"Stop med at sende til folk, der har købt"	En arbejdsgangsregel, der kontrollerer abonnenten mod et publikumsfilter eller et udløst mål før hver node, og annullerer arbejdsgangen, hvis den matcher

Forskellen betyder noget, fordi punkter om bedste praksis er lette at nikke til og svære at håndhæve. Arbejdsgangsnoder håndhæves af selve motoren. BESLUTNING kører hver gang. SPLIT_PATH balancerer hver abonnent. Fallback for stille timer aktiveres uden, at nogen husker at tjekke tiden. Exit-reglen annullerer arbejdsgangen, uanset om kampagneejeren er opmærksom eller ej.

For skabelonen for forladt indkøbskurv ovenfor betyder dette, at i det øjeblik en abonnent køber de forladte varer, udløses exit-reglen, arbejdsgangen annulleres for den pågældende abonnent, og den anden og tredje påmindelse sendes aldrig ud. Ingen supportbillet, ingen e-mail fra økonomiafdelingen, ingen undskyldningskampagne. Arbejdsgangen stoppede, fordi motoren havde en regel, der fortalte den at stoppe.

Flerkanalsorkestrering: én arbejdsgang, fire kanaler

De fleste push-notifikationsplatforme er et-kanalværktøjer. Nogle er to-kanal. Spørgsmålet, de ikke kan besvare godt, er det, som et retentionsteam i mellemmarkedet faktisk har brug for at besvare: givet denne abonnents tilstand, hvilken kanal skal udløses? Web push, hvis de har tilmeldt sig. E-mail, hvis de har afmeldt sig web push. WhatsApp, hvis kurvens værdi er over $200. Live chat, hvis abonnenten i øjeblikket er på webstedet.

Det beslutningstræ er en enkelt multi-kanal push-notifikationsautomatiserings-workflow, ikke fire kampagner i fire værktøjer. Med PushEngage Workflows kan en kurv-forladt rejse komponeres således:

• START: cart_abandoned-begivenhed
• VENT: 1 time
• BESLUTNINGSnode 1: er abonnenten tilmeldt web push?
  • JA-sti: HANDLING, send web push-påmindelse
  • NEJ-sti: fortsæt til næste beslutning
• VENT: 30 minutter efter web push (eller straks, hvis ingen push blev udløst)
• BESLUTNINGSnode 2: klikkede abonnenten på web push, eller er der ingen tilmeldt web push?
  • Hvis web push blev udløst og klikket på: AFSLUT (lad kurveforløbet afslutte)
  • Hvis web push blev udløst og ikke klikket på, eller ingen web push: fortsæt
• BESLUTNINGSnode 3: kurv-værdi større end $200?
  • JA-sti: HANDLING, udløs WhatsApp-besked via SendPushNotification-handlingen på WhatsApp-kanalen
  • NEJ-sti: HANDLING, udløs e-mail via en HTTP-anmodning til din ESP
• AFSLUT ved mål køb

Fire kanaler, én workflow, ét sæt afslutningskriterier, én abonnentidentitet. Den samme retention manager, der tidligere ikke kunne orkestrere dette uden tre leverandør-logins og et Zapier-flow, kan nu komponere det inden for ét workflow, som motoren håndhæver.

At gøre det samme på tværs af separate værktøjer betyder seks synkroniseringer mellem platforme, to segmenteringsmotorer, der er uenige om, hvem der tæller som en "VIP-abonnent", og ingen enkelt omsætningsattribution, fordi hvert værktøj rapporterer sine egne konverteringer. At gøre det inden for én workflow-motor betyder én abonnentidentitet, ét sæt beslutningslogik og én funnel-rapport. For mere om, hvordan push og e-mail fungerer sammen inden for en enkelt retention-plan, se push og e-mail multi-kanal orkestrering.

Dette er differentiatoren, der ikke har en analog i de dominerende side-et resultater. Ingen af de top femten resultater for dette søgeord beskriver et cross-channel workflow som et enkelt objekt. De behandler alle push som emnet og e-mail som sammenligningen.

Retention-regnskabet: omsætning pr. workflow, pr. kanal, pr. notifikation

Et workflow, som du ikke kan forsvare ved den næste P&L-gennemgang, er et workflow, der bliver dræbt. Retention managerens job er at vise, i dollars, hvad hver enkelt post producerede. De fleste artikler om "automatiserede push-notifikationer til e-handel" stopper ved klikraten. Det er ikke nok. Den rigtige metrik er genvundet omsætning pr. abonnent, pr. workflow, pr. kanal.

PushEngage Workflows sporer tre tal ved hver knude:

• Køede brugere: abonnenter, der i øjeblikket venter ved denne knude (typisk en VENT eller en omlægning af stille timer)
• Gennemførte brugere: abonnenter, der passerede gennem denne knude
• Afsluttede brugere: abonnenter, der forlod workflowet ved denne node, enten fordi afslutningskriterierne matchede, eller fordi de afmeldte sig

Her er, hvordan node-niveauanalyse ser ud for et aktivt workflow for forladt indkøbskurv (illustrative tal, hentet fra en realistisk liste med 200.000 abonnenter):

Knude	Køet	Gennemført	Afsluttet	Noter
START (cart_abandoned)	0	12,400	320	320 abonnenter matchede exit-kriterier ved start af workflow (købt mellem kurv-begivenhed og workflow-scanning)
VENT 1 time	180	11,900	320	Normal kødybde
HANDLING: påmindelse #1	0	11,900	0	Notifikation sendt
VENT 24 timer	240	9,800	1,860	Højt antal exits: 1.860 abonnenter købte efter påmindelse #1
BESLUTNING: kurv stadig forladt	0	9,800	0	Alle resterende abonnenter har stadig kurven åben
HANDLING: påmindelse #2 (10% rabat)	0	9,800	0	Notifikation sendt med rabat
VENT 48 timer	90	6,300	3,410	Yderligere 3.410 køb udløste exit
HANDLING: sidste påmindelse (20% rabat)	0	6,300	0	Sidste notifikation
SLUT	ikke relevant	6,300	ikke relevant	6.300 abonnenter købte ikke

I denne tragt købte 5.270 abonnenter (1.860 + 3.410) mens de var i workflowet, en genvundet kurv-rate på 42,5%. De to ventetider (24t og 48t) er de noder med flest exits i tragten, hvilket er det forventede mønster: beslutninger om købstidspunkt sker i ventevinduerne, ikke i handlingsvinduerne. Hvis dit workflow viser det omvendte mønster, med mange exits ved handlingsnoder og få exits ved ventenoder, er din timing forkert, og ventetiderne bør forkortes.

Genberegningen af fastholdelse skal også adressere omkostninger. Push-notifikationer koster intet pr. afsendelse, når abonnenten har givet samtykke. E-mail-omkostninger afhænger af din ESP, men med en liste på 200.000 abonnenter og en typisk Klaviyo- eller Bloomreach-opsætning koster en enkelt afsendelse af forladt indkøbskurv flere hundrede dollars i forbrug (dine kontraktvilkår gælder).

En push-først automatiseret push-notifikation for forladt indkøbskurv, der genvinder kurve med 42%, kan nå det samme genvundne omsætningsbeløb som et push-og-e-mail-workflow med 38%, til en markant lavere pris. Kør beregningen på din egen listestørrelse og ESP-kontrakt. Pointen er, at push, app push og WhatsApp ikke medfører de omkostninger pr. afsendelse, som e-mail gør, og workflowets opgave er at bruge den billigste kanal først, når abonnentens tilstand tillader det.

Når linjeposten kan forsvares (dette workflow genvandt X dollars i kurve til en samlet omkostning på Y dollars), er budgetsamtalen kort.

Byg det i PushEngage Workflows

Hvert blueprint i denne artikel kortlægges direkte til PushEngage Workflows-komponenter. Her er kortlægningen for de fem ovenstående blueprints:

Skabelon	Brugte knudepunkttyper	Brugte handlingstyper	Arbejdsgangsindstilling
Velkomstserie	START, VENT, BESLUTNING, HANDLING, SLUT	SendPushNotification, AddSegment	Kørselstype: Enkel
Forladt browsing	START, VENT, BESLUTNING, HANDLING, EXIT	SendPushNotification	Kørselstype: Flere parallelle
Eskalering af forladt indkøbskurv	START, VENT, BESLUTNING, HANDLING, SLUT	SendPushNotification	Kørselstype: Flere parallelle; exit ved mål purchase
Anmodning om anmeldelse efter køb	START, VENT, SPLIT_PATH, HANDLING, SLUT	SendPushNotification, HttpRequest	Kørselstype: Flere sekventielle; stille timer 22:00 – 08:00, omplanlægnings-fallback
Genkøb	START, HANDLING, VENT, BESLUTNING, SLUT	SendPushNotification, AddSegment	Kørselstype: Enkel; publikumsbaseret udløser

Workflows-motoren leveres med 60+ leverede skabeloner, der dækker hver af disse flows. Hver skabelon er et udgangspunkt. Hvert blueprint ovenfor kan installeres på under fem minutter på Shopify, Shopify Plus, WooCommerce, BigCommerce eller Magento inde i PushEngage push-notifikations workflow-bygger.

Workflows-funktionen dækker også beslutningslogikken og personaliseringstrinene, der muliggør den flerkanalsrouting, der er beskrevet i det foregående afsnit, og understøtter de elleve handlingstyper, der giver dig mulighed for mere end blot at sende en notifikation: opdatere abonnentattributter, sende webhooks til dit CRM, starte nedstrøms workflows eller stoppe modstridende workflows.

For et bredere overblik over, hvordan disse workflows passer ind i et komplet e-handels fastholdelsesprogram, dækker hub-indlægget om e-handels push-notifikationer de kampagnetyper, som disse skabeloner implementerer.

Gratisplanen giver dig 200 abonnenter, alle fire kanaler (web push, app push, WhatsApp og live chat) og hele Workflows-motoren fra dag ét. Det er nok til at bevise kanalen, før du budgetterer med den.

Hvad dette ændrer

Hvis du tager én ting med fra denne artikel, så tag dette: push-notifikationsautomatisering til e-handel er workflow-arkitektur, ikke en pose udløste kampagner. Indkøbsvognsafbrydelsesrejsen, der afsluttes ved køb, velkomstserien, der forgrenes baseret på førstegangs købsadfærd, og orkestreringen på tværs af kanaler, der vælger den billigste levedygtige kanal for hver abonnent, har alle samme form.

Én START, nogle VENTETIDER, nogle BESLUTNINGER, nogle HANDLINGER, én AFS LUTNING. Seks selvstændige udløsere kan ikke gøre dette. Én workflow-motor kan. Fastholdelsesregnestykket vokser derfra.

Start med gratisplanen for at implementere den første skabelon på under en time.