75% van de winkelwagens wordt verlaten. Deze WooCommerce browse-workflow helpt.

Het is maandagochtend bij een WooCommerce-winkel voor huishoudelijke artikelen met een GMV van $ 20 miljoen en de retentiemanager leest de trechter van vorige week in Google Analytics. Weergaven van productdetailpagina's: 180.000. Toevoegingen aan winkelwagens: 18.000. Aankopen: 1.800. Het Klaviyo-dashboard toont $ 3.200 die vorige week zijn teruggehaald uit winkelwagenverlating.

De browse-abandonment-lijn op hetzelfde dashboard leest nul, omdat Klaviyo browse-abandoners niet kan bereiken. Er is geen e-mail voor hen vastgelegd. Ze bezochten een productdetailpagina, voegden niets toe aan de winkelwagen en vertrokken. 162.000 bezoekers zijn deze week onzichtbaar voor e-mail.

Dit is het publiek waarvoor WooCommerce browse-abandonment pushmeldingen zijn gemaakt. Web push opt-in wordt geactiveerd bij het eerste gekwalificeerde bezoek, niet bij het vastleggen van e-mail in de winkelwagenfase. Dat enkele timingverschil betekent dat de browse-abandoner die nooit een e-mailadres invoert nog steeds bereikbaar is.

Een workflow van 3 berichten met de juiste exit-logica kan 8-14% van hen converteren naar toevoegen aan winkelwagen, wat bij 162.000 bezoekers per week een post is die het retentieteam kan verdedigen bij de volgende P&L-beoordeling. De rest van dit artikel behandelt die workflow, de exacte gebeurtenisinstrumentatie die het nodig heeft op de WooCommerce-stack en de retentiemathematiek bij drie lijstgroottes.

Browse-abandonment is niet winkelwagen-abandonment is niet sessie-abandonment

Definities, kort gezegd, omdat de SERP de drie door elkaar haalt. Browse-afhaken is een bezoek aan een productdetailpagina zonder een toevoeging aan de winkelwagen binnen dertig minuten. Winkelwagen-afhaken is een toevoeging aan de winkelwagen zonder afronding van de bestelling. Sessie-afhaken is een bezoek dat helemaal geen productdetailpagina heeft bereikt. Elk heeft een andere trigger, een ander publieksbereik en een andere workflow.

Het grootteverschil is de kop. Op een typische WooCommerce-winkel voor het middensegment, zijn er voor elke winkelwagen-afhaker vijf tot acht browse-afhakers. De funnel voor winkelwagen-afhaken wordt goed bediend door e-mail, omdat de klant hun adres heeft vastgelegd op het moment van de bestelafhandeling. De funnel voor browse-afhaken wordt helemaal niet bediend door e-mail, omdat er geen e-mail is vastgelegd. Daarom is het herstel van productpagina-afhaken het stille, oneconomische deel van de meeste retentiestacks geweest. Push lost het adresprobleem op, omdat het opt-in-evenement een browser-native dialoog is die wordt geactiveerd bij het eerste gekwalificeerde bezoek.

Trechterfase	Trigger-gebeurtenis	Typisch wekelijks volume op een winkel met een GMV van $ 20 miljoen	Erfende workflow
Sessie-abandonment	page_view (elke pagina)	erg hoog, ruis	geen aanbevolen
Browse-abandonment	page_view op productdetail zonder add_to_cart binnen 30 minuten	144,000	de browse-workflow in dit artikel
Winkelwagen-abandonment	add_to_cart zonder purchase binnen 60 minuten	18,000	de winkelwagen-abandonment workflow

De browse workflow gaat over in de winkelwagen workflow op het moment dat een browse-abandoner iets toevoegt aan de winkelwagen. Deze overdracht is belangrijk en wordt in de meeste browse-inhoud genegeerd. De twee workflows delen een event-taxonomie en de winkelwagen workflow erft een gedeeltelijk gekwalificeerde abonnee van de browse workflow telkens wanneer de derde aanraking landt.

