Potřebujeme Google Tag Manager v době AI?

Marek Prokop položil na sociálních sítích jednoduchou, ale důležitou otázku: potřebujeme ještě Google Tag Manager, když dnes může měření připravit AI agent? Po třinácti letech jej na nový web poprvé nenasadil. AI dokáže projít repozitář, najít vhodné místo, upravit kód, spustit kontroly a připravit změnu ke schválení.

Znamená to konec Google Tag Manageru? Neexistuje jedna odpověď pro všechny weby.

Na malém a stabilním webu bych dnes GTM nenasazoval automaticky. Na složitém webu bych jej ale neodstranil jen proto, že AI umí napsat JavaScript. Schopnost vytvořit změnu není totéž jako schopnost ji bezpečně a dlouhodobě řídit.

AI může převzít velkou část práce analytika nebo vývojáře. Sama o sobě však není zdrojem pravdy, systémem oprávnění, schvalovacím workflow, dokumentací, monitoringem ani mechanismem rollbacku.

Proč je otázka „GTM a nebo AI?“ zavádějící

Google Tag Manager vyřešil praktický problém: analytik nebo marketér nemusel s každým novým pixelem čekat na vývojáře a další release webu. Značku nastavil, otestoval a publikoval samostatně.

Současní coding agenti už velkou část tohoto procesu urychlí. Mohou prozkoumat repozitář, připravit změnu na samostatné větvi, spustit testy a vytvořit pull request. Takový způsob práce popisuje například dokumentace ke GitHub Copilot coding agentovi.

Původní otázka však spojuje dvě různé věci:

kdo změnu vytvoří,
kde se změna eviduje, testuje, schvaluje, nasazuje, sleduje a případně vrací zpět.

AI velmi dobře řeší první část. Druhá potřebuje konkrétní proces a vlastníka, ať už používáte GTM, Git, walkerOS nebo vlastní platformu. Prakticky je proto vhodné oddělit tři otázky:

Potřebujeme člověka, který ručně naklikává každou položku v GTM? Stále méně.
Potřebujeme browserový GTM kontejner na každém webu? Ne.
Potřebujeme u složitějšího měření řízenou vrstvu pro změny, oprávnění a distribuci dat? Většinou ano.

Kdy lze GTM vynechat

Přímá implementace dává smysl, pokud měříte několik stabilních událostí do jedné či dvou platforem, změny jsou vzácné, release rychlý a analytika má technického vlastníka. Události musí být centralizované, verzované a testované a marketing ani externisté nesmějí potřebovat vlastní publikační proces.

Blog, portfolio nebo jednoduchý obsahový web: pro základní návštěvnost a několik událostí stačí Google tag a gtag.js nebo jiná lehká analytika.
Malý lead-gen web s dostupným vývojářem: GA4, jednu reklamní platformu a několik konverzí můžete spravovat přímo v aplikaci, pokud změny nečekají týdny v backlogu.
Produkt se silným vývojovým a datovým týmem: s typovaným schématem, testy a vlastním event API může být přirozenější tracking-as-code. Git poskytne diff, code review, vazbu na issue i CI/CD.
Web s minimálním měřením a důrazem na výkon: lze použít menší loader nebo tenkou abstrakci, tým však přebírá odpovědnost za kompatibilitu, consent, dokumentaci i budoucí změny.

Kdy zachovat GTM nebo jinou řídicí vrstvu

Hodnota tag managementu roste s počtem systémů, lidí, dodavatelů, zemí a změn nezávislých na releasu aplikace. Nejde jen o JavaScript, ale o organizační a provozní rozhraní.

Více analytických a reklamních systémů: GA4, Google Ads, Meta, affiliate, personalizace, A/B testování, CRM a datový sklad očekávají různé payloady. Datová vrstva může vytvořit jeden vendorově neutrální event a GTM jej transformuje pro jednotlivé nástroje.
Časté změny mimo produktový release: nasazuje-li se aplikace jednou měsíčně kvůli testům, bezpečnosti nebo change approval boardu, samostatný release měření odstraní úzké hrdlo. AI změnu připraví, bezpečný deployment však stále vyžaduje dohodnutý proces.
Více týmů, zemí nebo značek: standardní rozhraní, naming convention, přehled značek a model tag–trigger–variable usnadňují spolupráci i předání. Vlastní systém může být lepší, musí se však navrhnout, zdokumentovat a udržovat.
E-shop nebo více webů s komplexním consentem: společná pravidla bývá levnější spravovat centrálně. Business logika má zůstat v produktu; řídicí vrstva řeší consent, transformaci a distribuci stabilních událostí, případně v hybridu se server-side vrstvou.
Velký marketplace, média nebo více agentur: governance, role, standardizace a nezávislé releasy zde převažují nad elegancí monolitického kódu. Volbou je řízený GTM, GTM 360 nebo vlastní event platforma.
Menší firma bez stabilního správce webu: lean GTM s omezenými právy může být předávacím bodem. Standardní rozhraní bývá cennější než řešení ovladatelné jen původním autorem.

