Perché gli annunci HTML5 generati dal feed vengono rifiutati da Google Ads, DV360 e Ad Manager

Google Ads limita una creatività display HTML5 caricata a 600 KB e 40 file all'interno dell'archivio ZIP, secondo la specifica ufficiale di Google per gli annunci display caricati. Display & Video 360 consente fino a 100 file, ma limita a 5 MB il peso totale scaricato dal browser quando l'annuncio viene pubblicato, e limita una singola creatività a 25 cookie e 100 chiamate HTTP esterne, secondo le linee guida di DV360 per le creatività HTML5. Nessuno di questi numeri è segreto: sono pubblicati nelle pagine delle specifiche di ciascuna piattaforma. Eppure una pipeline creativa basata sul feed ci inciampa di continuo, perché lo ZIP che un motore di template assembla a partire da qualche migliaio di SKU si comporta in modo completamente diverso da quello che un designer costruisce a mano. Questa guida è per chi è responsabile del QA creativo su un account catalogo: i motivi specifici per cui gli annunci HTML5 generati dai dati del feed di prodotto vengono rifiutati da Google Ads, DV360 e Google Ad Manager, e la soluzione per ciascuno, così da intercettarli prima che lo faccia la piattaforma.

Perché l'HTML5 generato dal feed non supera la revisione più spesso delle creatività fatte a mano

Un designer che crea a mano un banner incorpora direttamente la foto del prodotto nello ZIP, scrive un clickTag e controlla una volta il numero di file. Un motore di template che genera lo stesso banner per 4.000 SKU ripete ogni decisione 4.000 volte, e un errore che non costa nulla con n=1 si moltiplica su larga scala.

Quattro schemi spiegano la maggior parte dei casi. Primo, il template di solito richiama le immagini di prodotto tramite l'URL image_link preso direttamente dal feed, perché è il campo che il feed già contiene, invece di scaricare e incorporare il file, come richiede il formato ZIP. Secondo, un template che assegna a ogni stato del badge (disponibile, in saldo, best seller, scorte limitate) un proprio file immagine moltiplica il numero di file dell'archivio ancora prima di aggiungere una sola foto di prodotto. Terzo, la minificazione dell'output di build per velocizzare la consegna elimina metadati e offusca le variabili, compresi il meta tag ad.size e la variabile clickTag che le piattaforme pubblicitarie leggono per nome esatto. Quarto, ogni strumento dello stack (il livello di automazione creativa, il tag di analytics, il pixel della rete pubblicitaria) aggiunge un proprio script o cookie, e nessuno testa l'annuncio assemblato rispetto al limite complessivo della piattaforma finché non è già in revisione.

I limiti tecnici, piattaforma per piattaforma

Questi sono i numeri effettivamente applicati. Dove una piattaforma non ha pubblicato un numero preciso, lo diciamo invece di tirare a indovinare.

Fonti: specifiche degli annunci display caricati di Google Ads, risoluzione dei problemi degli asset HTML5 per le campagne per app di Google Ads, linee guida DV360 per le creatività HTML5, linee guida HTML5 di Google Ad Manager.

Cinque cause di rifiuto che si ripetono su tutte le piattaforme, e la soluzione per ciascuna

1. URL assoluti delle immagini invece di asset incorporati

Il template prende image_link direttamente dal feed e lo scrive nel markup così com'è:

<img src="https://cdn.example.com/feed/sku-4471-a.jpg">

Il validatore di asset HTML5 di Google restituisce un errore specifico per questo caso sui pacchetti interstitial delle campagne per app: "Il tuo annuncio HTML5 cerca di fare riferimento a un asset esterno al file .ZIP. Sono consentiti solo riferimenti a file interni." La stessa regola si applica, con un testo di errore meno esplicito, al display standard e a DV360.

Soluzione: in fase di build, scarica il file a cui punta l'URL image_link, ricodificalo nello ZIP con un percorso relativo e richiama quel percorso:

<img src="assets/sku-4471-a.jpg">

2. Numero di file esploso a causa di badge e icone per variante

Un template con sei stati del badge su otto formati creativi produce 48 file prima ancora di aggiungere una sola foto di prodotto, già oltre il limite di 40 file di Google Ads per il display standard. Su un catalogo con centinaia di promozioni attive, è il motivo più comune in assoluto per cui un'esportazione batch fallisce mentre lo stesso template aveva superato il QA su un set di prova di cinque prodotti.

