Guide, Marketing

Local Inventory Feed: cos’è, come si struttura e come crearlo per Google Merchant Center

Nota: se stai cercando una panoramica strategica sulle Local Inventory Ads — cosa sono, perché usarle e come configurare le campagne — ti rimandiamo all’articolo dedicato. Questo articolo è il suo complemento tecnico e parte dal presupposto che il lettore abbia già familiarità con le LIA.

Chi lavora con le Local Inventory Ads sa che la qualità degli annunci dipende quasi interamente da un componente tecnico: il Local Product Inventory Feed. Senza un feed preciso, aggiornato e ben strutturato, nemmeno la strategia di campagna più sofisticata può funzionare. Un dato di disponibilità errato, uno store_code che non corrisponde, un prezzo in formato sbagliato: bastano questi piccoli errori per bloccare la pubblicazione di centinaia di prodotti.

Questo articolo è una guida tecnica completa. Risponde a tre domande concrete: cos’è esattamente il Local Inventory Feed e in cosa si distingue dal Primary Feed? Quali attributi contiene e come vanno compilati? Come si crea, si carica su Google Merchant Center e si mantiene aggiornato nel tempo?

1. Cos’è il Local Inventory Feed (e perché esiste un feed separato)

Il Local Product Inventory Feed è un file di dati che comunica a Google Merchant Center la disponibilità e il prezzo dei prodotti per ciascun negozio fisico. Non è un sostituto del Primary Product Feed: è un file separato e complementare, progettato per contenere esclusivamente le informazioni che cambiano a livello di store.

La scelta di Google di separare i due feed risponde a una logica operativa precisa. I dati di negozio — disponibilità, quantità, prezzo locale — cambiano con una frequenza molto maggiore rispetto ai dati prodotto generali come titolo, descrizione o immagini. Gestire tutto in un unico file significherebbe ricaricare centinaia di attributi statici ogni volta che cambia la disponibilità di un singolo SKU in un singolo negozio. Con due feed distinti, il Primary Feed viene aggiornato raramente, il Local Inventory Feed viene aggiornato giornalmente o più spesso.

Primary Product Feed vs Local Product Inventory Feed: le differenze

Riassumiamo di seguito le differenze principali tra i due feed e il ruolo che ciascuno svolge nel sistema:

Primary Product Feed

Scopo: contiene i dati generali del prodotto — titolo, immagini, GTIN, descrizione e tutti gli attributi base del catalogo
Frequenza di aggiornamento: settimanale o mensile, essendo dati relativamente stabili nel tempo
Attributi principali: id, title, description, price, image_link, brand, GTIN e simili
Responsabile: tipicamente gestito dal team eCommerce o marketing
Impatto se obsoleto: annunci con titolo, immagine o prezzo base errati

Local Product Inventory Feed

Scopo: contiene la disponibilità e il prezzo specifici per ogni singolo negozio fisico, aggiornati in tempo reale
Frequenza di aggiornamento: giornaliera o più frequente, in base alla rotazione dello stock
Attributi principali: store_code, id, availability, price, quantity, pickup_method e simili
Responsabile: tipicamente gestito dal sistema gestionale o dall’ERP aziendale
Impatto se obsoleto: annunci con disponibilità errata, con conseguente UX negativa per l’utente e rischio concreto di sospensione dell’account da parte di Google

Come Google collega i due feed: il meccanismo di join

Google utilizza una chiave composta per abbinare le righe del Local Inventory Feed ai prodotti del Primary Feed: la combinazione univoca di id (identificativo del prodotto) e store_code (codice del negozio). Per ogni prodotto che si vuole mostrare nelle LIA di un determinato negozio, deve esistere una riga nel Local Inventory Feed con quella specifica coppia id + store_code.
Due conseguenze operative dirette di questo meccanismo:

Se un prodotto è presente nel Primary Feed ma non ha una riga corrispondente nel Local Inventory Feed per un certo negozio, Google non lo mostrerà nelle LIA di quel negozio — indipendentemente dal fatto che il prodotto sia fisicamente disponibile
Se lo store_code nel feed non corrisponde esattamente al codice configurato nel Business Profile — maiuscole incluse — il prodotto non verrà associato correttamente e non comparirà negli annunci

