Matomo a Sentry: napojení, co umí a proč je používat spolu

Google Analytics řekne, kolik lidí na web přišlo a kam klikli. Neřekne vám, proč třetina z nich zmizí uprostřed registrace — a vůbec neřekne, jestli za tím je špatný design, nebo prostě bug, který formulář neodeslal. Proto do auditů kromě GA zapojuji ještě dva nástroje: Matomo a Sentry.

Zvlášť toho umí každý trochu jiné věci. Spolu ale odpoví na otázku, kterou si klienti pokládají nejčastěji: je to problém designu, nebo problém kódu? A bez dat na to člověk jen hádá.

Matomo — co umí a jak ho napojit

Matomo je analytický nástroj podobný Google Analytics — měří návštěvy, chování a cesty uživatelů. Rozdíl je ve dvou věcech: kde data zůstávají a jak detailně vidíte jednotlivé relace.

• Visits a Unique Visitors — kolik návštěv proběhlo a kolik bylo skutečně různých lidí.
• Bounce rate a Exit rate — kde uživatelé odcházejí hned po příchodu, a kde odcházejí po libovolném počtu kroků.
• Actions per visit a Average visit duration — jak moc se s webem nebo appkou skutečně pracuje, ne jen prokliká.
• Page performance — kolik trvá načtení jednotlivých stránek (pod 1 s výborné, nad 3 s problém).
• Session replay / transitions — co se dělo před vstupem na stránku, na ní, a po odchodu z ní.

Napojení je stejné jako u Google Analytics: Matomo vygeneruje krátký trackovací kód, který se vloží do hlavičky webu, před uzavírací tag </head>. Matomo lze provozovat jako Matomo Cloud (placená správa, nic se neřeší) nebo self-hosted na vlastním serveru — a to je klíčový rozdíl oproti GA: data nikdy neopustí vaši infrastrukturu ani EU. Pro veřejnou správu, zdravotnictví nebo finanční služby to často rozhoduje, jestli analytiku můžou vůbec použít.

Jedna věc, kterou Matomo nevyřeší o nic líp než GA: cookie lišta a adblocky. Pokud uživatel sledování odmítne nebo mu ho blokuje prohlížeč, v datech ho neuvidíte. Je to limit, se kterým je potřeba počítat při každé interpretaci čísel — ne důvod data nepoužívat, ale důvod nevěřit jim na sto procent.

Sentry — co umí a jak ho napojit

Sentry sleduje úplně jinou vrstvu: ne co uživatel chtěl udělat, ale co se technicky stalo, když to zkoušel. Zachycuje chyby, výjimky a výkon aplikace v reálném provozu — tedy přesně to, co se v Matomu nebo GA neukáže nikdy.

• Errors / Issues — konkrétní chyby a výjimky, seskupené podle typu, s počtem postižených uživatelů.
• Error rate a crash-free rate — jak stabilní je aplikace v čase, podle verze, prohlížeče nebo zařízení.
• Výkon (p95 / p99 latence) — jak rychlá je aplikace pro 95 %, resp. 99 % uživatelů (průměr tady zavádí, extrémy bolí nejvíc).
• Core Web Vitals — LCP (jak rychle se vykreslí hlavní obsah), FCP (kdy se objeví první viditelný obsah), INP (odezva na kliknutí) a CLS (jak moc stránka při načítání "skáče").
• Session Replay — záznam toho, co uživatel na obrazovce skutečně dělal těsně před tím, než nastala chyba.

Napojení probíhá přes SDK přímo v kódu aplikace — pro Next.js existuje balíček s průvodcem nastavením, u jiných frameworků podobně. Po instalaci appka sama hlásí chyby, které potkávají reálné uživatele, včetně prohlížeče, stránky a akce, při které k nim došlo. Žádné čekání, až se někdo ozve podpoře.

Orientační čísla, podle kterých se Core Web Vitals obvykle hodnotí:

• LCP (vykreslení hlavního obsahu): do 2,5 s dobré, 2,5–4 s zhoršené, nad 4 s špatné.
• INP (odezva na interakci): do 200 ms dobré, 200–500 ms horší, nad 500 ms uživatel cítí lag.
• CLS (stabilita layoutu): do 0,1 dobré, 0,1–0,25 zhoršené, nad 0,25 frustrující — typicky obrázky bez rozměrů, pozdě načtené fonty nebo dynamický obsah, který posune zbytek stránky.

Proč je mít obě — a ne jen jednu

Matomo a Sentry se vzájemně doplňují přesně tam, kde je každý z nich sám o sobě slepý. Matomo vidí, co uživatel na webu dělal — ale neví, že mu v tu chvíli appka spadla. Sentry vidí, že appka spadla — ale neví, co uživatel dělal pět minut předtím.

Bez propojení obou systémů víte buď příčinu, nebo kontext. Nikdy obojí najednou.

Řešení je jednoduché na popis, a nenáročné na implementaci: Matomo generuje unikátní ID relace (visit ID) pro každou návštěvu. Totéž ID se předá do Sentry jako kontextový tag (typicky session_id). Ve chvíli, kdy Sentry zachytí chybu, máte u ní i odkaz na konkrétní relaci v Matomu — a můžete si přehrát přesně to, co uživatel dělal, než appka spadla.

V praxi se k tomu přidává ještě jedna vrstva — tagy, které popisují kontext dění, ne jen to, že k němu došlo:

• user_id / role — komu se to stalo a jakou má roli (admin, zákazník, specifická agenda).
• screen / action — kde v aplikaci k tomu došlo a co uživatel zrovna dělal (např. odesílání formuláře, schvalování).
• module / feature — která část systému je zasažená.
• session_id — spojnice mezi Sentry a session replayem v Matomu.

Dohromady to odpoví na otázku, kterou si klient klade jako první: komu se to stalo, kde, při čem, a proč to spadlo.

Scénář z praxe

V Sentry se objeví chyba. Sama o sobě jen řádek v seznamu — nevíte, jestli je drobná, nebo blokuje stovky lidí v práci. S propojenými daty vypadá rozbor takto:

• Kdo: uživatel s rolí „schvalovatel" v konkrétním modulu systému.
• Kde: krok 3 z 5 ve formuláři schválení (screen: approval_flow).
• Co dělal: klikl na tlačítko „Odeslat ke schválení" (action: submit_approval).
• Co se stalo: aplikace zamrzla na 5 sekund (p99 latence nad 3 s), následně bílá obrazovka.
• Důkaz: v session replay vidíte, že uživatel kliknul třikrát, než appka spadla — frustrace, ne náhoda.

Bez propojení dat tahle chyba zůstane jedna z mnoha v backlogu. S propojenými daty je jasné, že blokuje dokončení konkrétního kroku pro konkrétní typ uživatele — a že stojí za přednostní opravu. A protože víte, komu se to stalo, můžete se ozvat dřív, než se ozve on podpoře.

Co si z toho odnést do UX auditu

Analytika a error tracking nejsou nahraditelné intuicí, ale ani jedna vrstva samotná nestačí. Heatmapy a session replay (ať z Matoma, nebo třeba z Hotjaru) ukážou, kde uživatelé zaváhají. Sentry ukáže, jestli za tím zaváháním je skutečně špatný design — nebo jen chyba v kódu, kterou žádný redesign nevyřeší.

Když dělám UX audit, obě vrstvy čtu vedle sebe právě z tohoto důvodu: data z chování ukážou problém, data z chyb ukážou, jestli je problém designový, nebo technický. Doporučení, které vznikne z obou najednou, se pak neopírá o odhad, ale o to, co se na webu skutečně děje.