Diagnoza problemów z feedem — narzędzia i metody

Problemy feed merchant to zwykle nie „kilka disapproval” — to zwykle zawalona cała dystrybucja produktów w Google Shopping przez 72 godziny, podczas gdy konkurencja zjada impression share. W 2026, gdy Merchant Center Next wprowadziło nowe wymagania (obrazy produktów z białym tłem, ustandaryzowane atrybuty kolorów, GTIN dla większej grupy kategorii), zespoły e-commerce muszą umieć diagnozować feed w 15 minut, nie w 15 godzin.

Ten artykuł pokazuje systematyczną metodę diagnozy: od first-line checklist (czy w ogóle feed się załadował), przez analizę disapproval per przyczyna, po zaawansowane narzędzia (DataFeedWatch, Channable, własne skrypty). Pracujemy z realnymi przypadkami z polskich sklepów internetowych 2024–2026, w których rozwiązanie zajmowało od 30 minut do 5 dni, w zależności od znajomości procesu.

Tekst jest częścią klastra SEM i PPC 2026. Jeśli dopiero migrujesz do Merchant Center Next, zacznij od Merchant Center 2026. Jeżeli Twój feed działa, ale performance słaby, przeczytaj optymalizację feedu.

Spis treści

1. Co może pójść źle — mapa problemów
2. Metoda diagnozy: 5 kroków
3. Najczęstsze przyczyny disapproval w 2026
4. Narzędzia diagnostyczne Google
5. Narzędzia feed management
6. Custom scripty i walidacja
7. Account suspend — co robić
8. Prewencja — procesy, które ratują
9. 5 realnych przypadków diagnozy
10. FAQ
11. Co dalej

Co może pójść źle — mapa problemów

Na początek sprawdź Merchant Center 2026. Gdy opanujesz podstawy, przejdź do optymalizacji feedu — tam czekają zaawansowane techniki.

Metoda diagnozy: 5 kroków

Systematyczna metoda oszczędza godziny. Każda minuta, w której Shopping nie dostaje produktów, jest stracona — konkurencja przejmuje impression share.

Krok 1: Czy feed się w ogóle załadował

Idź do Merchant Center → Products → Feeds. Sprawdź:

• Data ostatniego fetch — powinna być dzisiaj (dla feed daily).
• Status — „Success” vs „Failed”; jeśli Failed, zobacz log błędu.
• Liczba produktów w feed — porównaj z wczoraj; jeśli spadek o 30%+ → problem po stronie sklepu (brak produktów w feed exporcie).

Krok 2: Ile produktów jest disapproved

Diagnostics → Product Issues. Widzisz liczbę produktów z błędami, podzieloną na:

• Disapproved — produkt wykluczony z Shopping całkowicie.
• Limited — produkt wyświetlany tylko w niektórych krajach lub formatach.
• Pending — w trakcie review.

Jeśli disapproved >20% produktów — problem systemowy (polityka, typ pliku, attribute). Jeśli <5% — lokalne problemy (specyficzne SKU).

Krok 3: Top issues

Merchant Center pokazuje top 10 issues z liczbą dotkniętych produktów. Naprawiaj po kolei — od „Affected products” największego do najmniejszego. 80/20 zwykle sprawdza się: 2–3 top issues obejmują 70–85% wszystkich disapproval. Praktyczne wskazówki zawiera Google Ads 2026.

Krok 4: Spot check — otwórz konkretny produkt

Klikasz na jeden disapproved produkt. Merchant Center pokazuje:

• Konkretny błąd (np. „Missing value: gtin”).
• Porównanie: co jest w feed vs co powinno być.
• Link do landing page produktu.
• Screenshot Google Shopping (jeśli produkt był widoczny).

Krok 5: Fix & re-fetch

Po naprawie w sklepie (lub w feed rules w MC):

1. Manual fetch feed w Merchant Center.
2. Czekaj 30–180 minut na re-processing.
3. Sprawdź, czy disapproved liczba spadła.
4. Nie zmieniaj kolejnych rzeczy przed zakończeniem re-processing — inaczej nie wiesz, co zadziałało.

Najczęstsze przyczyny disapproval w 2026

