Dlaczego reklamy HTML5 generowane z feedu są odrzucane przez Google Ads, DV360 i Ad Manager

Google Ads ogranicza przesyłaną kreację displayową HTML5 do 600 KB i 40 plików w archiwum ZIP – wynika to z własnej specyfikacji Google dotyczącej przesyłanych reklam displayowych. Display & Video 360 dopuszcza do 100 plików, ale ogranicza łączną wagę danych pobieranych przez przeglądarkę podczas wyświetlania reklamy do 5 MB, a pojedynczą kreację do 25 plików cookie i 100 zewnętrznych wywołań HTTP – zgodnie z wytycznymi DV360 dla kreacji HTML5. Żadna z tych liczb nie jest tajemnicą. Są publikowane na stronach specyfikacji każdej platformy. Mimo to pipeline kreacji oparty na feedzie nieustannie się o nie potyka, ponieważ ZIP składany przez silnik szablonów z kilku tysięcy SKU zachowuje się zupełnie inaczej niż ZIP zbudowany ręcznie przez projektanta. Ten przewodnik jest dla osoby odpowiedzialnej za kontrolę jakości kreacji na koncie katalogowym: opisuje konkretne powody, dla których reklamy HTML5 generowane z danych feedu produktowego są odrzucane przez Google Ads, DV360 i Google Ad Manager, oraz sposób naprawy każdego z nich – tak abyś wychwycił je, zanim zrobi to platforma.

Dlaczego kreacje HTML5 generowane z feedu częściej nie przechodzą weryfikacji niż kreacje tworzone ręcznie

Projektant budujący ręcznie jeden baner osadza zdjęcie produktu bezpośrednio w ZIP-ie, pisze jeden clickTag i raz sprawdza liczbę plików. Silnik szablonów generujący ten sam baner dla 4000 SKU powtarza każdą decyzję 4000 razy, a błąd, który przy n=1 nic nie kosztuje, kumuluje się w skali.

Większość problemów sprowadza się do czterech wzorców. Po pierwsze, szablon zwykle odwołuje się do zdjęć produktów przez URL image_link pobrany prosto z feedu, bo to pole feed już zawiera, zamiast pobrać i osadzić plik, czego wymaga format ZIP. Po drugie, szablon, w którym każdy stan plakietki (dostępny, promocja, bestseller, końcówka zapasów) ma własny plik graficzny, mnoży liczbę plików w archiwum, zanim zostanie dodane choćby jedno zdjęcie produktu. Po trzecie, minifikacja wyniku budowania w celu przyspieszenia dostarczania usuwa metadane i zaciemnia zmienne, w tym dokładny tag meta ad.size i zmienną clickTag, które platformy reklamowe odczytują po nazwie. Po czwarte, każde narzędzie w stosie – warstwa automatyzacji kreacji, tag analityczny, własny piksel sieci reklamowej – dodaje własny skrypt lub plik cookie, a nikt nie testuje złożonej reklamy względem łącznego limitu platformy, dopóki nie trafi ona do weryfikacji.

Limity techniczne platforma po platformie

To liczby, które są faktycznie egzekwowane. Tam, gdzie platforma nie opublikowała twardego limitu, mówimy o tym wprost, zamiast zgadywać.

Źródła: specyfikacja przesyłanych reklam displayowych Google Ads, rozwiązywanie problemów z zasobami HTML5 w kampaniach promujących aplikacje Google Ads, wytyczne DV360 dla kreacji HTML5, wytyczne HTML5 Google Ad Manager.

Pięć przyczyn odrzucenia, które powtarzają się na każdej platformie, i sposób naprawy każdej z nich

1. Bezwzględne adresy URL zdjęć zamiast osadzonych zasobów

Szablon pobiera image_link prosto z feedu i wpisuje go do kodu bez zmian:

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

Walidator zasobów HTML5 Google zwraca w tej sytuacji konkretny błąd dla paczek reklam pełnoekranowych w kampaniach promujących aplikacje: „Your HTML5 ad is trying to reference an asset that is external to your .ZIP file. Only internal file references are allowed.” Ta sama reguła obowiązuje – z mniej jednoznacznym komunikatem – w standardowych reklamach displayowych i w DV360.

Rozwiązanie: na etapie budowania pobierz plik, na który wskazuje URL image_link, zapisz go ponownie w ZIP-ie pod ścieżką względną i odwołuj się do tej ścieżki:

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

2. Liczba plików rozdmuchana przez zasoby plakietek i ikon dla każdego wariantu

Szablon z sześcioma stanami plakietek w ośmiu rozmiarach kreacji to 48 plików, zanim zostanie dodane choćby jedno zdjęcie produktu – czyli już ponad limit 40 plików Google Ads dla standardowych reklam displayowych. W katalogu z setkami aktywnych promocji to najczęstsza przyczyna, dla której eksport zbiorczy kończy się niepowodzeniem, choć ten sam szablon przeszedł kontrolę jakości na zestawie testowym z pięcioma produktami.

