Přejít k obsahu  Přejít k hlavnímu menu

Firemní weblog poradenské společnosti H1.cz

Zobrazit všechny články
Zpět

Vyhněte se duplicitám při měření kampaní

Na svých školeních o měření návštěvnosti pomocí Google Analytics vnímám největší zájem o sledování kampaní. U všech nástrojů, které umí měřit kampaně, se postupuje velmi podobně – přidáváním speciálních parametrů do URL. Tím ale mohou vzniknout duplicitní URL a způsobit problémy nejen ve vyhledávačích. O měření kampaní pomocí Google Analytics se dočtete například v počeštěné nápovědě. Do češtiny je přeložený už i nástroj URL Builder, s jehož pomocí můžete snadno generovat unikátní URL. Z nich Analytics poznají, že jde o kampaň, a uloží vámi nadefinované hodnoty do správných statistik. Google Adwords zase umožňují zapnout tzv. autotagging, který do URL přidává trackovací parametry automaticky.

Duplicitní obsah

Více různých URL pro stejnou stránku znamená vznik duplicit se všemi důsledky z toho vyplývajícími. Roboti sice zpravidla přímo neindexují adresy, které vkládáme do PPC kampaní jako AdWords či Sklik. Váš „označkovaný“ odkaz si ale někdo může vložit na svůj web nebo do oblíbených položek v prohlížeči. Daleko větší riziko vzniká při umístění měřicích parametrů do skutečných odkazů, placených zápisů v katalozích, k bannerům apod. Tyto odkazy vyhledávače najdou, zaindexují a později je najdete ve výsledcích hledání. Občas se dokonce zaindexuje i již zmiňované automatické taggování z Google Adwords. Kromě klasických SEO problémů vám s největší pravděpodobností vznikne nepořádek ve statistikách. Když někdo na takový označkovaný odkaz klikne, Google Analytics to vyhodnotí jako přístup z kampaně. Pokud se taková stránka umístí ve výsledcích hledání některého hledaného slova na dobré pozici, můžete se se smysluplnými čísly rozloučit úplně.

Řešením je přesměrování či mřížka

U klasických systémů založených na analýze serverových logů lze problém duplicit vyřešit okamžitým přesměrováním na základní variantu URL bez měřicího parametru. Takto to má vyřešeno například Megapixel. Po prokliknutí odkazu www.megapixel­.cz/?from=h1blog se toto URL i s parametrem uloží do logu. Následně je uživatel či robot pomocí HTTP 301 odpovědi automaticky přesměrován na správnou základní adresu www.megapixel.cz. Podrobněji je tento postup popsán ve starším článku Vyhodnocování účinnosti on-line kampaní. Google Analytics ale měří pomocí JavaScriptu až v prohlížeči. Měřicí parametry utm_source a utm_medium se tak nemohou přesměrovávat bez náhrady. Proto existuje alternativa, která je z hlediska SEO bezproblémová. Do konfiguračního skriptu Google Analytics (nebo do každé stránky před funkci pagetracker._trac­kPageview();) se vloží nastavení pageTracker._se­tAllowAnchor(tru­e);. Pokud používáte náš upravený měřicí skript, nemusíte přidávat vůbec nic, skript toto volání zajišťuje automaticky. Potom můžete vkládat měřicí parametry za mřížku #místo otazníku. Roboti část URL za mřížkou zcela ignorují, takže se touto cestou bezpečně vyhnete duplicitám.

Mřížka vs. Internet Explorer

