Wishlist Low-Stock Alert

Set this up when wishlisted items keep selling out before the people who saved them get a chance to buy, or support hears that nobody warned them in time. Wishlist add and remove events, real stock counts at product and variant level and push permission all have to sit on the same user identity, and the low-stock threshold has to be defined per product from live inventory. If stock is in fact plentiful and sales are simply slow, what is missing is price or product fit, not urgency; a manufactured scarcity message is not the answer to that.

Incremental purchase per stock event vs control

An item close to selling out may sell without any alert; the journey's worth is how many more of the pushed users buy it than the control group that heard nothing.

How it is counted: Every user and product pair assigned at the threshold crossing to the journey or control group is the denominator; the numerator is those who buy the item within the same follow-up window from assignment. Whether the push was delivered or opened does not change the denominator.

Also track

• Purchases before selloutIn both groups, track the share of purchases that happen before the item runs out; the alert exists to get the user to the product before it is gone.
• Visits to the productAmong pushed users, the share who go on to the product; the intermediate step before purchase, never a success on its own.
• Entries dropped at the pre-checkThreshold crossings that leave unmessaged because the item is no longer wishlisted or in stock, as a share of all crossings; a high share means the threshold fires too late or stock data lags.
• Push opt-outsWatch who turns push off after an alert; if one user keeps receiving low-stock alerts, narrow the threshold or the list scope.

• Trigger and entryA wishlisted item's stock falling below the threshold you set opens the journey. At that moment, randomly assign eligible users to the journey group or to a control group that gets no push for this stock event.
• Who must not enterOne user and product pair is followed through one stock event, so no second entry opens for the same event. Users who already bought the item, removed it from their list or hold no push permission stay out; once the item has sold out, it is a Back-in-Stock Alert matter, not a low-stock one.
• Timing and channelsAt the trigger, the journey checks that the item is still wishlisted and in stock; if so, a single push goes out and the journey waits 48 hours. After the wait it checks for a purchase first, then for stock; there is no further touch.
• Exit and handoffA purchase ends the journey. If after 48 hours there is no purchase but the item is still in stock, the journey closes without another message; if the item has sold out, the user is handed to Back-in-Stock Alert. Users who fail the pre-check also leave without a message.
• Frequency and consentExactly one push per stock event: do not retrigger the next day because stock is still low, and deduplicate by user, product and stock event. Users without push permission do not enter, and on the handoff verify the user's own restock request rather than creating an alert subscription for them.

1. 1Equal purchase rates in the two groups mean the alert only pulled forward a purchase that would have happened anyway; push opens or product visits do not make up for that. When the rise in push opt-outs outweighs the purchase gap, the journey does not pay.
2. 2The reading holds only for a single push and the 48-hour window. Once the item sells out and the user moves to Back-in-Stock Alert, a later purchase belongs to that journey; never count the same purchase in both. The handoff produces a message only when the user has actually asked to be told.
3. 3A purchase per stock event is a rare outcome; when the gap is small, enter each group's entries and purchases into the A/B test significance calculator, and if the gap is not significant, let more stock events accumulate and run the same read again.
4. 4If most alerted items are still in stock days later, the threshold does not reflect real scarcity; even with a few sales won, a manufactured scarcity message erodes the credibility of every later alert, so redefine the threshold from how fast inventory actually moves.