Waarom push het enige praktische kanaal is voor browse-abandonment

E-mail heeft een e-mailadres nodig. Een browse-abandoner op een WooCommerce storefront heeft er nog geen. Het PushEngage opt-in dialoogvenster wordt geactiveerd bij het tweede paginaweergave of na een configureerbaar interactiesignaal, en eenmaal geaccepteerd is de abonnee bereikbaar voor de rest van hun apparaatlevensduur zonder ooit hun adres te geven. Dit is de operationele aanname die browse herstelautomatisering economisch levensvatbaar maakt. WooCommerce pushmeldingen bereiken de anonieme bezoeker op een manier die geen enkel ander kanaal bereikt tegen acceptabele kosten.

De andere opties hebben economieën die een P&L-review bij browse-afhakingsvolume niet overleven. Betaalde remarketing op Meta en Google Ads rekent CPM-per-impressie en vreet CAC-budget voor elke browse-afhaker die je opnieuw aanraakt, ongeacht of ze converteren. SMS heeft een telefoonnummer nodig, wat nog onwaarschijnlijker is dan een e-mail in de browse-fase.

E-mail heeft een e-mail nodig. Push kost na een enkele opt-in bijna niets per verzending. Bij een WooCommerce-lijst van 200.000 abonnees is de marginale kosten van een browse-afhakingsverzending effectief het fractie van een cent dat de push-serviceprovider rekent voor leveringsinfrastructuur, niet een per bericht gemeten vergoeding.

De retentie/CAC-berekeningen volgen daaruit. Voor dezelfde herstelde omzet kost browse herstelautomatisering via push een fractie van de betaalde remarketing-alternatief. Dat is het argument voor de regel, en het leeft op de WooCommerce-stack omdat WooCommerce-winkels de neiging hebben productdetailpagina's te hebben die out-of-the-box goed zijn uitgerust voor page_view tracking.

De 3-bericht workflow voor browse-abandonment

Hier is de volledige workflow. Trigger: een PushEngage aangepaste gebeurtenis page_view gefilterd op productdetailpagina's (waar is_product = true) en waarbij de abonnee niet ook add_to_cart heeft geactiveerd binnen dertig minuten. Uitvoertype: Meerdere Parallelle, zodat een abonnee die vijf verschillende producten in een sessie bekijkt, vijf gelijktijdige workflow-instanties kan hebben die elk gericht zijn op het juiste product. Exit-criteria: doelen add_to_cart (de winkelwagen-workflow erft) of purchase (geen verdere berichten nodig).

Blueprint — De 3-bericht workflow voor browse-abandonment

• START: Aangepaste gebeurtenis page_view, filter is_product = true, EN geen add_to_cart van dezelfde abonnee binnen 30 minuten
• WACHTEN: 30 minuten
• BESLISSING 1: is de abonnee momenteel actief op de site (session_activity vlag ingesteld binnen de laatste 5 minuten)?
  • JA pad: EXIT (onderbreek geen actieve sessie; de workflow evalueert opnieuw bij een nieuwe trigger)
  • NEE pad: doorgaan
• ACTIE (Bericht 1): Stuur een webpush-melding ter herinnering aan het specifieke product dat is bekeken. Titel: “Nog aan het denken over {{event.data.product_title}}?” Body: “Het ligt precies waar je het hebt achtergelaten. Tik om verder te gaan.” URL: de URL van de productpagina. Afbeelding: {{event.data.product_image}}.
• WACHTEN: 4 uur
• BESLISSING 2: heeft de abonnee het product aan de winkelwagen toegevoegd?
  • JA-pad: AFSLUITEN (winkelwagen-verlatingsworkflow wordt overgenomen)
  • NEE pad: doorgaan
