WooCommerce-arbetsflöden för prisaviseringsvarningar för 2x behållningsgrad

It is Monday morning at a $25M GMV WooCommerce apparel store and the retention manager is launching the quarterly clearance sale. The team has already worked the storewide email: 25% off, expires Friday, single broadcast at 10 AM. Over the next seven days the email recovers $8,400 in attributable revenue. The other recovery surface is quieter.

Each time a merchandiser marks a Sale Price in the WooCommerce admin, an automatic workflow fires WooCommerce price drop alerts to the subscribers who were specifically watching that SKU. Over the same 72-hour window, the price-drop workflow recovers $19,200. Same store, same sale, two and a half times the recovery from the automation.

The two surfaces are not interchangeable. The storewide email is the broadcast. The price-drop workflow is the per-SKU surface. They stack rather than compete, and on most mid-market WooCommerce stores the per-SKU surface is the one that is materially under-instrumented.

This article walks through what the price-drop workflow looks like end to end, why a three-audience cascade is the right architecture, how to keep frequency capping from training a discount-hunter base, and how to attribute recovered revenue per SKU so finance can read the line item.

Why price drop is the highest-converting recovery trigger

Most retention workflows fire against a single audience. The cart-abandonment workflow targets cart-abandoners. The browse-abandonment workflow targets browse-abandoners. The welcome series targets new subscribers. The price-drop alert is different. Two audiences converge on the same trigger: browse-abandoners who viewed the product but did not add to cart, and cart-abandoners who left over price specifically. Both have demonstrated specific-product intent. Both are addressable from one workflow with one trigger and one exit criteria.

There is a third reason price drop converts at multiples of either standalone reminder. The trigger signal is more concrete than the audience signal alone. A browse-abandonment reminder asks the subscriber to take the merchant’s word for it that the product is still worth their attention. Price drop notifications carry the proof in the message itself: the price has actually moved, here is the new number. The subscriber sees the alert and the price simultaneously, which is why even cold audiences convert better on price-drop sends than on generic re-engagement nudges.

The opt-in moment for price alerts

A “notify me when price drops” button on the product detail page is one of the highest-quality opt-ins in mid-market eCommerce. The subscriber names the specific product they want tracked. Compared with a generic site-wide opt-in, the PDP price-alert opt-in produces a subscriber base that converts on the price-drop workflow at multiples of the rate of cold subscribers. The subscriber-quality compound argument is covered in more detail in the sibling article on triggered subscription prompts; the short version is that opt-in source predicts downstream revenue per subscriber as cleanly as any signal in retention.

For WooCommerce stores, the PDP opt-in is implemented through the PushEngage JS SDK’s subscribeToProduct(productId) method. The button writes the product ID into a subscriber attribute, which becomes a segment the price-drop workflow can route against. Stores already running the YITH or TI WooCommerce Wishlist plugin have a parallel route into wishlist price tracking: each wishlisted product is effectively an explicit price-alert opt-in by the customer.

The price-drop workflow, end to end

This is the full workflow specification. Lift it directly into the PushEngage Workflows builder.

• Trigger (START): Custom event price_dropped, fired from WooCommerce when the product_meta._sale_price field is updated and is less than _regular_price. Event payload includes product_id, old_price, new_price, and percent_off.
• Run type: Multiple Parallel. One workflow instance per product per subscriber. A subscriber tracking three products gets three concurrent instances; each one exits independently when its product is purchased.
• Frequency cap (workflow-level): Exit if the subscriber attribute last_price_drop_alert_at is within the last 14 days. The cap protects against training a discount-hunter audience and is defended in the next section.
• DECISION 1: Has the subscriber explicitly subscribed to alerts for this product (segment price_alert_subs_{product_id} or wishlist match)? YES path: send the explicit-subscriber price-drop alert. NO path: continue to DECISION 2.
• DECISION 2: Is the subscriber in the browse-abandonment segment for this product within the last 30 days? YES path: send the browse-abandoner price-drop reminder. NO path: continue to DECISION 3.
• DECISION 3: Is the subscriber in the cart-abandonment segment for this product within the last 14 days? YES path: send the cart-abandoner price-drop reminder. NO path: EXIT silently.
• WAIT: 24 hours after the first send.
• DECISION 4: Did the subscriber purchase the product? YES path: EXIT (success, exit criteria matched). NO path: send the stock-running-low second touch.
• END.