Capire questo meccanismo prima di costruire il feed evita di trovarsi con campagne attive ma prodotti che non appaiono: nella quasi totalità dei casi, la causa è un mismatch di id o store_code tra i due file.

2. La struttura del Local Inventory Feed: tutti gli attributi

Il Local Inventory Feed è più snello del Primary Feed, ma ogni attributo ha regole precise. Di seguito una reference completa: per gli attributi obbligatori, formato richiesto e valori accettati; per quelli facoltativi, l’impatto concreto sulla performance delle campagne.

Attributi obbligatori

Sono quattro gli attributi che devono essere presenti in ogni riga del feed. L’assenza di anche uno solo blocca la pubblicazione del prodotto per quel negozio.

store_code — Testo libero che deve coincidere esattamente con il codice negozio presente in Google Business Profile (campo case sensitive). Si recupera da Business Profile → Informazioni → ID negozio. Esempio: negozio_milano_01
id — Testo che deve coincidere con il campo id del prodotto nel Primary Feed. Le varianti hanno id distinti e richiedono righe separate nel feed. Esempio: SKU-12345-BLU-M
availability — Valori accettati: in stock, out of stock, limited availability, on display to order. Attenzione: il valore limited availability richiede che sia presente anche l’attributo quantity per funzionare correttamente. Esempio: in stock
price — Numero con punto decimale, seguito da uno spazio e dalla valuta in formato ISO 4217. È omettibile solo se il prezzo locale coincide con quello già presente nel Primary Feed. Esempio: 29.99 EUR

Alcune note pratiche sugli attributi obbligatori che vale la pena approfondire:
store_code — è l’attributo che causa più problemi in fase di setup. Il codice è case sensitive: ‘Negozio_Milano_01’ e ‘negozio_milano_01’ sono due store code distinti per Google. Per recuperare il codice esatto di ogni sede, accedere a Google Business Profile, selezionare la sede e cercare il campo ‘ID negozio’ nelle informazioni dell’attività.
availability — accetta quattro valori con significati precisi. ‘on display to order’ è specifico per prodotti fisicamente esposti in negozio ma acquistabili solo su ordine (es. divani su catalogo, auto in concessionaria): non deve essere usato genericamente per prodotti ordinabili online ma non presenti fisicamente in store.
price — il formato corretto è sempre: numero con punto come separatore decimale, uno spazio, codice valuta ISO 4217. Esempio: 29.99 EUR. Valori come ‘29,99 EUR’, ‘29.99’ (senza valuta) o ‘EUR 29.99’ vengono rifiutati.

Attributi facoltativi ad alto impatto

Questi attributi non sono obbligatori per la validazione del feed, ma la loro assenza limita significativamente la visibilità e l’efficacia degli annunci. In particolare, senza pickup_method e pickup_sla le etichette ‘Ritiro oggi’ e ‘In-store pickup’ non vengono mai mostrate — uno dei principali motivi per cui le LIA si differenziano dagli annunci Shopping standard.

quantity — Intero positivo (es. 5). Essenziale quando availability è impostato su limited availability; utile anche per il reporting interno sulla rotazione dello stock
sale_price — Numero seguito dalla valuta in formato ISO 4217 (es. 19.99 EUR). Attiva il badge promozione nell’annuncio e mostra il prezzo originale barrato, aumentando l’attrattività del prodotto
sale_price_effective_date — Formato ISO 8601 con data di inizio e fine promozione, incluso il timezone (es. 2024-12-01T00:00:00+01:00/2024-12-31T23:59:00+01:00). Senza questo attributo la promozione viene mostrata a tempo indeterminato, con il rischio di esporre prezzi scontati anche fuori dal periodo previsto
pickup_method — Valori accettati: buy, reserve, ship to store, not supported. Senza questo attributo le etichette di ritiro in negozio non vengono mai visualizzate nell’annuncio. Esempio: buy
pickup_sla — Valori accettati: same day, next day, 2-day, 3-day, 4-day, 5-day, 6-day, multi-week. I valori same day e next day ricevono un boost di visibilità rispetto ai tempi più lunghi e sono quelli che attivano le etichette più performanti nelle LIA. Esempio: same day

Attributi facoltativi per casi avanzati

Per retailer con esigenze specifiche, il feed supporta ulteriori attributi opzionali:

instoreProductLocation — posizione del prodotto all’interno del negozio (es. ‘Corsia 4 – Reparto Elettronica’). Utile per grandi superfici commerciali: il dato viene mostrato nello storefront per aiutare il cliente a trovare il prodotto fisicamente, riducendo l’attrito tra la visita in negozio e l’acquisto.
custom_label_0 / custom_label_4 — etichette personalizzate per segmentare le campagne in Google Ads per disponibilità locale, categoria merceologica o qualsiasi altra dimensione strategicamente rilevante.
ads_redirect — URL alternativo per il tracciamento. Utile per monitorare il traffico proveniente dalle LIA con parametri UTM dedicati, separandolo dal traffico Shopping standard nelle analytics

3. Come creare il Local Inventory Feed

Formato e struttura del file

Il Local Inventory Feed può essere creato in due formati, entrambi da salvare in UTF-8 senza BOM:

TSV (testo delimitato da tab): il formato più semplice e immediato. La prima riga contiene i nomi degli attributi come intestazione; ogni riga successiva rappresenta la disponibilità di un prodotto in uno specifico negozio. Adatto per cataloghi di dimensioni moderate o per chi inizia a lavorare con i feed locali.
XML: più verboso ma più robusto per cataloghi complessi o per chi gestisce già flussi XML nell’ecosistema tecnico aziendale. Ogni prodotto è incapsulato in un elemento <entry>.

Di seguito un esempio di feed TSV con i principali attributi compilati, che mostra lo stesso prodotto in due negozi diversi e due prodotti aggiuntivi:

Lo stesso contenuto in formato XML:

<?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: gestire più negozi in un unico feed

La logica del feed multi-store è semplice: ogni combinazione prodotto + negozio occupa una riga separata nel file. Con 500 prodotti distribuiti su 4 negozi, il feed conterrà 2.000 righe. Con 1.000 prodotti su 5 negozi, 5.000 righe.

Se un prodotto non è presente in un certo negozio, la riga corrispondente può essere inclusa con availability: out of stock, oppure omessa — Google tratterà l’assenza come prodotto non disponibile in quella sede. La prima opzione è preferibile per mantenere la coerenza del feed nel tempo e facilitare il debug in caso di errori.

Il vantaggio del formato multi-store in un unico file è la possibilità di gestire disponibilità e prezzi completamente distinti per sede: il prezzo del prodotto SKU-001 a Milano può essere diverso da quello a Roma, e ciascun valore comparirà nell’annuncio mostrato all’utente nella rispettiva area geografica. Con più sedi diventa ancora più critico che i store_code siano corretti e corrispondano esattamente a quelli del Business Profile — un solo codice errato esclude tutti i prodotti di quella sede dalle LIA.

Come caricare il feed su Google Merchant Center

Google Merchant Center supporta tre modalità di caricamento del Local Inventory Feed, con livelli crescenti di complessità e capacità di aggiornamento:

Upload manuale — Il file viene caricato direttamente dal pannello di Google Merchant Center. La frequenza di aggiornamento coincide con il momento del caricamento, il che lo rende adatto esclusivamente a test iniziali o cataloghi piccoli con inventario quasi statico. È una modalità sconsigliata per l’uso in produzione, poiché non garantisce l’accuratezza dei dati nel tempo.
Scheduled fetch (URL) — Google scarica il feed da un URL configurato a intervalli prestabiliti: ogni ora, ogni quattro ore o giornalmente. È la soluzione più diffusa per i retailer con aggiornamenti quotidiani e un sistema interno in grado di generare automaticamente il file di feed. Richiede che il file sia sempre disponibile all’URL indicato e aggiornato prima di ogni fetch.
Content API — Aggiornamenti push in tempo reale tramite le API di Google Merchant Center. È la modalità più avanzata e la più adatta a retailer con alta rotazione di stock, molte sedi o esigenze di massima accuratezza nella disponibilità esposta negli annunci. Richiede sviluppo tecnico dedicato, ma è l’unica soluzione che garantisce un allineamento pressoché immediato tra inventario reale e dati pubblicati su Google.

