[Alg] Bezoekers gedrag op site monitoren

[mocean]

Het volgende, op een site houd ik per bezoeker bij welke pagina's hij bezoekt in een sessie. Dat wordt vervolgens opgeslagen in een sessietabel, en dat ziet er ongeveer zo uit:

22-08-2005 11:13: 2,12,24,12,12,45,85,65,12,45
22-08-2005 12:12: 2,123,112,2,12,24,46,96,54,87,54
22-08-2005 13:00: 114,2,123,3,4,14,15,32,12,45,78
22-08-2005 13:01: 2,12,15,45,78,95,54

Van deze gegevens heb ik dus een hele rits. Om nu de navigatie van mensen te analyseren wil ik op zoek naar patronen binnen de navigatie. In bovenstaand lijstje komt bijvoorbeeld "2,12" 3 keer voor.

Ik heb zelf hetvolgende bedacht om deze gegevens te verwerken, maar dat duurt écht heel lang.
Uit alleen al de 1e sessie haal ik de volgende reeksen (met max van 4 pagina's):
2,12
12,24
24,12
12,12
12,45
45,85
85,65
65,12

2,12,24
12,24,12
24,12,12
12,45,85
45,85,65
85,65,12
65,12,45

2,12,24,12
12,24,12,12
24,12,12,45
12,12,45,85
12,45,85,65
45,85,65,12
85,65,12,45

Nu wil ik per sessie gaan kijken of er nieuwe combi's zijn, en als er een al in mn lijstje staat deze gaan tellen. Zo wil ik kijken welke navigatiepatronen er vaker voorkomen. Ik heb dit zelf wel eens in PHP gemaakt, maar dat is erg traag (gewoon alles afgaan). Weet iemand misschien een slimere manier of wiskundige truuk om deze reeksen te analyseren?

[NMe]

Kun je niet beter een aparte tabel gebruiken in plaats van comma seperated values? Daar is veel makkelijker/sneller mee om te gaan dan dit.

[mocean]

-NMe- schreef op maandag 22 augustus 2005 @ 16:04:
Kun je niet beter een aparte tabel gebruiken in plaats van comma seperated values? Daar is veel makkelijker/sneller mee om te gaan dan dit.

Ik heb ook elke hit los staan in een tabel, wat ik hierboven laat zien zijn de verzamelde gegevens.
Maar dan nog, hoe kan ik in SQL een patroon over meerdere records zien? Volgens mij wordt het daar niet makkelijker van...

[MSalters]

Kun je niet simpeler in SQL een frequentietabel bijhouden? Voor lengte 2 is dat helemaal simpel: kolom in, kolom uit, teller. Key is [in,uit]. Voor een klik op pagina 2 naar pagina 12 hoef je dan alleen de teller[2,12] te verhogen als die bestaat (en anders een nieuwe row met teller=1 aanmaken, desnoods automatisch)
Lengte 3 wordt een wat grotere tabel, maar omdat het aantal mogelijkheden beperkt is is het geen tabel met grootte N³. Voor lengte 2 is het tenslotte ook geen N² tabel, maar is het aantal entries maximaal het aantal links.

[MisterData]

MSalters schreef op maandag 22 augustus 2005 @ 17:27:
Kun je niet simpeler in SQL een frequentietabel bijhouden? Voor lengte 2 is dat helemaal simpel: kolom in, kolom uit, teller. Key is [in,uit]. Voor een klik op pagina 2 naar pagina 12 hoef je dan alleen de teller[2,12] te verhogen als die bestaat (en anders een nieuwe row met teller=1 aanmaken, desnoods automatisch)
Lengte 3 wordt een wat grotere tabel, maar omdat het aantal mogelijkheden beperkt is is het geen tabel met grootte N³. Voor lengte 2 is het tenslotte ook geen N² tabel, maar is het aantal entries maximaal het aantal links.

Dan sla je alleen op hoevaak iemand van een bepaalde pagina naar een andere gaat en dat wil de TS niet, de TS wil juist zoeken naar patronen in de volgorde van de bezochte pagina's

Ik lees verkeerd, maar een tabel per lengte van een patroon lijkt me niet echt handig?

[ Voor 6% gewijzigd door MisterData op 22-08-2005 17:35 ]

[mocean]

MSalters schreef op maandag 22 augustus 2005 @ 17:27:
Kun je niet simpeler in SQL een frequentietabel bijhouden? Voor lengte 2 is dat helemaal simpel: kolom in, kolom uit, teller. Key is [in,uit]. Voor een klik op pagina 2 naar pagina 12 hoef je dan alleen de teller[2,12] te verhogen als die bestaat (en anders een nieuwe row met teller=1 aanmaken, desnoods automatisch)
Lengte 3 wordt een wat grotere tabel, maar omdat het aantal mogelijkheden beperkt is is het geen tabel met grootte N³. Voor lengte 2 is het tenslotte ook geen N² tabel, maar is het aantal entries maximaal het aantal links.

Dan ga je ervanuit dat ik mensen alleen wil monitoren vanaf de start van hun sessie. Aangezien ik tot 5 pagina's op rij in een sessie wil kunnen monitoren, wordt dat al een vrij lastige zaak. Binnen een sessie van 20 visits, wil ik namelijk alle patronen herkennen.

Mijn voorkeur gaat dus uit naar het achteraf verwerken van de sessiegegevens. Ik ga zelf nog even verder denken, tips zijn welkom

[Dennis]

Kijk je alleen naar pagina's of ook naar hoe mensen er komen? Als je bijvoorbeeld twee links hebt kan het handig zijn om erachter te komen op welke men het meest klikt.

[H!GHGuY]

is het ook belangrijk dat de gegevens individueel blijven?

bvb:
als je in SQL zoals hierboven iemand aangeeft een tabel hebt met in,uit,aantal dan kun je vrij eenvoudig een hierarchisch diagram maken:
**** vertrekpunt: 2 ****
- X mensen gaan daaruit naar 24
- Y mensen naar 123
- Z mensen naar andere
---- **** vertrekpunt 24 ****
- A mensen naar paginablah
- B mensen naar ...
- C mensen naar andere
---- ****vetrekpunt 123 ****
- D mensen naar ...
- E mensen naar ...
- F mensen naar andere
---- ---- **** vertrekpunt paginablah ***
.....

dus je komt uit op een stroomdiagram met de "gemiddeld" belangrijkste paden

[mocean]

@HighGUY

Dan verlies ik wel de info over paden van meer dan 2 die veel doorlopen worden,
stel:
40% doet: 1,2
40% doet 2,3
maar niemand doet: 1,2,3

Dan zou uit het gemiddelde van jouw constructie wel blijken dat dat een vaak belopen pad is. Vandaar dat ik ook paden van tot 5 pagina's (of meer) wil detecteren.

[Voutloos]

mocean schreef op maandag 22 augustus 2005 @ 18:40:
[...]


Dan ga je ervanuit dat ik mensen alleen wil monitoren vanaf de start van hun sessie. Aangezien ik tot 5 pagina's op rij in een sessie wil kunnen monitoren, wordt dat al een vrij lastige zaak. Binnen een sessie van 20 visits, wil ik namelijk alle patronen herkennen.

Waarom zou dat per se alleen maar vanaf het begin zijn? Bij elke hit bekijk je of er al een paar hits aan vooraf gingen (via je huidige sessieinfo) en voeg je 1 nieuwe rij toe (of doe je hits++ bij een bestaande rij) in de tabellen die van toepassing zijn.

[H!GHGuY]

mocean schreef op maandag 22 augustus 2005 @ 19:29:
@HighGUY

Dan verlies ik wel de info over paden van meer dan 2 die veel doorlopen worden,
stel:
40% doet: 1,2
40% doet 2,3
maar niemand doet: 1,2,3

Dan zou uit het gemiddelde van jouw constructie wel blijken dat dat een vaak belopen pad is. Vandaar dat ik ook paden van tot 5 pagina's (of meer) wil detecteren.

Men beweert altijd: met statistiek kan je alles bewijzen. Dus hier komt ie:
De kans dat veel mensen 1,2,(niet 3) doen en veel mensen (niet 1), 2, 3 doen is op zich klein.
Gebeurt dit toch, dan kan je zelfs stellen dat je site "slecht" is. Je zou dan namelijk kunnen stellen dat op pagina 2 informatie staat die OF bij 1 OF bij 3 hoort, maar niet bij elkaar.
Gevolg: doet iemand 1,2, dan is de kans behoorlijk dat ie doorklikt naar 3 als veel anderen van 2 naar 3 doorklikken (al dan niet van 1 komend...)

bovendien denk ik zelfs dat wanneer je duidelijke paden hebt (na een tijdje) je de afwijking daarvan zal kunnen aanduiden als een Gauss-verdeling (of benoem ik hier nu de Gauss-curve).
Met mijn methode zal je ook net DIE curve duidelijk zien terugkeren.

[djluc]

Ik ben hier ook een tijdje mee bezig geweest. ( http://gathering.tweakers...D=&select_forum=#hitstart ) maar ben er uiteindelijk mee gestopt omdat het erg performance-eisend is.

Verder beschik je na een tijdje over een enorme hoeveelheid data welke je op de een of andere manier efficient moet gaan groeperen. Dat is echter erg lastig, zeker als je veel zoekmachine-bezoekers krijgt. Deze beginnen namelijk bijna altijd op een andere pagina dan de homepage.

Als je dus een soort boom-schema wilt maken van de bezoekers krijg je al meteen bij het begin bijna elke pagina te staan waarna het een enorme boom wordt waaruit je alsnog niets kunt halen. Verder is het dan vrijwel onmogelijk om te zien waar routes elkaar gaan treffen. Kortom: veel succes als je het voor elkaar krijgt