WN - Spara besöksstatistik i databas (C#, MySQL)

WN (https://www.wn.se/forum/index.php)

- Serversidans teknologier (https://www.wn.se/forum/forumdisplay.php?f=4)

- - Spara besöksstatistik i databas (C#, MySQL) (https://www.wn.se/forum/showthread.php?t=1042632)

Spara besöksstatistik i databas (C#, MySQL)

Jag håller på att bygga upp en egen site och ska spara statistik över alla som besöker sidan.
Jag är dock lite osäker på hur jag bygger upp strukturen på bästa sätt, så jag skulle vilja få lite feedback på hur jag tänkt mig det ska fungera.

Då jag är .NET utvecklare har jag byggt upp följande domänmodell för att representera tabellerna databasen:

Kod:

    public class Visitor : EntityWithTypedId<long>

    {

        public virtual DateTime Time { get; set; }

        public virtual string UserAgent { get; set; }

        public virtual string OS { get; set; }

        public virtual bool IsSpider { get; set; }



        public virtual VisitorIP Ip { get; set; }

        public virtual VisitorTarget Target { get; set; }

        public virtual VisitorReferrer Referrer { get; set; }

    }



    public class VisitorIP : EntityWithTypedId<long>

    {

        public virtual string Ip { get; set; }

        public virtual string CountryCode { get; set; }

        public virtual int Count { get; set; }

    }



    public class VisitorTarget : EntityWithTypedId<long>

    {

        public virtual string Url { get; set; }

        public virtual int Count { get; set; }

    }



    public class VisitorReferrer : EntityWithTypedId<long>

    {

        public virtual string Url { get; set; }

        public virtual int Count { get; set; }

    }



    public class VisitorDaily : EntityWithTypedId<long>

    {

        public virtual DateTime Date { get; set; }

        public virtual int UniqueVisits { get; set; }

        public virtual int TotalVisits { get; set; }

        public virtual string CompressedDetailedStatistics { get; set; }

    }

Varje gång någon besöker en sida så lägger man till en rad i Visitor tabellen.
Om IP adressen redan besökt så refererar man till raden som finns i VisitorIP tabellen. Samma gäller för VisitorTarget och VisitorReferrer.

En gång om dagen, troligast midnatt, så kör man sedan ett schemalagt jobb som tar ut all statistik för dagen, bearbetar, komprimerar och stoppar sedan in det i en ny rad i VisitorDaily tabellen.
efter detta så tömmer man Visitor, VisitorIP, VisitorTarget och VisitorReferrer tabellerna så att allt är rent för nästa dag.

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

Jag tycker spontant att det låter som ett bra sätt att arbeta på, men min andra tanke är:
Varför inte använda t ex Google Analytics som specialiserar sig på besöksstatistik och lägga din tid (som är värdefull) på något annat?

Lycka till.

En anledning att inte använda GA är att man inte vill att Google ska veta ALLT om en.

That said, GA har massor av intressanta funktioner för den som vill lära sig lite mer. Jag använder det för att spåra E-handel, där jag förutom den vanliga statistiken kan få in vilken omsättning jag har, till exempel per referer, eller per sökord, eller per annonskampanj.

Annonskampanjen är också en sak som är intressant att spåra, du kan slänga med QueryStrings i länken du använder och få besökaren taggad med just den annonskampanjen.

Det går naturligtvis att göra allt detta själv, men jag har bättre saker att göra med min tid

Jag vill gärna full tillgång till funktionerna på min site så att jag kan göra ändringar etc.
Dessutom måste man lägga in javascriptet för GA på varje sida, vilket jag tycker är lite bökigt. Är inte så mycket problem om jag slänger in det i en MasterPage dock.

Får se om jag använder GA. Mycket information som jag nog kan ha användning för i början när jag lanserar sidan.
Känns dock som jag i alla fall vill ha min egen statistik som backup.

Citat:

Ursprungligen postat av Uzza (Inlägg 20360464)

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.

Citat:

Ursprungligen postat av Uzza (Inlägg 20360338)

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.

Citat:

Ursprungligen postat av ITisGood.se (Inlägg 20360480)

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.

Citat:

Ursprungligen postat av Clarence (Inlägg 20360489)

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.

Citat:

Ursprungligen postat av Uzza (Inlägg 20360530)

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.

Citat:

Ursprungligen postat av Clarence (Inlägg 20360536)

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". :)

Citat:

Ursprungligen postat av Clarence (Inlägg 20360536)

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.

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.