1. Brakujące GTIN (EAN, UPC, ISBN)

Od 2026 Google wymaga GTIN dla większości kategorii markowych. Brak GTIN = disapproval lub limitowana dystrybucja. Rozwiązania:

• Producent ma GTIN — pobierz od niego (najlepsze źródło).
• Baza GS1 — oficjalna baza GTIN, 40 zł/rok członkostwo w Polsce.
• Narzędzia — GTIN Lookup w DataFeedWatch, Channable; accuracy 85–95%.
• Dla produktów własnej marki (private label) — zakup prefix GS1 (300–600 zł), generowanie własnych GTIN.

2. Niezgodność cen feed vs landing page

Google crawluje LP i porównuje cenę w feed z ceną na stronie. Różnica > 3 gr = disapproval „price mismatch”. Przyczyny:

• Feed ma cenę podstawową, LP pokazuje cenę promocyjną — dodaj sale_price do feed.
• Feed jest statyczny (daily), a LP dynamiczne (real-time) — zmiany intra-day powodują niezgodność.
• VAT — feed ma cenę brutto, LP netto (lub odwrotnie). W Polsce B2C feed musi być brutto (cena „dla klienta”).
• Waluty — feed EUR, LP PLN (przy niewłaściwej konfiguracji).

3. Availability mismatch

Feed mówi „in stock”, LP pokazuje „brak w magazynie”. Google disapprove za wprowadzanie w błąd.

Fix: używaj availability attribute (in_stock, out_of_stock, preorder, backorder) konsekwentnie z realnym stanem.

4. Images — white background, quality

Od 2025 Google preferuje białe tło dla product images. Obrazki na kolorowym tle są nadal akceptowane, ale: (a) są ważone niżej w rankingu Shopping, (b) w niektórych kategoriach (fashion, electronics) są disapproved.

Minimalne wymagania 2026:

• Minimum 800×800 px (zalecane 1200×1200+).
• Format: PNG, JPG (nie GIF, BMP).
• Brak watermarków, tekstu na obrazie, ramek.
• Produkt zajmuje minimum 75–90% powierzchni.
• Dla kategorii „fashion” — model z tłem białym/szarym.

5. Polityki (niedozwolone produkty)

Produkty, które Google blokuje: medyczne wymagające recepty, tytoń, alkohol z ograniczeniami wiekowymi, broń, dopalacze, niektóre suplementy („magic”, „detox”, „cleanse” w nazwie). Dla branż regulowanych: whitelisting wymaga osobnego review z Google, czasem 30+ dni.

Narzędzia diagnostyczne Google

Merchant Center Diagnostics

Główne narzędzie. Pokazuje:

• Account issues (account-level, np. polityki).
• Feed issues (feed-level, np. parsing error).
• Item issues (product-level, np. missing GTIN).

Merchant Center API

Dla zaawansowanych — programistyczny dostęp do listy disapproval per SKU. Używany w automatycznych skryptach monitorujących. Dokumentacja: developers.google.com/shopping-content. Więcej kontekstu daje SEM i PPC 2026.

Google Ads: Shopping reports

W Google Ads → Products report:

• Liczba aktywnych produktów w kampanii vs total w feed.
• Impression, clicks, conversions per produkt.
• Items that are Active vs Out of sync — jeśli są rozbieżne, problem synchronizacji MC-Ads.

Google Ads Editor

Offline edytor z szybszą diagnostyką niż web UI. Dla większych feedów (10k+ produktów) znacznie szybszy w masowych operacjach.

Narzędzia feed management

DataFeedWatch

Popularny w PL i EU. Plus: rule builder (jeśli cena < 10 zł, usuń produkt), GTIN lookup, multi-channel (Google, Meta, TikTok, Allegro, Ceneo z jednego feed). Ceny: od 499 zł/miesiąc (do 5k produktów), skalują do kilku tys. zł/miesiąc dla dużych sklepów.

Channable

Konkurent DataFeedWatch, podobna funkcjonalność. Mocniejszy w mapowaniu kategorii do różnych marketplace’ów. Ceny: od 400 zł/miesiąc.

GoDataFeed

US-origin, obecny w EU. Dobre dla sklepów amerykańskich skalujących do Europy.

