[PHP] Statistieken

[ripexx]

Situatie schets
De situatie is als volgt, ik heb een website ontwikkeld voor mijn hockeyclub. Behalve de frontend heb ik ook een CMS geschreven voor het invoeren van nieuws, content, nieuwspolls, teams wedstrijden etc etc. Alles zit in de db en de content wordt door een groep mensen bijgehouden. Ons clubje behelst ongeveer 500+ leden. Sinds het begin houden we statistieken bij doormiddel van een nedstat basic counter. Nu is het zo dat we hier echt te maken hebben met de huis, tuin en keuken gebruikers, en zijn de statistieken over afkomst, browser en os niet echt intressant. Wat wel weer intressant is welke pagina's er worden bezocht en hoevaak. Deze optie heeft een nedstat counter niet, de gratis variant dan wel te verstaan.

Probleem
Ik heb dus nu een counter gemaakt die alle hits op alle pagina's logt in een tabel. Nu dacht ik met zo'n 500 hits per week zal het wel niet zo storm lopen, dus mooi niet. In 10 dagen heb ik het volgende gelogd: bijna 2000 hits en een dikke 12000 pageviews. Helaas is het budget beperkt en ik vind het zonde om veel ruimte te verspillen aan een db, terwijl ik deze ruimte ook kan gebruiken voor plaatjes en content.

Hoe werkt de huidige counter:
Er wordt een sessie gestart en deze wordt bij elke view verhoogd met één. Daarnaast wordt de datum en tijd en sessie_id gelogd. Dit houdt dus in dat bij het huidige design voor elke hit er een db record hit gemaakt word. Nu is dit niet echt handg en maakt de selectie en analyse alleen maar lastiger.

Randvoorwaarden
Wat zou de nieuwe statistieken module moeten kunnen:
1 Inzicht in aantallen hits en pagevieuws per dag, week, maand en jaar;
2 Inzicht in pageviews per pagina/groep;
3 Inzicht in routing/pad van bezoekers;

Opties
Ik zie de volgende opties:
1 Doorgaan op de huidige weg;
2 Een andere structuur te kiezen, zoals bijvoorbeeld: [dag, hits, pageviews], [maand, hits, pageviews] en [week, hits, pageviews], en dan updaten;
3 ...

Vragen
Wat zijn andere opties om wat meer uit mijn statistieken te halen? Wie heeft nog tips, opmerkingen en ervaringen hiermee? Voor de duidelijkheid ik ben dus niet opzoek naar stukken code, db ontwerpen of zo iets, ik wil meer info hebben over opties en waarom te kiezen voor een bepaald ontwerp. Ik heb zeer veel gezocht en zeer veel gevonden. Maar ik zie door de bomen het bos niet meer. Dus ik zou graag een constructieve discussie willen voeren over welke methode/optie te kiezen.

[Verwijderd]

Mischien is het een idee om per week een record toe te voegen, dan heb je 52 records per jaar en 520 per 10 jaar.
Dan kan je b.v. denken aan een table als dit:

code:

id bigint(11) autoincreement + unique
totalhits decimal (11,0) of bigint(11)
uniquehits decimal (11,0) of bigint(11)

Dan moet je per iedere pagina die je hebt een record kunnen invullen van hoeveel hits deze al heeft, dan kan je dus ook per pagina zien hoeveel die pagina heeft.

Dan een tabel maken alla:

code:

id bigint(11) autoincreement unique
ip varchar(15)
hits decimal (11,0) of bigint(11)

Hierin count je de hits per ip gewoon door, als je dan 5000 ip's hebt dan kan je zo zeggen welk ip het actiefste is.

Zoiets kan je b.v. maken, of dit een goed systeem is zou ik niet weten, nooit echt over nagedacht.
Als je dit per hit wil doen is het veel werk.

Je kan ook gewoon iedere hit opslaan, en dan aan het einde van de maand alles bij elkaar gooien in 1 record, dan heb je eerst veel records maar doordat je die bij elkaar gooit heb je meer ruimte(1 record ipv 100000). Dit kost wel iedere maand even reken tijd, maarja je kan niet alles heben

[Verwijderd]

Ik zou (zoals kod ongeveer al zei) gewoon eens per week een script draaien die alles bij elkaar gooit en dan alsnog de output kan genereren die je nu genereerd.

[martinvw]

