Hlavní navigace

Obsahují webové logy bohatství?

30. 1. 2002
Doba čtení: 5 minut

Sdílet

Logový soubor webového serveru (HTTP, SHTTP a FTP) a clickstream analýza tvoří nerozlučný pár. Soubor s logy neobsahuje všechny informace pro analýzu, ale podstatné v něm obsaženy jsou. A protože je soubor logů snadno dostupným zdrojem dat, bývá nástroji pro clickstream analýzu často a poměrně úspěšně používán.

Soubor s logy je v podstatě pouhým referenčním záznamem o uživatelské aktivitě, který je generován webovým serverem. Obsahuje záznamy uživatelských požadavků na daný server spolu s dalšími doplňkovými informacemi. Původním standardem pro logové soubory je standard Common Log Format (CLF), definovaný internetovým konsorciem W3C, který obsahuje sedm základních datových položek. Jako jeho rozšíření byl posléze dodefinován takzvaný Extended Common Log Format (ECLF), kde k původním položkám přibyly další dvě. Dle W3C jsou položky logu označovány: remotehost, rfc931, authuser, date, request, status, bytes, referrer, user_agent. Rozebereme si podrobněji význam jednotlivých položek pro clickstream analýzu.

Remotehost je internetová adresa prohlížeče nebo jiné uživatelské aplikace, komunikující jako klient s webovým serverem. Nejčastěji nabývá podoby číselné IP adresy, případně doménového jména, provádí-li server zpětný překlad IP adresy. Tato činnost ovšem při vekém objemu záznamů pro překlad představuje pro server nežádoucí zátěž. Proto je účelné provádět zpětný překlad během ETL zpracování logového souboru. Doménové jméno indikuje více informací o uživateli než jeho IP adresa, typicky je z něj možno určit národní doménu 1. úrovně nebo např. poskytovatele internetového připojení, prostřednictvím kterého se uživatel připojuje k Internetu. IP adresa nebo doménové jméno představují pro clickstream analýzu základní údaj k identifikaci návštěvníka webového serveru. Většina klientských počítačů připojujících se k Internetu však nemá pevnou, nýbrž dynamicky přidělovanou IP adresu. Taková adresa samozřejmě není spolehlivým identifikátorem uživatele, zejména chceme-li odhalit jeho opakované návštěvy na serveru. Důležité je, že se dynamická adresa uživatele nemění během jeho aktuálního připojení, takže je možno jednotlivá připojení správně analyzovat. Ke spolehlivější identifikaci uživatelů se používají techniky založené na cookies nebo na unikátních identifikátorech uživatelských připojení, generovaných webovým serverem.

Nejspolehlivější „technikou“, jak identifikovat uživatele, je jeho přihlášení k serveru pod uživatelským jménem (a heslem). Tento způsob lze z pochopitelných důvodů použít jen v omezené míře, protože není možné nutit uživatele k přihlášení (a jemu předcházející registraci), neodpovídá-li tomu povaha obsahu či účel aplikace na serveru. Pokud existuje na webovém serveru možnost přihlášení (v rámci možností protokolu HTTP), bude položka logu authuser obsahovat přihlašovací jméno, kterým se uživatel úspěšně přihlásil na daný server. Pro další analýzu je to cenná uživatelská informace. Položku logu rfc931 vynecháváme, její přínos pro analýzu a frekvence jejího používání servery je zanedbatelná.

Položka date je důležitou informací pro analýzu průchodu webovou aplikací na serveru. Obsahuje datum a čas vzniku požadavku nebo datum a čas vyřízení požadavku – záleží na specifikaci konkrétního serveru. Čas požadavku, resp. časový rozdíl mezi jednotlivými požadavky je cennou informací o tom, jakou pozornost věnují uživatelé obsahu aplikace na webovém serveru. Současně představuje klíč definující chronologii průchodu uživatele jednotlivými obrazovkami na serveru. Jistě je možno namítnout, že chronologie průchodu je přesně určena pořadím záznamu v souboru s logy. To však není vždy pravda. Je-li online aplikace provozována na více počítačových serverech, pak každý server generuje svůj vlastní soubor s logy. Tak se snadno může stát, že jsou záznamy průběhu připojení na aplikaci rozloženy do několika souborů. Obsah těchto souborů je nezbytné spojit a posoudit jednotlivá připojení v rámci zpracování pomocí ETL nástrojů. Abychom mohli spojit různé logované záznamy aktivit podle času, musíme zajistit přesnou časovou synchronizaci jednotlivých serverů. Položka date se ukládá s přesností na jednu vteřinu, ale synchronizaci je nutno provést přesněji, alespoň na jednu desetinu vteřiny. Naprosto nevypočitatelným faktorem je přechod serverů na letní čas. Ačkoli se to může jevit jako banální problém, ve skutečnosti způsobuje nekonzistence v datech, jejichž důsledkem je nekorektnost výsledků clickstream analýzy. Pro úspěšnou analýzu nelze tedy přechod na letní čas doporučit.

