Pokud si otevřete libovolný report v Looker Studiu napojený na Google Analytics 4, téměř jistě narazíte na tabulku zdroj / médium. Lidově řečeno: odkud přišla návštěvnost na váš web.

Pro většinu marketérů, webových analytiků a majitelů webů je to jeden ze základních pohledů. Jenže právě tady často vzniká nenápadný, ale zásadní problém: pokud toto není ošetřeno, tak jeden reálný zdroj návštěvnosti se v datech rozpadá do několika různých položek. A analyzovat cokoliv na takto rozpadlých číslech přestává dávat smysl.

Facebook: jeden zdroj, pět různých řádků v reportu

Dobře je to vidět například na Facebooku. Návštěvnost z něj přichází jak z organických příspěvků, tak z reklam. Člověk by logicky očekával dvě položky. Realita je ale o něco chaotičtější. Pokud se podíváte na referral návštěvnost zFacebooku, zjistíte, že se neobjevuje jen jako facebook / referral, ale i pod dalšími variantami domén a subdomén, které se v datech tváří jako samostatné zdroje:

• web.facebook.com
• m.facebook.com
• l.facebook.com
• lm.facebook.com
• fb.me

Instagram a Pinterest: stejný problém, jiná forma chaosu

Úplně stejný princip funguje i u dalších platforem, jako je Instagram nebo Pinterest. Pokud si projdete všechny zdroje do konce, tak nalezete instagram rozpadlý do:

• instagram.com
• l.instagram.com
• m.instagram.com

U Pinterestu je tenhle problém ještě viditelnější. Platforma používá lokalizované domény podle jednotlivých zemí, takže se v GA4 a Looker Studiu setkáte s celou řadou variant, například:

• at.pinterest.com
• ch.pinterest.com
• cl.pinterest.com
• co.pinterest.com
• dk.pinterest.com
• es.pinterest.com
• hu.pinterest.com

Heureka v GA4: výkon rozházený napříč subdoménami

Nebo český srovnávače produktů Heureka. Ta kromě logického heureka.cz / refferer posílá návštěvnost podle jednotlivých kategorií Heureky. A tak v GA4 můžete vidět něco podobného:

• domov.heureka.cz / referral
• zahrada.heureka.cz / referral
• nacini.heureka.cz / referral

Facebook Ads: paid, cpc, paid_social… a nikdo neví proč

To jsme se zatím věnovali neplacené návštěvnosti, tak pojďme se kouknout na moje oblíbené značkování Facebookových reklam. Zde není ustanovený obecný vzor pro UTM parametry a proto zde člověk může vídět spoustu různých variant. Občas to přechází do extrému, kdy v rámci jednoho účtu běží několik kampaní s různým značkováním.

• facebook / paid
• facebook / cpc
• fb / cpc
• facebook / paid_social
• facebook / reklama
• meta / cpc

Nebo když firma změní Facebook specialistu a nový FB specialista rovnou rozjede svůj vlastní styl značkování kampaní.

Case sensitivity: jeden newsletter rozpadlý na tři kanály

Dalším typickým příkladem je case sensitivity v Google Analytics 4. Lidově řečeno: malá a velká písmena nejsou totéž. A právě u UTM parametrů se tak může stát, že vám do GA4 dorazí následující varianty zdrojů návštěvnosti:

email / newsletter
email / Newsletter
email / NEWSLETTER

Všechno je to jeden označený zdroj pomoci UTM parametrů, ale kvůli tomu, že daný člověk použil (často v dobré víře) různou velikost písmen, tak je Google rozdělil do různých zdrojů. To má zá následek rozpad výkonů newsletterů do 2+ kanálů a bez spojení zase nedáme daná čísla dohromady.

Jak z chaosu ve zdrojích udělat pořádek

Problém jsme si popsali, teď přichází ta lepší část — řešení. A to je překvapivě jednoduché. Stačí sáhnout po vypočítaném poli (ano, ten český překlad calculated field není dobrý) a jednotlivé rozpadlé kanály si spojíme dohromady.

Přeloženo do řeči webových analytiků: data normalizujeme / očišťujeme.