Soluzione: consolida gli stati dei badge in un unico spritesheet o in un <symbol> SVG inline richiamato tramite classe CSS, così il numero di file resta costante indipendentemente da quanti stati del badge o formati usa la campagna.

3. Meta tag ad.size mancante o rimosso

I passaggi di minificazione pensati per la velocità, e non per la conformità ad-tech, spesso rimuovono o riordinano il contenuto di <head>, compreso il meta tag delle dimensioni che le piattaforme leggono per nome esatto. L'errore del validatore di Google Ads in questo caso recita: "Nel tuo annuncio HTML5 manca un file .HTML principale. I file .HTML principali includono un tag Dimensioni annuncio." Google Ad Manager richiede la stessa informazione nella forma <meta name="ad.size" content="width=300,height=250">.

Soluzione: esegui il controllo del meta tag dopo la minificazione, non prima, e aggiungilo come verifica automatica nella pipeline di esportazione invece che come controllo manuale a campione.

4. clickTag scritto direttamente nel codice, mancante o minificato fino a diventare irriconoscibile

Un minificatore trasforma un gestore di clic leggibile in qualcosa come var a=b(3). Le indicazioni di DV360 sono esplicite: il click tag "deve essere facile da leggere per l'ad server" e i team non devono passarlo in un minificatore di codice; Ad Manager richiede la stessa variabile, dichiarata esattamente come clickTag, nell'head.

Soluzione: dichiarala una sola volta, non minificata, ed escludi quella riga dal passaggio di minificazione: var clickTag = "https://example.com/product/4471";. Non scrivere mai l'URL di destinazione direttamente in altri punti del markup: Ad Manager non può attribuire i clic che non vede passare attraverso la variabile.

5. Limite di cookie e chiamate HTTP superato per l'accumulo di tracking

DV360 limita rigidamente una singola creatività a 25 cookie e 100 chiamate HTTP esterne. Ogni singolo tag (un pixel di retargeting, una richiesta di web font, una chiamata GA4, lo snippet di tracking della piattaforma di automazione creativa) è conforme da solo. Sommati in un unico annuncio assemblato non lo sono più, e lo sforamento emerge solo quando qualcuno testa il pacchetto finito anziché il template.

Soluzione: fai passare il tracking attraverso un unico container di tag manager per annuncio invece di aggiungere i pixel uno per uno, carica i font localmente invece che tramite una richiesta esterna e verifica il conteggio su un'esportazione reale renderizzata, non sul template, perché i test a livello di template sottostimano i numeri.

Checklist prima che un batch di creatività HTML5 generate dal feed vada online