http://www.phpfreakz.nl/artikelen.php?aid=16

Ik vond dit een goed artikel en heb het op ongeveer deze manier verwezenlijkt, gaat ook redelijk efficient met je database gegevens om

[ripexx]

M4rt1nvW schreef op 18 March 2003 @ 17:54:
http://www.phpfreakz.nl/artikelen.php?aid=16

Ik vond dit een goed artikel en heb het op ongeveer deze manier verwezenlijkt, gaat ook redelijk efficient met je database gegevens om

Ja deze tutorial had ik al gezien, maar hier wordt vooral de nadruk gelegt op stats ala browsers, os, resolutie etc. Dit is juist in mijn geval niet intressant, de meeste en dan bedoel ik 99,9% ken geen andere browser dan IE en zal bij het wordt resoltie zeggen dat het een leuk woord voor galgje is. Ik weet vanuit nedstat al deze cijfers. Ik wil specifiek meer gaan doen met routing, en als je dat toch gaat doen dan kun je er maar beter stats aan gaan koppelen.

Oja ik kan niet direct een cronjob runnen vanuit de webserver. Wel kan ik vanuit mij eigen server iets gaan proberen, daar kan ik dagelijks of wekelijks een job runnen die alles verwerk tot werkbare data. (Gewoon een wget naar een php pagina met als argument een md5 string) Maar ik wil liever niet afhankelijk zijn van men eigen server.

[martinvw]

ik doel ook meer op de database benadering.

Bestaat iets tel er dan één bij op, bestaat iets niet voeg dan toe met als aantal 1.

Dit is dus zeer globaal het idee waar bij je dus neit elke hit op slaat maar alleen een bepaald deel van de gegevens.

[ripexx]

M4rt1nvW schreef op 18 March 2003 @ 18:15:
ik doel ook meer op de database benadering.

Bestaat iets tel er dan één bij op, bestaat iets niet voeg dan toe met als aantal 1.

Dit is dus zeer globaal het idee waar bij je dus neit elke hit op slaat maar alleen een bepaald deel van de gegevens.

Oke sorry, ik dacht dat je meer doelde op de tutorial. Deze optie zal waarschijnlijk mijn voorkeur gaan hebben, maar dan zit ik vooral nog met de methode om de routing te volgen.

Nu wordt het volgende gelogd:
Sessie hit, elke hit verhoogd met een
Pagina (nieuws items, frontpage etc)
Pagina groep (nieuws, wedstrijd, teamstukjes etc.)
Vorige insert id.

Je kunt op deze manier de route per geval vast stellen, maar als je daar een query op lostlaat om dat geheel te analyseren dan ben je nog wel ff bezig. Zeker als je telt dat het nu dus ongeveer 1000 pageviews per dag zijn.

[Rotjeknor]

Als je interesse hebt, ik ben op het moment ook bezig met het uitwerken van (uitgebreide) statistieken van een site. Voeg me toe aan icq/ msn, dan wil ik er best even over discussieren. Ik heb namelijk al een aantal ideeen op papier staan, ben nog bezig met uitwerken.

btw vanavond ben ik er niet.

Heb nu weinig tijd, anders kon ik er hier wel wat meer over uitwijden. Ik hoor het wel.

[Joove]

Hiervoor bestaat al een goede teller www.stats4all.com

Deze voldoet aan allen dingen, die jij wilt hebben.

[ripexx]

Joove schreef op 19 March 2003 @ 15:12:
Hiervoor bestaat al een goede teller www.stats4all.com

Deze voldoet aan allen dingen, die jij wilt hebben.

Ik heb het even bekeken, maar ik wil het liever in eigen beheer houden, en zelf mijn analyses te bepalen.

Rotjeknor schreef op 18 March 2003 @ 18:32:
Als je interesse hebt, ik ben op het moment ook bezig met het uitwerken van (uitgebreide) statistieken van een site. Voeg me toe aan icq/ msn, dan wil ik er best even over discussieren. Ik heb namelijk al een aantal ideeen op papier staan, ben nog bezig met uitwerken.

btw vanavond ben ik er niet.

Heb nu weinig tijd, anders kon ik er hier wel wat meer over uitwijden. Ik hoor het wel.

Ik ben niet zo vaak online met MSN en ICQ maar ik zal je eens gaan toevoegen, ff kijken waar die bende ook al weer zit