WakeupData

Węgierski dostawca, tańszy dla mniejszych sklepów. Od 249 zł/miesiąc.

Shoper/WooCommerce wtyczki

Natywne wtyczki sklepów generują podstawowy feed, ale bez zaawansowanych rules. Dobre dla startujących, nieskalowalne do 10k+ SKU.

Custom scripty i walidacja

Dla zespołów technicznych własne narzędzia dają największą kontrolę. Kilka pomysłów.

Python validator — run przed upload

Skrypt, który sprawdza:

• Każdy produkt ma wymagane pola (id, title, link, image_link, price, availability, GTIN lub MPN+brand).
• Cena jest w formacie „PRICE CURRENCY” (np. „199.99 PLN”).
• Title długość 30–150 znaków (Google zaleca 70).
• Description minimum 50 znaków.
• Image_link HTTPS (nie HTTP).
• Brak duplikatów ID.

Uruchom skrypt w CI/CD przed każdym upload. Redukuje error rate o 60–80%.

Monitoring daily

Cron skrypt, który pobiera z Merchant Center API daily summary i wysyła alert na Slack, jeśli:

• Disapproved rate > baseline + 5%.
• Liczba produktów w feed spadła o 10%+.
• Nowe top issue pojawiło się z 10+ dotkniętymi produktami.

Porównanie historyczne

Zapisuj snapshot feed (hash każdego produktu) do bazy danych codziennie. Gdy wystąpi problem, porównanie „vs wczoraj” pokazuje, co się zmieniło w feed — często wystarcza do znalezienia sprawcy.

Account suspend — co robić

Najgorszy scenariusz. Google podejrzewa, że sklep narusza politykę (misrepresentation, fake reviews, hidden costs, poor customer service) i zawiesza całe konto Merchant Center. Wszystkie kampanie Shopping stają. W 2026 to zdarza się 2–4% sklepów rocznie, szczególnie przy skali wzrostu i szybkich zmianach.

Najczęstsze przyczyny suspend

1. Misrepresentation — różnice między tym, co sklep oferuje, a rzeczywistością (np. „darmowa dostawa” w reklamie, płatna w checkout).
2. Poor customer service — wysoka liczba skarg, slow response, brak danych kontaktowych.
3. Payment issues — problemy z procesorem płatności, chargebacks powyżej 1%.
4. Fake reviews — Google wykrywa kupione opinie; konto zawieszone.
5. Landing page policy — brak polityki zwrotów, warunków sprzedaży, kontaktu.

Proces odwoławczy

1. W Merchant Center → Request Review.
2. Przygotuj dokumentację: screenshoty przed/po poprawce, zmiany na stronie, polityki, emaile z klientami.
3. Napisz appeal — konkretnie „co zmieniliśmy”, nie „sądzimy, że to pomyłka”.
4. Czekaj 7–14 dni na pierwszy review. Jeżeli odrzucony — kolejny appeal po dalszych zmianach.
5. Proces może trwać 30+ dni. W międzyczasie kampanie Shopping nie działają — strata przychodu 20–60% miesięcznych dla e-commerce performance-driven.

Prewencja suspend

• Transparentne warunki sprzedaży, polityka zwrotów, dane firmy.
• Responsive customer service (odpowiedź do 24 h).
• Monitoring chargebacks i reklamacji.
• Brak „dark patterns” (np. „99% discount” zamiast 9%).
• Okresowe self-review strony przez eksperta zewnętrznego (raz na 6 miesięcy).

Prewencja — procesy, które ratują

Feed QA checklist (tygodniowo)

1. Liczba produktów w feed vs liczba aktywnych w sklepie (odchylenie < 2%).
2. Disapproval rate vs baseline (odchylenie < 1 pp).
3. Top 5 issues nie zmieniły się od zeszłego tygodnia.
4. Random spot check 5 produktów — feed vs LP cena, dostępność.
5. Performance report Shopping — CTR, konwersja, ROAS per kategoria.

Change management

Każda zmiana w sklepie, która dotyka feed (nowa kategoria, zmiana cen, nowy schemat URL), wymaga:

