Local Inventory Feed: what it is, how it's structured and how to create It for Google Merchant Center

Note: if you're looking for a strategic overview of Local Inventory Ads — what they are, why to use them and how to set up campaigns — we recommend reading ourdedicated article.This article is its technical companion and assumes the reader is already familiar with LIAs.

Anyone working with Local Inventory Ads knows that ad quality depends almost entirely on one technical component: the Local Product Inventory Feed. Without a precise, up-to-date and well-structured feed, even the most sophisticated campaign strategy will fall short. A single incorrect availability value, a mismatched store_code, a price in the wrong format — these small errors are enough to block the publication of hundreds of products.

This article is a complete technical guide. It answers three concrete questions: what exactly is the Local Inventory Feed and how does it differ from the Primary Feed? Which attributes does it contain and how should they be filled in? How do you create it, upload it to Google Merchant Center and keep it updated over time?

1. What is the Local Inventory Feed (and why does it exist as a separate feed)?

The Local Product Inventory Feed is a data file that communicates to Google Merchant Center the availability and price of products for each physical store. It is not a replacement for the Primary Product Feed: it is a separate, complementary file designed to contain exclusively the information that changes at store level.

Google's decision to separate the two feeds follows a clear operational logic. Store-level data — availability, quantity, local price — changes far more frequently than general product data such as titles, descriptions or images. Managing everything in a single file would mean re-uploading hundreds of static attributes every time the availability of a single SKU changes at a single store. With two distinct feeds, the Primary Feed is updated infrequently, while the Local Inventory Feed is updated daily or more often.

Primary Product Feed vs Local Product Inventory Feed: key differences

Let's summarize the main differences between the two feeds and the role each plays in the system:

Primary Product Feed

• Purpose: contains general product data — title, images, GTIN, description, and all the core catalog attributes
• Update frequency: weekly or monthly, as this data is relatively stable over time
• Main attributes: id, title, description, price, image_link, brand, GTIN, and similar
• Owner: typically managed by the eCommerce or marketing team
• Impact if outdated: ads displaying incorrect titles, images, or base prices

Local Product Inventory Feed

• Purpose: contains availability and pricing specific to each individual physical store, updated in real time
• Update frequency: daily or more frequently, depending on stock turnover
• Main attributes: store_code, id, availability, price, quantity, pickup_method, and similar
• Owner: typically managed by the store management system or the company's ERP
• Impact if outdated: ads showing incorrect availability, resulting in a poor user experience and a concrete risk of account suspension by Google

How Google joins the two feeds

Google uses a composite key to match rows in the Local Inventory Feed to products in the Primary Feed: the unique combination of id (product identifier) and store_code (store code). For every product you want to show in the LIAs of a given store, there must be a row in the Local Inventory Feed with that specific id + store_code pair.
Two direct operational implications of this mechanism:

• If a product is present in the Primary Feed but has no corresponding row in the Local Inventory Feed for a given store, Google will not show it in that store's LIAs — regardless of whether the product is physically available
• If the store_code in the feed does not match exactly the code configured in the Business Profile — including capitalisation — the product will not be correctly matched and will not appear in ads

Understanding this mechanism before building the feed avoids the frustrating situation of having active campaigns but products that never appear. In the vast majority of cases, the root cause is an id or store_code mismatch between the two files.

2. The structure of the Local Inventory Feed: all attributes

The Local Inventory Feed is leaner than the Primary Feed, but each attribute has precise rules. What follows is a complete reference: for required attributes, the required format and accepted values; for optional ones, the concrete impact on campaign performance.

Required Attributes

There are four attributes that must be present in every row of the feed. The absence of even one of them blocks publication of the product for that store.

• store_code — Free text that must match exactly the store code in Google Business Profile (case sensitive field). It can be retrieved from Business Profile → Info → Store ID. Example: store_milan_01
• id — Text that must match the id field of the product in the Primary Feed. Variants have distinct ids and require separate rows in the feed. Example: SKU-12345-BLU-M
• availability — Accepted values: in stock, out of stock, limited availability, on display to order. Note: the value limited availability requires the quantity attribute to also be present in order to work correctly. Example: in stock
• price — A decimal number using a period separator, followed by a space and the currency in ISO 4217 format. It can be omitted only if the local price matches the one already present in the Primary Feed. Example: 29.99 EUR

Some practical notes on required attributes worth expanding on:
store_code is the attribute that causes the most issues during setup. The code is case sensitive: Store_London_01 and store_london_01 are two distinct store codes for Google. To retrieve the exact code for each location, go to Google Business Profile, select the location and look for the 'Store ID' field in the business information.
availability accepts four values with precise meanings. on display to order is specific to products physically displayed in store but purchasable only on a separate order basis (e.g. catalogue sofas, cars at a dealership): it must not be used generically for products that can be ordered online but are not physically present in store.
price must always follow this format: number with a full stop as the decimal separator, a space, then the ISO 4217 currency code. Example: 29.99 GBP. Values such as 29,99 GBP, 29.99 (without currency) or GBP 29.99 are rejected.