Notification copy for each branch:

• Explicit subscriber: “Priset har sjunkit på produkten du bevakar. {{product_name}} kostar nu {{new_price}}, {{percent_off}}% rabatt. Handla till det nya priset.”
• Browse-abandoner: “Bra tajming. {{product_name}} som du tittade på förra veckan kostar nu {{new_price}}, {{percent_off}}% rabatt.”
• Cart-abandoner: “Du lämnade {{product_name}} i din varukorg. Priset har precis sjunkit till {{new_price}}. Din varukorg finns kvar.”
• Stock-running-low second touch: “Observera. {{product_name}} för {{new_price}} börjar ta slut. Lagret går snabbt för reavaror.”

Prisaviseringens arbetsflöde har en utlösare, tre sändningsgrenar och ett avslutningskriterium. Läsaren som också kör varukorgs- och webbläsararbetsflöden har redan målgruppssegmenten och prenumerantattributen på plats. Prisaviseringens arbetsflöde sätts ihop på under en timme ovanpå den befintliga infrastrukturen.

Why the audience-cascade is the right architecture

De flesta retentionsstackar bygger tre separata prissänkningskampanjer. En för explicita önskeliste-prenumeranter, som hanteras av lojalitetschefen. En för de som övergett webbläsning, som hanteras av livscykelmarknadsföraren. En för de som övergett varukorgen, som hanteras av CRM-ansvarige. Tre kampanjer innebär tre kampanjägare, tre uppsättningar texter som driver isär under tredje kvartalet, och tre platser där avslutningskriteriet glöms bort. Kaskaden kollapsar dessa till ett arbetsflöde med tre BESLUTs-noder, avslutas tyst för prenumeranten utan avsikt, och skickar aldrig dubbelt.

Koncept	Tre separata kampanjer	Ett kaskadararbetsflöde
Ägare	Tre (lojalitet, livscykel, CRM)	En (retention manager)
Textvarianter	Tre, driver isär	En kanonisk variant per gren
Avslutningskriterier	Tre regler, satta separat	En arbetsflödesregel
Frekvensbegränsning	Ingen (kampanjer koordinerar inte)	En begränsning, på arbetsflödesnivå
Attribuering	Tre rader	En rad, tre gren-delbelopp
Risk för dubbelsändning	Hög (en önskeliste-prenumerant kan också vara en som övergett varukorgen)	Noll (kaskaden sorterar efter avsikt)

Kaskadens ordning spelar roll. Explicita prenumeranter utvärderas först eftersom anmälan är den starkaste avsiktsindikatorn. De som övergett webbläsning utvärderas som andra eftersom produktvisningen är mer aktuell och specifik än övergiven varukorg för de flesta butiker. De som övergett varukorgen utvärderas som tredje eftersom arbetsflödet för övergiven varukorg redan har meddelat dem med en rabattstege på 0/10/20 %; prisaviseringen är en annan vinkel på samma prenumerant och bör landa sist i kaskaden för att undvika att staplas med varukorgsarbetsflödets egen eskalering.

Pricing-strategy integration: avoid training the discount-hunter

En prenumerant som får meddelanden om reapriser varannan vecka lär sig att vänta. Detta är den dolda kostnaden för ett obegränsat prissänkningsprogram: den kohort som konverterar på aviseringarna skjuter också upp efterföljande köp och väntar på nästa nedsättning. Över fyra kvartal kan det tränade beteendet att jaga rabatter helt urholka retentionsmatematiken. En 5 % marginalförlust i utbyte mot återhämtning är acceptabel. En 25 % tränad beteendeförlust över kohorten under tolv månader är det inte.