Web bez jasného vlastníka analytiky: nejdříve určete vlastníka. Žádný Tag Manager, Git ani AI agent nevyřeší organizační vakuum.

Externí specialisté a princip nejmenších oprávnění

Jeden z nejsilnějších argumentů pro GTM vzniká, když má PPC specialista, analytik nebo agentura spravovat konverze bez přístupu do celého repozitáře a vývojové pipeline. GTM umožňuje oddělit role:

vývojový tým vlastní aplikaci a datovou vrstvu,
agentura připravuje změny v kontejneru,
seniorní analytik nebo interní vlastník je kontroluje,
publikační právo zůstává omezenému počtu lidí.

Při změně agentury nový správce přebírá standardní rozhraní, nikoli skripty rozptýlené po aplikaci. Tento argument zazníval i v diskusi na LinkedIn.

Bezpečnostní přínos GTM nespočívá v tom, že přes něj nelze rozbít web. Spočívá v možnosti neotevřít externímu člověku celý vývojový systém a oddělit přípravu změny od jejího publikování.

GTM je současně privilegovaná produkční vrstva. Publikační právo a libovolný Custom HTML mohou web výrazně ovlivnit. Agenturám bych proto nedával neomezené publikování, omezoval Custom HTML, preferoval sandboxované šablony a auditoval přístupy.

Alternativou je omezený Git workflow, v němž externista mění jen analytický modul. Může být čistší, musí jej však někdo navrhnout, provozovat a vysvětlovat dodavatelům. GTM ji nabízí jako hotovou hranici.

Zkušenost z praxe:
GTM vývojářům opakovaně posloužil jako rychlá záchranná vrstva při nepovedeném releasem, což mohou i oni zneužít, bacha. Bez něj vývojáře zatěžovaly změny na desítkách míst; po návratu ocenili, že data odešlou do dataLayer jednou. U vlastních řešení je obtížná i dynamická reakce na změny souhlasu. Starý kód v GTM se neuklízí sám: za dvanáct let mě marketér jen asi dvakrát upozornil, že starý kód lze odstranit.

Co GTM skutečně řeší

Verze, historie a rollback: GTM uchovává publikované verze, autora změny a historii nasazení. K chybné verzi se lze vrátit bez releasu celé aplikace; podrobnosti uvádí dokumentace k publikování, verzím a schvalování. Dobře navržený Git workflow může nabídnout přesnější diff, automatické testy a povinné code review.
Oprávnění a oddělení rolí: uživatelé mohou mít různá práva pro čtení, úpravy, schvalování a publikaci. Plnohodnotná fronta žádostí o schválení je funkcí GTM 360, ale i běžný GTM umožňuje omezit publikování; viz správa uživatelů a oprávnění.
Preview a debugování: Tag Assistant ukazuje události, hodnoty datové vrstvy a značky, které se spustily či nespustily. Agent může testovat pokročileji, stále však potřebuje definované scénáře a očekávané výsledky.
Standardizaci a přehlednost: GTM zná velká část analytiků, PPC specialistů a agentur, takže nový člověk nemusí studovat interní framework. Skripty, pravidla a proměnné jsou na jednom místě místo kódu rozptýleného po aplikaci. Kontejner přidává JavaScriptový overhead, centralizace dat a společných funkcí však může část nákladů vyvážit.
API pro lidi i agenty: Google Tag Manager API zpřístupňuje kontejnery, workspaces, tagy, triggery, proměnné, verze, prostředí i oprávnění. AI tak nemusí GTM nahradit: může porovnat specifikaci s kontejnerem, připravit změnu v samostatném workspace, doplnit popis verze a předložit ji člověku ke kontrole.

Kde má GTM limity

GTM může obejít Git, code review, typovou kontrolu i standardní CI/CD a postupně se proměnit ve druhou, pro vývojáře málo viditelnou aplikaci. Stejná nezávislost je tedy jeho největší výhodou i nevýhodou.

Staré kampaně, duplicitní značky, nepojmenované proměnné a dočasná řešení se navíc hromadí snadno. AI tento problém sama nevyřeší; sníží-li cenu změn, může bez pravidel technický dluh urychlit. Zdravý kontejner potřebuje jasné naming conventions, vlastníky integrací, minimum publikačních práv, pravidelný audit, expiraci dočasných kampaní, minimum Custom HTML a Custom JavaScriptu a pravidelné exporty či zálohy.

GTM také není automaticky bezpečný sandbox. Lze přes něj načítat skripty, odesílat síťové požadavky a ovlivnit běh stránky. Bezpečnější jsou Custom Templates se sandboxovaným JavaScriptem a deklarovanými oprávněními, ani ty však nenahrazují správu přístupů a kontrolu publikace.

Browserový kontejner přidává vzdáleně řízenou vrstvu a závislost na Googlu. U malého webu může být tento trade-off zbytečný. Odstranění GTM však automaticky neodstraní externí skripty: přesunete-li stejné pixely přímo do aplikace, prohlížeč je stále musí stáhnout, parsovat a spustit.

