Most teams argue about creative when the real leak is time. Shopify says zero. Meta still says in stock. Every minute in that gap is a tax on the media budget and on trust.
If you are testing a vendor rather than your own bridge, the controlled version of this experiment is in how to verify a tool's variant-level stock sync.
Why lag is a tax, not a footnote
Dynamic product ads and Shopping both assume availability is roughly true. When it is late:
- You pay for clicks that bounce or refund.
- You train algorithms on bad experiences.
- Support absorbs the conversation you already paid to start.
A 3% CTR improvement will not outrun a two-hour OOS lie on a hero size during a sale.
The experiment (do not skip the log)
Pick a low-risk variant. Record Shopify qty and Meta catalogue availability for the matching retailer ID. Set qty to zero (or sell the last unit on purpose). Timestamp it. Poll until the catalogue shows unavailable. Restock and time the flip back.
Write four fields every time: SKU, time to unavailable, time to available again, who owns the bridge. One clean measurement beats six Slack opinions.
| Lag band | How to read it | Typical response |
|---|---|---|
| Under 15 min | Healthy for most DTC | Monitor heroes; keep buffers |
| 15 to 60 min | Common, still a tax on flash demand | Tighten channel settings; stage pauses on thin cover |
| 1 to 4 hours | Material waste on paid days | Fix feed/location; do not scale heroes blind |
| Over 4 hours | Broken bridge | Stop arguing creatives; fix inventory path first |
Where lag usually hides
- Wrong location in multi-location inventory
- Batch sync instead of near-real-time
- ID mismatches (variant vs product)
- App or channel errors nobody watches
- Buffers that exist in someone’s head but not in the feed
Pair this with the variant-level DPA reality in platforms and OOS variants, and with buffer stock for paid.
If you cannot state your lag in minutes, you do not have a stock-aware ads system. You have hope.
Turn the number into a media rule
Example: lag is 40 minutes on average. Hero cover is 2 days. You do not “monitor”. You cap prospecting when cover crosses your threshold, and you assume up to ~40 minutes of dirty availability after true zero. That is how operators think. Dashboard people wait for refunds.
Ralph’s posture here is correlation and staged action: surface thin cover and OOS risk next to spend, then you approve. It does not invent a zero-lag Meta feed for you. The feed is still your job (or your channel partner’s).
Google in the same afternoon
If Shopping matters, repeat a light version in Merchant Center. Different pipes, same tax. See empty shelves on Shopping.
Estimating the tax in pounds
Rough: (lag hours / 24) × daily spend on product/dynamic campaigns that can still serve the SKU × share of traffic that would have hit that SKU. It is ugly maths and directionally enough. If the estimate is material, lag is a board-level ops issue, not a “feed niggle”.
During BFCM-style peaks, lag multiplies. Run the test before peak, not during it.
Questions people actually ask
What is a good catalogue lag?
Under 15 minutes is strong for most DTC. Under an hour is common. Multi-hour lag on heroes is a media tax you should treat as urgent.
Should I test on a bestseller?
No. Use a low-risk variant with little traffic so you do not create real customer pain.
Does Google lag the same way?
Often yes, sometimes worse. Run a parallel Merchant Center check if Shopping is material.
Can software fix lag alone?
Software can monitor and stage pauses. The feed/channel setup still has to push availability correctly.
If a sold-out size is the problem: Ralph reads every size against every campaign overnight, finds the ones still paying for an empty shelf, and stages the exclusion with a revert for restock day. You say yes. See Ralph · How Ralph handles out-of-stock sizes · Docs