Proto příště místo sáhnutí po metrice session source / medium zvolíme vypočítané pole (calculated field) a začneme do něj psát SQL výraz podle potřeby.

Ten může vypadat například takto. Základ vždy tvoří konstrukce CASE, na kterou navazují jednotlivé podmínky WHEN … THEN. V překladu: pokud se zdroj / médium rovná určité hodnotě, přepiš ho na jinou. Na konci je dobré doplnit i podmínku ELSE, která určuje, co má Looker Studio udělat s hodnotami, které nesplní žádnou z předchozích podmínek. Nejčastěji se jednoduše ponechají beze změny.

Kvůli case sensitivitě doporučuji používat funkci LOWER(), která převede všechna písmena na malá. Součástí výrazu je také regex, což je strašák pro spoustu lidí, ale ve skutečnosti není čeho se bát. S pomocí ChatGPT se dnes dá zvládnout velmi slušně, i když i tak doporučuji načíst si alespoň základy. Budou se hodit častěji, než se může zdát.

Je také dobré mít na paměti, že Looker Studio vždy použije první podmínku, která vyhoví, a další už nevyhodnocuje. Toho se dá při návrhu SQL výrazu dobře využít a mít nad logikou sjednocování plnou kontrolu.

A ještě drobná poznámka k zápisu: — slouží k přidávání komentářů k jednotlivým částem výrazu, což se hodí hlavně u složitějších CASE struktur.

CASE

-- ukázka očištění špatně značené Facebook / Meta kampaně

WHEN `session source / medium` IN (
  "facebook / cpc_paid",
  "facebook / paid",
  "fb / cpc",
  "meta / cpc"
) THEN "facebook / cpc"

-- ukázka očištění Facebook referreru

WHEN REGEXP_CONTAINS(
  LOWER(`session source / medium`),
  "(^|\\.)facebook\\.com.*referral"
)
THEN "facebook / referral"

-- ukázka očištění Instagram referreru

WHEN REGEXP_CONTAINS(
  LOWER(`session source / medium`),
  "(^|\\.)instagram\\.com.*referral"
)
THEN "instagram / referral"

-- ukázka očištění Pinterest referreru

WHEN REGEXP_CONTAINS(
  LOWER(`session source / medium`),
  "(^|\\.)pinterest\\.com.*referral"
)
THEN "pinterest / referral"

-- ukázka očištění Heureka referreru

WHEN REGEXP_CONTAINS(
  LOWER(`session source / medium`),
  "(^|\\.)heureka\\.cz.*referral"
)
THEN "heureka / referral"

WHEN REGEXP_CONTAINS(
  LOWER(`session source / medium`),
  "(^|\\.)heureka\\.cz.*cpc"
)
THEN "heureka / cpc"

-- ukázka očištěného e-mailingu

WHEN REGEXP_CONTAINS(
  LOWER(`session source / medium`),
  "(email|newsletter|mailchimp|ecomail|sendgrid)"
) THEN "email / newsletter"

-- ukázka očištěného (not set)

WHEN `session source / medium` IN (
  "(direct) / (none)",
  "(not set) / (not set)"
) THEN "(direct) / (none)"

-- pravidlo pro zbývající kanály

ELSE LOWER(`session source / medium`)
END

V uvedeném SQL výrazu používám jen několik obecných příkladů. V praxi je vždy dobré si je přizpůsobit vlastním potřebám a konkrétním datům. Pokud si s tím nechcete lámat hlavu, klidně mi napište, rád pomůžu nejen s tímto konkrétním výrazem.

Slova na závěr

Jakmile si zdroje návštěvnosti tímto způsobem očistíme, můžeme se konečně soustředit na to podstatné — samotnou analýzu. Budeme mít jistotu, že Facebook se v přehledech neobjevuje třikrát pod různými názvy a že Heureka je sjednocená bez ohledu na použité subdomény.

Na závěr jeden praktický tip: doporučuji mít na skrytém listu (nebo mimo hlavní zobrazovanou část reportu) jednoduchý přehledový graf s původními zdroji návštěvnosti a jejich očištěnou variantou. Stačí ho čas od času zkontrolovat a rychle tak ověřit, že všechno funguje přesně tak, jak má.