V předchozích dílech jsem psal, že log soubor popisuje komunikaci serveru s klientskými programy pomocí protokolu HTTP. Tuto podstatu vzniku log souboru je nutné mít neustále na paměti, protože může vnášet do následné analýzy poměrně vážné nepřesnosti. Cílem tohoto článku je upozornit na tyto nepřesnost pramenící z povahy log souboru, a naznačit způsob jejich řešení.
Vzhledem k tomu, že log soubory zaznamenávají všechny požadavky klienta na webový server, není jejich hrubá podoba příliš vhodná pro analýzu. Zatímco log soubor zaznamenává komunikaci všech klientů se serverem, my bychom obvykle rádi znali kompletní údaje o interakci jednoho konkrétního lidského uživatele se serverem v rámci jedné návštěvy. Abychom se co nejvíce přiblížili tomuto ideálu, je nutné si uvědomit nedostatky vyplývající z podstaty log souborů a snažit se je nějakým způsobem vyřešit či alespoň minimalizovat nepřesnosti vznikající v jejich důsledku.
Jak již bylo dříve řečeno, v log souboru jsou údaje o všech požadavcích, které byly učiněny klientem (browser, robot, atd.). Tedy nejen požadavky na html stránky, ale také požadavky na jejich součásti, jako jsou obrázky, externí JavaScript nebo kaskádové styly. Pro analýzu návštěvnosti jsou však v naprosté většině případů důležité pouze html stránky, popř. další soubory, které jsou poskytnuty uživatelům ke stažení (takovým souborem může být například produktový list v PDF).
Pokud víme, že nebudeme požadavky na obrázky a jiné doplňkové soubory potřebovat, můžeme logování těchto souborů zakázat podle koncovky nebo tyto požadavky můžeme logovat do jiného souboru. Ušetříme tak kapacitu disků i pozdější práci s filtrováním nepotřebných položek.
Kromě požadavků od lidských uživatelů zaznamenává log soubor také požadavky od robotů. Robot (nebo také bot, crawler či spider) je počítačový program, který prohledává internet a sbírá informace na základě obsahu stránek nebo provádí automatizované posuzování stránek z různých hledisek. Nejčastějšími roboty jsou roboti vyhledávacích strojů, ale jejich typů je daleko více. Za všechny můžu jmenovat například roboty pro online testování výkonu nebo roboty pro posuzování stránek (sem patří různé validátory, nástroje pro hodnocení on-page SEO faktorů, roboti kontrolující funkčnost odkazů a podobně)
Ačkoli mohou být údaje o přístupech robotů v určitých případech užitečné, je nutné je umět přístupy těchto „umělých uživatelů“ rozpoznat a vyloučit je v případě analýzy použití systému klasickými uživateli. Přístupy k rozeznávání robotů jsou v podstatě dva:
Cacheování je spolu s roboty největším zdrojem nepřesností při analýze log souborů. Cacheováním rozumíme ukládání kopií souboru na zařízení blíže k uživateli, které se provádí nejčastěji za účelem zvýšení výkonu. Zařízením, kde se cachuje obsah internetové prezentace může být například server ISP (Internet Service Provider) nebo disk uživatele, kam se ukládá tzv. browser cache. Pokud tedy uživatel prohlíží určitou stránku poněkolikáté neposílá již požadavek na původní server, ale využije cacheovanou stránku z jiného zařízení. Problém je zřejmý – pokud klient nepošle požadavek na server, nebude prohlížení této stránky zahrnuté v log souboru což může vést k poměrně velkým nepřesnostem.
Řešení tohoto problému je poměrně prosté, nicméně není úplně ideální. Pomocí hlaviček protokolu HTTP můžeme cacheování dokumentů zakázat. Používají se hlavičky cache-control, pragma, expires. Ve statickém HTML souboru lze zakázat cacheování pomocí elementu META
<HEAD>
<TITLE>Titulek stránky</TITLE>
<META HTTP-EQUIV="cache-control" CONTENT="no-cache">
<META HTTP-EQUIV="pragma" CONTENT="no-cache">
<META HTTP-EQUIV="expires" content="AKTUÁLNÍ DATUM A ĆAS">
</HEAD>Při použití dynamicky generovaných stránek zašleme hlavičky prostřednictvím příkazů konkrétního programovacího prostředí. Pokud jsem mluvil o nepřílišné ideálnosti tohoto řešení, musíme si uvědomit, že zakázáním cacheování zpomalíme načítání stránek. Klient totiž bude muset i při opakovaném dotazu na stejnou stránku dotazovat původní server.
Log soubor v rámci požadavku identifikuje IP adresu, ze které byl požadavek zaslán. My bychom při analýze návštěvnosti a její interpretaci nejraději vztahovali požadavky k unikátnímu návštěvníkovi naší prezentace. Bohužel, IP adresa nám pouze velmi nepřesně poslouží jako identifikátor unikátního návštěvníka a to zejména z následujících důvodů.
Proto se pro zpřesnění identifikace unikátního uživatele používá několik dalších mechanismů, které se liší v univerzálnosti použití a přesnosti.
| Metoda | Popis | Ohrožení soukromí | Výhody | Nevýhody |
|---|---|---|---|---|
| IP adresa + user-agent | Předpokládá, že každá unikátní kombinace IP adresy a user-agenta jako položek log souboru je unikátní uživatel. | Nízká | Vždy dostupná. Není nutná žádná další technologie. | Stále nepříliš přesná metoda. Je zhruba o 10% přesnější než samotná identifikace pomocí IP |
| Vložené session ID | Dynamicky generované stránky nesou v URL označení session ID. | Nízká až střední | Vždy dostupné. Nezávislé na IP adrese. | Nezachytí opakující návštěvy. Nepřehledný formát URL. |
| Registrace | Uživatel se registruje při použití internetové prezentace. | Střední | Identifikuje skutečně individuální osoby a ne pouze browsery. Dokáže identifikovat opakované návštěvy. | Mnoho uživatelů se nechce registrovat a chybí sledování předtím, než se zaregistrují. |
| Cookie | Uloží ID návštěvníka na klientský počítač. | Střední až vysoká | Identifikuje opakované návštěvy stejným browserem. | Uživatelé mohou mít vypnuty podporu cookies, mohou je smazat. |
| Software agent | Program načtený do browseru, který posílá zpět údaje o používání internetové prezentace. Toto je podstata získávání dat pomocí aktivního obsahu, která je rozebrána v samostatné kapitole. | Vysoká | Nejpřesnější údaje pro jednotlivé prezentace. | Uživatelé mohou blokovat spouštění těchto skriptů. |
Princip použití jednotlivých metod a jejich omezení je z tabulky zřetelně patrné. Musíme si uvědomit, co těmito metodami vlastně dokážeme zjistit a jak se naše zjištění může lišit od skutečného unikátního návštěvníka. Pomocí IP adresy a položky user-agent identifikujeme unikátní kombinace IP adresy, operačního systému a internetového prohlížeče. Zvláště ve firemním prostředí však může stejnou kombinaci těchto parametrů vykazovat i velký počet počítačů. Vložené session ID identifikuje v podstatě unikátní prohlížeč v rámci jedné návštěvy (session). S velkou pravděpodobností tak identifikuje skutečně jednoho fyzického návštěvníka, protože je málo pravděpodobné, že se uživatelé vymění u počítače v průběhu session. Tato přesnost je však vykoupena nemožností sledování opakovaných návštěv jednotlivých uživatelů. Cookies jako nejpoužívanější metoda identifikují v podstatě unikátní prohlížeče. Pokud stejný prohlížeč na stejném počítači používá více uživatelů, nedokážeme je nijak rozlišit. Registrace je jediná metoda, která dokáže přesně rozlišit unikátního fyzického uživatele. Nicméně její použití je velmi omezené, protože není jednoduché přimět uživatele k registraci na webu.
Pojmem session (či návštěva) rozumíme souhrn aktivit provedených jedním uživatelem od okamžiku vstupu na internetovou prezentaci až do okamžiku opuštění této prezentace. Pokud jsme pomocí některé výše uvedené metody identifikovali unikátního návštěvníka, lze mu poměrně snadno na základě log souboru přiřadit jím prováděné aktivity na internetové prezentaci. Často však potřebujeme zjistit, co vše uživatel provedl během jedné návštěvy. Proto provádíme rozdělení těchto aktivit do jednotlivých návštěv, neboli rekonstrukci sessions (v anglické literatuře se používá pojem sessionization). Klasickým přístupem ke rekonstrukci session je jejich oddělení určitou dobou neaktivity. Pokud je mezi požadavky uživatele doba delší než stanovená hranice, vytváří se nová session. Jako rozumná hranice pro rozlišení sessions pomocí časové mezery mezi požadavky se uvádí 30 minut.
Zadejte výraz pro vyhledávání
Tento web shrnuje teoretické základy analýzy návštěvnosti pomocí log souboru nebo pomocí aktivního obsahu (JavaScript tagů). Nové články jsou pravidelně publikovány.