Rozwiązanie: połącz stany plakietek w jeden spritesheet lub wbudowany SVG <symbol> wywoływany klasą CSS, aby liczba plików pozostawała stała niezależnie od tego, ile stanów plakietek lub rozmiarów wykorzystuje kampania.

3. Brakujący lub usunięty tag meta ad.size

Etapy minifikacji projektowane z myślą o szybkości, a nie o zgodności z wymogami ad-tech, często usuwają lub przestawiają zawartość <head>, w tym tag meta z wymiarami, który platformy odczytują po dokładnej nazwie. Komunikat błędu walidatora Google Ads brzmi w tym przypadku: „Your HTML5 ad is missing a primary .HTML file. Primary .HTML files include an Ad Size tag.” Google Ad Manager wymaga tej samej informacji w postaci <meta name="ad.size" content="width=300,height=250">.

Rozwiązanie: uruchamiaj sprawdzanie tagu meta po minifikacji, a nie przed nią, i dodaj je jako automatyczną bramkę w pipeline eksportu zamiast ręcznej kontroli wyrywkowej.

4. clickTag wpisany na sztywno, brakujący lub zminifikowany nie do poznania

Minifikator zamienia czytelną obsługę kliknięcia w coś w rodzaju var a=b(3). Wytyczne DV360 jednoznacznie stwierdzają, że click tag „powinien być łatwy do odczytania dla serwera reklam”, i zalecają, by nie przepuszczać go przez minifikator kodu; Ad Manager wymaga tej samej zmiennej, zadeklarowanej dokładnie jako clickTag, w sekcji head.

Rozwiązanie: zadeklaruj ją raz, bez minifikacji, i wyłącz tę jedną linię z procesu minifikacji: var clickTag = "https://example.com/product/4471";. Nigdy nie wpisuj na sztywno docelowego adresu URL w innym miejscu kodu – Ad Manager nie przypisze kliknięć, których nie widzi przez tę zmienną.

5. Przekroczony limit plików cookie i wywołań HTTP przez nakładające się tagi śledzące

DV360 twardo ogranicza pojedynczą kreację do 25 plików cookie i 100 zewnętrznych wywołań HTTP. Każdy pojedynczy tag – piksel retargetingowy, żądanie czcionki internetowej, wywołanie GA4, własny fragment śledzący platformy automatyzacji kreacji – sam w sobie jest zgodny z limitami. Nałożone razem w jednej złożonej reklamie już nie są, a przekroczenie wychodzi na jaw dopiero wtedy, gdy ktoś przetestuje gotową paczkę, a nie szablon.

Rozwiązanie: kieruj śledzenie przez jeden kontener menedżera tagów na reklamę zamiast dodawać piksele pojedynczo, ładuj czcionki lokalnie zamiast przez zewnętrzne żądanie i testuj liczbę wywołań na faktycznie wyrenderowanym eksporcie – nie na szablonie – ponieważ testy na poziomie szablonu zaniżają wyniki.

Lista kontrolna przed uruchomieniem partii kreacji HTML5 generowanych z feedu

• Każde odwołanie do zasobu w kodzie jest względne wobec katalogu głównego ZIP-a, a nie jest bezwzględnym adresem URL prowadzącym z powrotem do CDN feedu.
• Liczba plików jest sprawdzana na złożonym ZIP-ie konkretnego produktu – nie na szablonie – i mieści się w limicie docelowej platformy.
• Tag meta ad.size (lub jego odpowiednik w DV360/Ad Manager) jest obecny i niezminifikowany po etapie budowania, a nie tylko przed nim.
• Zmienna clickTag jest zadeklarowana raz, bez minifikacji, i jest jedynym miejscem docelowym kliknięcia w pliku.
• Łączna liczba plików cookie i zewnętrznych wywołań HTTP jest testowana na wyrenderowanej reklamie, względem limitu 25/100 DV360, a nie szacowana dla poszczególnych tagów.
• Łączna waga pobierania jest mierzona „na zimno”, po kompresji, względem faktycznego limitu platformy – 600 KB dla standardowych reklam displayowych Google Ads, łącznie 5 MB dla DV360.

Czego ten przewodnik nie obejmuje

To warstwa zgodności technicznej, a nie pełna strategia kreatywna. Nie obejmuje społecznościowych i natywnych dynamicznych reklam katalogowych – placementów Meta i Instagram, reklam katalogowych TikTok – budowanych z tego samego feedu, ponieważ działają one na zasobach graficznych i wideo przez własny menedżer reklam katalogowych platformy, a nie przez przesyłanie ZIP-a HTML5. Do tego konkretnego zadania wyspecjalizowane narzędzia naprawdę lepiej się sprawdzają niż ogólny pipeline HTML5: Confect jest zbudowany specjalnie wokół szablonów reklam katalogowych Meta i Google z cogodzinną synchronizacją produktów, a Hunch – wokół dynamicznych kreacji społecznościowych i wideo, w tym wariantów silnie lokalizowanych. Żadne z nich nie tworzy banerów displayowych HTML5 zgodnych ze specyfikacją IAB, czyli właśnie tej luki, którą zajmuje się ten przewodnik, ale w swojej dziedzinie warto ocenić je na ich własnych warunkach.

