availability

Availability is the field that wastes the most ad budget when it's wrong. Items marked "in stock" after actual inventory hits zero keep spending impressions on products users can't buy. Channels suspend out-of-stock items from delivery only when the feed flips — until then, the user-facing experience and the actual fulfillment reality drift apart. The wasted-budget calculation: for a £10 average CPC on a category with a 4% conversion rate and 24-hour stockout drift, a 1000-unit catalog wastes roughly 1000 × £10 × 4% × 24/720 ≈ £13/day per stocked-out item that's still serving. Across a few dozen stockouts, this is meaningful spend going to dead products.

The right refresh cadence varies sharply by inventory velocity. Stable catalogs (furniture, slow-moving home goods) can run on daily refreshes without much drift. Active assortments (fashion, electronics, anything with stockouts during the day) need hourly refreshes minimum. Real-time updates via the Catalog Batch API are the gold standard for price-sensitive or stockout-prone inventory. Most catalogs running daily refreshes are silently overserving on items that have stocked out earlier in the day.

The variant handling is where most catalogs trip. When a specific size or colour variant sells out, only that variant's availability should flip — the parent item_group stays in stock because other variants remain. Feed pipelines that flip the whole item_group when one variant stocks out pull the entire product out of serving, which loses real available inventory to the algorithm. Treat variant-level stock separately from item-group-level stock.

The four-value enum (in stock, out of stock, preorder, backorder) is more nuanced than it looks. Backorder means "you can buy it now, it'll ship when restocked"; preorder means "you can buy it now, it ships on a known future date"; out of stock means "you can't buy it right now". Channels treat these differently. Preorders without a pair availability_date get suppressed (channels distrust unspecified preorders). Backorders without realistic restocking expectations damage account quality when orders don't actually ship. Out of stock items remain in the catalog but don't serve in placements — historical learning signal is preserved.

The strategic question of "delete vs out-of-stock" comes up often. Out of stock preserves the product's historical performance signal — when restocked, the item resumes optimisation from where it was. Deleted items lose their signal; restocking effectively creates a new product from the algorithm's perspective. For products that come back into stock within weeks (most fashion seasonals, recurring releases), out-of-stock is the right answer. For products genuinely discontinued (end-of-line, replaced by newer SKU), delete is correct.

Schema.org markup verification matters here too. Google reads availability schema markup on landing pages. If the schema says "in stock" while the feed says "out of stock", channels treat the schema as more authoritative for the visible page state. Pages that visually show "Sold out" but have stale schema markup showing "InStock" get the listing flagged as Mismatched value [availability]. Audit schema as part of availability diagnostics, not just the visible page state.

For real-time availability via Catalog Batch API, the implementation discipline matters. Updates should be triggered by stock-state changes in the source system, not on schedule. A stockout at 14:23 should trigger a feed update at 14:23, not at 15:00 with the next scheduled push. Most modern integrations support webhook-driven updates; older ones don't and need explicit polling, which is closer to scheduled refreshes than true real-time.