Abandoned Cart Recommendations With Out-of-Stock and Price Drift

There are three failure modes:

1. Inventory staleness: the catalog sync runs every 12 hours, so an item that goes out of stock at 9 a.m. can still be promoted at 1 p.m. This drives clicks to sold-out pages and is the most visible customer-experience failure.
2. Price staleness: a price drop at 10 a.m. is not reflected until the next sync. This is a trust and sometimes legal issue, but it is less likely to cause an immediate complaint than a sold-out link.
3. Missing fallback: the template pulls item IDs directly from the cart event. If an item is removed from the catalog or the ID is invalid, the template may render blank or broken content.

I would prioritize out-of-stock promotion because it creates a dead-end experience and can trigger complaints. Price drift is second, and missing fallback is third but should be fixed in the same change because it prevents broken emails when catalog data is incomplete.

I would use the 2-hour sync budget on the fields that change fastest and add send-time fallback logic.

• Sync high-velocity fields every 2 hours: inventory status, price, and product URL for the products collection. Keep slower descriptive fields on the existing cadence if needed.
• Create an in_stock_products collection: populate it from the same sync and include only items with inventory > 0. The journey template should look up the cart item in this collection first.
• Conditional fallback: if the cart item is not in in_stock_products, render an alternative from the same category or a best-seller collection, not a sold-out item. For the backpack price drop, always render the current catalog price rather than a price stored on the cart event.
• Staleness check: include a last_synced_at field. If the catalog data is older than 4 hours at send time, fall back to a generic recommendation block rather than risk stale inventory.
• Template validation: handle missing item IDs with a default block and a link to the cart, not an empty image.

This stays within the API limit because it changes what is synced and how it is used, not how often the full catalog is pulled.

I would run an A/B test in the journey: control uses the current 12-hour catalog and direct item lookup; treatment uses the 2-hour high-velocity sync, in_stock_products, and fallback logic.

Primary metric: purchase conversion rate per journey entrant, measured against the journey holdout where possible.

Secondary metrics: click-through rate on the cart item, fallback-block click rate, revenue per recipient, and sold-out landing-page rate.

Guardrails: complaint rate, unsubscribe rate, and email render-failure rate. The complaint rate is especially important because the current 0.05% baseline should not rise.

I would also monitor catalog sync lag and the percentage of sends that used a fallback. A healthy result is a lower sold-out click rate and stable or higher conversion, with no increase in complaints. If conversion drops because the fallback recommendations are weaker, I would tune the fallback collection before rolling out broadly.