Google Analytics Client ID v GTM: vlastní JavaScript už nepotřebujete

Co je Google Analytics Client ID

Client ID je pseudonymní identifikátor konkrétní instance prohlížeče. Při povoleném analytickém úložišti ho Google Analytics standardně ukládá do first-party cookie _ga a používá ho k rozlišení pseudonymních uživatelů a jejich návštěv. Toto chování popisuje přímo dokumentace ke sběru dat v Google Analytics.

Client ID identifikuje prohlížeč, ne člověka. Jednomu člověku může odpovídat několik Client ID a jedno Client ID nemusí být dlouhodobě stabilní. Podrobnější dopad cookies, ITP a dalších omezení na metriku uživatelů popisuji v článku Google Analytics metriky v době ITP.

• jiný prohlížeč nebo zařízení znamená jiné Client ID;
• anonymní a běžné okno mohou mít odlišné identifikátory;
• po smazání nebo expiraci cookie vznikne nové Client ID;
• omezení úložiště, ochrany prohlížeče a stav souhlasu mohou hodnotu znepřístupnit;
• na prvním zobrazení může záležet na tom, zda už Google tag stihl cookie vytvořit.

User-ID musí být stabilní v rámci vaší vlastní přihlašovací identity a nesmí obsahovat PII, například e-mail nebo telefon. Google ho popisuje jako vlastní neosobní identifikátor přihlášeného uživatele v dokumentaci k implementaci User-ID.

Client ID, User-ID a Session ID nejsou vzájemně zaměnitelné. Žádnou z těchto hodnot nepoužívejte jako přihlašovací, autorizační nebo bezpečnostní token.

Kterou GTM proměnnou zvolit

Jak zapnout vestavěnou proměnnou Analytics Client ID

1. Otevřete webový kontejner v Google Tag Manageru.
2. Přejděte do části Proměnné.
3. U vestavěných proměnných zvolte Konfigurovat.
4. V sekci Utilities zapněte Analytics Client ID.
5. Otevřete náhled a hodnotu ověřte v Tag Assistantu.

Podle dokumentace k vestavěným proměnným webového kontejneru poskytuje Analytics Client ID hodnotu z výchozí Google Analytics Client ID cookie. Žádný regulární výraz, ruční ořezávání prefixu GA1.2. ani Custom JavaScript už nepotřebujete.

Proměnná sama nevytváří vlastní identifikátor a neodesílá další síťový požadavek. Když cookie ještě neexistuje, je blokovaná nebo se proměnná vyhodnotí dříve, než Google tag hodnotu vytvoří, musí navazující značka nebo kód bezpečně přijmout chybějící hodnotu.

Stav souhlasu ověřujte samostatně. Z přítomnosti ani absence Client ID neodvozujte, zda uživatel souhlasil. Zdroj pravdy je stav Consent Mode nebo stav, který vaše CMP předává do implementace.

Testujte proto první návštěvu v čistém profilu prohlížeče, ne jen svůj běžný prohlížeč se starou cookie a dříve uděleným souhlasem.

Analytics Storage pro vlastní prefix cookies a konkrétní session

Pro pokročilé konfigurace vytvořte uživatelskou proměnnou typu Analytics Storage:

1. Proměnné > Proměnné definované uživatelem > Nová.
2. Vyberte typ Analytics Storage.
3. Zvolte datové pole Client ID, Session ID nebo Session Number.
4. Podle potřeby doplňte cookie prefix nebo Measurement ID.

Pokud na webu běží více GA4 streamů nebo destinations, zadejte u session hodnot Measurement ID. Jinak neberte první nalezené číslo bez ověření, protože výsledek může obsahovat více session hodnot.

Pozor na podobný název: uživatelská proměnná Analytics Storage v GTM je čtečka analytických identifikátorů. Consent type analytics_storage v Consent Mode určuje, zda Google tag smí používat analytické úložiště. Nejde o stejnou věc.

Jak bezpečně odstranit starý parser cookie _ga

Pokud v kontejneru najdete tuto nebo podobnou Custom JavaScript proměnnou, nahraďte její použití nativní hodnotou a po otestování ji odstraňte:

function() {
  return ('; ' + document.cookie).split('; _ga=')
    .pop()
    .split(';')
    .shift()
    .match(/GA1.[0-9]{1}.(.+)/)[1]
}

Tento kód už nekopírujte. Má několik konkrétních problémů:

• když cookie _ga neexistuje, match() vrátí null a přístup k [1] skončí chybou;
• tečky v regulárním výrazu znamenají libovolný znak, protože nejsou escapované;
• parser předpokládá konkrétní interní formát cookie, který Google negarantuje jako veřejné API;
• neřeší vlastní prefix, domain, path ani více relevantních cookies;
• čte syrový cookie string nezávisle na logice Google tagu a může tak pracovat se starou cookie i ve chvíli, kdy navazující zpracování nemá proběhnout;
• document.cookie je synchronní API, které může blokovat hlavní vlákno, a Custom JavaScript proměnná se v GTM může vyhodnotit opakovaně.

Původní text navíc mluvil o ošetření přes try, ale ve zveřejněné ukázce žádný try/catch není. Ani přidání try/catch by však nevyřešilo závislost na interním formátu cookie.

Google už 1. srpna 2025 přidal podporované API readAnalyticsStorage pro vlastní šablony a v prosinci stejného roku zpřístupnil hotové proměnné přímo v GTM. Důvod uvedl výslovně: reverse engineering formátu cookies nebyl spolehlivý a mohl se rozbít při změně jejich struktury.

Bezpečný migrační postup

1. Vyhledejte všechny značky, triggery a proměnné, které starý parser používají.
2. Zapněte vestavěnou proměnnou nebo vytvořte Analytics Storage pro vlastní prefix.
3. Nahrazujte reference postupně, ne přejmenováním staré proměnné pod rukama celému kontejneru.
4. Ověřte čistou první návštěvu, udělení souhlasu, zamítnutí a odvolání bez reloadu.
5. Publikujte pojmenovanou verzi kontejneru s možností rychlého rollbacku.
6. Starý parser smažte až ve chvíli, kdy na něj nezůstala žádná reference.

Kdy Client ID opravdu potřebujete

Nejčastější smysluplný případ je GA4 Measurement Protocol: chcete odeslat serverový nebo offline event a spojit ho s browserovou aktivitou, která už proběhla přes Google tag. Rozdíl mezi přímým serverovým měřením, client-side měřením a server-side GTM podrobněji vysvětluji v článku Client-side a server-side měření vs. Google server-side tagging.

U webového streamu používá Measurement Protocol:

• measurement_id v URL požadavku;
• client_id v JSON těle;
• api_secret v URL požadavku, ale pouze na důvěryhodném serveru;
• podle use case také session_id, engagement_time_msec a případně timestamp_micros.

Client ID má odpovídat hodnotě vytvořené Google Analytics tagem na webu. API secret nikdy nevkládejte do GTM proměnné, datové vrstvy ani browserového JavaScriptu. Každý návštěvník by ho mohl přečíst a posílat do vaší GA4 služby falešná data.

Pokud má serverový event převzít atributy konkrétní návštěvy, potřebujete také session_id. Google pro session attribution vyžaduje odeslání nejpozději do 24 hodin od začátku session. Pro správné metriky engagementu a lepší zobrazení v Realtime doporučuje dokumentace přidat také engagement_time_msec.

Measurement Protocol má měření přes Google tag doplňovat, ne nahrazovat. Samotné server-to-server eventy bez odpovídajícího online kontextu mohou mít jen částečné reportování a horší atribuci.

Další legitimní případy

• cílené ladění konkrétního datového toku;
• serverové spojení online a offline události s jasně definovaným účelem;
• datový import podporovaný GA4;
• vlastní analytický backend, který respektuje stav souhlasu, přístupová práva a dobu uchování.

„Třeba se to někdy bude hodit“ není dostatečný use case pro sběr dalšího pseudonymního identifikátoru.

Proč Client ID neposílat jako vlastní dimenzi u každého eventu

Původní článek doporučoval posílat Client ID s každým hitem do vlastní dimenze. Pro Universal Analytics to býval rozšířený trik. V GA4 bych to jako výchozí postup nedělal.

Client ID má téměř unikátní hodnotu pro každou instanci prohlížeče. Vzniká tedy vysoce kardinalitní dimenze. Google považuje za vysokou kardinalitu více než 500 unikátních hodnot za den. Taková dimenze zvětšuje počet řádků, zvyšuje riziko seskupení do řádku (other) a spotřebuje jednu z omezeného počtu vlastních definic.

Podle cíle použijte vhodnější cestu:

• Potřebuji surová eventová data: GA4 BigQuery export obsahuje pseudonymní pole user_pseudo_id. Ani ono ale nepředstavuje stabilního člověka napříč prohlížeči a zařízeními.
• Potřebuji spojit přihlášeného uživatele napříč zařízeními: implementujte systémové User-ID, ne vlastní dimenzi s Client ID nebo User-ID.
• Potřebuji projít aktivitu jednotlivého pseudonymního uživatele: použijte User exploration nebo BigQuery podle dostupnosti a účelu.
• Potřebuji serverový event: předejte Client ID pouze do konkrétního serverového toku a dodržte pravidla Measurement Protocolu.

Consent Mode: co se stane bez analytických cookies

Jak podrobněji vysvětluji v článku Consent Mode je jen pomocník, a ne řešení, při analytics_storage='denied' Google Analytics nebude číst ani zapisovat first-party analytické cookies. V Advanced Consent Mode však může odesílat měření bez cookies pro základní měření a modelování.

Basic Consent Mode

Google tag je do udělení souhlasu blokovaný. V čistém profilu se před souhlasem nevytvoří cookie _ga a není k dispozici stabilní Client ID vytvořené Google Analyticsem.

Advanced Consent Mode

Google tag se může načíst s výchozím odmítnutým úložištěm a odesílat cookieless pings. To není povolení vytvořit si vlastní stabilní identifikátor bokem. Cookieless měření nenahrazujte vlastní cookie, localStorage ID, serverovým fingerprintem ani jiným obcházením volby uživatele.

Odvolání dříve uděleného souhlasu

Odvolání souhlasu a fyzické smazání všech dříve vytvořených cookies nejsou automaticky totéž. Google tag při odmítnutém analytics_storage nemá analytické cookies číst ani zapisovat, ale stará cookie může v prohlížeči zůstat, dokud ji neodstraní vaše CMP nebo vlastní logika. Praktické testování čistého stavu a mazání úložišť rozebírám v článku Smazání všech cookies dané stránky není tak lehké, jak se může zdát.

Dokumentace nové GTM proměnné neurčuje přesnou návratovou hodnotu pro každou kombinaci existující staré cookie, okamžité změny souhlasu a vyhodnocení bez reloadu. Proto platí tři pravidla:

• consent state ověřujte nezávisle na hodnotě Client ID;
• navazující tok musí bezpečně přijmout prázdnou nebo nedostupnou hodnotu;
• přítomnost ani absence Client ID není důkaz uděleného nebo odmítnutého souhlasu.

Stejná pravidla musí respektovat váš backend, CRM a další systémy, do kterých Client ID posíláte. Odvolání souhlasu nesmí zastavit jen Google tag a nechat vlastní serverový tok běžet dál.

Testovací matice pro Client ID a stav souhlasu

Nehledejte jeden univerzální očekávaný řetězec. V každém scénáři ověřujte samostatně stav Consent Mode, hodnotu proměnné, cookies a síťové požadavky.

Výkon, soukromí a kontrolní seznam

Výkon

Vestavěná proměnná nevytváří další síťový požadavek a odstraňuje vlastní regulární výraz. Jedno ruční čtení document.cookie web obvykle nezpomalí měřitelným způsobem, ale jde o synchronní API a GTM může Custom JavaScript proměnnou vyhodnotit opakovaně. Nativní řešení je tedy současně spolehlivější, jednodušší a levnější na údržbu.

Soukromí

Client ID je pseudonymní, nikoli anonymní. Recitál 30 GDPR výslovně uvádí cookie identifikátory mezi online identifikátory, které mohou v kombinaci s dalšími informacemi vytvořit profil nebo přispět k identifikaci člověka. Pseudonymizace snižuje riziko, ale sama z údajů nedělá anonymní data.

Mějte proto konkrétní účel, odpovídající právní základ, přiměřenou dobu uchování a přístupová pravidla. Pokud Client ID ukládáte do vlastního backendu nebo CRM, zahrňte ho do datového inventáře, procesu odvolání souhlasu a mazání dat. Google zároveň zakazuje posílat do Analytics PII a upozorňuje, že jeho smluvní definice PII nemusí být totožná s definicí osobních údajů podle GDPR. Podrobnosti jsou v dokumentaci k PII v podmínkách Google Analytics.

Nepřipojujte Client ID k e-mailu, telefonu nebo jiné přímo identifikující hodnotě bez jasného, posouzeného a zdokumentovaného důvodu. PII nikdy neposílejte do Google Analytics.

Nejlepší GTM proměnná je někdy ta, kterou vůbec nepotřebujete. Nativní Analytics Client ID řeší spolehlivé získání hodnoty. Neřeší za vás účel sběru, kvalitu identity, pořadí značek, Consent Mode ani správu dat v navazujících systémech.