1. Notyfikacji zespołu performance marketingu 48 h wcześniej.
2. Testu na staging environment.
3. Monitor intensywny przez 24 h po zmianie (4–6 spot checków).
4. Rollback plan, jeśli disapproval rate rośnie.

Dokumentacja błędów

Każdy disapproval, który wystąpił i został naprawiony, dokumentuj w runbooku: opis, przyczyna, rozwiązanie, czas naprawy. Po roku masz wewnętrzną encyklopedię, która pozwala juniorom rozwiązać 80% problemów bez angażowania senior.

5 realnych przypadków diagnozy

Case 1: Shoper, sklep fashion, 3 500 SKU — nagły spadek impression

Objaw: Poniedziałek rano, impression Shopping spadły o 70% w ciągu doby.

Diagnoza: Disapproval rate 42%. Top issue: „Image quality too low”. Sklep w weekend zmienił procesor obrazów — nowe thumbnails 400×400 zamiast 1200×1200.

Fix: Rollback procesora obrazów, re-generate thumbnails. 6 h pracy, 36 h na re-processing w Google, pełny powrót impression po 72 h.

Nauka: każda zmiana tech-side w sklepie dotycząca assetów wymaga informacji dla marketing team.

Case 2: WooCommerce, elektronika, 15 000 SKU — masowy disapproval GTIN

Objaw: 3 200 produktów z disapproval „Missing GTIN”.

Diagnoza: Sklep dodał nową kategorię „Akcesoria”, która była markowa (Apple, Samsung), ale producent w sklepie wpisał generyczne nazwy. GTIN wymagany dla tych marek przez Google.

Fix: Pobranie GTIN z DataFeedWatch GTIN Lookup (pokrycie 92%), dla pozostałych 8% ręczne wpisanie. 18 h pracy (w tym integracja DataFeedWatch), 24 h na re-processing.

Case 3: Shopify, kosmetyki, 800 SKU — price mismatch

Objaw: 280 produktów disapproved „Price mismatch”.

Diagnoza: Sklep uruchomił promocję „Pre-Black Friday” — zmienił ceny na LP, ale feed export był cached 24 h i nadal pokazywał stare ceny.

Fix: Zmniejszenie cache feed z 24 h do 1 h. Natychmiastowe force-refresh. Zanikło w 4 h.

Nauka: cache feed >2 h jest ryzykiem dla sklepów z częstymi zmianami cen.

Case 4: Magento 2, B2B wholesale, 45 000 SKU — suspend account

Objaw: Account suspension po 14 miesiącach smoothego działania. Powód: misrepresentation.

Diagnoza: Polityka zwrotów na LP produktu różniła się od polityki w FAQ. FAQ: „zwrot 14 dni”. Produkt: „zwroty w ciągu 7 dni”. Google uznał za misrepresentation.

Fix: Ujednolicenie polityki w każdym miejscu, appeal z dokumentacją zmian. Re-approval po 11 dniach.

Koszt: 11 dni bez Shopping = ~480 tys. zł utraconych przychodów performance.

Case 5: Shoper, meble, 2 200 SKU — feed się nie pobiera

Objaw: Merchant Center pokazuje „Feed fetch failed” od 3 dni.

Diagnoza: Sklep przeniósł URL feed, ale nie zaktualizował w MC. Plus: hosting zaczął rate-limitować Google bot (zbyt częste zapytania).

Fix: Aktualizacja URL w MC, whitelisting Google bot IP na firewall. 2 h pracy, natychmiastowa naprawa.

FAQ

Jak często Google pobiera feed?

Standardowo Google pozwala ustawić częstotliwość fetch w zakresie 1–24 h. Dla sklepów z dynamicznymi cenami/dostępnością (promocje, fresh stock) rekomendacja: co 1–3 h. Dla ustabilizowanych, z rzadkimi zmianami — 12–24 h wystarczy. Uwaga: feed pobrany co godzinę obciąża serwer sklepu (pobiera cały plik XML/CSV) — przy 50k SKU to 10–40 MB per fetch. Alternatywa: supplemental feeds z Content API dla real-time updates (zmienia się tylko to, co się zmieniło). W 2026 dla sklepów z 10k+ SKU Content API integration staje się standardem, zastępując tradycyjny feed.