The defense is a workflow-level frequency cap. Max 1 price-drop notification per subscriber per 14 days, enforced inside the workflow as an exit criteria check on the subscriber attribute last_price_drop_alert_at. Each successful send updates the attribute via an UpdateAttribute action node. The next price_dropped event that fires against the same subscriber checks the attribute; if it is within 14 days, the workflow exits before any of the three DECISION branches evaluates.

The cap window can be tuned. Stores running weekly sales may need to drop to 7 days to stay relevant. Stores running quarterly clearance sales can hold at 14 days or extend to 21. The point is that the cap is a workflow rule, enforced by the engine, not a calendar reminder for the campaign owner. Workflow rules do not get forgotten when the campaign owner changes seats.

There is a corollary. Frequency cap also protects the relationship with subscribers who are not in the price-drop hunting frame. A customer who bought the product at full price last week does not want a price-drop alert for the same product this week. The exit criteria audience filter (purchase within last 30 days for this product) handles that case as a separate rule, but the 14-day cap is the universal floor.

WooCommerce stack integration

The data inputs are specific. WooCommerce stores Sale Price as _sale_price and Regular Price as _regular_price in the product meta table. The WooCommerce-PushEngage integration plugin hooks into the save_post_product action and reads the meta on each product save; if _sale_price is non-empty and less than _regular_price, the plugin fires the price_dropped CustomEvent with the SKU, the old and new prices, and the percent-off. This is the event the price-drop workflow START node listens for.

Dynamic Pricing plugins (Advanced Dynamic Pricing for WooCommerce, WooCommerce Dynamic Pricing & Discounts) write to the same meta layer when their rules engage and trigger the same hook. The price-drop workflow does not need to know whether the price change came from a manual Sale Price edit or from an automated Dynamic Pricing rule. It listens for the event regardless of source.

For explicit opt-ins, the PushEngage JS SDK exposes subscribeToProduct(productId). The PDP price-alert button calls this method on click; the subscriber is added to a per-product segment named price_alert_subs_{product_id}. Stores using the YITH or TI WooCommerce Wishlist plugins can write a parallel hook that maps each wishlisted product to the same per-product segment, so wishlist price tracking and the explicit price-alert opt-in feed the same audience.

What to instrument first. The top 100 SKUs by sales volume cover most of the revenue. Wire the save_post_product hook to fire price_dropped for those SKUs first. Add the PDP price-alert button on the same set. Stand up the workflow against this scoped audience, measure, and expand. The full catalog can wait.

Per-workflow attribution

Återvunnen intäkt per prissänkningshändelse, per SKU, per kanal. Detta är den renaste intäktsåterföringen inom retention eftersom triggern (prisändring) är tidsstämplad och konverteringshändelsen (köp av samma SKU) är tidsstämplad. Subtrahera de två; skillnaden är den återvunna intäkten per avisering.

PushEngage Workflows spårar köade, slutförda och avslutade användare vid varje nod. Här är hur analysen på nodnivå ser ut för ett realistiskt prissänkningsflöde på en lista med 200 000 prenumeranter under en kvartalsvis rensningsvecka:

Nod	Köad	Slutförd	Avslutad	Anteckningar
START (pris_sänkt, 40 SKU:er)	0	18,400	0	18 400 prenumerant-produktpar berättigade
Avslut baserat på frekvensbegränsning	0	17,100	1,300	1 300 begränsade från en nyligen genomförd avisering
BESLUT 1: explicit prenumerant	0	4 200 (JA)	0	Dirigerad till sändning för explicit prenumerant
BESLUT 2: övergiven-bläddring	0	7 800 (JA)	0	Dirigerad till sändning för övergiven-bläddring
BESLUT 3: övergiven-kundvagn	0	2 300 (JA)	0	Dirigerad till sändning för övergiven-kundvagn
BESLUT 3 NEJ-sökväg: AVSLUT	0	0	2,800	Prenumeranter utan avsikt avslutas tyst
ÅTGÄRD: första sändning	0	14,300	0	Skickad över tre grenar
VÄNTA 24 timmar	1,800	9,400	3,100	3 100 köpte inom 24 timmar, avslutas
BESLUT 4: köpt?	0	9,400	0	Alla icke-köpare fortsätter
ÅTGÄRD: lagret sinar andra kontakt	0	9,400	0	Andra sändningen
SLUT	ej	9,400	ej	1 200 av dessa konverterar inom de kommande 48 timmarna

I denna tratt köpte 4 300 prenumeranter (3 100 plus 1 200) den aviserade SKU:n inom 72 timmar från prissänkningshändelsen. Med en genomsnittlig kundvagn på 58 USD är det cirka 249 400 USD i återvunnen intäkt under veckan, mot 14 300 sändningar och noll kostnad per sändning för push-kanalen. Aggregerat per SKU landar intäkten per SKU på säljarens instrumentpanel tillsammans med mått för rabattrealisering. Arbetsflödet slutar vara en kampanjkostnad och blir en intäktslinje för prissättning.

Den rätta inramningen för finansavdelningen är att prissänkningsflödet är återfunnen intäkt. Det här är prenumeranter som inte skulle ha köpt till ordinarie pris men som köpte till reapriset efter aviseringen. Butiken skulle ändå ha sänkt priset på dessa SKU:er. Arbetsflödet omvandlar den planerade nedsättningen till återvunnen efterfrågan.

Bygg det i PushEngage Workflows

Prissänkningsflödet mappar direkt till PushEngage Workflows-komponenter.

Arbetsflödesdel	PushEngage-element
Utlösare	START with CustomEvent price_dropped, Multiple Parallel run type
Frekvensbegränsning	Exit criteria with audience filter on subscriber attribute last_price_drop_alert_at
Audience cascade	DECISION x3 with audience filter on segment membership
Sends	ACTION SendPushNotification x4 (three branches plus second touch)
Attribute update	ACTION UpdateAttribute on last_price_drop_alert_at after each send
Vänta	VÄNTA 24 timmar
Purchase exit	DECISION with Goal.Tracked filter on purchase event matching product ID
Terminal	SLUT

The Workflows engine ships with 60-plus shipped templates covering price-drop and the supporting cart and browse flows. The retention manager whose cart and browse workflows are already live can stand up the WooCommerce push notifications price-drop layer on top of the existing audience segments in under an hour.

Vad detta förändrar

For stores running multi-channel retention plans, the push and email orchestration approach layers email as the fallback for unsubscribed-from-push customers. The broader ecommerce push notifications hub covers the surrounding workflows the price-drop layer compounds with, including the WooCommerce cart abandonment workflow and the browse abandonment recovery workflow that share audience segments with this one.

The price-drop alert is not a campaign. It is a workflow that compounds across two existing audiences plus one explicit opt-in cohort, from a single trigger, with a single exit criteria. The merchandiser keeps marking Sale Prices in the WooCommerce admin. The workflow keeps firing per-SKU. The retention manager keeps reading the per-SKU revenue line. Three campaigns become one. The trained-discount-hunter risk is held at the workflow-level cap. The recovered revenue lands as found dollars on the next P&L. The math compounds across every sale the store runs.

The free plan gives you 200 subscribers, all four channels (web push, app push, WhatsApp, and live chat), and the full Workflows engine on day one. That is enough to instrument the price-drop workflow on your top 10 SKUs and prove the recovery math on real subscribers before requesting budget.

Start on the free plan and ship the price-drop layer on top of your existing workflows this week.