• ACTIE (Bericht 2): Stuur een webpush-melding met gerelateerde producten. Titel: “Misschien vind je deze ook leuk uit onze {{event.data.category}} collectie.” Body: “Drie suggesties vergelijkbaar met {{event.data.product_title}}.” URL: de WooCommerce categorie-archiefpagina. Afbeelding: de eerste gerelateerde productafbeelding.
• WACHTEN: 48 uur
• ACTIE (Bericht 3): Stuur een webpush-melding met kortingsontdekking. Titel: “Je had je oog op dit laten vallen.” Body: “We hebben het voor je bewaard met 10% korting. Code: BROWSE10.” URL: de productpagina-URL met de kortingscode vooraf toegepast.
• EINDE

Dat is de volledige workflow voor het verlaten van de browse-sessie. Drie berichten, twee wachttijden met beslissingen, één stille exit-tak, twee doelgerichte exits. De productweergavemeldingen in Bericht 1 en Bericht 3 pushen elk het oorspronkelijk bekeken product; Bericht 2 schakelt over op gerelateerde producten omdat na 4 uur na het browsen, herinneringsmoeheid reëel is en ontdekking de hefboom is die converteert. De volgende twee H2's gaan dieper in op de exit voor 'nog aan het browsen' en de hefboom voor gerelateerde producten, omdat beide de grootste onbenutte details op de SERP zijn.

Een opmerking over het uitvoertype. Multiple Parallel is correct voor het verlaten van de browse-sessie, omdat een enkele abonnee vijf producten kan bekijken in een sessie van veertig minuten en elk daarvan is een eigen workflow-instantie met zijn eigen productcontext. De PushEngage Workflows-engine houdt de entry_flag timestamp per instantie bij, zodat de vijf instanties niet met elkaar in conflict komen. Als je deze workflow op Single instelt, krijgt slechts één van de vijf producten een herstel-aanraking en de andere vier gaan stil.

De exit-tak 'nog aan het browsen'

Dit is het meest gemiste detail in elk resultaat op de eerste pagina voor het trefwoord. De meeste artikelen over het verlaten van de browse-sessie vertellen je om op het dertig minuten-punt een bericht te sturen, punt uit. Dat advies genereert ruis voor actieve shoppers en erodeert het kanaal. Een abonnee die op minuut éénendertig nog steeds op de site is, heeft geen melding nodig over het product waar hij momenteel naar kijkt. Ze moeten met rust gelaten worden om de sessie te voltooien.

Het DECISION-knooppunt bij de dertig minuten durende wachtoplossing lost dit op. Het leest een session_activity heartbeat-attribuut op het abonneeprofiel. Als de timestamp van het attribuut binnen de laatste vijf minuten valt, sluit de workflow stil af. De abonnee wordt niet bestraft voor het zijn op de site. De volgende keer dat ze vertrekken, vuurt de volgende productdetailpagina-weergave de trigger opnieuw af en start een nieuwe workflow-instantie met up-to-date context. Dit is het allerbelangrijkste om toe te voegen aan een workflow voor het verlaten van de browse-sessie die de meeste teams zonder verzenden.

De implementatie is lichtgewicht. De PushEngage JavaScript SDK kan elke vijf minuten een heartbeat-aangepaste gebeurtenis activeren terwijl de pagina op de voorgrond is, wat de subscriber-attribuut schrijft via de UpdateAttribute-actie van de Workflows-engine. Het DECISION-knooppunt’s publieksfilter leest vervolgens subscriber.attributes.session_active_at en vergelijkt dit met now() - 5min. Het publieksfilter wordt gedocumenteerd in de PushEngage Workflows decision-logic reference.

De retentiecase voor de 'still-browsing'-exit is direct. Een anonieme browse-abandoner die nog steeds op de site is, is een gebruiker met actieve intentie, en een pushmelding is het verkeerde hulpmiddel. Door hen de sessie te laten voltooien, wordt de leverbaarheidsscore van het kanaal behouden, wordt het uitschrijvingspercentage laag gehouden en worden de verzendingen van de workflow geconcentreerd op het segment waar push daadwerkelijk een getal verplaatst. Browse recovery-automatisering staat of valt bij deze discipline.

