Přeskočit na obsah
ŘEŠENÍ PROBLÉMŮ

GA4 Realtime ukazuje méně server-side než client-side eventů

Osm příčin proč server-side ukazuje méně dat než client-side — od chybějícího "Send to server container" v primárním GA4 Configuration tagu (gap v page_view) přes ad-blockery blokující popisné sGTM subdomény až po Consent Mode v2. Triage checklist v 5 minutách.

10 min Read Začátečník Updated 18.5.2026

Otevřete GA4 Realtime, srovnáte web stream s server-side streamem a server-side má méně eventů než client-side? Nejčastěji to není výpadek našeho kontejneru — je to konfigurace web GTM kontejneru, GA4 property nebo ad-blocker. Tady je 8 příčin seřazených podle toho, jak často se v praxi objevují.

Než začnete: ověřte, že server-side kontejner skutečně doručuje

Otevřete Dashboard → Statistiky a podívejte se na Match rate a Error rate za posledních 24 h:

  • Match rate ≥ 99 % a error rate < 1 % → kontejner doručuje, problém je výš (web GTM, GA4 nebo ad-blocker). Pokračujte níže.
  • Error rate > 5 % → kontejner nebo cílová platforma má reálný problém. Otevřete Activity a podívejte se na error message konkrétních eventů. Napište nám a obratem se podíváme.

Quick win — porovnání bez GA4 přístupu: na Dashboard → Přehled najdete kartu "Top eventy přes sGTM (24 h)". Číslo u page_view srovnejte s GA4 → Reporty → V reálném čase → "Eventy podle názvu" za stejné období. Rozdíl < 5 % je normální (timing + bot filter). Rozdíl > 15 % = některá z příčin níže.

1. Primární GA4 Configuration tag nemá "Send to server container"

Nejčastější příčina rozdílu v page_view a sessions. Web GTM má jeden GA4 Configuration tag, který spouští všechny GA4 Event tagy a sám fire-uje Enhanced Measurement eventy (page_view, scroll, click, file_download…). Pokud nemá zapnuté Send to server container, jdou všechny tyhle eventy přímo na google-analytics.com a server-side stream je nedostane.

Jak ověřit (2 minuty):

  1. Otevřete Google Tag Manager → váš web kontejner
  2. Tags → vyfiltrujte typ Google Analytics: GA4 Configuration
  3. Otevřete tag → Show More Settings → Send to server container
  4. Pokud je nezaškrtnuté nebo Server Container URL je prázdné = příčina nalezena

