PostHog a Claude: návod, jak zjistit, proč lidé nedokončí nákup

Napsáno 9. listopadu 2026. Ceny a funkce PostHogu se mění, aktuální stav ověřte v ceníku. Navazuje na sérii o Claude v agentuře.

Postup jsem vyzkoušel u klienta, který prodává vstupenky online. Za pár dní jsme měli osm konkrétních příčin, proč lidé nedokončí nákup, seřazených podle dopadu a s vlastníkem opravy. Tou případovkou návod končí. Čísla jsou anonymizovaná, ukazuju jen poměry.

Co se naučíte a co budete potřebovat

Naučíte se:

• nastavit PostHog tak, aby měřil jen to podstatné a nevyčerpal limity zdarma,
• nasadit ho přes Google Tag Manager s ohledem na souhlas s cookies,
• připojit ho ke Claude tak, aby nemohl nic rozbít,
• položit Claude správné otázky a dostat seznam problémů s daty,
• poznat, kterým číslům věřit a kterým ne.

Budete potřebovat:

• přístup do Google Tag Manageru webu nebo obchodu,
• obchod, který posílá do dataLayer e-commerce události (přidání do košíku, nákup),
• účet v PostHogu (stačí bezplatný),
• Claude s možností přidat konektor,
• volitelně GA4 pro srovnání a skill pudeto-posthog, který celý postup obsahuje jako recept.

Co je PostHog

PostHog je nástroj na produktovou analytiku. Neříká jen, kolik lidí přišlo a nakoupilo, ale co přesně dělali: kam klikali, která pole formuláře vyplnili, kde se zasekli a jak rychle jim stránka reagovala. Umí záznamy obrazovky (session replay), heatmapy, A/B testy a průzkumy. Je open source a běží v cloudu v EU nebo v USA.

GA4 nenahrazuje, doplňuje ho:

Jak to celé funguje

Obchod posílá události přes Google Tag Manager do PostHogu (jen po souhlasu a jen ze stránek obchodu) a do GA4. Claude čte oba nástroje přes konektory, píše dotazy, počítá a výsledky skládá do dokumentu pro klienta. Otázky klade a rozhoduje člověk.

Krok 1: Založte účet a organizaci

Založte si účet na PostHogu a zvolte EU cloud. Pro každý web nebo klienta vytvořte samostatnou organizaci, ideálně na e-mail klienta nebo samostatný účet. Limity zdarma platí pro celou organizaci a projekty v ní si je dělí, další projekt nepřidá další záznamy zdarma. Oddělené organizace navíc znamenají oddělená data a čisté předání, když spolupráce skončí. My tak dnes máme dva až tři účty v PostHogu pod různými e-maily.

Projekt pojmenujte podle webu (ne „Default project“) a nastavte časovou zónu Europe/Prague, jinak budou denní přehledy časově posunuté.

Free, nebo placená verze?

Pro jeden obchod nebo košík většinou stačí bezplatná verze. Placená (pay-as-you-go) má stejné měsíční limity zdarma a platíte jen to, co je nad nimi. Hlavní rozdíl: ve free verzi se data nad limit zahazují, v placené pokračují a dají se omezit limitem útraty.

Ceny podle ceníku PostHogu k 9. 11. 2026. Limity se každý měsíc obnovují a nepřevádějí. Pro představu: obchod s tisíci návštěv denně, měřený jen po souhlasu, spotřebuje zhruba polovinu limitu událostí. Záznamy ale dojdou za pár dní, pokud se nahrává všechno – proto krok 2.

Krok 2: Nasaďte PostHog přes Google Tag Manager

PostHog se do GTM vkládá jako šablona značky. Potřebujete dvě značky a jedno blokační pravidlo:

1. Značka „Init“ načte PostHog s klíčem projektu a zapne záznamy. Spouští se na události souhlasu (consent update), jednou za událost.
2. Značka „E-commerce“ posílá do PostHogu události z dataLayer: přidání do košíku, zobrazení košíku, začátek pokladny, nákup. „Init“ má nastavenou jako setup značku, takže se PostHog vždy načte dřív.
3. Blokační pravidlo zastaví obě značky všude, kde nechcete měřit. U obchodu se vstupenkami jsme měřili jen stránky obchodu, u e-shopu jen košík a jeho kroky.
4. Souhlas: obě značky vyžadují všechny čtyři signály Consent Mode (analytics_storage, ad_storage, ad_user_data, ad_personalization), tedy jen po „Přijmout vše“.
5. Nastavení záznamů v PostHogu: maskovat všechna pole formulářů, kde se osobní údaje zobrazují jako text (adresa, děkovná stránka), maskovat i veškerý text. Nahrávat jen návštěvy, které dojdou na stránku objednávky, a minimální délku záznamu dát na 2 sekundy.
6. Test v náhledu GTM a publikace. Publikuje vždy člověk.

Init se spustí až po souhlasu a je setup značkou pro e-commerce, takže události nikdy nepřijdou dřív než PostHog. Blokační pravidlo platí pro obě značky.

Chyby, na které jsme narazili

• Oficiální šablona v sandboxu GTM nefungovala. V galerii GTM nebyla, tak jsme ji vložili ze zdrojového kódu na GitHubu. E-commerce události padaly, protože kontrola copyFromWindow('posthog') v sandboxu vrací prázdno. Pomohlo kontrolovat posthog.__loaded a přidat k tomu oprávnění na čtení.
• Jednostránkový obchod nehlásil přechody. Obchod mění adresu bez načtení stránky a PostHog posílal zobrazení jen poprvé. Opravilo to nastavení capture_pageview: 'history_change'.
• Limit záznamů došel za šest dní. Nahrávali jsme všechny návštěvy obchodu a 5 000 záznamů měsíčně bylo pryč za necelý týden. Pak se přestalo nahrávat, bez upozornění. Proto bod 5: nahrávat jen relevantní návštěvy.
• Nákup se v náhledu otestovat nedá. Bez platby nevznikne. Ověřte ho na první reálné objednávce v PostHogu.

Co má test v náhledu ukázat: PostHog se načte z EU až po souhlasu, zobrazení stránek chodí i po změně adresy, e-commerce události mají stejné hodnoty jako dataLayer, po „Jen nezbytné“ a mimo obchod neodejde nic a ostatní značky se chovají stejně jako předtím.

Krok 3: Připojte PostHog ke Claude přes MCP

MCP (Model Context Protocol) je standard, kterým se AI připojí k cizímu nástroji. PostHog má oficiální MCP server. V Claude ho přidáte jako konektor s adresou serveru a přihlásíte se účtem PostHogu (OAuth, případně osobním API klíčem).

Adresu doporučuju rovnou doplnit o ID projektu a režim jen pro čtení:

https://mcp.posthog.com/mcp?project_id=123456&readonly=true

• project_id konektor „připíchne“ ke konkrétnímu projektu. PostHog pak skryje nástroje na přepínání organizací a projektů, takže Claude omylem nesáhne do cizího projektu. ID najdete v nastavení projektu.
• readonly=true schová všechny nástroje, které něco vytvářejí, mění nebo mažou.
• Více klientů = více konektorů. Jedno připojení je vždy jeden účet a jeden projekt. Pro dalšího klienta přidejte další konektor s vlastním názvem (PostHog – klient A, PostHog – klient B) a přihlaste se jeho účtem.
• Region (EU, nebo USA) se pozná podle účtu sám. Kdo má účty v obou regionech, potřebuje dvě připojení.

Podrobnosti jsou v dokumentaci PostHog MCP.

Krok 4: Nechte data týden běžet a zkontrolujte je

Analýza má smysl po týdnu, aby byly v datech všední dny i víkend. Než se začnete ptát na příčiny, nechte si od Claude potvrdit, že data jsou v pořádku:

Kolik událostí, lidí a relací se v PostHogu nahrálo od spuštění? Které e-commerce události chodí a kolik jich je? Kolik záznamů obrazovky se nahrálo po dnech?

Hledáte tři věci: chodí všechny události, které obchod má posílat (přidání do košíku, zobrazení košíku, nákup); sedí počet nákupů zhruba na realitu, s ohledem na to, že PostHog měří jen po souhlasu; a nahrávají se záznamy každý den. U nás se tady ukázalo, že záznamy po šesti dnech přestaly a že nákup převodem obchod neposílá vůbec.

Krok 5: Zeptejte se Claude

Jeden funnel řekne, kde lidé odpadají. Proč odpadají, ukáže až kombinace několika pohledů: kdo to je, co dělali ve formuláři, jak rychle jim stránka reagovala a co viděli na obrazovce. Claude je umí projít všechny sám, stačí mu je zadat.

Hlavní otázka, se kterou můžete začít:

Proč lidé odpadají v košíku? Udělej funnel po osobách od přidání do košíku po nákup, rozpad podle zařízení, operačního systému a prohlížeče uvnitř aplikace (Facebook, Instagram). Projdi kroky na stránce objednávky, naštvané klikání, rychlost stránek a rozbor 30 záznamů lidí, kteří nezaplatili. Porovnej s GA4 a dej mi seznam problémů seřazený podle dopadu.

Doplňující otázky:

Claude si sám najde, jaké události v projektu jsou, napíše dotazy v HogQL (SQL dialekt PostHogu), spočítá výsledky a zkontroluje součty. Rozbor záznamů čerpá kredity Replay Vision, proto ho nechávám vždy na vzorek 25–30 relací, které čísla označila jako problémové.

V dobré odpovědi má být u každého čísla období, zdroj a omezení. Když něco chybí, Claude má říct, že to neví, ne to dopočítat.

Krok 6: Z nálezů udělejte úkoly

Čísla sama nic neopraví. Poslední krok je převést nálezy na úkoly. U každého problému chci:

• co se děje jednou větou,
• kolika lidí se to týká a jak velký je rozdíl proti nejlepší skupině,
• důkaz: číslo z dat a ideálně záznam, kde je to vidět,
• návrh opravy,
• kdo to opraví: dodavatel obchodu, marketing, klient, nebo my.

Claude z toho složí dokument a prezentaci pro klienta a seřadí úkoly podle dopadu. Po opravách stačí stejnou analýzu spustit znovu a porovnat.

Co to vyřešilo u klienta

Klient prodává vstupenky online přes obchod externího dodavatele. Věděl, že z lidí, kteří si přidají vstupenku do košíku, nakoupí asi 42 %. Nevěděl, kde a proč se ztrácí zbytek. Po dvou týdnech dat a jedné analýze podle kroků 4–6 to bylo jasné.

Kde se lidé ztrácejí: na stránce objednávky, ne na platbě

Platební brána propustí 97 % lidí, takže není důvod ji řešit. Kdo začne vyplňovat formulář, ze tří čtvrtin nakoupí. Rozhoduje se mezi otevřením objednávky a prvním polem: 41 % lidí tam nezačne vůbec. Polovina z nich odejde do 10 sekund a většina se vrátí do výběru nebo vstupenky odebere. Chodí do objednávky zjistit celkovou cenu s poplatkem.

Kdo se ztrácí: Android a prohlížeč uvnitř aplikace

Typ zařízení (mobil vs počítač) skoro nerozhoduje. Rozhoduje operační systém a hlavně to, jestli člověk nakupuje v běžném prohlížeči, nebo uvnitř aplikace Facebook či Instagram. Z aplikací přišla pětina košíků, nakoupila ale jen pětina těchto lidí. GA4 to neodhalí, protože prohlížeč Facebooku na Androidu hlásí jako Chrome.

Nejlepší prohlížeč na iPhonu převede košík na nákup skoro šestkrát častěji než aplikace Instagram na Androidu.

