OpenStats - analysis of collected data
In one of the previous articles the logging library was described - in this article we'll look into the library used to analyze the collected data, which basically means aggregation of the data according to various criteria. This library is not called directly from your application, but from the cron scripts provided. Nevertheless basic undertandning to it's "guts" is useful when configuring the analysis process. We'll look at the cron script and it's configuration.
Main file of this part is the OpenStats_Analysis library itself, i.e. the file lib/openstats_analysis.php. The functions defined in this file may be grouped into two groups - functions that may be used to update information about sessions (browser, country, ...) and functions aggregating data collected by the OpenStats_Logging library.
Updating of session information
No matter if you use postponed detection or if you detect all the information when creating the session, these functions are called:
- detectBrowser - detection of browser using the HTTP User-Agent header
- parseBrowserVersion - detection of browser version using the HTTP User-Agent header
- detectCountry - detection of country using the IP address
- detectArchitecture - detection of the architecture using the HTTP User-Agent header
- detectOperatingSystem - detection of operating system using the HTTP User-Agent header
These functions are quite simple - basically the HTTP User-Agent header is compared to regular expressions in tables Architectures, Browsers and Operating_systems (see the article about database structure of the OpenStats project), or using the IP address. In case of successfull browser detection, the version is detected too.
Aggregation of collected data
Main part of the functions for aggregation of collected data is just a rather simple SQL query, aggregating data from relevant tables (always Actions and Sections, sometimes joined with other tables), and inserts them into the prepared tables.
All the functions may aggregate data by all time intervals (month, week, day), and some of the functions do add another parameters (page, browser, OS, etc.).
Currently implemented functions are:
- buildGlobalStats - no additional parameters are used to aggregate the data
- buildStatsOfPages - data are aggregated according to pages (Actions.page_id)
- buildStatsOfActionTypes - data are aggregated according to action type (Actions.type_id)
- buildStatsOfBrowsers - data are aggregated by browser (Sessions.browser_id)
- buildStatsOfArchitectures - data are aggregated by architekture (Sessions.arch_id)
- buildStatsOfOperatingSystems - data are aggregated by operating system (Sessions.os_id)
It's not very difficult to implement other statistics, or extend existing ones (for example implementing aggregation by your own parameters).
All the listed function do have the same signature - these are the parameters:
- dateFrom - starting date (default value "now")
- dateTo - ending date (default value "now")
- buildDaily - build daily stats (default value "yes")
- buildWeekly - build weekly stats (default value "yes")
- buildMonthly - build monthly stats (default value "yes")
The first two parameters - starting and ending date - should be explained. These two parameters are used to limit the amount of analyzed data (applied to the Actions.action_date column), but not directly - the values are derived from the passed values for each time interval (daily, weekly or monthly).
- daily - from the beginning of the day containing dateFrom till the end of the day containing dateTo
- týdenní - from the beginning of the week containing dateFrom till the end of the day containing dateTo
- měsíční - from the beginning of the month containing dateFrom till the end of month containing dateTo
For example if the "dateFrom" is set to "2008-01-30 13:57:03" and "dateTo" is set to "2008-02-06 21:34:19" (resp. to the matching unix timestamps), these interval boundaries will be used:
| type | beginning date | ending date | comment |
|---|---|---|---|
| daily | 2008-01-30 00:00:00 | 2008-02-07 00:00:00 | 8 days |
| weekly | 2008-01-28 00:00:00 | 2008-02-11 00:00:00 | 2 weeks |
| monthly | 2008-01-01 00:00:00 | 2008-03-01 00:00:00 | 2 months |
The remaining three parameters (buildDaily, buildWeekly, buildMonthly) may be used to optimize the analysis. For example if you don't want to build weekly (or monthly) statistics until the week (or month) is over (and all the relevant data are collected), then you may disable them setting the buildWeekly (or buildMonthly) to false (see the next section).
Cron scripts
Cronový skript je sice jediný, ale má dva hlavní úkoly - zaprvé aktualizaci údajů o sessions (toto potřebujete pouze pokud využíváte možnost odloženého určování údajů), zadruhé vlastní agregaci dat. Kromě toho adresář "cron" obsahuje také konfigurační soubor, a jeho obsah tedy je:
- config.php - konfigurační soubor (spojení na databázi, apod.)
- run-analysis.php - aktualizace informací o sessions a vlastní agregace dat
Konfigurace je velmi jednoduchá - soubor cron-config.php obsahuje v podstatě pouze následující konstanty:
- DB_HOSTNAME - hostname pro připojení k databázi
- DB_PORT - port pro připojení k databázi
- DB_DATABASE - název používané databáze
- DB_USERNAME - jméno uživatele
- DB_PASSWORD - heslo uživatele
- UPDATE_SESSION_DATA - aktualizovat informace o sessions
- BUILD_DAILY - generovat denní data (výchozí hodnota "ano")
- BUILD_WEEKLY - generovat týdenní data (výchozí hodnota "ano")
- BUILD_MONTHLY - generovat měsíční data (výchozí hodnota "ano")
- BUILD_FINAL_DATA_ONLY - zpracovávat pouze data za skončená období (výchozí hodnota "ne")
Význam konstant s předponou "DB_" je myslím celkem zřejmý - jedná se o nastavení přístupu k databázi. Další proměnné se týkají vlastního generování statistik, přičemž význam voleb BUILD_DAILY, BUILD_WEEKLY a BUILD_MONTHLY je opět zřejmý již z jejich názvu. Pokud je volba UPDATE_SESSION_DATA nastavena na "ano" (true), budou před samotným generováním statistik zpracovány informace o sessions (detekce browseru, architektury, země, apod.).
Poslední volba BUILD_FINAL_DATA_ONLY je poněkud komplikovanější, a význam má zejména pro týdenní a měsíční statistiky. Standardní chování (BUILD_FINAL_DATA_ONLY = false) je takové, že jsou počítány i průběžné statistiky za ještě neskončené období, například v polovině měsíce (resp. týdne) budou vypočteny statistiky i za první polovinu měsíce (resp. týdne). Při příštím generování statistik jsou tato průběžná data smazána a znovu vygenerována, díky čemuž ale vznikají "dead tuples" (a tedy nutnost vacuování tabulek se statistikami).
Pokud je těchto odstraňovaných dat velké množství, může to způsobovat různé problémy (výkonnostní, při údržbě, apod.) takže pokud tyto průběžné statistiky nepotřebujete, negenerujte je. Stačí prostě nastavit "true" a statistiky budou generovány pouze za již skončená období (nikoliv za tento den, týden či měsíc).