Oprava: zaškrtněte Send to server container, do Server Container URL dejte vaši tracking subdoménu (např. https://sst.vasweb.cz) → Save → Submit → Publish. Do 5 minut by se v Dashboard → Přehled mělo objevit znatelně víc page_view eventů.

2. Web GTM má dva paralelní GA4 Configuration tagy

Typický scénář migrace ze Stape/jiného sGTM: starý GA4 Configuration tag, který fire-uje přímo na googletagmanager.com, zůstal aktivní + přidal se nový tag, který posílá na sst.vasweb.cz. Pokud nemají identické triggery, na některé eventy fire-uje jen client-side, na jiné jen server-side.

Jak ověřit:

  1. Otevřete Google Tag Manager → váš web kontejner
  2. Tags → filter Google Analytics
  3. Pokud vidíte 2 a více GA4 Configuration tagů — to je váš problém
  4. Otevřete každý tag → Server Container URL: jeden bývá prázdný (= client-side direct), druhý ukazuje na sst.vasweb.cz (= server-side)

Oprava: Smažte client-side GA4 Configuration tag (ten s prázdným Server Container URL). Server-side tag pokryje 100 % eventů + odolá adblockerům + ITP.

3. GA4 property má dva data streamy (web + sst)

Pokud při onboardingu vznikl nový GA4 data stream pro sst.vasweb.cz místo aby se použil ten existující web stream, máte v GA4 dvě oddělené sady dat. Realtime view ukazuje vždy jen jeden stream.

Jak ověřit:

  1. GA4 → Admin → Data streams
  2. Pokud vidíte 2+ streamy se stejnou property — máte split

Oprava: Server-side tag posílejte na stejné měření ID jako web tag (G-XXXXXXXX). Server-side nemá svůj vlastní data stream — používá ten existující web stream. Druhý stream v GA4 Admin → Data streams smažte (jeho historická data zůstanou dohledatelná v Explore).

4. Ad-blocker blokuje vaši sGTM subdoménu

20-40 % EU uživatelů používá uBlock Origin, AdGuard, Brave Shields nebo Pi-hole. Tyhle nástroje vycházejí z EasyList / EasyPrivacy a blokují všechno, co matchuje známé tracking regexy. Když je vaše sGTM subdoména příliš popisná (např. analytics.vasweb.cz, tracking.vasweb.cz, gtm.vasweb.cz), ad-blockery ji odchytnou stejně jako google-analytics.com — a client-side v GA4 ji uvidí (web tag fire-uje před blokem), server-side nikoli (request nikdy nedoletí).

Jak ověřit (3 minuty):

  1. V Chrome zapněte uBlock Origin (nebo si nainstalujte na 5 minut)
  2. Otevřete váš web → DevTools → Network → filter collect
  3. Pokud requesty na vaši sst.vasweb.cz/g/collect svítí červeně (blocked), ad-blocker je blokuje
  4. Druhý test: otevřete adblockanalyzer.com, zadejte svou subdoménu

Oprava: přejmenujte subdoménu na něco generického (např. data.vasweb.cz, m.vasweb.cz, api.vasweb.cz, cdn.vasweb.cz). V Dashboard → Domény přidejte novou doménu, vygenerujte SSL, nasaďte. Stará subdoména zůstane aktivní (kvůli rollbacku), nový web GTM Server Container URL nasměrujte na novou. Recovery rate +20-40 % během týdne.

5. Ecommerce eventy (purchase, view_item, add_to_cart) jdou jen client-side

Specifická příčina pro e-shopy s gapem v ecommerce eventech (page_view sedí, ale purchase ne). Web GTM má samostatné GA4 Event tagy pro purchase, view_item atd., které ale referencují jiný GA4 Configuration tag bez Server Container URL.

Jak ověřit:

  1. GTM → Tags → filter GA4 Event
  2. U každého ecommerce eventu otevřete tag → najděte referenci na GA4 Configuration Tag
  3. Otevřete ten Configuration tag → zkontrolujte Server Container URL
  4. Pokud je prázdné = ecommerce eventy jdou klient-side

Oprava — varianta A (přesměrování všeho na server-side): sjednoťte všechny GA4 Event tagy aby referencovaly jeden Configuration tag s Server Container URL. Save → Submit → Publish.

Oprava — varianta B (paralelní client + server): Pokud chcete client-side reporting zachovat (např. abyste viděli i 3rd-party reklamní pixely), zduplikujte GA4 Event tagy: jeden bez Server Container URL (current client-side), druhý s ním (nový server-side). V GA4 Admin nastavte deduplikaci přes transaction_id u purchase eventů. GA4 si je samo spojí. Bonus: server-side prošlou eventy, které ad-blocker / iOS / Brave klient-side blokuje (typicky 20-40 % zachycených konverzí navíc).

6. Cookie Keeper je vypnutý → každý Safari/iOS visitor přichází jako jiný user

Safari ITP zkracuje životnost first-party cookies set přes JavaScript na 7 dní. Bez Cookie Keeperu sGTM neumí prodloužit (jeho cookies set client-side mají stejný limit). Výsledek: po 8 dnech se vrátí stejný uživatel jako nový cid, atribuce se láme, session count je dvojí. Projevuje se jako gap v "users" a "sessions", ne v page_view.

Oprava: Dashboard → Power-Ups → Cookie Keeper → zapnout. Defaultní seznam cookies (_ga, _gid, _gcl_aw, _gcl_au, _fbp, _fbc, FPID, FPLC) pokrývá GA4, Google Ads i Meta. Cookie lifetime nastavte na 400 dní (max pro first-party). Efekt je viditelný za 1-2 týdny — recovery rate roste s tím jak se vrací staří uživatelé.

7. Bot Detection je vypnutý → bot traffic narouží Realtime, ale je filtrovaný v reportech

GA4 má vlastní bot filter (IAB Bot List) — odfiltruje automatický traffic v reportech, ale Realtime ho ukazuje. Bot Detection v DataNostro přidává X-Device-Bot header → GTM tag template může bot eventy filtrovat na server-side před odesláním do GA4 → server-side číslo v Realtime je nižší, ale reálná data v reportech jsou stejná nebo lepší.

Není to bug — je to čistší data. Dashboard → Power-Ups → Bot Detection defaultně běží v headers_only módu (jen označuje, neblokuje). Pokud chcete agresivnější filtraci, přepněte na block_requests a nastavte threshold (default 75 % = blokuje typické scrapery, ne crawlery).

8. Consent Mode v2 — server-side respektuje consent striktněji

Pokud máte na webu Consent Mode v2 (CMP banner) a uživatel odmítl analytics, klient-side GA4 dál posílá cookieless ping (basic_consent=denied). Server-side GA4 tag s defaultními nastaveními tyhle pingy obvykle dropne nebo zahodí cid → v Realtime se neukáže.

Jak ověřit: v URL eventu (Activity → konkrétní event) hledejte gcs=G100 nebo gcs=G101. G111 = oba consenty granted, G100 = oba denied. Pokud máte víc G100 než G111, většina visitorů odmítla.

Oprava: v GA4 Admin zapněte Modeled conversions + Behavioral modeling. GA4 doplní data o uživatelích, kteří odmítli, pomocí ML. Server-side stream tyhle modelované eventy v Realtime neuvidíte, ale v reportech (24-48 h zpožděně) ano.

Triage checklist (5 minut)

  1. Dashboard → Přehled → "Top eventy přes sGTM" — page_view číslo. Pokud je < 80 % toho, co vidíte v GA4 Realtime, pokračujte.
  2. Dashboard → Statistiky → Match rate ≥ 99 %? Pokud ne, kontejner má problém — napište nám.
  3. GTM Web → Tags → GA4 Configuration tag → "Send to server container" zaškrtnuté? Pokud ne, příčina #1.
  4. Kolik GA4 Configuration tagů celkem? 2+ = příčina #2.
  5. GA4 → Admin → Data streams → 2+ se stejnou property = příčina #3.
  6. Vyzkoušejte web s uBlock Origin → blokované requesty na vaši sGTM subdoménu = příčina #4. Přejmenujte subdoménu.
  7. Dashboard → Přehled → "Top eventy" — vidíte tam purchase / view_item / add_to_cart? Pokud ne a jste e-shop, příčina #5.
  8. Power-Ups → Cookie Keeper zapnutý? Pokud ne a máte sessions gap, zapněte.
  9. Vzorek 10 eventů v Activity → kolik gcs=G111 vs G100? Většina G100 = příčina #8 (zapněte modeled conversions v GA4).

Pokud po průchodu checklistem server-side stále signifikantně < client-side (rozdíl víc než 15 %), DataNostro Care obsahuje 30min diagnostickou seanci. Zalogujeme se vám do GTM a GA4, projdeme to spolu, najdeme zdroj rozdílu, ukážeme opravu.

Co je naopak normální

  • Rozdíl 1-5 % mezi client a server-side: timing rozdíly (klient pošle eventy v batch, server-side má per-event latency), žádný problém.
  • Server-side má víc než client-side: výborně — recovery z adblockerů/ITP funguje, klient přišel o data, server zachránil.
  • Server-side má méně po nasazení Bot Detection: cleaner data, ne bug.
Pomohl vám tento článek?
✓ Děkujeme za zpětnou vazbu