Czy warto używać multiple feeds dla różnych kategorii?

Tak, dla sklepów z 5 000+ SKU warto dzielić feed po kategorii lub brand. Plus: łatwiejsza diagnostyka (widać, która kategoria ma problem), szybsze re-processing po zmianie (cały feed się nie przetwarza), lepsza struktura Google Ads (kampanie per kategoria/brand z osobnym tROAS). Minus: więcej miejsc do utrzymania, możliwość niespójności między feed. Rekomendacja: 1 feed per „priority segment” (Top Sellers, Standard, Clearance) + supplemental feed dla overrides. Dla sklepów do 5k SKU jeden monolithic feed jest prostszy i wystarczający.

Jak testować zmiany w feed bez ryzyka disapproval dla całego konta?

Użyj Test Merchant Center (drugie konto MC pod tym samym email) — podepnij tam zmieniony feed, sprawdź disapproval, dopiero potem wdróż na produkcji. Alternatywa: Feed Rules w głównym koncie — dodawaj/modyfikuj atrybuty tylko dla losowej próbki 5–10% produktów, obserwuj efekt, skaluj po 24 h. Trzecia opcja: używaj narzędzia typu DataFeedWatch z built-in preview — widzisz, jak feed będzie wyglądał po rule, przed upload. Nigdy nie testuj zmian „na żywo” na całym feedzie produkcyjnym — ryzyko masowego disapproval jest zbyt duże.

Co jeśli sklep nie może zapewnić GTIN dla produktów własnej marki?

Opcje: (1) kup prefix GS1 (jednorazowo 300–600 zł w zależności od liczby GTIN), generuj GTIN własne — to jest „prawidłowe” rozwiązanie; (2) użyj kombinacji brand + MPN (Manufacturer Part Number) — Google akceptuje dla private label; ważne: MPN musi być unikalny i stały; (3) dla kategorii, które Google nie wymaga GTIN (handmade, custom, vintage, art), ustaw identifier_exists na false — oficjalnie deklarujesz brak identyfikatora. Uwaga: kategoria „fashion — ready-to-wear” w 2026 wymaga GTIN dla brandów głównych; private label OK bez GTIN. Sprawdź aktualną listę kategorii wymagających GTIN w Google Merchant Center Help.

Ile kosztuje outsource feed management w agencji PL?

W 2026: 800–3 000 zł/miesiąc za utrzymanie feed dla sklepu do 5k SKU (monitoring, fixes, rule management). 3 000–8 000 zł/miesiąc dla 5–25k SKU z aktywnym feed optimization. 8 000–20 000 zł/miesiąc dla dużych sklepów 25k+ SKU z integracją multi-channel (Google, Meta, TikTok, Allegro, Ceneo). Plus licencja narzędzia (DataFeedWatch, Channable) — 500–4 000 zł/miesiąc w zależności od wolumenu. ROI dla performance-driven sklepów: zwykle 4–10× kosztu przez wyższy aktywny produkt rate i szybsze rozwiązywanie problemów. Dla sklepu z budżetem Shopping 50k+ zł/miesiąc wartościowość outsource jest bezdyskusyjna.

Jak działa Content API vs klasyczny feed XML?

Content API dla Shopping (od 2024 znane jako Merchant API) to programistyczny interfejs, przez który sklep wysyła zmiany produktów do Google natychmiast (webhook po zmianie ceny/dostępności), zamiast czekać na następny fetch feed. Plus: real-time updates, mniejsze obciążenie serwera, wyższa dokładność cen. Minus: wymaga developera (integracja), błędy w API od razu widoczne w Merchant Center (nie ma okna „między fetchami” na korektę). Dla sklepów z 10k+ SKU i dynamicznym pricingiem (multi-channel sellers, marketplace, flash sales) Content API jest standardem 2026. Dla małych sklepów z 50–500 SKU klasyczny XML feed codzienny wystarczy i jest prostszy w utrzymaniu.

Co dalej

Jeśli chcesz pogłębić temat, sprawdź Merchant Center 2026. Warto też przejrzeć optymalizacji feedu — oba materiały dobrze uzupełniają powyższy artykuł.