Optional attributes with high impact

These attributes are not required for feed validation, but their absence significantly limits ad visibility and effectiveness. In particular, without pickup_method and pickup_sla, the "Pick up today" and "In-store pickup" labels are never displayed — one of the main ways LIAs differentiate themselves from standard Shopping ads.

• quantity — Positive integer (e.g. 5). Essential when availability is set to limited availability; also useful for internal stock turnover reporting
• sale_price — Number followed by the ISO 4217 currency code (e.g. 19.99 GBP). Activates the promotional badge in the ad and displays the original price with a strikethrough, increasing product appeal
• sale_price_effective_date — ISO 8601 format with start and end dates, including timezone (e.g. 2024-12-01T00:00:00+00:00/2024-12-31T23:59:00+00:00). Without this attribute, the promotion is displayed indefinitely, with the risk of showing discounted prices outside the intended period
• pickup_method pickup_method — Accepted values: buy, reserve, ship to store, not supported. Without this attribute, in-store pickup labels are never displayed in the ad
• pickup_sla — Accepted values: same day, next day, 2-day, 3-day, 4-day, 5-day, 6-day, multi-week. The values same day and next day receive a visibility boost over longer timeframes and are the ones that activate the highest-performing labels in LIAs

Optional attributes for advanced use cases

For retailers with specific needs, the feed supports additional optional attributes:

• instoreProductLocation — the product's location within the store (e.g. "Aisle 4 - Electronics"). Useful for large retail spaces: the data is shown in the storefront to help the customer locate the product physically, reducing friction between the store visit and the purchase.
• custom_label_0 / custom_label_4 — custom labels for segmenting campaigns in Google Ads by local availability, product category or any other strategically relevant dimension.
• ads_redirect — alternative URL for tracking purposes. Useful for monitoring traffic from LIAs with dedicated UTM parameters, separating it from standard Shopping traffic in analytics.

3. How to create the Local Inventory Feed

File format and structure

The Local Inventory Feed can be created in two formats, both saved in UTF-8 without BOM:

• TSV (tab-delimited text): the simplest and most straightforward format. The first row contains attribute names as headers; each subsequent row represents the availability of a product in a specific store. Suitable for moderate-sized catalogues or for those getting started with local feeds.
• XML: more verbose but more robust for complex catalogues or for those already managing XML flows within their technical infrastructure. Each product is encapsulated in an element.

Below is an example TSV feed with the main attributes filled in, showing the same product in two different stores and two additional products:

The same content in XML format:

<?xml version="1.0" encoding="UTF-8"?>

<feed xmlns="http://www.w3.org/2005/Atom"
      xmlns:g="http://base.google.com/ns/1.0">

  <entry>
    <g:store_code>store_milan_01</g:store_code>
    <g:id>SKU-001</g:id>
    <g:availability>in stock</g:availability>
    <g:price>49.99 EUR</g:price>
    <g:quantity>5</g:quantity>
    <g:pickup_method>buy</g:pickup_method>
    <g:pickup_sla>same day</g:pickup_sla>
  </entry>

  <!-- repeat one <entry> for each product + store combination -->

</feed>

Multi-Store: managing multiple stores in a single feed

The logic of a multi-store feed is straightforward: each product + store combination occupies a separate row in the file. With 500 products distributed across 4 stores, the feed will contain 2,000 rows. With 1,000 products across 5 stores, 5,000 rows.

If a product is not present in a given store, the corresponding row can either be included with availability: out of stock, or omitted entirely — Google will treat the absence as the product being unavailable at that location. The first option is preferable for maintaining feed consistency over time and making it easier to debug errors.

The advantage of a multi-store format in a single file is the ability to manage completely distinct availability and prices per location: the price of SKU-001 in London can differ from the price in Manchester, and each value will appear in the ad shown to users in the respective geographic area. With multiple locations, it becomes even more critical that store_code values are correct and match exactly those in the Business Profile — a single incorrect code excludes all products from that location from LIAs.

How to upload the feed to Google Merchant Center

Google Merchant Center supports three methods for uploading the Local Inventory Feed, with increasing levels of complexity and update capability:

• Manual upload — The file is uploaded directly from the Google Merchant Center dashboard. Update frequency coincides with the moment of upload, making it suitable only for initial testing or small catalogues with near-static inventory. Not recommended for production use, as it cannot guarantee data accuracy over time.
• Scheduled fetch (URL) — Google downloads the feed from a configured URL at set intervals: hourly, every four hours, or daily. This is the most common solution for retailers with daily updates and an internal system capable of automatically generating the feed file. It requires the file to always be available at the specified URL and updated before each fetch.
• Content API — Real-time push updates via the Google Merchant Center API. The most advanced option and the most suitable for retailers with high stock turnover, many locations or a need for maximum accuracy in the availability shown in ads. Requires dedicated technical development, but is the only solution that guarantees near-immediate alignment between real inventory and data published on Google.