Uživatelský požadavek na server je v logu zaznamenán jako request. Představuje popis metody protokolu HTTP (GET, POST), neboli akce, jež je požadována klientem. Za záznamem metody v položce request následuje URL adresa požadovaného objektu (stránky, obrázku apod.) a popis verze protokolu HTTP podporovaného klientem. Metoda POST je pro analýzu obzvlášť zajímavá, neboť signalizuje přítomnost dodatečných informací odeslaných na server. Za přínosná se považují zejména klíčová slova zadávaná při vyhledávání nebo parametrické informace webové aplikace související s navigací. URL klientského požadavku pak jednoznačně udává cestu průchodu serverem při jednom připojení. Některé webové servery umožňují vypnout ukládání záznamů o přístupech na jiné než HTML stránky – jde zejména o záznamy přístupů na grafické objekty. Tato možnost může být užitečná pro zmenšení objemu souboru s logy, mnohdy je však důležité ukládat i tyto záznamy.

Položka status má pro clickstream analýzu minoritní přínos, má význam především pro odhalování chyb v konzistenci aplikace na serveru. Obsahuje kód, který server vrací klientovi v reakci na jeho požadavek (např. 404 Not Found). Počet bytů vracených serverem v bytes je mimo náš zájem, což ale neplatí o položce referrer. Ta byla přidána do HTTP protokolu verze 1.0, aby umožnila zpětně vystopovat původní webový server, ze kterého byl iniciován požadavek request. Krátce řečeno: jde o URL adresu v rámci cizího serveru. Položka byla přidána, aby bylo možno zaznamenávat informace o spolupráci jednotlivých webových serverů. S výhodou lze tyto informace využít pro posouzení (vyhodnocení) reklamních kampaní provozovaných na cizích serverech (reklamních systémech). Položka referrer také poskytuje cenné informace o efektivitě zobrazení odkazů na náš webový server v internetových katalozích a vyhledávačích. Rovněž znalost původního serveru, navštíveného uživatelem, poskytuje dodatečnou informaci o uživatelově identitě. User_agent je položka identifikující klientskou aplikaci komunikující se serverem. Podle ní je možno zjistit typ prohlížeče nebo operačního systému uživatele, stejně jako skutečnost, že nás navštívil indexovací robot internetového vyhledávače typu Altavista, Google a jiných.

BRAND24

I když se může zdát, že máme všechny nezbytné informace pro analýzu k dispozici v souboru s logy, není tomu tak. Omezení metody je dáno skutečností, že tyto soubory nejsou určeny k tomu, aby zaznamenávaly interakce uživatelů a jejich klientských aplikací s webovým serverem, ale pouze požadavky klientských aplikací na server. Zcela nám chybí informace o tom, zda-li byl požadovaný objekt úspěšně doručen klientovi a zobrazen v prohlížeči. Tato informace je podstatná pro přesnou rekonstrukci uživatelské zkušenosti z návštěvy serveru a log představuje pouze více či méně přesnou aproximaci této zkušenosti. Přestože existuje mnoho dalších proprietárních logových formátů pro webové servery, je jejich obsah implicitně omezen obsahem informací samotného HTTP protokolu. A tak nezbývá, než se spokojit s možnostmi logu nebo se poohlédnout po náročnějším zdroji clickstreamových dat. A pokud vás dnes nechává clickstream analýza chladnými, nezahazujte i tak logové soubory, jednou se vám mohou hodit.

V dalším článku se podíváme na metody odposlechu síťové komunikace mezi prohlížečem a webovým serverem a jeho možnosti v clickstream analýze.

Byl pro vás článek přínosný?

Autor článku

Autor je systémovým analytikem pro oblast datových skladů a ETL zpracování dat. Rovněž se zabývá problematikou moderních analytických postupů v BI a CRM systémech.
Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).