O cookies dnes slyšel každý — odklikáváme je na každém webu. Málokdo ale umí vysvětlit, co to vlastně je, natož jaký je rozdíl mezi first-party a third-party cookie. Přitom právě na téhle mechanice stojí atribuce, remarketing i to, jestli GA4 vůbec pozná vracejícího se zákazníka. A životnost cookies je v některých prohlížečích mnohem kratší, než si většina marketérů myslí.
Kolik lidí se toho týká? Na svých projektech dlouhodobě měřím podíl prohlížečů v návštěvnosti.
Napříč weby, které spravuji, je medián podílu Safari kolem 16 % — typicky tedy každý šestý návštěvník. Na některých webech (s publikem nakloněným k Applu) je to až 24 %, tedy zhruba každý čtvrtý. Firefox je zastoupen asi 4 %.
Proč sleduji zrovna Safari a Firefox? Protože právě tyhle dva prohlížeče zacházejí s cookies nejtvrději — jak přesně, rozebereme za chvíli.
Jedno vymezení předem: článek se soustředí na životnost cookies. Vím, že identitu návštěvníka v datech tříští i další vlivy — typicky přístup z více zařízení nebo z více prohlížečů. Ty tu záměrně nechávám stranou, ať se problematika dá uchopit. Počítejte tedy s tím, že reálný rozpad dat je ještě o něco větší, než co popisuju níž.
Jak cookies a úložiště fungují
Než se pustíme do toho, proč cookies mizí, stručně: kdo je vlastně nastavuje a komu patří.
Cookie může nastavit JavaScript ve vašem měřicím kódu nebo HTTP hlavička odpovědi ze serveru. A může patřit doméně, kterou návštěvník vidí v adresním řádku (first-party), nebo úplně jiné doméně (third-party). Konkrétní příklad: prohlížíte si eshop.cz — cookie patřící doméně eshop.cz je first-party. Když vám na tomtéž webu uloží cookie HTTP hlavička facebookového pixelu, patří doméně facebook.com — a to je third-party cookie.
Kombinace těchto dvou os určuje, jak moc je cookie zranitelná vůči zásahům prohlížeče:
| First-party (vaše doména) | Third-party (cizí doména) | |
|---|---|---|
| JS-set (nastavuje JavaScript) | Cookie _ga, do které si GA4 ukládá identifikátor návštěvníka — nejběžnější případ na webu | Klasické reklamní pixely třetích stran — blokované v Safari a Brave; Firefox je izoluje do vlastního „cookie jaru” pro každý web (partitioning — pro cross-site tracking to dopadá stejně); v Chrome zatím fungují |
| HTTP-set (nastavuje server) | Cookie ze server-side trackingu, nastavená serverem v hlavičce Set-Cookie — typicky s atributem HttpOnly, takže na ni JavaScript vůbec nedosáhne | Third-party trackery v HTTP hlavičce — dnes prakticky nefunkční |
Měřicí cookie Google Analytics je JS-set first-party cookie — nastavuje ji JavaScript. Právě proto se jí týká většina toho, o čem je tenhle článek.
Kdo tuhle mechaniku zná, může sekci přeskočit — na zbytek článku to nemá vliv. Pojďme k tomu, proč cookies i přes svou expiraci nastavenou v kódu nakonec stejně zmizí dřív.
Životnost cookies v Safari, Firefoxu a Chromu
Expirace, kterou cookie nastavíte v kódu, je jen strop. Jak dlouho cookie reálně přežije, si každý prohlížeč určuje po svém — a rozdíly jsou zásadní.
Safari: JS cookies přežijí maximálně 7 dní
Safari má v ITP (Intelligent Tracking Prevention) tvrdý limit: JS-set cookies maže po 7 dnech. Bez debaty — tečka. A když návštěvník přijde přes odkaz, který nese v URL sledovací parametry známého trackeru — typicky proklik z reklamy s gclid nebo fbclid v adrese (téhle technice se říká link decoration) — je limit ještě přísnější: 24 hodin.
Safari navíc od verze 14 (2020) prohlíží DNS a odhaluje CNAME cloaking (kdy se cookie schová za vaši vlastní subdoménu, typicky u server-side trackingu) a od verze 16.4 (2023) porovnává i IP adresy: pokud se u serveru, který cookie v HTTP odpovědi nastavuje, neshoduje s hlavní doménou ani první polovina IP adresy (pravidlo se uplatní jen bez CNAME detekce, tedy při prázdném CNAME řetězci), dopadne cookie na stejný 7denní limit.
Apple v Safari 26 (září 2025) zapnul Advanced Fingerprinting Protection defaultně pro veškeré prohlížení. Fingerprinting je technika, jak poznat návštěvníka i bez cookies: skript si přečte kombinaci vlastností prohlížeče a zařízení — rozlišení, fonty, způsob vykreslování grafiky — a složí z nich prakticky unikátní „otisk”. Známým fingerprintovacím skriptům (typicky hotovým knihovnám, které si web pro tenhle účel nasadí) teď Safari přístup k těmto údajům omezuje a navíc jim nedovolí uložit dlouhodobou cookie ani localStorage — otisk si nemají kam trvale odložit. V anonymním režimu navíc maže trackovací parametry z URL. Tohle je dokumentované chování z blogu WebKitu; nejasný je zatím přesný dopad na konkrétní měřicí nástroje.
Firefox: cookies nemaže, ale izoluje
Firefox jde jinou cestou — v rámci Enhanced Tracking Protection nasadil mechanismus Total Cookie Protection. Third-party cookies neblokuje, ale izoluje každému webu do vlastního „cookie jaru” (partitioning) — pro sledování napříč weby to vyjde nastejno. First-party měřicí cookies ale nechává žít; žádný 7denní limit jako v Safari tu nenajdete.
Chrome: cookies smíte nastavit až na 400 dní
Chrome se chová jinak, než čekáte, pokud jste zaslechli, že „cookies končí”. Cookie tam smíte nastavit až na 400 dní a third-party cookies Chrome navzdory letitým ohlášením stále neblokuje — Privacy Sandbox, projekt, který to měl změnit, Google v říjnu 2025 oficiálně ukončil a žádný termín konce third-party cookies v Chrome teď neexistuje. Věta „cookies umírají” tak v plné síle platí hlavně pro Safari a Brave.
Brave: nejpřísnější ze všech
Brave má v běžné návštěvnosti malý podíl — a v GA4 ho většinou ani neuvidíte samostatně, protože se identifikuje jako Chrome. K cookies je ale nejpřísnější ze všech: JS-set cookies zkracuje na 7 dní stejně jako Safari, cookies z HTTP hlavičky omezuje na 6 měsíců a third-party úložiště blokuje úplně — cizí web dostane jen dočasné efemérní úložiště, které zmizí, jakmile návštěvník web opustí.
Cookies mažou lidé
K chování prohlížečů přidejte změnu zařízení a ruční mazání cookies — podle starých studií mazala cookies aspoň jednou měsíčně třetina uživatelů (comScore 2007) a blokací či smazáním končily skoro dvě třetiny tracking cookies (Flashtalking 2018). Aktuálnější studie jsem nenašel.
Berte je tedy jako ilustraci trendu, ne aktuální fakt.
Cookies může mazat i cookie lišta
Mimochodem: i vaše vlastní cookie lišta umí cookies sama mazat, pokud to máte zapnuté v administraci — než začnete pátrat po chybě v prohlížeči, stojí za kontrolu, ať si nepřičítáte na vrub Safari něco, co si způsobujete sami (chyby v cookie liště mohou zkreslovat vaše data i jinými způsoby).
Vědecká poznámka
Je to jako poločas přeměny radioaktivního vzorku — cookie nemá životnost danou datem, které jí nastavíte v kódu, ale tou, kterou jí dovolí prohlížeč. Vaše publikum se rozpadá podobně, den za dnem. V Safari je to ale rozpad s ultimátem: kdo se nevrátí do 7 dnů, nerozpadl se částečně — rozpadl se celý.
Dopady na platnost cookies
Výsledek: reálná platnost cookies je daná tím nejpřísnějším pravidlem, které se na daného návštěvníka zrovna vztahuje. Na webech s vyšším podílem Safari nebo Firefox se doba platnosti významně zkracuje.
A pozor na localStorage: v Safari vám nepomůže — ITP maže veškeré úložiště zapisovatelné skriptem (včetně localStorage) po 7 dnech používání prohlížeče bez interakce s webem. Chrome a Firefox ho sice takhle nečistí, ale problém řešíte právě kvůli Safari — takže si od něj víc perzistence neslibujte.
Čísla z praxe
Jak moc se jeden člověk v datech násobí? Před pár lety jsem dělal vyhodnocení návštěvnosti na intranetu, kde jsem znal user ID každé návštěvy — a kde se lidé přihlašovali opakovaně ze stejných zařízení. Lepší podmínky pro cookies si přát nemůžete. I tak vycházelo zhruba 2,1 uživatele v GA4 na jednoho reálného člověka (jeden reálný člověk = jedno unikátní user ID).
U veřejných webů — bez přihlašování, s vyšším podílem Safari a mobilů — čekám číslo výrazně vyšší, klidně tři a víc GA4 uživatelů na jednoho reálného návštěvníka. To už změřené nemám; je to odhad opřený o mechanismy popsané výš.
Proto GA4 ukazuje víc uživatelů, než máte: nikdo vám z dat nezmizel. Jen se každý počítá víckrát.
Dopady na měření a marketing
Tohle všechno zůstává akademické, dokud to nespočítáte proti vlastnímu nákupnímu cyklu. Co se konkrétně stane, když cookie umře dřív než cesta zákazníka k nákupu?
Vícenávštěvová atribuce se přetrhne. GA4 spojuje návštěvy stejného návštěvníka přes _ga cookie (client_id). Umře-li cookie mezi návštěvou z kampaně a návštěvou, kde padne konverze, GA4 tyhle dvě návštěvy nespojí. Konverze se připíše poslednímu zdroji — často direct — a zákazník se v datech tváří jako nový, přestože o vaší značce ví už týdny. (Direct traffic má i další, mnohem častější příčiny — špatně tagované UTM parametry nebo redirecty, které je nezachovají. Cookie decay je jedna z příčin, ne vysvětlení celého problému.)
Affiliate provize mizí. Affiliate systémy běžně nastavují 30denní cookie okno. Pokud je to JS-set first-party cookie (dnes běžný setup), v Safari je fakticky 7denní — zbylých 23 dní okna existuje jen na papíře. Third-party affiliate cookie v Safari nefunguje vůbec.
Konverzní okno reklamních platforem se zkracuje. gclid a fbclid, které Google Ads a Meta Ads používají k měření konverzí, se ukládají do _gcl_aw / _fbc — JS-set first-party cookies, na které v Safari typicky dopadá dokonce přísnější 24hodinový limit: vznikají totiž po prokliku z domény, kterou ITP klasifikuje jako tracker (google.com, facebook.com), s click ID v URL — přesně podmínky pravidla o link decoration. Platformy část těchto ztrát řeší modelováním přes enhanced conversions — k tomu se dostaneme v sekci o hranicích za cookies.
Remarketing je rozdělený na dvě vrstvy s různým dopadem. Klasický remarketing přes third-party cookie v Safari nefunguje vůbec — a to už od roku 2020, ne „po 7 dnech”. Publika stavěná z first-party dat (publika GA4, seznamy z gclid) fungují, ale ztrácí každého, kdo se nevrátí do 7 dnů.
A/B testy dostávají šum. Návštěvník, kterému expirovala cookie, může při dalším příchodu dostat jinou variantu testu, než viděl poprvé. Test tím není rozbitý — ale šum prodlužuje čas, za který dosáhnete statistické průkaznosti.
Žádný z těchto dopadů není katastrofa sám o sobě. Součet bolí.
Hodnocení měřicích setupů
Chcete-li cookie, která opravdu vydrží, je třeba:
- Nastavená HTTP-set hlavičkou (ne javascriptem)
- First-party – ideálně na úplně stejné doméně (např. www.mujeshop.cz)
Nejjednodušší setup — klasický Google Tag Manager (GTM) + GA4 na straně klienta — má životnost přesně takovou, jakou popisuje předchozí sekce. Nic víc, nic míň. Je to nejjednodušší i nejlevnější řešení, a pro spoustu webů s krátkým nákupním cyklem naprosto dostatečné.
Jakmile firma zvažuje server-side měření cookies (co je server-side měření a proč je důležité jsem popsal v samostatném článku), typicky narazí na tři varianty server-side Google Tag Manageru (sGTM) — a každá řeší jiný kus problému:
| Setup | Životnost v Safari | Odolnost vůči blokování | Náročnost / cena |
|---|---|---|---|
| Klasický GTM + GA4 (client-side) | 7 dní (JS cookie), third-party cookies nefungují vůbec | Nízká — blokuje ji ITP i ad blockery | Nízká |
| sGTM na subdoméně, výchozí Cloud Run deployment | Stále 7 dní — past CNAME cloakingu (viz níže) | Střední — obchází blokování skriptů, ne ITP limit | Střední |
| Google Tag Gateway | Beze změny — pořád 7 dní (řeší blokování skriptů, ne limit ITP) | Vysoká pro Google stack, nulová pro ostatní nástroje | Nízká až střední |
| sGTM za vlastní infrastrukturou se shodnou IP | Plná nastavená expirace (až 400 dní v Chrome) | Vysoká napříč nástroji | Vysoká |
Čím blíž se dostanete k tomu, aby cookie nastavoval server namísto JavaScriptu, tím míň se vás týká 7denní limit ITP.
Past, na kterou narazí skoro každý, kdo si server-side tracking nastaví sám: sGTM na subdoméně přes výchozí deployment na Google Cloud Run. Vypadá to jako řešení — cookie teď „nastavuje váš server”. Jenže výchozí napojení subdomény na Cloud Run vede přes CNAME záznam na server Googlu (ghs.googlehosted.com) — a přesně tenhle vzorec Safari od verze 14 vyhodnocuje jako CNAME cloaking a životnost cookie zkrátí na 7 dní. A i kdybyste subdoménu napojili napřímo přes A záznam na IP Googlu, chytí to od verze 16.4 druhá pojistka: Safari porovná IP adresu serveru s IP hlavní domény, a pokud se neshoduje ani první polovina adresy, dopadne cookie stejně. Klient si myslí, že má vyřešeno. Nemá.
Google Tag Gateway je novější varianta od Googlu — a tady je dobré být přesný, protože název svádí k mylné představě. Gateway neřeší 7denní limit ITP ani past popsanou výš; cookies dál nastavuje JavaScript, takže Safari je ořeže na 7 dní úplně stejně jako předtím. Řeší jiný problém: blokování skriptů a požadavků (ad blockery, ztráta signálu), protože je vede přes vaši vlastní doménu. Z pohledu životnosti cookies to řešení není. Nástrojům mimo Google stack (Meta, affiliate systémy, CDP) navíc nepomůže vůbec.
Google Tag Gateway považuji za solidní řešení pro firmy, které měří skoro výhradně přes Google a bojují hlavně s blokováním.
Poslední varianta — sGTM za vlastní infrastrukturou se stejnou IP jako hlavní doména — řeší problém nejúplněji.
Pokud používáte CloudFlare nebo jinou podobnou CDN, případně Cloud Load Balancer, může být toto relativně jednoduché. Pokud ne, je tahle cesta poměrně náročná.
Co dává smysl pro koho
Než se rozhodnete cokoliv měnit, spočítejte si tři čísla: jak dlouhý je váš nákupní cyklus, jaký podíl Safari máte v publiku a kolik jste ochotní investovat.
E-shop, kde lidé nakupují do dvou dnů od první návštěvy, řeší úplně jiný problém než B2B firma s tříměsíčním rozhodovacím cyklem. Prvnímu 7denní limit v Safari vadí minimálně — většina cest ke konverzi se do něj vejde. Druhému může utrhnout atribuci u zákazníků, kteří se vrací opakovaně přes týdny.
Podíl Safari v publiku najdete v GA4 v přehledu prohlížečů za posledních 90 dní. Pokud je pod 10 % a nákupní cyklus krátký, klidně zůstaňte u klasického GTM + GA4 setupu — investice do server-side trackingu se vám nevrátí, pokud ovšem nemáte jiný pádný důvod: typicky boj s ad blockery nebo požadavek na kvalitnější konverzní data pro kampaně.
Pokud je podíl Safari vysoký (typicky B2C s Apple publikem) a zároveň máte delší cyklus nebo silně stavíte na remarketingu a affiliate, server-side tracking dává smysl — ale vybírejte podle předchozí sekce, ne podle toho, co vám prodá první agentura. Google Tag Gateway stačí, pokud měříte skoro jen přes Google. Jinak počítejte s náročnější variantou.
Rozpočet nakonec rozhoduje mezi „stačí to spravit” a „chceme to vyřešit pořádně” — obě odpovědi jsou legitimní, pokud vycházíte z čísel, ne z obav.
Za hranice cookies
Cookies nejsou jediná cesta, jak si spojit návštěvu s konverzí.
Většina nástrojů dnes umí propojit návštěvy a konverze přes hashované osobní údaje — e-mail, telefon nebo přihlašovací user ID. Google Ads na to má enhanced conversions, Meta advanced matching a GA4 funkci User-ID; jak platformy osobní údaje hashují jsem popsal v souvislosti s formuláři. Pokročilé firmy jdou ještě dál a propojují identitu zákazníka napříč zdroji (web, CRM, e-shop) v customer data platform (CDP) — tomu se říká identity resolution a zaslouží si samostatný článek.
Pokud máte delší nákupní proces, tohle je směr, kterým se rozhodně vyplatí uvažovat: identita postavená na přihlášení nebo e-mailu nezávisí na tom, jestli cookie přežila týden.
Závěr
O tom, jestli vaše atribuce a remarketing fungují, nebo jen vypadají, že fungují, rozhodují dvě věci: životnost cookies a to, jak umíte pracovat s identitou návštěvníka. Cookie sama o sobě není trvanlivý identifikátor — je to křehká věc, jejíž trvání vám z velké části diktuje prohlížeč, ne vaše nastavení v administraci. Pokud je váš nákupní cyklus delší než týden, měření v Safari vám systematicky lže — typicky u každého šestého návštěvníka, na některých webech u každého čtvrtého.
Podívám se na váš podíl Safari a délku nákupního cyklu a řeknu vám, jestli setup měnit — a jestli vůbec. Ozvěte se mi.