Back-in-Stock Alert

Build this when requests to be told about an out-of-stock product keep piling up and, once the item returns, fade out without a purchase. Before launch, confirm the request is stored at product and variant level (size, model), that the restock signal comes from live inventory rather than an estimated supply date, and that push permission, email subscription and SMS consent are each held separately. If items stay out of stock for months or supply dates keep slipping, the problem sits in sourcing, not in the notification; settle the stock plan first, because a message flow cannot turn a waiting request into a sale.

Incremental purchase of the requested item vs control

Someone who asked to be told may already be watching the product, so the value lies in the purchase gap between the alerted group and the control group that got no alert, not in deliveries or clicks.

How it is counted: Count everyone assigned at the request to the journey or control group whose product came back in stock, and within them those who buy the requested item within the same follow-up window from the restock. Whether an alert was delivered or clicked does not change the denominator.

Also track

• Return-to-product rateHow many assigned users return to the product page after the restock; the intermediate step before purchase, readable separately after each touch.
• Contribution by channel orderTrack purchases after the push, the email and the SMS separately; if the SMS step adds no sales, consider dropping the third touch.
• False alertsCount alerts sent while the item was not actually available or had sold out again; anything above zero points to a lag in the stock signal.
• Push opt-outs, unsubscribes and SMS complaintsWatch permission loss per channel; even a user who asked to be told can switch a channel off after three messages in a row.

• Trigger and entryThe journey opens when a user asks to be notified about an out-of-stock product; messaging starts only when that product is genuinely back in stock. At the request, randomly assign the user to the journey group or to a control group that gets none of these alerts.
• Who must not enterOne user's request for one product is the scope: no second flow opens for the same request, and a user who buys the item elsewhere during the wait gets no push. Someone who only saved or browsed the product without asking belongs to Saved Product Reminder or Browse Abandonment, not here.
• Timing and channelsA push goes the moment stock returns; an email follows if there is no purchase after 1 day, and an SMS 2 days after that, only if there is still no purchase and SMS is permitted. Recheck purchase status and availability before each touch; if the item sold out again, hold the next message.
• Exit and handoffWhenever a purchase happens, the journey ends on the spot and the remaining messages are cancelled. A user without SMS consent leaves after the post-email check; a user who got the SMS leaves after the final 1-day wait if there is still no purchase. Nothing is handed to another journey.
• Frequency and consentEach request gets at most three alerts: push, email, and SMS only where consent exists. Gate every channel on its own permission, and send on a real restock event, never because an estimated supply date has arrived.

1. 1When the journey group does not buy the requested item more often than the control group, those users were tracking the product on their own; strong opens or clicks do not change that reading. Weigh the purchase gap between the groups together with the false-alert count when you decide.
2. 2This reading holds for this channel order and these waits; there is no handoff, so a purchase is credited to this request alone. Even if the same user also saved or browsed the product, do not count the purchase a second time in Saved Product Reminder or Browse Abandonment while the request is open.
3. 3Restocks are irregular, so the data builds slowly. Feed the purchase rate you expect per request and the smallest gap worth acting on into the sample size calculator to see how many requests each group needs; do not interpret the gap before you reach that number.
4. 4A single alert sent while the item had sold out again, or only because an estimated supply date arrived, damages trust; if you see false alerts, fix the stock signal before you change the journey.