For production environments, scheduled fetch is the minimum acceptable solution: it enables automatic updates without manual intervention, provided the system generating the file is reliable. The Content API is the recommended solution for retailers with dynamic inventories: it allows availability and quantity for a single product in a single store to be updated at the exact moment they change in the management system, eliminating the risk of ads displaying outdated data.

To configure a new feed: from Google Merchant Center → Products → Feeds → click (+) Add feed → select country and language → choose 'Local inventory feed' as the type → select preferred upload method.

Update frequency: how often to refresh the feed

The right frequency depends on how quickly inventory changes:

• Daily updates (absolute minimum): appropriate for low-turnover categories such as furniture, high-end appliances or specialist technical items
• Updates every 4–6 hours: recommended for fashion, consumer electronics and sporting goods
• Real-time updates via Content API: necessary for very high-turnover categories or promotional items with time-limited availability

The cost of an outdated feed is not only a performance issue. A user who clicks on an ad showing "In stock" and arrives at the store to find the product out of stock doesn't just walk away empty-handed — they lose trust in the brand. Google monitors feed accuracy rates and can limit ad distribution, or suspend the account, if data is systematically inaccurate.

4. Common errors and how to fix them

The vast majority of Local Inventory Feed issues fall into three categories: feed mismatch errors, availability errors, and format or upload errors. Here are the most frequent, with their solutions.

Feed mismatch errors

• store_code doesn't match the Business Profile. The most common error during setup. The feed uses Store_London_01 but the Business Profile code is store_london_01. The system finds no match and the product doesn't appear in LIAs for that store. Solution: verify the exact code directly from the Business Profile — don't rely on how it was previously noted down — and update all feeds accordingly.
• Product id not found in the Primary Feed. Google cannot match a row in the Local Inventory Feed to any product in the Primary Feed. This often happens when the two feeds are managed by different systems with different ID conventions (e.g. one uses SKU-001, the other uses 001). Solution: define a unique product ID mapping shared between the two systems before going into production with the feed.
• Price in wrong format. Values such as 29,99 GBP (comma instead of full stop), 29.99 (without currency) or GBP 29.99 (currency before the number) cause parsing errors and rejection of the entire row. The correct format is always: number.decimals space CURRENCY — e.g. 29.99 GBP.

Availability errors

• Product listed as in stock with zero quantity. This contradiction generates warnings in Google Merchant Center and can lead to suspensions if recurring. The rule is simple: if quantity is 0, availability must be out of stock. Make sure the system generating the feed applies this logic automatically before exporting.
• Incorrect use of on display to order. This value is reserved for products physically displayed in store but purchasable only via a separate order (catalogue sofas, cars at a dealership). It must not be used as a generic alternative to in stock for products that can be ordered online but are not physically present in store.
• Inventory system to feed synchronization lag. By far the most common scenario: a product is sold, the stock level drops to zero in the management system, but the feed isn't updated for hours. The only structural solution is direct integration between the inventory management system and the feed generation process — not periodic manual updates.

Upload and validation errors

• Incorrect encoding. Files saved in Latin-1 or Windows-1252 cause errors on characters such as accented letters, ç, ü. Configure the management system export directly to UTF-8, or convert the file before uploading.
• Invisible BOM at the start of the file. TSV files saved as 'UTF-8 with BOM' begin with an invisible control character (U+FEFF) immediately before the first column header. The practical result is that GMC does not recognise id as a valid attribute name — it reads it as an unknown token because of the extra invisible character prepended — and the entire column is ignored. Solution: always save as 'UTF-8 without BOM'.
• Scheduled URL unreachable by Google. Google cannot download the feed from the configured URL. Most common causes: authentication required on the endpoint, Google's IP not whitelisted on the server, file temporarily unavailable. Quick test: open the URL in a private/incognito browser window — if it's not accessible without credentials, the same will apply to Google.

How to read the Google Merchant Center diagnostics section

The GMC Diagnostics section is the primary tool for monitoring feed status after each upload. It can be found at Products → Diagnostics.

Google distinguishes between errors — which block product publication — and warnings, where the product is published but with suboptimal data. Always prioritise errors before addressing warnings.

• The Feed tab shows file processing errors: format issues, unrecognised attribute names, values outside the accepted range
• The Item tab shows errors at individual product level: mismatches with the Primary Feed, policy issues, inconsistent data between attributes

For each error, GMC shows the number of products affected and a concrete example: always start with the error blocking the most products to maximise recovery in terms of ad coverage.

