Geautomatiseerde WooCommerce pushmeldingen om 12+% van verlaten winkelwagens te herstellen

Het is dinsdag om 9 uur en je kijkt naar het WooCommerce-dashboard van een winkel met een GMV van $35 miljoen. Klaviyo heeft vorige week $4.800 aan verlaten winkelwagentjes hersteld. Het niet-herstelde deel is $46.000. Dat gat is geen Klaviyo-probleem. De e-mailreeks is prima. Het gat bestaat omdat e-mail een derde van de winkelwagen-afhakers helemaal niet kan bereiken: de open gebeurt nooit, het preview-venster gaat nooit open, de inbox blijft vol met orderbevestigingen van vorige week.

WooCommerce winkelwagen-afhakken pushmeldingen dichten dat gat niet door de e-mailreeks te vervangen, maar door deze parallel eraan te laten lopen met een andere timing, in een ander formaat, tegen een ander oppervlak.

Dit artikel is de workflow-specificatie die een WooCommerce retentiemanager daadwerkelijk nodig heeft: de exacte 3-bericht push-reis, de exacte gebeurtenisnamen, de exacte wachtvensters, de kortingsladder verdedigd in marge dollars, de exit-regel die de workflow stopt op het moment dat de winkelwagen converteert, en de per-winkelwagen attributieberekening die je aan financiën kunt presenteren.

Til het direct naar PushEngage en laat het binnen een uur draaien. De herstelde winkelwagen is gevonden omzet, geen betaalde omzet, en dat is de hele retentie/CAC-argument in één zin.

Waarom “push in plaats van e-mail” de verkeerde formulering is

De meeste artikelen over verlaten winkelwagentjes zetten een valse binaire keuze op. Push versus e-mail. SMS versus push. WhatsApp versus alle drie. De mid-market WooCommerce-winkels die 25-40% van de waarde van verlaten winkelwagentjes herstellen, kiezen er niet één. Ze stapelen. E-mail bereikt de inbox-gebruikers die e-mail twee keer per dag controleren. Push bereikt de desktop- en mobiele gebruikers die helemaal geen e-mail controleren, maar wel naar meldingen kijken. SMS bereikt de waardevolle winkelwagentjes waarbij het bericht binnen de volgende dertig seconden moet landen. De taak van de retentiemanager is het samenstellen van de gelaagde stapel, niet het debatteren over welk enkel kanaal wint.

Voor een WooCommerce-winkel die momenteel een e-mail-only reeks uitvoert, is de vraag niet "moet ik overschakelen op push". Het is "wat voegt push toe bovenop wat e-mail al doet". Het antwoord is eenvoudig. Push vuurt sneller dan e-mail opens (een eerste contact na 60 minuten landt een uur voordat de typische e-mail wordt geopend). Push is moeilijker te negeren (geen preview-venster). Push eindigt op de aankoopgebeurtenis, ongeacht welk kanaal krediet kreeg voor de conversie. Dit zijn additieve eigenschappen, geen vervangingen.

De rest van dit artikel is gebaseerd op die formulering. De onderstaande 3-bericht push-workflow gaat ervan uit dat je al een 3- of 4-bericht e-mail herstelreeks draait in Klaviyo, Omnisend, of welke ESP je ook gebruikt. Het vult die reeks aan in plaats van deze te vervangen.

Waarom WooCommerce push-vriendelijk is (en waar niet)

WooCommerce vuurt drie native gebeurtenissen af die dit alles beheersbaar maken. add_to_cart wordt geactiveerd telkens wanneer een product wordt toegevoegd. woocommerce_cart_updated wordt geactiveerd wanneer de winkelwagenstatus verandert. woocommerce_payment_complete wordt geactiveerd wanneer een bestelling is betaald.