• Ogni riferimento ad asset nel markup è relativo alla radice dello ZIP, non un URL assoluto che punta alla CDN del feed.
• Il numero di file viene controllato sullo ZIP assemblato e specifico per prodotto, non sul template, ed è sotto il limite della piattaforma di destinazione.
• Il meta tag ad.size (o l'equivalente DV360/Ad Manager) è presente e non minificato dopo la fase di build, non solo prima.
• La variabile clickTag è dichiarata una sola volta, non minificata, ed è l'unica destinazione di clic nel file.
• Il numero complessivo di cookie e di chiamate HTTP esterne viene testato sull'annuncio renderizzato, rispetto al limite 25/100 di DV360, non stimato tag per tag.
• Il peso totale del download viene misurato a freddo, dopo la compressione, rispetto al limite effettivo della piattaforma: 600 KB per il display standard di Google Ads, 5 MB totali per DV360.

Cosa non copre questa guida

Questo è un livello di conformità tecnica, non una strategia creativa completa. Non tratta gli annunci catalogo dinamici social e nativi (posizionamenti Meta e Instagram, annunci catalogo TikTok) creati dallo stesso feed, perché questi funzionano con asset immagine e video tramite il gestore di annunci catalogo della piattaforma, non con il caricamento di uno ZIP HTML5. Per quel compito specifico, gli strumenti dedicati sono davvero più adatti di una pipeline HTML5 generica: Confect è costruito specificamente attorno ai template per gli annunci catalogo di Meta e Google con sincronizzazione oraria dei prodotti, e Hunch è costruito attorno alla creatività dinamica per social e video, comprese varianti iper-localizzate. Nessuno dei due produce banner display HTML5 conformi allo standard IAB, che è proprio la lacuna affrontata da questa guida, ma nel loro ambito meritano di essere valutati per ciò che offrono.

La guida non tratta nemmeno il testing creativo o la misurazione della performance (capire se un template converte più di un altro è una disciplina diversa dal capire se supera la revisione tecnica) e non sostituisce la revisione delle norme sui contenuti di una piattaforma. Risolvere ogni punto della checklist qui sopra evita un rifiuto tecnico, ma non sblocca una creatività che viola nella sostanza le norme pubblicitarie di una piattaforma.

Domande frequenti

Qual è la dimensione massima di un annuncio display HTML5 in Google Ads?

Per gli annunci display caricati standard, il file ZIP deve essere di 600 KB o meno e contenere al massimo 40 file. Gli asset interstitial HTML5 delle campagne per app seguono una specifica separata: fino a 5,2 MB e 512 file, ma solo nelle dimensioni 320×480 o 480×320.

Perché DV360 misura il peso totale del download invece della dimensione dello ZIP?

Perché uno ZIP può decomprimersi in un insieme di file molto più grande una volta che il browser lo renderizza. DV360 limita a 5 MB il peso effettivo che il browser del visitatore scarica quando l'annuncio viene pubblicato, un indicatore più accurato dell'impatto reale sul caricamento rispetto alla dimensione dell'archivio compresso.

Un annuncio HTML5 generato dal feed può richiamare font o immagini esterni?

In genere no. Il display standard di Google Ads consente riferimenti esterni solo a Google Fonts e a una breve lista di librerie ospitate da Google (CreateJS, GSAP, jQuery); tutto il resto, compresa ogni immagine di prodotto, deve essere incorporato nello ZIP con un percorso relativo.

Perché un annuncio HTML5 supera i test locali ma non la revisione della piattaforma?

I test locali di solito vengono eseguiti sul codice sorgente prima della minificazione e della compressione, non sull'esatto ZIP che viene caricato. La minificazione può eliminare il tag ad.size o alterare la variabile clickTag dopo che il test locale è già stato superato, quindi i controlli vanno eseguiti sull'artefatto di build finale.

Il limite di 40 file si applica per prodotto o per campagna?

Per singolo ZIP creativo. Un'esportazione batch che genera uno ZIP per SKU deve rispettare il limite per ciascuno di essi, singolarmente: il limite non si calcola come media sul numero totale di file di una campagna.

Qual è la differenza tra la specifica HTML5 per le campagne per app e quella per il display standard?

Sono specifiche separate con limiti diversi, destinate a inventari diversi. Gli annunci display caricati standard sono limitati a 600 KB e 40 file con dimensioni flessibili; gli interstitial HTML5 delle campagne per app consentono fino a 5,2 MB e 512 file, ma solo in due dimensioni fisse, verticale e orizzontale. Applicare le ipotesi di una specifica alla superficie dell'altra è una causa comune di pacchetti rifiutati.

Queste regole su file e clickTag si applicano anche alle creatività video generate dallo stesso feed?

No: gli asset video seguono le specifiche degli annunci video di ciascuna piattaforma (codifica, durata, proporzioni), non le regole per gli ZIP HTML5 di questa guida. Una pipeline basata sul feed che produce sia output video sia HTML5 ha bisogno di passaggi di QA separati per ciascuno.

Come posso testare il numero di cookie e di chiamate HTTP prima di caricare su DV360?

Renderizza la creatività assemblata in un browser con gli strumenti per sviluppatori aperti, carica l'annuncio in una scheda isolata e conta nel pannello di rete i cookie effettivamente impostati e le richieste effettivamente inviate. Testare il template da solo, prima che i tag di tracking vengano inseriti in fase di build, sottostima entrambi i valori.

Se gestire a mano questo livello di conformità non è un buon uso del tempo del tuo team, scopri come Creative Suite di Feedance genera creatività pronte per ogni canale direttamente dal tuo feed di prodotto (banner statici, video e HTML5), insieme all'arricchimento del feed per i dati di prodotto sottostanti. Karaca ha usato lo stesso approccio dal feed alla creatività per produrre 10.000 creatività brandizzate per il Black Friday in due ore. Parlaci del tuo catalogo e del tuo attuale tasso di rifiuto.