5. Managing the feed over time: automation and tools

Why manual updates don't scale

The maths is straightforward: a retailer with 800 active SKUs distributed across 5 stores has 4,000 combinations to keep updated every day. Managing these manually is not operationally sustainable — and even relying on semi-automatic spreadsheet exports introduces a constant risk of human error and delayed updates.

Feed automation is not an advanced option: it is the prerequisite for making Local Inventory Ads a reliable long-term tool. A chronically delayed feed not only reduces campaign performance but can lead to penalties from Google for systematically inaccurate data.

Integration with the Inventory Management System / ERP

The ideal flow is: inventory management system or ERP as the single source of truth → automatic feed update whenever availability changes → push to Google Merchant Center via scheduled fetch or Content API.

The three data points that must be synchronised between the management system and the feed are: availability (in stock / out of stock), quantity per store and local price (if it differs by location). More static attributes — such as pickup_method, pickup_sla and instoreProductLocation — change rarely and can be managed separately or updated at a much lower frequency.

In the absence of direct integration, an intermediate solution is to automate the export from the management system in TSV format and configure a scheduled fetch in GMC: even this approach eliminates manual updating and guarantees a synchronisation frequency adequate for most use cases.

Feed management platforms and tools

Several platforms specialise in creating and managing local inventory feeds, making it possible to automate and significantly simplify the process compared to a manual approach. Solutions such as DataFeedWatch, Channable and Feedonomics offer useful tools for structuring and synchronising product data, reducing the risk of errors and the time needed to keep feeds up to date. Entrusting this to these platforms means being able to manage large volumes of data centrally, with automatic transformation rules and continuous feed quality monitoring.

However, when it comes to the Local Inventory Feed and the complexity involved in integrating physical store data, real-time availability and Google's specific requirements, not all platforms offer the same level of specialisation. Highstreet.io stands clearly apart: with over 10 years of experience and the capacity to process more than 2 billion data points per day, it delivers enterprise-grade performance and reliability at scale. The platform integrates with e-commerce systems, PIMs, DAMs and OMS to receive all product, inventory and store data centrally — but the flow is not one-directional: Highstreet.io is capable of feeding order data back into those same systems, keeping stock consistently aligned across online channels and physical stores.

Unlike generalist solutions, Highstreet.io pairs every client with a dedicated onboarding service and continuous support throughout the entire project, from initial configuration to campaign optimisation — making it the ideal choice for those who want to get the most out of Local Inventory Ads.

6. Frequently Asked Questions

Does the Local Inventory Feed replace the Primary Feed?

No. The two feeds are complementary and must coexist. The Primary Feed contains general product information (title, description, images, GTIN); the Local Inventory Feed adds per-store availability information. Without the Primary Feed, the Local Inventory Feed has no effect — Google does not have the base information needed to build the ad.

Can I use the same feed for multiple countries?

No. Each feed is associated with a specific country in Google Merchant Center. For retailers with stores in different countries, separate feeds must be created — with store_code values and prices in the local currency of the corresponding country — and configured separately for each country in the GMC dashboard.

How many rows can a Local Inventory Feed contain?

Google does not impose an official limit on the number of rows. Feeds with millions of rows (very large catalogues with many locations) are processed normally, provided file size limits are respected. For very large feeds, the Content API is preferable to scheduled fetch to ensure acceptable update times.

How do I verify that the feed has been processed correctly?

In Google Merchant Center: Products → Diagnostics for the overall status. Or Products → Feeds → select the specific feed to view the details of the last upload: number of products processed, errors encountered and timestamp of the last update.

Do product variants (colour, size) require separate rows?

Yes. Each variant has a distinct id in the Primary Feed and requires a separate row in the Local Inventory Feed for each store where it is available. If variant SKU-001-BLU-M is available in two stores, two rows are needed: one for the first store's store_code, one for the second.

What happens if a product shows as out of stock in the feed but is actually available in store?

The experience of the customer who visits the store is positive (they find something they weren't expecting), but that product is not shown in LIAs until the feed is updated with the correct availability. Over time, a feed that is systematically slow to register stock replenishments means losing visibility on available products — and potential sales going to competitors.

7. Conclusions

The Local Product Inventory Feed is the technical core of Local Inventory Ads. Without a precise, up-to-date and correctly structured feed, the campaign will not deliver results regardless of the quality of the strategy driving it. Investing in the correct attribute setup, update automation and error monitoring is not an optional technical activity — it is the necessary condition for LIAs to generate value over the long term.

To explore how LIAs fit into an omnichannel strategy, what sets them apart from standard Shopping ads and how to configure campaigns in Google Ads, refer to ourcomplete guide on Local Inventory Ads..

Want to automate the management of your Local Inventory Feed? Find out how we can help.