De PushEngage WooCommerce-integratieplug-in koppelt deze aan een aangepaste PushEngage-gebeurtenis genaamd cart_abandoned (geactiveerd wanneer een winkelwagen inactief blijft na de afhaakdrempel) en aan een doel genaamd purchase (geactiveerd wanneer de betaling is voltooid). De cart_abandoned-gebeurtenis payload bevat cart_id, cart_value, cart_url (de herstellink) en een productlijst. Die payload wordt de variabelebron die de meldingen van de workflow gebruiken.

De PushEngage-integratie regelt ook het herstellen van de winkelwagen. Wanneer een abonnee op een pushmelding klikt, komen ze op de winkelwagen met hun artikelen al gevuld in plaats van op een lege productpagina. Dit is geen klein detail: een herstelde winkelwagen met een one-click checkout converteert ongeveer drie keer zo snel als een herstelde winkelwagen waarbij de abonnee de artikelen opnieuw moet toevoegen.

Herstel van de winkelwagen is een van de pushmeldingfuncties van WooCommerce die de PushEngage-integratie direct biedt; op platforms zonder de integratie moet het retentieteam de herstellink handmatig bouwen.

Er is één WooCommerce-specifieke valkuil om op te merken. Winkels die gebruikmaken van off-platform checkout (Stripe Checkout, PayPal hosted checkout, Mollie hosted, Klarna hosted) activeren woocommerce_payment_complete pas wanneer de klant terugkeert naar de bedankpagina. Als die omleiding nooit plaatsvindt (de klant sluit het browsertabblad op de gehoste pagina van Stripe na betaling), heeft de workflow geen manier om te weten dat de winkelwagen is geconverteerd. De oplossing is een doel-trackingpixel op de bedankpagina-omleiding die het PushEngage purchase-doel activeert met de cart_id. Zonder die pixel blijft de workflow herinneringen sturen naar abonnees die al hebben betaald, en dat is de faalmodus die elk retentieteam wil vermijden. Configureer de pixel voordat u de workflow inschakelt.

Twee aanvullende contextnotities. Ten eerste wordt de workflow-woordenschat in de rest van dit artikel (START, WAIT, DECISION, ACTION, END) gedefinieerd in de PushEngage Workflows builder en uitgebreid behandeld in het bovenliggende eCommerce-artikel. Ten tweede is deze WooCommerce-workflow voor verlaten winkelwagens een van de vijf WooCommerce-specifieke pushworkflows in deze serie; de andere (browse-verlating, prijsdaling, back-in-stock, post-aankoop) linken vanuit de afsluitende sectie.

De 3-bericht winkelwagen-afhakken workflow, van begin tot eind

Dit is het middelpunt. De volledige specificatie van de workflow voor verlaten winkelwagens.

Trigger en looptijd

• Trigger (START): PushEngage CustomEvent met event_name = cart_abandoned, geactiveerd door de WooCommerce-integratie wanneer een winkelwagen inactief blijft na de afhaakdrempel (doorgaans 60 minuten inactiviteit).
• Run type: Multiple Parallel. Een abonnee die winkelwagen A op dinsdag en winkelwagen B op vrijdag verlaat, krijgt twee gelijktijdige workflow-instanties, één per winkelwagen, elk met zijn eigen cart_id. Dit is cruciaal: een run type Single of Multiple Sequential zou het herstel van winkelwagen B blokkeren totdat de workflow van winkelwagen A is voltooid, en een terugkerende klant die voor de tweede keer afhaakt, krijgt niets.
• Exit criteria: Doel purchase dat overeenkomt met de cart_id van de trigger-gebeurtenis. Op het moment dat het WooCommerce purchase doel voor die winkelwagen wordt geactiveerd, wordt de workflow voor die abonnee geannuleerd, ongeacht waar ze zich momenteel in de reis bevinden.
• Quiet hours: 22:00 tot 08:00 in de tijdzone van de abonnee, fallback reschedule. De reschedule instelling houdt meldingen vast tot 08:01 lokale tijd in plaats van ze te laten vallen, wat de meeste retentieteams verkiezen omdat gevallen meldingen ook uit de analyse verdwijnen.

Stroom