De gerelateerde producten-hendel (Bericht 2)

Bericht 2 stuurt niet hetzelfde product dat de abonnee al heeft bekeken. Het stuurt een samengestelde lijst met gerelateerde producten, omdat vier uur na de oorspronkelijke browse de herinneringsmoeheid is ingetreden en de klant ofwel al terug is gekomen of niet meer terugkomt voor dat specifieke artikel. Ontdekking is de hefboom op het vieruurs-punt, geen herinnering.

WooCommerce maakt dit eenvoudig. Het platform levert wc_get_related_products als een ingebouwde functie die is gekoppeld aan zijn producttaxonomie. De functie retourneert up-sells, cross-sells en categorie-vergelijkbare producten die aan het bekeken product zijn gekoppeld. De PushEngage WooCommerce-integratieplug-in kan deze doorgeven aan de workflow als event-data variabelen, zodat het bericht van Bericht 2 de gerelateerde producten’s titels, afbeeldingen en URL’s kan weergeven zonder een aparte API-aanroep. Een typische tekstregel voor Bericht 2: “Misschien vind je deze ook leuk uit onze {{event.data.category}} collectie.”

Dit is het WooCommerce-specifieke voordeel. Winkels op platforms zonder een ingebouwde gerelateerde-producten taxonomie moeten gerelateerdheid berekenen op het moment van workflow-triggering, wat een aangepaste recommender-service betekent. WooCommerce-winkels krijgen dit gratis van het platform. Mid-market WooCommerce-winkels met brede SKU-catalogi zien de grootste winst van Bericht 2, omdat het gerelateerde-producten oppervlak breed genoeg is om een tweede product te vinden dat de abonnee daadwerkelijk wil. Winkels met smalle catalogi zien hier minder winst en kunnen Berichten 2 en 3 samenvoegen tot een enkele kortings-ontdekkings-touchpoint na 24 uur.

Het patroon is belangrijk omdat herinnerings-only browse-abandonment de standaard van de SERP is en het conversieplafond laag is. Het toevoegen van een ontdekkings-touchpoint verhoogt de recovered-cart rate van de workflow met 30-50% bij winkels met een reeds gevulde gerelateerde-producten taxonomie, wat de meeste WooCommerce-installaties hebben, of de merchandiser dat nu weet of niet.

Browse-abandonment gegevens op de WooCommerce-stack

Drie gebeurtenis-inputs voeden de workflow. Hier is waar elk van afkomstig is en de installatievolgorde als je koud begint.

Gebeurtenis 1, page_view met product_id. Wordt geactiveerd vanuit de PushEngage JavaScript SDK op elke productdetailpagina. De minimale payload is { event_name: 'page_view', product_id: '...' }; de aanbevolen payload bevat ook product_title, product_image en category, zodat de workflow deze in Berichten 1, 2 en 3 kan weergeven zonder een tweede API-aanroep. Installeer dit eerst omdat de trigger van de browse-workflow hiervan afhankelijk is.

Gebeurtenis 2, add_to_cart. Wordt geactiveerd vanuit de WooCommerce-PushEngage integratieplugin, die de woocommerce_add_to_cart WordPress-actie koppelt. Installeer deze als tweede omdat BESLISSING 2 van de workflow (en de exit-criteria van de workflow) deze gebeurtenis lezen. Als u de installatie van de integratieplugin uitstelt, wordt de browse-workflow nog steeds uitgevoerd; deze kan alleen niet netjes worden overgenomen in de winkelwagen-workflow.

