A back-in-stock subscriber hands you the highest-intent signal in ecommerce. They asked for one specific thing and want to know the moment it exists again. Alert them about the wrong size or color and you have spent that intent on a disappointment, and if the alert fires product-wide you can email 200 people about 3 restocked units. This piece explains why a Klaviyo back-in-stock flow notifies the wrong variant and how to find the exact layer where it breaks.
Key takeaways
- Klaviyo keys a back-in-stock subscription to a single catalog variant, not to the parent product, so wrong-variant alerts almost always trace to how the subscription or the catalog was built, not to the flow logic.
- The flow triggers on the Subscribed to Back in Stock metric and releases waiting profiles when a variant's inventory moves from zero to positive.
- If your catalog feed only carries parent products, every subscriber on any option gets released when one option restocks.
- The alert email looks up the product at send time using
event.VariantId, so a missing or wrong variant ID shows the wrong image and price even when the right people receive it. - Diagnosis has three layers to check in order: what the subscribe event captured, what the catalog contains, and what the email template renders.
What actually triggers a back-in-stock send in Klaviyo?
The flow starts from the Subscribed to Back in Stock metric and holds each profile in a back-in-stock delay step until inventory returns. According to Klaviyo's documentation on how back-in-stock flows work, waiting contacts stay in the delay component's "Waiting" list and move to "Moved to Next Step" only when the item they subscribed to comes back into inventory. The message status has to be Live or Manual for anyone to enter the waiting list at all.
The important part is what "the item they subscribed to" resolves to. Klaviyo's API keys each subscription to a catalog variant through a composite identifier of the form integrationType:::catalogId:::externalId, and the back-in-stock subscription API reference states plainly that it is not possible to submit multiple events for a profile for the same variant. Subscriptions live at the variant level by design. When the wrong people get alerted, something above the flow collapsed that variant down to a product.
Why does the flow notify people who wanted a different variant?
Because the subscription got attached to the parent product rather than the specific variant, so any variant restock releases the whole waitlist. There are three common ways this happens, and they sit at different layers.
The first is the catalog. Klaviyo decides a variant is back in stock by reading the $inventory_quantity field on a catalog item and watching it cross from zero to positive, with $inventory_policy controlling whether an out-of-stock item still appears in dynamic blocks, per the guide to enabling back in stock for custom catalog feeds. If your feed publishes only parent products and never emits catalog-variant items, there is no per-variant inventory to watch. Klaviyo then tracks stock at the product level, and a single option coming back reads as "the product is back," so it releases everyone.
The second is the subscribe call itself. If the "notify me" integration submits a product ID where a variant relationship belongs, every subscriber lands on the same parent record regardless of the option they picked. The third is a mismatch between the ID the subscribe event sent and the ID the catalog actually stores. These composite IDs are scoped to a specific integration and catalog, the same reason cloned flows break in a destination account, and a near-miss ID either matches nothing or matches a fallback parent.
How does the "notify me" button capture the wrong variant?
On Shopify the button often submits the default or first-listed variant rather than the one the shopper selected, because the form was never wired to the variant picker. A product page loads with variant one preselected in the markup. If the subscribe handler reads a static hidden field instead of the live selection, a shopper who switches to Large Navy still submits Small Red. They then get released when Small Red restocks and stay silent when their real choice returns.
This is the failure that looks most like "the flow is wrong" and is actually a front-end capture bug. The tell is that the subscribe events on affected profiles all carry the same variant, usually the one that sorts first. Shopify itself now exposes a variant-scoped signal for this class of automation: its Product variant back in stock trigger in Shopify Flow activates only when a specific variant crosses from zero or negative inventory to one or more units, which is the granularity your subscription capture needs to match.
Why does the email show the wrong image or price even when the right people get it?
The alert template re-looks-up the product at send time and renders whatever the variant ID resolves to, so a missing ID falls back to the parent. Klaviyo populates the restocked product block with dynamic event variables, and on Shopify the block pulls variant data through {% catalog event.VariantId integration='shopify' %}, described in Klaviyo's guide to configuring back-in-stock alert emails. If event.VariantId is empty, the lookup returns the parent product, and the email shows the default image, the "from" price, and a generic title instead of the exact option the shopper waited for.
So there are two distinct wrong-variant symptoms. Wrong recipients means the subscription or catalog collapsed to the product. Wrong content to the right recipients means the recipients are correct but the template lacks a variant ID to render. They have different fixes, which is why you diagnose by layer.
How do you diagnose which layer is broken?
Work from the subscribe event outward, because each layer depends on the one before it. The table maps each symptom to the layer, the exact thing to inspect, and what a healthy account looks like.
| Layer | Symptom you see | What to inspect | Healthy state |
|---|---|---|---|
| Subscribe capture | All subscribers on a product share one variant, usually the first-listed | The Subscribed to Back in Stock events on several profiles; compare their variant against the option each person chose | Each event carries the exact variant the shopper selected |
| Catalog feed | One option restocks and the entire waitlist releases | Whether the catalog contains catalog-variant items with their own $inventory_quantity, not just parent products | Every sellable variant is a distinct catalog item with live inventory |
| ID match | Alerts never fire, or fire for a fallback product | That the composite ID on the subscribe event matches an ID that exists in the catalog for that integration | Subscribe-event variant IDs resolve to real catalog variants |
| Email render | Right people, wrong image or price | Whether event.VariantId is present on the event feeding the template's catalog lookup | The dynamic block renders the subscribed variant's image and price |
A fast confirmation on Shopify: open three affected profiles, read the metric detail on their Subscribed to Back in Stock events, and check the variant. If the variant is identical across shoppers who clearly chose different options, the bug is in capture and no flow edit will fix it. If the variants differ correctly but the send went wide, the catalog is tracking at the product level.
What breaks after the first send, and what to watch
Klaviyo cannot re-verify inventory between messages in a back-in-stock sequence, so a two- or three-message reminder series keeps sending even if the restock sold out an hour after the first alert. That turns a low-stock restock into a queue of disappointed clicks. Keep the sequence short, or gate later messages behind a conditional split that rechecks availability against the catalog before it sends.
The other judgement call is who to release. Notifying every subscriber the instant a variant crosses zero maximizes speed but oversells a thin restock. For scarce, high-demand variants, releasing in batches sized near the restocked quantity protects the experience, at the cost of some urgency. Variant-level tracking also produces long-lived waitlists for options you rarely restock, so audit stale back-in-stock subscriptions the same way you would any dormant segment rather than letting them accumulate against your sending reputation.
Above all, fix the capture layer first. A perfect flow sending a perfectly rendered alert to the wrong person is still the wrong alert, and it spends the one moment where the shopper's intent was already yours.