WAIT 1 uur → Bericht 1 (geen korting) → WAIT 24 uur → BESLISSING: winkelwagen nog steeds verlaten? → JA pad: Bericht 2 (10% korting) → WAIT 48 uur → BESLISSING: winkelwagen nog steeds verlaten? → JA pad: Bericht 3 (20% korting + urgentie) → EINDE.

De NEE-paden op beide beslissingsknooppunten leiden naar EXIT (de winkelwagen is geconverteerd tussen de wachtperiodes en de taak van de workflow is voltooid).

Meldingskopie

Bericht 1 (1 uur na verlating, geen korting):

• Titel: Je hebt iets achtergelaten
• Body: Je {{event.data.product_name || cart}} is er nog. Wil je de bestelling afronden?
• URL: {{event.data.cart_url}}

Bericht 2 (25 uur na verlating, 10% korting):

• Titel: Nog aan het nadenken? Hier is 10% korting
• Body: Je {{event.data.product_name || cart}} is één klik verwijderd. Gebruik SAVE10 bij het afrekenen.
• URL: {{event.data.cart_url}}?coupon=SAVE10

Bericht 3 (73 uur na verlating, 20% korting, urgentie):

• Titel: Laatste kans: 20% korting op je winkelwagen
• Body: We hebben je {{event.data.product_name || cart}} nog een dag bewaard. Code SAVE20 verloopt vanavond.
• URL: {{event.data.cart_url}}?coupon=SAVE20

Elke titel blijft onder de 50 tekens en elke body onder de 130 tekens, waardoor ze zichtbaar blijven zonder afbreking op Chrome desktop, iOS Safari 16.4+ en Android Chrome. De || syntax biedt een fallback als de variabele productnaam ontbreekt.

Waarom 1 uur, 25 uur en 73 uur

De drie wachtperiodes zijn niet willekeurig. Elk venster vangt een andere herstelpsychologie op.

1 uur. De eerste aanraking vangt de 'Ik ging elders prijzen vergelijken'-afhaker voordat het sessiegeheugen vervaagt. De meeste winkelwagens die ooit worden hersteld, doen dat binnen het eerste uur. De meeste die het eerste uur zonder conversie passeren, zullen niet converteren zonder een tweede aanraking. Een eerste wachtperiode van 30 minuten is te vroeg: het onderbreekt het vergelijken van winkelen waar de klant actief mee bezig is. Een eerste wachtperiode van 4 uur is te laat: de winkelwagencontext is verdwenen. Eén uur zit op het keerpunt.

25 uur. De tweede melding komt de volgende dag, opzettelijk 25 uur in plaats van precies 24 uur, zodat iemand die 's avonds afhaakt, de tweede melding niet op hetzelfde tijdstip ontvangt als de eerste (wat het brein als spam ervaart). Een wachttijd van 25 uur verplaatst de tweede melding naar de routine van de volgende ochtend voor mensen die 's avonds afhaken, of naar de volgende avond voor mensen die 's ochtends afhaken, wat het praktische bereik is voor een aanbieding van 10% korting.

73 uur. Laatste poging voordat de winkelwagen 'koud' wordt. Drie dagen later, de intentie van de abonnee is ofwel via een ander kanaal gerealiseerd (in welk geval de exit-regel al is geactiveerd) ofwel volledig gestagneerd. Een korting van 20% met urgentie is de laatste haalbare zet voordat de winkelwagen waardeloos is. Langer dan 96 uur wachten levert een afnemend herstelpercentage op tegen gegarandeerde margeskosten; korter dan 48 uur na Bericht 2 leert abonnees om te wachten op de korting.

Stille uren omvatten de hele reeks. Een eerste melding van een gebruiker die om 23:00 uur afhaakt, zou anders om middernacht aankomen. Met reschedule ingesteld op 08:01 uur, wordt het bericht uitgesteld tot de volgende ochtend. De workflow voor het verlaten van de winkelwagen blijft leveringsverantwoordelijk in plaats van stil verzendingen 's nachts te laten vallen.