Przewodnik nie obejmuje też testowania kreacji ani pomiaru skuteczności – to, czy dany szablon konwertuje lepiej niż inny, to odrębna dyscyplina niż to, czy przechodzi weryfikację techniczną – i nie zastępuje weryfikacji zgodności z zasadami treści platformy. Naprawienie każdego punktu z powyższej listy kontrolnej zapobiega odrzuceniu z przyczyn technicznych. Nie przepuści jednak kreacji, która merytorycznie narusza zasady reklamowe platformy.

Najczęściej zadawane pytania

Jaki jest maksymalny rozmiar pliku reklamy displayowej HTML5 w Google Ads?

W przypadku standardowych przesyłanych reklam displayowych plik ZIP musi mieć maksymalnie 600 KB i zawierać nie więcej niż 40 plików. Zasoby HTML5 reklam pełnoekranowych w kampaniach promujących aplikacje podlegają osobnej specyfikacji: do 5,2 MB i 512 plików, ale tylko w wymiarach 320×480 lub 480×320.

Dlaczego DV360 mierzy łączną wagę pobierania zamiast rozmiaru ZIP?

Ponieważ ZIP po wyrenderowaniu przez przeglądarkę może rozpakować się do znacznie większego zestawu plików. DV360 ogranicza faktyczną wagę danych pobieranych przez przeglądarkę odwiedzającego podczas wyświetlania reklamy do 5 MB, co lepiej odzwierciedla rzeczywisty wpływ na ładowanie niż rozmiar skompresowanego archiwum.

Czy reklama HTML5 generowana z feedu może odwoływać się do zewnętrznych czcionek lub zdjęć?

Co do zasady nie. Standardowe reklamy displayowe Google Ads dopuszczają zewnętrzne odwołania tylko do Google Fonts i krótkiej listy dozwolonych bibliotek hostowanych przez Google (CreateJS, GSAP, jQuery); wszystko inne, łącznie z każdym zdjęciem produktu, musi być osadzone w ZIP-ie ze ścieżką względną.

Dlaczego reklama HTML5 przechodzi testy lokalne, ale nie przechodzi weryfikacji platformy?

Testy lokalne zwykle wykonuje się na kodzie źródłowym sprzed minifikacji i kompresji, a nie na dokładnie tym ZIP-ie, który jest przesyłany. Minifikacja może usunąć tag ad.size lub zniekształcić zmienną clickTag już po pomyślnym teście lokalnym, dlatego kontrole muszą być wykonywane na finalnym artefakcie budowania.

Czy limit 40 plików dotyczy produktu czy kampanii?

Pojedynczego ZIP-a kreacji. Eksport zbiorczy, który generuje jeden ZIP na SKU, wymaga, by każdy z nich z osobna mieścił się w limicie – limit nie uśrednia się w skali łącznej liczby plików w kampanii.

Czym różni się specyfikacja HTML5 kampanii promujących aplikacje od standardowej specyfikacji HTML5 dla reklam displayowych?

To odrębne specyfikacje z różnymi limitami, przeznaczone dla różnych zasobów reklamowych. Standardowe przesyłane reklamy displayowe są ograniczone do 600 KB i 40 plików przy elastycznych wymiarach; reklamy pełnoekranowe HTML5 w kampaniach promujących aplikacje dopuszczają do 5,2 MB i 512 plików, ale tylko w dwóch stałych wymiarach pionowym i poziomym. Stosowanie założeń jednej specyfikacji do drugiej to częste źródło odrzucanych paczek.

Czy te zasady dotyczące plików i clickTag obowiązują też kreacje wideo generowane z tego samego feedu?

Nie – zasoby wideo podlegają specyfikacjom reklam wideo każdej platformy (kodowanie, długość, proporcje obrazu), a nie opisanym tu regułom dla ZIP-ów HTML5. Pipeline oparty na feedzie, który generuje zarówno wideo, jak i HTML5, potrzebuje osobnych etapów kontroli jakości dla każdego z nich.

Jak przetestować liczbę plików cookie i wywołań HTTP przed przesłaniem do DV360?

Wyrenderuj złożoną kreację w przeglądarce z otwartymi narzędziami deweloperskimi, załaduj reklamę w izolowanej karcie i policz w panelu sieci faktycznie ustawione pliki cookie i wysłane żądania. Testowanie samego szablonu, zanim tagi śledzące zostaną wstrzyknięte na etapie budowania, zaniży oba wyniki.

Jeśli ręczne utrzymywanie tej warstwy zgodności nie jest najlepszym wykorzystaniem czasu twojego zespołu, zobacz, jak Creative Suite od Feedance generuje gotowe do użycia w kanałach kreacje bezpośrednio z feedu produktowego – statyczne, wideo i banery HTML5 – razem ze wzbogacaniem feedu dla bazowych danych produktowych. Karaca wykorzystała to samo podejście „od feedu do kreacji”, aby przygotować 10 000 firmowych kreacji na Black Friday w dwie godziny. Porozmawiaj z nami o swoim katalogu i obecnym odsetku odrzuceń.