Proč: osm konkrétních příčin

Největší překvapení byla rychlost. Stránka objednávky reaguje na Androidu na ťuknutí čtyřikrát pomaleji než na iPhonu, a Android přitom dělá skoro polovinu tržeb. Ostatní stránky obchodu jsou v pořádku.

I po vypnutí nahrávání záznamů zůstala odezva na Androidu nad hranicí (536 ms), takže zpomalení nejde jen za měřením.

1. Stránka objednávky je na Androidu pomalá – o 10 procentních bodů méně nákupů z objednávky než na iPhonu.
2. Celkovou cenu s poplatkem lidé vidí až v objednávce – proto 41 % nezačne vyplňovat.
3. Formulář napoprvé neprojde – na Androidu kliká na „Zaplatit“ opakovaně každý čtvrtý, nákup zastavovala kontrola telefonu a hláška, která neřekne, které pole chybí.
4. Prohlížeč uvnitř Facebooku a Instagramu – nakoupí 20 % lidí, v běžném prohlížeči 49 %.
5. Tři zaškrtávátka souhlasu – nejčastější místo naštvaného klikání v obchodě.
6. Dva typy produktů nejdou do jednoho košíku – obchod nabídne „Smazat aktuální košík a pokračovat“.
7. Vypršení rezervace během vyplňování.
8. Klik na platbu bez přesměrování – na Androidu tři lidé ze sta.

Co ukázaly záznamy

Claude nechal PostHog Replay Vision projít 30 záznamů lidí, kteří došli na objednávku a nezaplatili. Ze 27 skutečných odchodů bylo 15 porovnávání po zobrazení celkové ceny a 6 technická překážka (validace, nefunkční tlačítko, vypršená rezervace). Dva „odchody“ ve skutečnosti objednali převodem, který obchod do analytiky neposílá.

Co se tím vyřešilo

• Místo dohadů seznam osmi příčin s čísly, důkazy a vlastníky. Sedm z nich šlo jako zadání dodavateli obchodu, seřazené podle dopadu.
• Platební brána je v pořádku. Klient nemusí řešit výměnu brány, problém je o krok dřív.
• Marketing ví, co s reklamami na Metě. Lidé z Facebooku a Instagramu nakupují v prohlížeči aplikace a odcházejí. Doporučení: optimalizovat kampaně na nákup a dát cenu přímo do reklamy.
• Našly se díry v měření, které by jinak zkreslovaly reporty: záznamy se přestaly nahrávat, nákup převodem se neměřil a „začátek pokladny“ chodil až po kliknutí na platbu.
• Chyby v šabloně GTM odhalil test v náhledu dřív, než šly na živý web.
• Postup je opakovatelný. Po opravách se spustí stejná analýza a ukáže, jestli se čísla pohnula.

Na co si dát pozor

• Limit záznamů hlídejte sami. Po vyčerpání se nahrávání zastaví bez upozornění. Před prací se záznamy si nechte spočítat záznamy po dnech.
• PostHog a GA4 nebudou sedět. PostHog měří po souhlasu, GA4 i bez něj. Porovnávejte poměry a rozdíly mezi skupinami, ne absolutní počty.
• Některé události lžou. Ověřte si, kdy se která posílá. U nás „začátek pokladny“ chodil až po kliknutí na platbu a nákup převodem nechodil vůbec.
• AI se může splést. Pozorování ze záznamů je výklad modelu. Technické nálezy si nechte ověřit proti událostem a odhad dopadu vždy označte jako odhad s výpočtem.
• Malé skupiny nehodnoťte. Pod 30 lidí v segmentu je výsledek náhoda.

Všechna pravidla, celý recept na vyhodnocení košíku, 19 hotových dotazů a prompt pro rozbor záznamů najdete ve skillu pudeto-posthog. Stáhněte ho, doplňte svůj config a nahrajte do Claude.

Časté otázky