Buďte ale obezřetní, kde mřížku používáte. Internet Explorer ji totiž při některých přesměrováních odstraní. Paradoxně jej odstraní právě u prokliků z AdWords nebo AdSense, kde nedochází ke standardnímu přesměrování přes HTTP hlavičku 301. To může naměřená čísla významně pokřivit. Naše řešení problému spočívá v tom, že se měřicí parametry utm_source, utm_medium a další předávají standardně za otazníkem, ale na serveru se přesměrují na variantu s křížkem. Roboti vyhledávačů tedy duplicitu nezaznamenají, parametr přitom bez problému projde všemi neočekávanými přesměrováními až k měřicímu skriptu Google Analytics. Dodatečnou výhodou je i fakt, že pak můžete sledovat své kampaně najednou pomocí systémů založených na analýze logů i na měřicí tečce či JavaScriptu. Přesměrování z otazníku na křížek můžete zařídit snadno pomocí mod_rewrite. Stačí vložit do vašeho .htaccess souboru následující pravidla – aktualizováno 24. ledna 2009: /---code RewriteEngine On RewriteCond %{QUERY_STRING} ^(utm_.)$ RewriteRule ^(.)$ /$1#%1? [R=301,NE,L] RewriteCond %{QUERY_STRING} ^(.?)&(utm_.)$ RewriteRule ^(.)$ /$1?%1#%2 [R=301,NE,L] \--- Pozor, pro správnou funkčnost těchto pravidel je nutné mít na serveru Apache 2.x! Pokud máte starší verzi Apache 1.x, nebudou pravidla fungovat. V takovém případě můžete jako náhradní nedokonalou berličku použít alespoň následující původní pravidla z první verze tohoto článku, která však mají některé nevýhody: /---code RewriteEngine On RewriteCond %{QUERY_STRING} ^(.+)&(utm_sou­rce=.+&utm_me­dium.+|utm_me­dium=.+&utm_sou­rce=.+)$ RewriteRule ^(.)$ /$1?%1#%2 [R=301,NE,L] RewriteCond %{QUERY_STRING} ^(utm_source=­.+&utm_medium=­.+|utm_medium=­.+&utm_source=­.+)$ RewriteRule ^(.*)$ /$1#%1? [R=301,NE,L] \--- Přestože jsme všechna pravidla testovali, může být u vašeho webu nutná nějaká úprava. Na IIS/ASP je nutné tuto záležitost řešit jinak. Víte-li o řešení, které by fungovalo, budeme rádi, pokud se o ně s námi podělíte v komentářích.

 

Autorem článku je Roman Appeltauer.

  • Martin
    20. 12. 2007 / 13:46

    Ještě lepší je měřící kód s otazníkem přesměrovaný na běžnou adresu, která ovšem ví, že je cílem přesměrování a příslušný klik pošle Googlu vlastním skriptem v onload.

  • Roman
    20. 12. 2007 / 15:04

    [1] Martine, testoval jste to?

    My jsme si s touto myšlenkou pohrávali už dávno kvůli měření v GA i ClickTracks. Mám ale pocit, že by to byla už dost geekovina, příliš náročné na implementaci a byla by velká pravděpodobnost, že při nasazování řešení někdo udělá chybu.

    IMHO by se před spuštěním funkce urchinTracker nebo nové _trackPageview(); musela vytvořit nějaká simulace toho, že ty parametry v URL jsou, aby si to Google Analytics zpracoval sám.

    Krom toho by musel existovat skript na straně serveru, který by to zajistil. Takový skript by zase do některých CMS nešel vůbec zakomponovat, přišli bychom tak o jednoduchost implementace a využitelnost pro širokou veřejnost.

    Už ty 4 řádky do .htaccess může být někdy docela komplikované vložit správně.

  • Jan Brašna
    20. 12. 2007 / 23:32

    Možná budu mlžit, ale pokud mě paměť neklame, zaslaná 301 ze serveru (v HTTP hlavičce Location) podle RFC nesmí obsahovat #hash část.

    Což nepopírá funkčnost, kolikrát už jsem to používal … ale nemusí to být funkční v úzkostlivých implementacích UA.

  • Roman
    21. 12. 2007 / 03:47

    [3] Honzo, nemlžíš :)

    Nemá to tam co dělat, ale funguje to narozdíl od přesměrování přes 302 a jiných ještě obskurnějších. :) Naším cílem je hlavně vyřešit ten zpropadený IE, který defaultně tuto praktiku „pobere“.

    Úzkostlivé UA nám ve statistikách udělají chybu srovnatelnou s normální statistickou chybou. A to je furt míň, než co napáchá IE :)

  • Jan Brašna
    21. 12. 2007 / 14:41

    [4] To zní fér, díky za info.

  • Josef Richter
    11. 06. 2009 / 04:16

    jestli se nepletu tak tento problém je v současnosti už vyřešen použitím link canonical? viz. http://googlewebmastercentral.blogspot.com/…nonical.html

  • Jan Tichý
    13. 06. 2009 / 11:25

    [6] Pletete. Link canonical by neměl sloužit k ošetření stoprocentních duplicit, ale jen podobností, viz článek http://blog.h1.cz/canonical/. Není navíc zdaleka podporován všemi vyhledávači, například Seznamem. A v neposlední řadě sice možná řeší SEO dopady, ale už se vůbec neohlíží na ostatní negativa duplicit, typicky v oblasti použitelnosti, webové analytiky apod.

  • Jakub Mahdal
    19. 06. 2009 / 11:53

    Není řešením disallow v robot.txt? Viz. GA diskuze.

RSS feed komentářů k tomuto článku
RSS feed komentářů ke všem článkům



(nebude zveřejněn)



Položky označené * jsou povinné