WooCommerce pris-drop-advarsels-arbejdsgange for 2x fastholdelsesrater

Det er mandag morgen i en WooCommerce-beklædningsbutik med en GMV på 25 mio. USD, og retentionschefen lancerer det kvartalsvise udsalg. Teamet har allerede arbejdet med hele butikkens e-mail: 25 % rabat, udløber fredag, enkelt udsendelse kl. 10. Over de næste syv dage indhenter e-mailen 8.400 USD i tilskrevet omsætning. Den anden indhentningsflade er mere stille.

Hver gang en indkøber markerer en udsalgspris i WooCommerce-admin, udløser en automatisk arbejdsgang WooCommerce-prisaldersmeddelelser til abonnenter, der specifikt fulgte den pågældende SKU. Over det samme 72-timers vindue indhenter prisaldersarbejdsgangen 19.200 USD. Samme butik, samme udsalg, to en halv gange indhentningen fra automatiseringen.

De to flader kan ikke udskiftes. Hele butikkens e-mail er udsendelsen. Prisaldersarbejdsgangen er den pr. SKU-flade. De supplerer snarere end konkurrerer, og i de fleste mellemmarkeds WooCommerce-butikker er pr. SKU-fladen den, der er materielt underinstrumenteret.

Denne artikel gennemgår, hvordan prisaldersarbejdsgangen ser ud fra ende til ende, hvorfor en tre-målgruppe-kaskade er den rigtige arkitektur, hvordan man forhindrer frekvensbegrænsning i at træne en rabat-jægerbase, og hvordan man tilskriver indhentet omsætning pr. SKU, så økonomiafdelingen kan læse posteringen.

Hvorfor prisalders er den højest konverterende indhentningstrigger

De fleste retentionsarbejdsgange udløses mod en enkelt målgruppe. Arbejdsgangen for forladte indkøbskurve retter sig mod dem, der har forladt indkøbskurven. Arbejdsgangen for forladt browsing retter sig mod dem, der har forladt browsing. Velkomstserien retter sig mod nye abonnenter. Prisaldersmeddelelsen er anderledes. To målgrupper konvergerer på den samme trigger: dem, der har forladt browsing, som har set produktet, men ikke lagt det i kurven, og dem, der har forladt indkøbskurven specifikt på grund af prisen. Begge har demonstreret specifik produktintention. Begge kan adresseres fra én arbejdsgang med én trigger og ét exit-kriterium.

Der er en tredje grund til, at prisalders konverterer med multipla af enhver enkeltstående påmindelse. Trigger-signalet er mere konkret end selve målgruppesignalet. En påmindelse om forladt browsing beder abonnenten om at tage forhandlerens ord for, at produktet stadig er opmærksomheden værd. Prisaldersmeddelelser bærer beviset i selve beskeden: prisen er faktisk ændret, her er det nye tal. Abonnenten ser meddelelsen og prisen samtidigt, hvilket er grunden til, at selv kolde målgrupper konverterer bedre på prisaldersafsendelser end på generelle genoptagelses-skub.

Tilvalgsmomentet for prisaldersmeddelelser

En knap til "giv mig besked, når prisen falder" på produktdetaljesiden er en af de bedste opt-ins i mellemmarkedets e-handel. Abonnenten navngiver det specifikke produkt, de ønsker sporet. Sammenlignet med en generisk opt-in for hele webstedet producerer PDP-prisvarslings-opt-in en abonnentbase, der konverterer på pris-fald-workflowet med multipla af hastigheden af kolde abonnenter. Argumentet om den samlede abonnentkvalitet er dækket mere detaljeret i den søsterartikel om udløste abonnementsprompter; den korte version er, at opt-in-kilden forudsiger downstream-omsætning pr. abonnent lige så rent som ethvert signal i fastholdelse.

For WooCommerce-butikker implementeres PDP-opt-in gennem PushEngage JS SDK's subscribeToProduct(productId)-metode. Knappen skriver produkt-ID'et ind i en abonnentattribut, som bliver et segment, som pris-fald-workflowet kan dirigere imod. Butikker, der allerede kører YITH- eller TI WooCommerce Wishlist-pluginet, har en parallel rute til ønskeliste-prissporing: hvert ønskelistede produkt er effektivt en eksplicit prisvarslings-opt-in fra kunden.

Prisaldersarbejdsgangen, ende til ende

Dette er den fulde workflow-specifikation. Løft den direkte ind i PushEngage Workflows-byggeren.