Ik denk dat ik iets met een cronjob ga doen, deze zal dan alle data zo verwerken dat je er iets mee kan. Nadeel is dan alleen dat je geen realtime data meer heb maar dat is dan een keuze. Zodra ik wat meer weet zal ik het wel posten.

[Verwijderd]

ripexx schreef op 18 March 2003 @ 17:05:

Probleem
Ik heb dus nu een counter gemaakt die alle hits op alle pagina's logt in een tabel. Nu dacht ik met zo'n 500 hits per week zal het wel niet zo storm lopen, dus mooi niet. In 10 dagen heb ik het volgende gelogd: bijna 2000 hits en een dikke 12000 pageviews. Helaas is het budget beperkt en ik vind het zonde om veel ruimte te verspillen aan een db, terwijl ik deze ruimte ook kan gebruiken voor plaatjes en content.

mayb een oplossing een optel sommetje maken voor de hits.. dus
id | page | hits
1 | home | 1983 (als jer een nieuwe is gewoon 1983 uit de tabel halen +1 en overschrijven)
voor de laatste 10 kun je het zelfde doen alleen dan met 10 entrys

[Rotjeknor]

Verwijderd schreef op 20 March 2003 @ 08:08:
[...]
mayb een oplossing een optel sommetje maken voor de hits.. dus
id | page | hits
1 | home | 1983 (als jer een nieuwe is gewoon 1983 uit de tabel halen +1 en overschrijven)
voor de laatste 10 kun je het zelfde doen alleen dan met 10 entrys

Dit is wel leuk als je alleen het aantal hits wil weten van een pagina, maar dan zit je nog met een aantal zaken:
-Wat doe je als je van een index naar een links en weer terug gaat naar een index, tel je dan index als 2 hits?
-Op deze manier weet je niet op welk tijdstip een pagina wordt bekeken
-Op deze manier kan je niet nagaan wat de route van een persoon door de site is
-Je kan ook niet nagaan of iemand meerdere keren op de site komt over een bepaalde periode
-Je kan ook niet zien of een pagina gedurende een bepaalde periode in hits stijgt (procentueel)

Wat ik gebruik, is een tabel waarin ik een aantal dingen in heb staan:
id
ip
page
access time //dit is de begin tijd
subpage //ik gebruik nog wel content.php?item=copyright
article id //aangezien op mijn site veel met artikelen wordt gewerkt

Ik ben ook niet heilig ofcoz, maar ik denk dat deze manier (voor mijn situatie iig) redelijk alle benodigde zaken voor statistieken afvangt.

[ Voor 1% gewijzigd door Rotjeknor op 20-03-2003 08:31 . Reden: klein detail ]

[Verwijderd]

Als je voor ieder uniek stuk data een nieuw record maakt, bestaat een stuk data al, update het dan. Wat je dan krijgt:

Iemand komt op de website. Het script kijkt welke pagina het is. Je kijkt of deze pagina op deze dag al voorkomt in de database, zo jah: update het aantal views (+1), zo niet, maak een nieuw record aan met de dag en zet het aantal views op 1.

Zo bespaar je een hoop ruimte, maar heb je toch per dag het aantal views/hits op iedere pagina.

Succes!

[Rotjeknor]

Hiermee kan je dus niet de route van een persoon door een pagina registreren...

[ripexx]

Daarnaast heb ik nog een probleem met de logging van unieke bezoekers. Ik probeer dit momenteel te doen met sessies. Dit gaf een vertekend beeld, dus heb ik de sessie lifetime verhoogd naar 1 uur. Als je langer dan een uur bent weg geweest wordt je als nieuwe bezoeker aangemerkt. NedStat daarin tegen registreerd toch iets anders. Na enig zoek werk ben ik er achter gekomen dat NedStat waarschijnlijk een cookie van +/- 30 minuten gebruikt. Al zie ik hiervoor geen bewijs in mijn cookie manager van Mozilla.

Nu loop ik dus tegen een probleem aan. Nedstat wordt volgens mij gezien als een betrouwbare methode om statistieken te verkrijgen. Nu kloppen mijn stats dus niet met die van NedStat.

Wat gebruiken jullie om te bepalen wanneer ene bezoeker uniek is? Gebruiken jullie hiervoor ip's, cookies enz.

[Rotjeknor]