Per la produzione, lo scheduled fetch è la soluzione minima accettabile: permette aggiornamenti automatici senza intervento manuale, a patto che il sistema che genera il file sia affidabile. La Content API è la soluzione raccomandata per retailer con inventari dinamici: consente di aggiornare disponibilità e quantità di un singolo prodotto in un singolo negozio nel momento esatto in cui cambiano nel gestionale, eliminando il rischio di annunci con dati obsoleti.

Per configurare un nuovo feed: da Google Merchant Center → Prodotti → Feed → clic su (+) Aggiungi feed → selezionare il paese e la lingua → scegliere ‘Feed di inventario locale’ come tipo → selezionare il metodo di caricamento preferito.

Frequenza di aggiornamento: con che cadenza ricaricare il feed

La frequenza giusta dipende da quanto velocemente cambia l’inventario:

Aggiornamento giornaliero (minimo assoluto): adeguato per categorie a bassa rotazione come arredamento, elettrodomestici di fascia alta o articoli tecnici specializzati
Aggiornamento ogni 4–6 ore: consigliato per moda, elettronica di consumo, articoli sportivi
Aggiornamento in tempo reale via Content API: necessario per categorie ad altissima rotazione o articoli promozionali con disponibilità limitata nel tempo

Il costo di un feed obsoleto non è solo di performance. Un utente che clicca su un annuncio che mostra ‘Disponibile in negozio’ e trova il prodotto esaurito al momento della visita non solo non compra, ma perde fiducia nel brand. Google monitora il tasso di accuratezza del feed e può limitare la distribuzione degli annunci — o sospendere l’account in caso di dati sistematicamente errati.

4. Errori comuni e come risolverli

La maggior parte dei problemi con il Local Inventory Feed rientra in tre categorie: errori di mismatch tra feed, errori di disponibilità e errori di formato o caricamento. Ecco i più frequenti con le relative soluzioni.

Errori di mismatch tra feed

store_code non corrisponde al Business Profile. È l’errore più comune in fase di setup. Il feed usa ‘Negozio_Milano_01’ ma nel Business Profile il codice è ‘negozio_milano_01’. Il sistema non trova corrispondenza e il prodotto non appare nelle LIA per quel negozio. Soluzione: verificare il codice esatto direttamente dal Business Profile — non fidarsi di come era stato annotato in precedenza — e aggiornare tutti i feed di conseguenza.
id prodotto non trovato nel Primary Feed. Google non riesce ad abbinare una riga del Local Inventory Feed a nessun prodotto nel Primary Feed. Accade spesso quando i due feed sono gestiti da sistemi diversi con convenzioni di ID diverse (es. uno usa ‘SKU-001’, l’altro usa ‘001’). Soluzione: definire una mappatura univoca dell’id prodotto condivisa tra i due sistemi prima di avviare la produzione del feed.
Prezzo in formato errato. I valori ‘29,99 EUR’ (virgola invece di punto), ‘29.99’ (senza valuta) o ‘EUR 29.99’ (valuta prima del numero) causano errori di parsing e il rifiuto dell’intera riga. Il formato corretto è sempre: numero.decimali spazio VALUTA — es. ‘29.99 EUR’.

Errori di disponibilità

Prodotto in stock con quantità zero. Contraddizione che genera warning in Google Merchant Center e può portare a sospensioni se ricorrente. La regola è semplice: se quantity è 0, availability deve essere out of stock. Assicurarsi che il sistema che genera il feed applichi questa logica automaticamente prima di esportare.
Uso errato di ‘on display to order’. Questo valore è riservato a prodotti fisicamente esposti in negozio ma acquistabili solo tramite ordine separato (divani su catalogo, auto in concessionaria). Non va usato come alternativa generica a ‘in stock’ per prodotti ordinabili online ma non presenti fisicamente in store.
Mancata sincronizzazione gestionale-feed. Il caso più frequente in assoluto: il prodotto viene venduto, la giacenza scende a zero nel gestionale, ma il feed non viene aggiornato per ore. L’unica soluzione strutturale è l’integrazione diretta tra il sistema gestionale e il processo di generazione del feed — non gli aggiornamenti manuali periodici.

Errori di caricamento e validazione