• Udløser (START): Brugerdefineret begivenhed price_dropped, udløst fra WooCommerce, når feltet product_meta._sale_price opdateres og er lavere end _regular_price. Begivenheds-payload inkluderer product_id, old_price, new_price og percent_off.
• Kørselstype: Flere parallelle. Én workflow-instans pr. produkt pr. abonnent. En abonnent, der sporer tre produkter, får tre samtidige instanser; hver enkelt afsluttes uafhængigt, når dens produkt købes.
• Frekvensbegrænsning (workflow-niveau): Afslut, hvis abonnentattributten last_price_drop_alert_at er inden for de sidste 14 dage. Begrænsningen beskytter mod at træne et publikum af rabat-jægere og forsvares i næste afsnit.
• BESLUTNING 1: Har abonnenten eksplicit tilmeldt sig alarmer for dette produkt (segment price_alert_subs_{product_id} eller ønskeliste-match)? JA-sti: send eksplicit-abonnent pris-fald-alarmen. NEJ-sti: fortsæt til BESLUTNING 2.
• BESLUTNING 2: Er abonnenten i browse-abandonment-segmentet for dette produkt inden for de sidste 30 dage? JA-sti: send browse-abandoner pris-fald-påmindelse. NEJ-sti: fortsæt til BESLUTNING 3.
• BESLUTNING 3: Er abonnenten i cart-abandonment-segmentet for dette produkt inden for de sidste 14 dage? JA-sti: send cart-abandoner pris-fald-påmindelse. NEJ-sti: AFSLUT lydløst.
• VENT: 24 timer efter første afsendelse.
• BESLUTNING 4: Købte abonnenten produktet? JA-sti: AFSLUT (succes, exit-kriterie matchet). NEJ-sti: send lager-løber-tør anden kontakt.
• AFSLUT.

Notifikationskopi for hver gren:

• Eksplicit abonnent: “Prisen er faldet på det produkt, du sporer. {{product_name}} er nu {{new_price}}, {{percent_off}}% rabat. Køb til den nye pris.”
• Browsing-afbryder: “God timing. {{product_name}}, som du kiggede på i sidste uge, er nu {{new_price}}, {{percent_off}}% rabat.”
• Indkøbskurv-afbryder: “Du efterlod {{product_name}} i din indkøbskurv. Prisen er lige faldet til {{new_price}}. Din indkøbskurv er der stadig.”
• Lageret er ved at løbe tør, andet forsøg: “Bemærk. {{product_name}} til {{new_price}} er ved at løbe tør. Lageret skifter hurtigt på udsalgsvarer.”

Prisvarslings-workflowet har én udløser, tre afsendelses-grene og ét exit-kriterie. Læseren, som også kører indkøbskurv- og browsing-workflows, har allerede målgruppesegmenterne og abonnentattributterne på plads. Prisvarslings-workflowet samles på under en time oven på den eksisterende infrastruktur.

Hvorfor målgruppekaskaden er den rigtige arkitektur

De fleste retention-stacks bygger tre separate pris-fald-kampagner. Én for eksplicitte ønskeliste-abonnenter, ejet af loyalitetsmanageren. Én for browsing-afbrydere, ejet af lifecycle-markedsføreren. Én for indkøbskurv-afbrydere, ejet af CRM-lederen. Tre kampagner betyder tre kampagneejere, tre sæt tekst, der driver fra hinanden i tredje kvartal, og tre steder, hvor exit-kriteriet glemmes. Kaskaden kollapser disse til ét workflow med tre BESLUTNINGS-knudepunkter, afslutter stille for abonnenten uden intention, og sender aldrig dobbelt.

Koncept	Tre separate kampagner	Ét kaskade-workflow
Ejer	Tre (loyalitet, lifecycle, CRM)	Én (retention manager)
Tekst-varianter	Tre, driver fra hinanden	Én kanonisk variant pr. gren
Exit-kriterier	Tre regler, sat separat	Én workflow-regel
Frekvens-cap	Ingen (kampagner koordinerer ikke)	Én cap, workflow-niveau
Attribution	Tre linjeposter	Én linjepost, tre gren-delsummer
Dobbelt-send risiko	Høj (en ønskeliste-abonnent kan også være en indkøbskurv-afbryder)	Nul (kaskade ordner efter intention)

Kaskade-rækkefølgen betyder noget. Eksplicitte abonnenter evalueres først, fordi tilmeldingen er det højeste intentions-signal. Browsing-afbrydere næst, fordi produktvisningen er mere nylig og mere specifik end indkøbskurv-afbrydelse for de fleste butikker. Indkøbskurv-afbrydere tredjeverst, fordi indkøbskurv-afbrydelses-workflowet allerede har sendt dem en 0/10/20 rabat-stige; pris-fald-varslet er en anden vinkel på den samme abonnent og bør lande sidst i kaskaden for at undgå at stable med indkøbskurv-workflowets egen eskalering.

Integration af prisstrategi: undgå at træne rabat-jægeren