De kortingsladder-verdediging

De kortingsladder is 0% / 10% / 20%. Het voor de hand liggende alternatief is een vaste 15% voor alle drie de meldingen. De ladder wint op netto herstelde inkomsten, zelfs als de vaste structuur wint op het ruwe herstelpercentage. Hier is de wiskunde op een representatieve schaal voor WooCommerce in het middensegment.

Scenario. 200.000 push-abonnees. 70% afhaakpercentage van de winkelwagen. $145 gemiddelde bestelwaarde. Ongeveer 12.000 verlaten winkelwagens per week gevolgd via de push-workflow (na overlap van abonnees met e-mail).

Vaste 15% voor alle drie de meldingen. Stel dat dit het ruwe herstelpercentage verhoogt naar 30%. Dat herstelt 3.600 winkelwagens per week bij een AOV van $145 = $522.000 bruto. Elke herstelde winkelwagen betaalt 15% korting, dus de netto herstelde inkomsten zijn $522.000 × 0,85 = $443.700 per week.

0/10/20 ladder. Stel dat dit een ruw herstelpercentage van 25% oplevert (lager, omdat Bericht 1 geen stimulans heeft). Maar het herstel verspreidt zich over de drie meldingen: 12% converteert op Bericht 1 (geen korting), 8% op Bericht 2 (10%), 5% op Bericht 3 (20%). Netto per winkelwagen: 12% × $145 + 8% × $145 × 0,90 + 5% × $145 × 0,80 = $17,40 + $10,44 + $5,80 = $33,64 per verlaten winkelwagen. Over 12.000 winkelwagens is dat $403.680 per week, iets minder dan vast.

Maar de bruto-marge realiteit is scherper. De meeste WooCommerce-winkels in het middensegment draaien op een bruto-marge van 35-45%. Een vaste korting van 15% verlaagt die marge naar 20-30%. Een conversie van 0% op Bericht 1 behoudt de volledige marge. Het retentieteam dat de ladder beheert, geeft ongeveer 3 procentpunten van het herstelpercentage op (28% versus 31%) en herstelt een materieel groter deel van de marge dollars. Netto bijdragemarge, niet bruto herstelde inkomsten, is het juiste getal om te verdedigen.

Het tweede argument voor de ladder is training van abonnees. Een lijst die consequent 15% korting ziet in elke winkelwagenherinnering, leert te wachten op de korting. Het herstelpercentage van het volgende kwartaal bij een vlakke 15% daalt omdat abonnees het patroon hebben geleerd. Een 0/10/20 ladder behoudt de optie om tegen volledige prijs te converteren.

Het derde argument is segmentatie. Een abonnee die converteert bij Bericht 1 is een klant met hoge intentie die het waard is om anders te her-targeten in de volgende campagne. Een abonnee die alleen converteert bij Bericht 3 is prijsgevoelig en de moeite waard om te segmenteren in een prijsgestuurd retentiepad. De ladder produceert signaal; de vlakke korting produceert ruis.

Per-winkelwagen attributie en de herstelde-omzet berekening

Push workflow-analyses in PushEngage volgen drie getallen bij elke knooppunt: wachtende gebruikers (wachtend bij dit knooppunt), voltooide gebruikers (doorgegeven) en vertrokken gebruikers (verlieten de workflow bij dit knooppunt, meestal omdat de exit-regel werd geactiveerd).

Hier ziet de analyse op knooppuntniveau eruit voor een actieve WooCommerce winkelwagenverlatingsworkflow die draait op de winkel met 200.000 abonnees en een AOV van $145:

Knooppunt	In wachtrij	Voltooid	Verlaten	Opmerkingen
START (winkelwagen_verlaten)	0	11,940	240	240 winkelwagens geconverteerd tussen event fire en workflow scan
WACHT 1 uur	220	11,720	0	Normale wachtrijdiepte
ACTIE: Bericht 1	0	11,720	0	Melding verzonden
WACHTEN 24 uur	280	9,290	2,150	2.150 winkelwagens geconverteerd bij Bericht 1 (herstel met de hoogste intentie)
BESLISSING: nog steeds verlaten?	0	9,290	0	Resterende winkelwagens gecontroleerd tegen doel
ACTIE: Bericht 2 (10% korting)	0	9,290	0	Melding verzonden met SAVE10
WACHT 48 uur	120	7,460	1,710	1.710 winkelwagens geconverteerd bij Bericht 2
BESLISSING: nog steeds verlaten?	0	7,460	0	Laatste controle
ACTIE: Bericht 3 (20% korting)	0	7,460	0	Melding verzonden met SAVE20
EINDE	n.v.t.	7,460	n.v.t.	7.460 winkelwagens werden niet hersteld via push

Totaal hersteld via push: 240 (pre-touch) + 2.150 + 1.710 = 4.100 winkelwagens. Ruw push-herstelpercentage: 4.100 / 12.180 = 33,7%. Herstelde winkelwagenwaarde bij $145 AOV = $594.500 bruto per week. Netto van de ladderkorting (240 winkelwagens tegen 0%, 2.150 tegen 0%, 1.710 tegen 10%), netto-inkomsten = $570.795 per week.

Lees de funnel als volgt. De twee wachtperiodes (24 uur en 48 uur) zijn de knooppunten met de meeste exits, wat het juiste patroon is: klanten besluiten te kopen tijdens de wachtvensters, niet tijdens het lezen van de melding. Als uw workflow het omgekeerde laat zien (veel exits bij actieknooppunten, weinig bij wachtperiodes), is de timing te lang en moet u de wachtperiodes verkorten. Als het START-knooppunt ongebruikelijk veel exits laat zien, is de verlatenheidsdrempel te kort en vangt u winkelwagens op die nooit echt verlaten waren.

Dit is de herstelde-inkomstenregel die een retentiebeheerder kan verdedigen bij de volgende P&L-review. WooCommerce pushmeldingen hebben vorige week $570.795 netto hersteld via de workflow voor het verlaten van winkelwagens, tegen een kostprijs van nul per pushverzending en de abonnementskosten van het platform. De kosten per herstelde dollar zijn klein genoeg dat de financiële afdeling geen vervolgvragen heeft.

Multi-channel orkestratie: push + e-mail + WhatsApp + live chat

De bovenstaande pushworkflow met 3 berichten loopt parallel aan de e-mailherstelreeks. Dezelfde workflowarchitectuur kan ook escaleren tussen kanalen op basis van de status van de abonnee. Met één workflow-engine stelt de reis zich als volgt samen:

• START: cart_abandoned event met cart_id en cart_value
• WACHTEN: 1 uur
• BESLISSING 1: is de abonnee geabonneerd op web push? JA: stuur web push herinnering; NEE: ga door
• WACHTEN: 30 minuten
• BESLISSING 2: is de push verzonden en is erop geklikt? JA: EXIT; NEE: ga door
• BESLUIT 3: is cart_value > $200? JA: stuur WhatsApp-bericht; NEE: stuur e-mail via HTTP-verzoek naar ESP
• BESLUIT 4: is de abonnee momenteel ter plaatse? JA: activeer live chat ping; NEE: ga verder naar Wacht op Bericht 2
• AFSLUITEN op doel purchase

Vier kanalen, één workflow, één set exitcriteria, één abonnee-identiteit. Dit is de orkestratie die retentieteams niet kunnen samenstellen wanneer elk kanaal in een andere tool zit. Met afzonderlijke leveranciers wordt de winkelwagenworkflow zes synchronisaties, twee segmentatiemachines die het oneens zijn over wie als VIP telt, en geen uniforme omzettoerekening.

Met één workflow-engine is de reis één object. Voor meer informatie over hoe push en e-mail samenwerken binnen één retentieplan, zie het hoofdartikel over push- en e-mail orkestratie voor meerdere kanalen.