Allereerst: Nedstat is niet betrouwbaar. Als je Nedstat op je index.php zet, en je gaat naar een andere pagina en weer terug naar index.php, registreert Nedstat 2x een hit. Dit was voor mij ook een extra reden om eigen statistieken te gaan maken.

Ik maak op dit moment gebruik van ip's (zoals je hierboven kan zien). Nadeel hiervan is, is dat mensen met een inbelverbinding bijna altijd een ander ip adres krijgen.

Later wil ik ook cookies gaan toevoegen om dit probleem grotendeels te omzeilen.

[Guru Evi]

Ik zou cookies gebruiken als iemand aanlogged met daarin het session_id, expire time: 1h. Dan kun je in een database iedere keer zetten:
"session_id_nr" | "page_nummer_1_view + 1" | "vorige_page" | "page_nummer_2_view + 1" | "vorige_page" | ...
Dan heb je in een database:
sessie | page_1_bezocht (index) | page_2_bezocht | komt_van_page | datum
1 2 3 1 02/03/03
2 1 1 3 02/03/03
Dan kun je daar mooie gemiddelden uit nemen
aantal_page1_visitors: 6000
aantal_page2_visitors: 5000
gemiddelde_page2_visitors_komt_van_pagenr: 1,3 (hier de komma erafkappen, afronden) = 1 dus de gemiddelde page_2 bezoeker komt van pagina 1
Dan kun je ook een zoekfunctie inzetten per datum, die dus weergeeft welke datums hoeveel keer dit en dat bezocht wordt.
Dan kun je vb: een glijdend register bouwen (na 30 dagen wordt automatisch de record van je sessie verwijderd en kun je mooi statistieken bouwen)
Zou redelijk accuraat moeten zijn, niet voor 10 visitors maar op een schaal van 6000 bezoekers per maand gaat het wiskundig naar eenzelfde getal streven.
Natuurlijk: je haalt daar aan dat zulke grafieken uit een database halen redelijk traag is: tsja, grote databases heb je grote computers voor nodig maar je kunt je php code en je zoekalgoritmes goed updaten.

[ Voor 28% gewijzigd door Guru Evi op 20-03-2003 15:30 ]

[ripexx]

Even een paar conclusies:

Bij externe statistieken wordt er negen van de tien keer gewerkt met een plaatje. Nadeel hiervan is dat deze images gecached kunnen worden. Ook al geef je aan dat ze niet gecached moeten worden.

Als je dan toch al servers side en met db's bezig bent is de keuze dus al snel gemaakt. Een eigen module. Nu loop je dus tegen genoeg problemen aan.

1. Je wil graag zelf kunnen bepalen welke data belangrijk is voor jouw side, dus os-info, browser-info, routing-info etc. etc. Maar ook gegevens over stats per uur, dag, week maand en jaar. Verder zijn gevens over verblijftijd, pageviews per hit etc intressante gegevens voor een website bouwer.
2. Welke grootheden ga je begruiken, hits, pageviews, tijd enz en hoe defineer je deze. Met name dus de hits (hoe uniek is een hit )

Als je dit hebt uitgewerkt kun je een model gaan maken. Hierin kun je dan weer je eigen ontwerp keuzes maken. Wie heeft hier nog zaken aan toe te voegen en dan met name welke factoren ik over het hoofd heb gezien.

[Rotjeknor]

Theoretisch kom je een heel eind qua model opzetten van wat je allemaal wilt zien uit de data. Ik heb zelf een lijstje gemaakt, gekeken naar nedstat en wat andere stats, vanuit daar gewoon begonnen. Je komt dan snel genoeg dingen tegen die je anders moet gaan doen, of zaken die dieper uitgewerkt kunnen worden.

Ik heb zelf een hekel aan om superlang theoretisch bezig te zijn, ik zie liever snel resultaat, dan kan ik me vaak beter indenken waar ik eigenlijk mee bezig ben (ook handig (-: ), en wat ik wil doen/ maken. Maar goed... wie ben ik...

[djluc]

Denk dat de rekenkracht als je de site bij een prof. bedrijf host niet zo'n probleem zal zijn.

Een idee wat mogelijk zou zijn:
je slaat de gegevens op zoals je ze nu hebt, omdat het opslaan dan weinig moeite kost, en je gaat met een cronjob die gegevens eens per dag oid samenvoegen.