Gebeurtenis 3, session_activity heartbeat. Een aangepaste gebeurtenis die elke vijf minuten door de PushEngage SDK wordt geactiveerd terwijl de pagina op de voorgrond is. Werkt het subscriber-kenmerk session_active_at bij. Installeer deze als derde. De browse-workflow degradeert gracieus zonder deze: de wachttijd van 30 minuten geldt nog steeds en Bericht 1 wordt nog steeds verzonden, maar de exit-tak 'nog steeds aan het browsen' kan niet worden geactiveerd en actieve shoppers ontvangen soms meldingen midden in de sessie. Dit is de optionele polijststap.

De meeste WooCommerce-winkels met de geïnstalleerde PushEngage-plugin krijgen gebeurtenissen 1 en 2 gratis tijdens de onboarding. De session_activity heartbeat is de optionele derde gebeurtenis die de workflow van "goed" naar "best op de SERP" maakt. Winkels die engineeringwerkzaamheden uitstellen, kunnen de workflow in week één verzenden met gebeurtenissen 1 en 2 en de heartbeat in week drie toevoegen.

Per-workflow analyse: lees de funnel

PushEngage Workflows volgt wachtende, voltooide en afgesloten gebruikers bij elke knooppunt. Voor browse-verlating op een WooCommerce-winkel met 200.000 abonnees en ongeveer 30.000 productdetailpaginaweergaven per week (illustratieve cijfers), ziet de trechter er als volgt uit:

Knooppunt	In wachtrij	Voltooid	Verlaten	Opmerkingen
START (page_view filter)	0	28,000	0	Abonnees die deze week de workflow binnenkomen
WACHT 30 minuten	850	27,150	0	Normale wachtrijdiepte
BESLISSING 1 (nog aan het browsen?)	0	21,800	5,350	5.350 actieve sessies stil afgebroken
ACTIE Bericht 1	0	21,800	0	Herinnering verzonden
WACHT 4 uur	280	18,520	3,000	3.000 abonnees toegevoegd aan winkelwagen (winkelwagen-workflow wordt overgenomen)
BESLISSING 2 (toegevoegd aan winkelwagen?)	0	18,520	0	Alle overgebleven alleen nog aan het browsen
ACTIE Bericht 2	0	18,520	0	Gerelateerde producten verzonden
WACHT 48 uur	600	16,300	2,220	2.220 toegevoegd aan winkelwagen gedurende de volgende twee dagen
ACTIE Bericht 3	0	16,300	0	Kortingsontdekking verzonden
EINDE	n.v.t.	16,300	n.v.t.	Niet toegevoegd aan winkelwagen

In deze funnel hebben 5.220 abonnees (3.000 + 2.220) aan de winkelwagen toegevoegd terwijl ze zich in de browse-workflow bevonden, een browse-naar-winkelwagen-ratio van 18,6% van de 28.000 die binnenkwamen. Van die aan-winkelwagen-toevoegingen herstelt de winkelwagen-verlatings-workflow vervolgens een extra fractie naar aankoop. De knooppunten met de hoogste exit zijn de twee wachtperiodes, wat het verwachte patroon is: tijd-tot-beslissing vindt plaats in de wachtvensters, niet in de actievensters. De exit 'nog aan het browsen' bij BESLISSING 1 draagt nog eens 5.350 stilzwijgend afgesloten actieve sessies bij; zonder die aftakking zouden die abonnees midden in een sessie Bericht 1 hebben ontvangen, wat het kanaal zou aantasten.

De wiskunde van de herstelde inkomsten schaalt met de lijstgrootte. Dezelfde workflow op een lijst van 50.000 abonnees produceert ruwweg een kwart van deze cijfers; op een lijst van 1.000.000 abonnees produceert het ruwweg vijf keer zoveel. De kosten per verzending blijven gedurende het hele proces bijna nul, wat het structurele voordeel van het kanaal is.