Zijbalk: het beheren van de winkelwagen-workflow vanuit je AI-assistent

Met WordPress-plugin 4.2.4 en de WordPress Abilities API wordt de winkelwagenworkflow beheersbaar vanuit elke MCP-bewuste AI-assistent. De plugin stelt pushengage/list-push-automation-campaigns (geeft de huidige WooCommerce push-automatiseringsconfiguratie terug) en pushengage/update-push-automation-campaign (schakelt een campagne in, uit of herconfigureert deze op ID) beschikbaar. Beide mogelijkheden vereisen dat de gebruiker de WordPress-capability manage_options heeft en dat WooCommerce actief is op de site.

Voor een retentiemanager die Claude, ChatGPT of Cursor gebruikt met de PushEngage MCP blootgesteld, betekent dit dat de workflow voor winkelwagenverlating kan worden onderbroken tijdens een geplande site-uitval, daarna opnieuw kan worden ingeschakeld, of opnieuw kan worden geconfigureerd om kopievarianten te wisselen zonder WP admin te openen. Meer hierover in de aankondiging van PushEngage AI-assistenten.

Bouw het in PushEngage

Het installatiepad is kort. Installeer de PushEngage-plugin op de WooCommerce-site (deze detecteert automatisch WooCommerce en stelt de WooCommerce-specifieke gebeurtenissen beschikbaar). Verbind de plugin met een PushEngage-account. Importeer de sjabloon voor de workflow voor winkelwagenverlating in de PushEngage Workflows builder.

Het wordt geleverd met de 1u / 25u / 73u timing, de kortingsladder-placeholders en de exit-on-purchase regel al geconfigureerd. Wissel de placeholder-coupons in voor uw echte codes. Configureer de drempelwaarde voor verlating (standaard 60 minuten is redelijk voor de meeste winkels). Activeer de workflow. Bekijk de eerste 200 verlaten winkelwagens die erdoorheen lopen voordat u opschaalt.

Als dit de eerste PushEngage-workflow op de winkel is, geeft het gratis abonnement u 200 abonnees en de volledige Workflows-engine, genoeg om het kanaal te bewijzen op een gecontroleerde lijst voordat u budget aanvraagt voor een betaalde laag. Begin met het gratis abonnement om deze week de eerste instantie uit te voeren.

Wat dit verandert

Dit artikel is een van de vijf WooCommerce-specifieke push-workflowspecificaties. De broers behandelen WooCommerce browse-verlatingsworkflow, prijsdalerwaarschuwingen, back-in-stock meldingen en WooCommerce post-purchase workflow. Voor de bredere cross-platform behandeling van winkelwagenverlating behandelt de bredere playbook voor winkelwagenverlating het onderwerp op strategisch niveau.

Voor waar dit past in een compleet e-commerce retentieprogramma, is de ecommerce pushmeldingen hub post het overzicht.

De retentiemanager die dinsdag het WooCommerce-dashboard opent en $46.000 aan onherwonnen winkelwagens ziet, heeft een keuze. Blijf de e-mailreeks optimaliseren die een plateau heeft bereikt, of leg pushmeldingen erbovenop als het tweede kanaal dat op andere tijden, in een ander formaat en met een andere exitregel draait. De bovenstaande workflow van 3 berichten, die parallel loopt aan elke e-mailcadans die al is ingesteld, herstelt de 12-25% van de winkelwagenwaarde die e-mail niet kan bereiken.

Met de 0/10/20 kortingsladder levert de herstelde omzet een hogere nettowinstmarge op dan een workflow met een vaste korting. Met de exit-on-purchase regel stopt de workflow met het afvuren van berichten op het moment dat de winkelwagen converteert. Met per-node analyse is het specificatie verdedigbaar voor financiën op basis van cijfers, niet anekdotes. Dat is het volledige argument voor het herstellen van verlaten winkelwagens, en het volledige argument voor automatisering van winkelwagenherstel, in één workflow.