Encoding non corretto. File salvati in Latin-1 o Windows-1252 causano errori su caratteri come accenti (à, è, ò), ç, ü. Configurare l’export del gestionale direttamente in UTF-8, o convertire il file prima del caricamento.
BOM invisibile all’inizio del file. I file TSV salvati come ‘UTF-8 with BOM’ iniziano con un carattere di controllo invisibile (U+FEFF) che precede immediatamente il primo header di colonna. Il risultato pratico è che GMC non riconosce ‘id’ come nome attributo valido — lo legge come un token sconosciuto perché ha un carattere extra invisibile davanti — e l’intera colonna viene ignorata. Soluzione: salvare sempre come ‘UTF-8 without BOM’.
URL scheduled non raggiungibile da Google. Google non riesce a scaricare il feed dall’URL configurato. Cause più comuni: autenticazione richiesta sull’endpoint, IP di Google non in whitelist sul server, file temporaneamente non disponibile. Test rapido: aprire l’URL in una finestra di navigazione in incognito — se non è accessibile senza credenziali, lo stesso accadrà a Google.

Come leggere la sezione Diagnostica di Google Merchant Center

La Diagnostica di GMC è lo strumento principale per monitorare lo stato del feed dopo ogni caricamento. Si trova in Prodotti → Diagnostica.

Google distingue tra errori — che bloccano la pubblicazione del prodotto — e avvisi, dove il prodotto è pubblicato ma con dati subottimali. È bene prioritizzare sempre gli errori prima di occuparsi degli avvisi.

Il tab Feed mostra gli errori di elaborazione del file: problemi di formato, nomi di attributi non riconosciuti, valori fuori dal range accettato
Il tab Articolo mostra errori a livello di singolo prodotto: mismatch con il Primary Feed, problemi di policy, dati incoerenti tra attributi

Per ogni errore GMC mostra il numero di prodotti coinvolti e un esempio concreto: partire sempre dall’errore che blocca più prodotti per massimizzare il recupero in termini di copertura degli annunci.

5. Gestione del feed nel tempo: automazione e strumenti

Perché l’aggiornamento manuale non scala

Il calcolo è semplice: un retailer con 800 SKU attivi distribuiti su 5 negozi ha 4.000 combinazioni da tenere aggiornate ogni giorno. Gestirle manualmente non è operativamente sostenibile — e anche ricorrere a export semiautomatici da un foglio di calcolo introduce un rischio costante di errori umani e aggiornamenti ritardati.

L’automazione del feed non è un’opzione avanzata: è il prerequisito per rendere le Local Inventory Ads uno strumento affidabile nel lungo periodo. Un feed cronicamente in ritardo non solo riduce la performance delle campagne, ma può portare a penalizzazioni da parte di Google per dati sistematicamente inaccurati.

Integrazione con il gestionale / ERP

Il flusso ideale è: gestionale o ERP come unica source of truth → aggiornamento automatico del feed ogni volta che cambia la disponibilità → push verso Google Merchant Center tramite scheduled fetch o Content API.

I dati da sincronizzare obbligatoriamente tra gestionale e feed sono tre: disponibilità (in stock / out of stock), quantità per negozio e prezzo locale (se diverso da sede a sede). Gli attributi più statici — come pickup_method, pickup_sla e instoreProductLocation — cambiano raramente e possono essere gestiti separatamente o aggiornati con una cadenza molto meno frequente.

In assenza di integrazione diretta, una soluzione intermedia è automatizzare l’export dal gestionale in formato TSV e configurare uno scheduled fetch su GMC: anche questo approccio elimina l’aggiornamento manuale e garantisce una frequenza di sincronizzazione adeguata per la maggior parte dei casi d’uso.

Strumenti e piattaforme di feed management

Esistono diverse piattaforme specializzate nella creazione e gestione dei Local Inventory Feed che permettono di automatizzare e semplificare notevolmente il processo rispetto a un approccio manuale. Soluzioni come DataFeedWatch, Channable e Feedonomics offrono strumenti utili per strutturare e sincronizzare i dati di prodotto, riducendo il rischio di errori e il tempo necessario per mantenere i feed aggiornati. Affidarsi a queste piattaforme significa poter gestire grandi volumi di dati in modo centralizzato, con regole di trasformazione automatiche e monitoraggio continuo della qualità del feed.