En abonnent, der modtager udsalgspris-meddelelser hver anden uge, lærer at vente. Dette er den skjulte pris for et ubegrænset pris-fald-program: den kohorte, der konverterer på varslerne, forsinker også efterfølgende køb og ser efter den næste nedsættelse. Over fire kvartaler kan den trænede-rabat-jæger-adfærd fuldstændig udhule retention-regnestykket. En 5% margin-handel for genopretningen er acceptabel. En 25% trænet-adfærdshandel på tværs af kohorten over tolv måneder er ikke.

Forsvaret er en frekvensbegrænsning på arbejdsgangsniveau. Maks. 1 pris-fald-notifikation pr. abonnent pr. 14 dage, håndhævet inde i arbejdsgangen som en exit-kriterie-kontrol på abonnentattributten last_price_drop_alert_at. Hver succesfuld afsendelse opdaterer attributten via en UpdateAttribute-handlingsknude. Den næste pris_dropped-begivenhed, der udløses for den samme abonnent, kontrollerer attributten; hvis den er inden for 14 dage, afsluttes arbejdsgangen, før nogen af de tre DECISION-grene evalueres.

Vinduet for begrænsningen kan justeres. Butikker med løbende ugentlige udsalg kan have brug for at falde til 7 dage for at forblive relevante. Butikker med kvartalsvise oprydningsudsalg kan holde sig til 14 dage eller udvide til 21. Pointen er, at begrænsningen er en arbejdsgangsregel, håndhævet af motoren, ikke en kalendermeddelelse for kampagneejeren. Arbejdsgangsregler bliver ikke glemt, når kampagneejeren skifter plads.

Der er en følgevirkning. Frekvensbegrænsningen beskytter også forholdet til abonnenter, der ikke er i pris-fald-jagt-rammen. En kunde, der købte produktet til fuld pris i sidste uge, ønsker ikke en pris-fald-advarsel for det samme produkt i denne uge. Exit-kriterie-publikumsfilteret (køb inden for de sidste 30 dage for dette produkt) håndterer den sag som en separat regel, men 14-dages begrænsningen er det universelle gulv.

WooCommerce-stackintegration

Data-inputtene er specifikke. WooCommerce-butikker gemmer udsalgspris som _sale_price og normalpris som _regular_price i produktets meta-tabel. WooCommerce-PushEngage-integrationspluginet kroger ind i save_post_product-handlingen og læser metaen ved hver produktgemning; hvis _sale_price ikke er tom og mindre end _regular_price, udløser pluginet price_dropped CustomEvent med SKU, de gamle og nye priser og procent-rabatten. Dette er den begivenhed, som pris-fald-arbejdsgangens START-knude lytter efter.

Dynamiske prisplugins (Advanced Dynamic Pricing for WooCommerce, WooCommerce Dynamic Pricing & Discounts) skriver til det samme meta-lag, når deres regler aktiveres og udløser den samme krog. Pris-fald-arbejdsgangen behøver ikke at vide, om prisændringen kom fra en manuel redigering af udsalgspris eller fra en automatiseret dynamisk prisregel. Den lytter efter begivenheden uanset kilden.

For eksplicitte tilmeldinger eksponerer PushEngage JS SDK subscribeToProduct(productId). PDP-pris-alert-knappen kalder denne metode ved klik; abonnenten tilføjes til et pr-produkt-segment kaldet price_alert_subs_{product_id}. Butikker, der bruger YITH- eller TI WooCommerce Wishlist-plugins, kan skrive en parallel krog, der mapper hvert ønsket produkt til det samme pr-produkt-segment, så ønskeliste-prissporing og den eksplicitte pris-alert-tilmelding fodrer det samme publikum.

Hvad skal instrumenteres først. De top 100 SKU'er efter salgsvolumen dækker det meste af omsætningen. Kobl save_post_product-krogen til at udløse price_dropped for disse SKU'er først. Tilføj PDP-pris-alert-knappen på det samme sæt. Opsæt arbejdsgangen mod dette afgrænsede publikum, mål, og udvid. Hele kataloget kan vente.

Tilskrivning pr. arbejdsgang

Genindvundet omsætning pr. prisfalds-event, pr. SKU, pr. kanal. Dette er den reneste omsætningsattribution i fastholdelse, da udløser-eventet (prisændring) er tidsstemplet, og konverterings-eventet (køb af samme SKU) er tidsstemplet. Træk de to fra hinanden; forskellen er den genindvundne omsætning pr. alarm.

PushEngage Workflows sporer kø-lagte, afsluttede og frafaldne brugere ved hver knude. Her er, hvordan knude-niveau analyser ser ud for en realistisk prisfalds-workflow på en liste med 200.000 abonnenter under en kvartalsvis oprydningsuge:

Knude	Køet	Gennemført	Afsluttet	Noter
START (pris_faldet, 40 SKU'er)	0	18,400	0	18.400 abonnent-produkt-par berettiget
Frekvens-cap exit	0	17,100	1,300	1.300 capped fra en nylig alarm
BESLUTNING 1: eksplicit abonnent	0	4.200 (JA)	0	Routet til eksplicit-abonnent-afsendelse
BESLUTNING 2: browse-abandoner	0	7.800 (JA)	0	Routet til browse-abandoner-afsendelse
BESLUTNING 3: cart-abandoner	0	2.300 (JA)	0	Routet til cart-abandoner-afsendelse
BESLUTNING 3 NEJ-sti: EXIT	0	0	2,800	Abonnenter uden intention forlader stille og roligt
HANDLING: første afsendelse	0	14,300	0	Sendt på tværs af tre grene
VENT 24 timer	1,800	9,400	3,100	3.100 købte inden for 24 timer, exit
BESLUTNING 4: købt?	0	9,400	0	Alle ikke-købere fortsætter
HANDLING: lageret er ved at løbe tør, andet touch	0	9,400	0	Anden afsendelse
SLUT	ikke relevant	9,400	ikke relevant	1.200 af disse konverterer inden for de næste 48 timer

I denne tragt købte 4.300 abonnenter (3.100 plus 1.200) den alarmerede SKU inden for 72 timer efter prisfalds-eventet. Med en gennemsnitlig kurv på 58 dollars er det cirka 249.400 dollars i genindvundet omsætning i løbet af ugen, mod 14.300 afsendelser og nul omkostninger pr. afsendelse for push-kanalen. Aggregeret pr. SKU lander den pr. SKU-omsætning på merchandiserens dashboard sammen med metrikker for rabatrealisering. Workflown stopper med at være en kampagneomkostning og bliver en post for prisrealisering.

Den rette ramme for finansafdelingen er, at prisfalds-workflown er fundet omsætning. Dette er abonnenter, der ikke ville have købt til normal pris, men som købte til udsalgspris efter alarmen. Butikken ville alligevel have nedsat disse SKU'er. Workflown omdanner den planlagte nedskrivning til genindvundet efterspørgsel.

Byg det i PushEngage Workflows

Prisfalds-workflown mapper direkte til PushEngage Workflows-komponenter.

Workflow-del	PushEngage-element
Udløser	START med CustomEvent price_dropped, Multiple Parallel run type
Frekvens-cap	Exit-kriterier med publikumsfilter på abonnentattributten last_price_drop_alert_at
Publikumskaskade	BESLUTNING x3 med publikumsfilter på segmentmedlemskab
Afsendelser	HANDLING SendPushNotification x4 (tre grene plus andet touch)
Attributopdatering	HANDLING UpdateAttribute på last_price_drop_alert_at efter hver afsendelse
Vent	VENT 24 timer
Købsafslutning	BESLUTNING med Goal.Tracked-filter på purchase-event, der matcher produkt-ID
Terminal	SLUT

Workflows-motoren leveres med over 60 skabeloner, der dækker prisfald og de understøttende kurv- og browserflows. Retentionsmanageren, hvis kurv- og browserflows allerede er live, kan opsætte WooCommerce push-notifikationer prisfaldslaget oven på de eksisterende publikumssegmenter på under en time.

Hvad dette ændrer

For butikker, der kører flerkanals retentionsplaner, lagrer push- og e-mail-orkestreringsmetoden e-mail som fallback for kunder, der har afmeldt sig push. Det bredere ecommerce push-notifikationshub dækker de omgivende workflows, som prisfaldslaget udbygger med, herunder WooCommerce kurv-afbrudt workflow og browser-afbrudt genopretningsworkflow, der deler publikumssegmenter med dette.

Prisfaldsalarmsystemet er ikke en kampagne. Det er et workflow, der udbygges på tværs af to eksisterende publikummer plus en eksplicit opt-in kohorte, fra en enkelt trigger, med et enkelt exit-kriterium. Indkøberen bliver ved med at markere udsalgspriser i WooCommerce-administrationen. Workflovet bliver ved med at køre pr. SKU. Retentionsmanageren bliver ved med at læse pr. SKU-omsætningslinjen. Tre kampagner bliver til én. Risikoen for den trænede rabat-jæger holdes på workflow-niveauets loft. Den genvundne omsætning lander som fundne penge på den næste P&L. Regnestykket udbygges på tværs af hvert salg, butikken kører.

Den gratis plan 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 instrumentere prisfalds-workflowet på dine top 10 SKU'er og bevise genopretningsregnestykket på rigtige abonnenter, før du anmoder om budget.

Start på den gratis plan og implementer prisfaldslaget oven på dine eksisterende workflows i denne uge.