[Clarence]

Ursprungligen postat av Uzza

Låter detta som ett bra sätt att hantera besöksstatistik, eller är jag helt ute och cyklar?

Det verkar helt OK om syftet är att göra det smidigt. Om du däremot vill ha flexibilitet i framtida rapporter eller prestandaoptimering är det kanske inte optimalt.

För att få flexibilitet och kunna framställa godtyckliga rapporter med gammal data i framtiden kan man vilja spara rådata. Logga till en tabell med timme/dag/vecka/månad i namnet så är det lättare och effektivare löst att ta bort, rotera eller flytta gammal data.

Då loggning ska ha så lite påverkan som möjligt på livemiljön är det väldigt vanligt att spara loggningen denormaliserat och göra eventuell analys till en normaliserad modell i efterhand. I ditt fall skulle det innebära att alla tabeller förutom Visitor och VisitorDaily går bort. För att bara få fram datan i VistorDaily-tabellen räcker det med en enda SQL-fråga som kan köras dagligen istället. Roterar du dessutom statistiken per dag kan du i framtiden flytta gammal data till en bearbetningsserver som sköter rapporter och annat som vid hög trafik ofta blir tungt på en livemiljön.

[Uzza]

Ursprungligen postat av ITisGood.se

Du måste ju lägga in all trackingkod på alla sidor oavsett om du använder GA eller en egen lösning.
Enda anledningen till att inte använda GA är väl att man inte vill ge google så mycket information som jag ser det.
En stor fördel med GA är att man kan köra det asynkront så att det inte påverkar sidladdningshastigheten.

Jag använder ASP.NET, vilket gör att på serversidan så finns det en gemensam entrypoint för alla requests mot sidan, så all loggning ska ske där.
Där finns det heller inga som helst problem för mig att sätta upp ett asynkront jobb som hanterar loggningen, så det hindrar inte laddningen.

Ursprungligen postat av Clarence

För att få flexibilitet och kunna framställa godtyckliga rapporter med gammal data i framtiden kan man vilja spara rådata. Logga till en tabell med timme/dag/vecka/månad i namnet så är det lättare och effektivare löst att ta bort, rotera eller flytta gammal data.

Det jag sparrar i VisitorDaily är rådatan. Kolumnen "CompressedDetailedStatistics" är en GZippad XML struktur som innehåller all rådata. Just i tabellen så lagrar jag det som en Base64.

Tanken var dessutom att ha all statistik i en separat databas, så att den senare utan problem skulle kunna flyttas till en egen server etc, så att det inte påverkar huvudserverns prestanda.

[Clarence]

Ursprungligen postat av Uzza

Det jag sparrar i VisitorDaily är rådatan. Kolumnen "CompressedDetailedStatistics" är en GZippad XML struktur som innehåller all rådata. Just i tabellen så lagrar jag det som en Base64.

Tanken var dessutom att ha all statistik i en separat databas, så att den senare utan problem skulle kunna flyttas till en egen server etc, så att det inte påverkar huvudserverns prestanda.

Låter bra det. Tolkade det som att "CompressedDetailedStatistics" innehöll mer detaljer såsom besök per timme eller liknande. När du har en XML där är det dessutom rätt flexibelt att exportera i mindre delar för tyngre bearbetning med t ex Hadoop, om det nu någon gång kommer finnas behov för det.

Dock tror jag fortfarande att det vore bättre att logga endast denormaliserat. Att köra en extra select (alternativt insert som behöver läsa samma data) mot target-, referrer- och ip-tabellerna för varje sidvisning känns som onödig overhead. Desto effektivare blir det i längden att göra detta i omgångar. Givetvis förutsatt att du inte behöver denna information för att visa någonstans på sidan i realtid.

[Uzza]

Ursprungligen postat av Clarence

Låter bra det. Tolkade det som att "CompressedDetailedStatistics" innehöll mer detaljer såsom besök per timme eller liknande.

Kanske ska byta namnet till något bättre, som "CompressedDailyRawData".

Ursprungligen postat av Clarence

Dock tror jag fortfarande att det vore bättre att logga endast denormaliserat.

Tanken var att enklare kunna få tillgång till statistik över antal besök från ett visst ip/referrer.
Kommer troligtvis inte kolla på statistiken i realtid dock, så det kanske blir lite överflödigt. XML strukturen skulle samtidigt bli mycket enklare och mindre då.
Kommer nog ha kvar ip dock, eftersom jag tänkt använda GeoIPService för att få fram vilket land ip-adressen kommer ifrån.
Då känns det bäst att spara det i en tabell för sig så att anropet inte behöver göras flera gånger för varje ip, utan bara första gången den besöker sidan varje dag.

[Bjorne]

Vilket land kommer 127.0.0.1 ifrån? Clarence har rätt, det är effektivare att lagra data av den här typen denormaliserat och bearbeta den offline.