The short answer: a local inventory feed connects a stable product ID to a stable store ID and reports an availability state—often with quantity, price, and pickup information—at a defined time. The format matters, but identity, freshness, validation, and honest fallback behavior matter more.
Product data and inventory data are different
A product catalog describes the item: title, brand, model, identifiers, image, category, and attributes. Local inventory describes the item at a particular location: whether it is available, how many may be present, what it costs there, and whether pickup is possible.
Keeping those concerns separate reduces duplication. A retailer does not need to resend the full product description for every store if the systems can reliably join:
product ID + store ID → availability record
Google’s Merchant Center inventory model follows this pattern: products are identified by ID, stores by store code, and local records communicate availability and related attributes.
The minimum useful fields
A practical feed usually needs:
- Product identifier: a key that resolves to one item or variant
- Store identifier: a stable code that resolves to one physical location
- Availability: a controlled state such as in stock, limited, out of stock, or unknown
- Updated timestamp: when the source system produced the record
Depending on the use case, it may also include:
- Quantity
- Local price and currency
- Sale price and effective dates
- Pickup method or service level
- On-display or special-order status
- Location-specific product URL
Use controlled values rather than free-text variations such as “yes,” “available,” “we have it,” and “2-ish.” A feed can be syntactically valid while remaining operationally unusable.
Identity is the first hard problem
The inventory record is only useful if both ends resolve correctly.
The product key must connect the retailer’s item to the brand’s canonical product or variant. GTIN, MPN, and brand can help, but retailer SKUs often require a maintained mapping. The store key must connect the retailer’s location code to the exact location displayed in the locator.
Never use an address string as the only store key. Addresses change formatting, suites move, and punctuation differs. Keep a stable internal code and treat address as descriptive data.
Freshness must be defined, not implied
“In stock” is a time-sensitive claim. Decide:
- How often the source can publish updates
- How long a record remains trustworthy
- What happens when an expected feed is late
- Whether the interface shows the last update time
- When availability should fall back to unknown
Google recommends at least daily updates for one of its inventory feed programs, but the right interval depends on sales velocity and customer expectations. Daily may be adequate for durable equipment and inadequate for limited-release products.
Do not keep showing yesterday’s “in stock” state indefinitely because no new file arrived. A stale-feed rule should degrade certainty rather than preserve it.
Full feeds versus incremental updates
A full feed restates the complete current inventory set. It is easier to reconcile but larger to transfer and process. An incremental feed sends only changes. It is more efficient but needs precise rules for deletion, missing records, replay, and recovery after a failed run.
Whichever method you use, document whether omission means:
- No change
- Zero inventory
- Product no longer carried
- Store no longer active
- Data unavailable
Those meanings are not interchangeable. Silent assumptions create phantom inventory or erase valid records.
Validation before ingestion
Validate every delivery at two levels.
File and schema validation
- Required columns exist
- Encoding and delimiter are correct
- Controlled values are valid
- Dates, prices, and quantities parse
- Product and store keys are present
- Duplicate keys are handled consistently
Business validation
- Store codes resolve to active locations
- Product IDs resolve to the intended products
- Quantities and availability do not conflict
- Currency matches the market
- Record counts are within an expected range
- Changes are plausible compared with the previous delivery
A file with ten records can pass its schema while accidentally replacing a feed that normally contains ten thousand. Monitor both format and business shape.
Design the customer-facing confidence states
The UI should distinguish:
- In stock: fresh data supports availability
- Limited availability: supported by the source definition
- Out of stock: a fresh record explicitly says unavailable
- Availability unknown: no fresh, reliable claim can be made
- Dealer carries this product or brand: assortment evidence exists, but store-level stock does not
Offer a sensible action for each state. A customer may still want to call a dealer, visit the seller site, or request directions when exact inventory is unknown.
Operational ownership
Assign an owner for feed failures and exception queues. Define alerts for missing deliveries, rejected records, sudden count changes, unmatched products, unknown stores, and prolonged stale data. Give retailer or dealer partners a clear way to report incorrect results.
The feed is not “set and forget” plumbing. It is a recurring claim to customers about what they can find at a location.
How Omacro uses inventory inputs
Omacro supports local inventory results and provides CSV templates for product and local inventory feeds. The implementation should align identifiers and update rules with each supplier and seller before availability is shown. Start with product matching across retailer catalogs, then review the Help Center templates and downloads.