Lijstgrootte	Wekelijkse productdetailweergaven	Wekelijkse browse-verlaters die de workflow ingaan	Wekelijkse herstelacties in de winkelwagen (18,6%)	Geschatte herstelde inkomsten bij $85 AOV × 15% sluitingspercentage
50,000	7,500	7,000	1,300	$16,600
200,000	30,000	28,000	5,220	$66,500
1,000,000	150,000	140,000	26,000	$331,500

Dit zijn richtinggevende cijfers; de werkelijke winst voor uw winkel is afhankelijk van AOV, productmix en het sluitingspercentage van herstelde winkelwagen-toevoegingen. Het punt is dat de wiskunde zich opstapelt met de lijstgrootte tegen kosten per verzending die niet opstapelen.

Bouw het in PushEngage Workflows

De browse-verlatingsworkflow komt rechtstreeks overeen met de PushEngage Workflows-componenten. Hier is de mapping:

Workflowcomponent	Gebruikte knooppunttypen	Gebruikte actietypen	Workflowoptie
De 3-bericht workflow voor browse-abandonment	START, WACHT, BESLISSING, ACTIE, EXIT, EINDE	SendPushNotification	Run type: Meerdere parallelle; exit op doelen add_to_cart of purchase

De Workflows-engine wordt geleverd met 60+ verzonden sjablonen die eCommerce-flows dekken, waaronder browse- en winkelwagenverlating. Het sjabloon voor browse-verlating is het juiste startpunt; kloon het, vervang uw WooCommerce categorie- en productvariabelen, en de workflow is binnen een uur live in de PushEngage Workflows builder.

Wat dit verandert

Voor een bredere context over hoe deze workflow past in een volledig WooCommerce-retentieprogramma, behandelt de eCommerce pushmeldingen hub de campagnetypes die deze workflow implementeert, en de bestaande browse-afhakingscampagnes post biedt een strategie-overzicht voor het bredere onderwerp. De zuster WooCommerce winkelwagen-afhakingsworkflow is de natuurlijke volgende stap zodra browse actief is; deze erft de abonnee op het moment dat Bericht 1 of Bericht 2 een toevoeging aan de winkelwagen stimuleert. De PushEngage winkelwagen-afhakingsherstelreeks behandelt de playbook-details daar. Voor multi-channel teams die push naast e-mail uitvoeren, behandelt de multi-channel push en e-mail post de orkestratievraag.

Als u één getal uit dit artikel haalt, neem dan 162.000. Dat is het wekelijkse publiek dat de winkelwagen verlaat bij een enkele WooCommerce-winkel van $ 20 miljoen GMV, waarvan er bijna niemand een e-mailadres heeft dat u kunt bereiken. E-mail en SMS zullen dit publiek niet aanspreken. Betaalde remarketing zal dat wel doen, tegen een CAC-kosten die zich opstapelen tegen retentie. WooCommerce pushmeldingen voor verlaten winkelwagens bereiken hetzelfde publiek tegen bijna nul kosten per verzending, met een workflow die 's middags wordt geleverd en een nog steeds browsende exit-tak die het kanaal afleverbaar houdt.

De retentiemathematica maakt het posten verdedigbaar. Met een lijst van 200.000 abonnees en de bovenstaande workflow, wordt de verwachte wekelijkse herstelde omzet van de orde van grootte $66.500 bij typische mid-market AOVs. Dat aantal schaalt lineair met de lijstgrootte, en de kosten per verzending blijven bijna nul. Eerst de browsen-verlatingsworkflow, daarna de winkelwagen-verlatingsworkflow die daarvan overerft, en de rest van de WooCommerce-retentiestack die zich rond deze twee vormt.

Het gratis abonnement geeft je vanaf dag één 200 abonnees, elk kanaal en de volledige Workflows-engine. Dat is genoeg om de page_view-gebeurtenis te instrumenteren, de workflow te verzenden en de trechter een week te bekijken voordat je de budgetpost aanvraagt. Begin met het gratis abonnement om Bericht 1 van deze workflow vóór vrijdag te verzenden.