Přesnější rovnice není „bez GTM = rychlý web“, ale „méně nepotřebného third-party JavaScriptu, méně měřicích, reklamních a UX nástrojů a lepší způsob načítání = rychlejší web“.
To může zároveň omezit marketing, vývoj nebo přehled o chování webu a tím ovlivnit obchodní výsledek. Jde proto o širší produktové rozhodnutí, ne pouze o volbu tag manageru.

Stejný princip zdůrazňují doporučení web.dev pro tagy a tag managery.

Co AI agent skutečně mění

Přímá implementace je levnější

Přidání události už nemusí znamenat několik kol vysvětlování a čekání na sprint. Agent může v jednom workflow připravit změnu aplikace, schéma, testy i dokumentaci. Tím se posouvá hranice, od které se vyplatí tracking-as-code.

Agent potřebuje datový kontrakt, ne chaotický DOM

AI umí najít tlačítko podle textu nebo CSS selektoru, ale nejde o stabilní základ měření. Dlouhodobě zdravý systém potřebuje předvídatelné události a parametry. Také Google doporučuje používat konzistentní datovou vrstvu, nikoli parsovat hodnoty rozptýlené po stránce.

V době AI proto roste význam measurement planu, event schématu, naming convention, definice povinných a volitelných parametrů, pravidel pro consent, seznamu dat zakázaných pro třetí strany, automatických testů a produkčního monitoringu. Bez kvalitního, strukturovaného a dostupného kontextu agent pouze rychleji automatizuje chaos.

AI může obsluhovat GTM

Budoucnost nemusí být jen „AI místo GTM“, ale také „AI odstraní většinu ruční práce uvnitř GTM“. V navazující diskusi na Facebooku zazněly příklady, kdy AI připravuje dokumentaci, dataLayer nebo importní JSON kontejneru a člověk následně zkontroluje tagy, triggery a Preview.

To je bezpečnější než předstírat, že AI do správy GTM nepatří nebo dát agentovi neomezené právo publikovat produkční kód. Výstupy AI je vždy nutné kontrolovat a debugovat. Modely se liší kvalitou a často neznají do hloubky konkrétní nastavení GTM, GA4 ani méně obvyklé nástroje. Jednoduchý web zvládnou lépe než složitou implementaci s mnoha výjimkami.

Čím levnější je změnu vytvořit, tím více změn vznikne. Bez automatických pravidel se mohou množit duplicitní eventy, nekonzistentní názvy, nechtěné osobní údaje, konflikty mezi nástroji nebo chyby v consent logice.

Dříve byl problém, že změnu uměl udělat jen někdo. Dnes může být problém, že ji dokáže vytvořit téměř kdokoliv… člověk i agent.

Bezpečný model zůstává stejný: agent připraví změnu, automatické kontroly ji ověří a oprávněná osoba rozhodne o nasazení.

Otázky před nasazením nebo odstraněním GTM

Jak často se měření mění a musí změny vycházet nezávisle na produktovém releasu?
Kolik systémů data spotřebovává?
Kdo změny vytváří, kontroluje, publikuje a dlouhodobě za ně odpovídá?
Potřebují externí lidé přístup do codebase nebo jim stačí omezená měřicí vrstva?
Existuje stabilní kontrakt událostí nebo měření stojí na CSS selektorech a znalostech jednoho člověka?
Jak probíhají testy, Preview, monitoring a rollback?
Může agent sám zasáhnout produkci a kdo bude systém aktualizovat, auditovat a předávat za tři roky?

Čím více nástrojů, týmů, agentur, změn a nezávislých release cyklů, tím větší smysl dává standardizovaný tag management nebo event routing platforma. Čím menší, stabilnější a vývojářsky lépe spravovaný projekt, tím snazší je GTM vynechat.

Potřebujeme tedy ještě Google Tag Manager?

Ne na každém webu. Na malém projektu s několika stabilními událostmi, rychlým vývojem a jedním vlastníkem analytiky může být GTM zbytečná mezivrstva. AI snižuje cenu přímé implementace natolik, že často dává větší smysl mít měření v kódu, verzovat je v Gitu a nasazovat společně s aplikací.

U velkého nebo často měněného webu však AI sama funkci tag managementu nenahrazuje. Nahrazuje část práce při tvorbě změny. Stále potřebujeme zdroj pravdy, testování, oprávnění, schvalování, deployment, rollback, dokumentaci a monitoring.

Pro agentury navíc GTM odděluje měřicí vrstvu od codebase a klientovi ponechává finální publikaci. Tuto roli může plnit GTM, Git a CI/CD, walkerOS, jiný tag manager nebo kvalitně navržená vlastní platforma. Nějaký systém ji však plnit musí.

AI podle mě neznamená konec Google Tag Manageru. Znamená konec doby, kdy jsme jej museli ručně obsluhovat a bez přemýšlení nasazovat na každý nový web.

Správná otázka proto nezní jen „Dáme tam GTM?“, ale: kde bude zdroj pravdy pro měření, kdo smí změny publikovat, jak je otestujeme a vrátíme zpět a kdo bude celý systém dlouhodobě vlastnit?

Zdroje a další čtení