Tuttavia, quando si tratta di Local Inventory Feed e della complessità che comporta l’integrazione tra dati di negozio fisico, disponibilità in tempo reale e requisiti specifici di Google, non tutte le piattaforme offrono lo stesso livello di specializzazione. Highstreet.io si distingue nettamente dalla concorrenza: con oltre 10 anni di esperienza e una capacità di elaborare più di 2 miliardi di dati al giorno, garantisce performance e affidabilità su scala enterprise. La piattaforma si integra con eCommerce, PIM/DAM e OMS per ricevere in modo centralizzato tutti i dati di prodotto, inventario e di negozio — ma il flusso non è unidirezionale: Highstreet.io è in grado di reinviare i dati sugli ordini generati verso questi stessi sistemi, mantenendo lo stock sempre aggiornato e allineato tra canali online e punti vendita fisici.

A differenza delle soluzioni generaliste, Highstreet.io affianca ogni cliente con un servizio di onboarding dedicato e un supporto continuativo lungo tutto il progetto, dalla configurazione iniziale fino all’ottimizzazione delle campagne — rendendola la scelta ideale per chi vuole ottenere il massimo dalle Local Inventory Ads.

6. Domande frequenti

Il Local Inventory Feed sostituisce il Primary Feed?

No. I due feed sono complementari e devono coesistere. Il Primary Feed contiene le informazioni generali del prodotto (titolo, descrizione, immagini, GTIN); il Local Inventory Feed aggiunge le informazioni di disponibilità per negozio. Senza Primary Feed, il Local Inventory Feed non ha effetto — Google non ha le informazioni di base per costruire l’annuncio.

Posso usare lo stesso feed per più paesi?

No. Ogni feed è associato a un paese specifico in Google Merchant Center. Per retailer con sedi in paesi diversi è necessario creare feed separati, con store_code e prezzi nella valuta locale del paese corrispondente, e configurarli separatamente per ogni paese nel pannello GMC.

Quante righe può contenere un Local Inventory Feed?

Google non impone un limite ufficiale al numero di righe. Feed con milioni di righe (cataloghi molto ampi con molte sedi) vengono elaborati normalmente, purché nel rispetto dei limiti di dimensione file. Per feed molto grandi, la Content API è preferibile allo scheduled fetch per garantire tempi di aggiornamento accettabili.

Come verifico se il feed è stato elaborato correttamente?

In Google Merchant Center: Prodotti → Diagnostica per lo stato generale. Oppure Prodotti → Feed → selezionare il feed specifico per vedere i dettagli dell’ultimo caricamento: numero di prodotti elaborati, errori riscontrati e timestamp dell’ultimo aggiornamento.

Le varianti di prodotto (colore, taglia) richiedono righe separate?

Sì. Ogni variante ha un id distinto nel Primary Feed e richiede una riga separata nel Local Inventory Feed per ogni negozio in cui è disponibile. Se la variante SKU-001-BLU-M è disponibile in due negozi, servono due righe: una per store_code del primo negozio, una per il secondo.

Cosa succede se un prodotto risulta esaurito nel feed ma è in realtà disponibile in negozio?

L’esperienza del cliente che visita il negozio è positiva (trova qualcosa che non si aspettava), ma quel prodotto non viene mostrato nelle LIA finché il feed non viene aggiornato con la disponibilità corretta. Sul lungo periodo, un feed sistematicamente in ritardo nel registrare i rientri di stock significa perdere visibilità su prodotti disponibili — e potenziali vendite che vanno ai competitor.

7. Conclusioni

Il Local Product Inventory Feed è il cuore tecnico delle Local Inventory Ads. Senza un feed preciso, aggiornato e correttamente strutturato, la campagna non produce risultati indipendentemente dalla qualità della strategia che la governa. Investire nel setup corretto degli attributi, nell’automazione degli aggiornamenti e nel monitoraggio degli errori non è un’attività tecnica accessoria — è la condizione necessaria perché le LIA generino valore nel lungo periodo.

Per approfondire come le LIA si integrano in una strategia omnicanale, cosa le differenzia dagli annunci Shopping standard e come configurare le campagne in Google Ads, rimandiamo all’articolo completo sulle Local Inventory Ads.

Vuoi automatizzare la gestione del tuo Local Inventory Feed? Scopri come possiamo aiutarti.