Unieke bezoekers tellen, best practice?
Ik heb al een idee bedacht om dit te kunnen realiseren:
Ikzelf zat te denken om op session-basis te werken, en aan de hand van een SessionID de gebruiker te herkennen. Elke hit die hij doet in een item wordt dan in een tabel hitcounter opgeslagen. Een hit op dezelfde pagina geldt pas als er drie minuten tussenzit vergeleken met de vorige. Dat voorkomt dat iemand per ongeluk even op 'back' drukt of iets dergelijks en dat dat ook als een hit wordt geteld.
Uiteindelijk moet een cronjob die elk uur draait ervoor zorgen dat het totaal van de hits netjes overgeplaatst wordt naar de hits-veld van het artikel, zodat ik dit kan gebruiken als in de algoritme.
Natuurlijk zal ik ook zorgen dat searchspiders met een eenvoudige user-agent en/of IP-range herkenning niet geteld zullen worden. Echter was ik benieuwd wat jullie van deze opzet vinden? Ook vroeg ik me af wat nu als er door session_regenerate een nieuw SessionID wordt uitgegeven. Dan zal dit idee niet mer werken.
Wat vinden jullie van deze opzet? Opmerkingen hoor ik graag.
Gewijzigd op 05/02/2019 16:09:36 door - Ariën -
kijk eens op https://www.phpjunkyard.com/. Vandaar vertrekkende voor je cronjob kan niet moeilijk zijn voor jou :)
https://www.phpjunkyard.com/php-graphical-hit-counter.php heb ik gebruikt voor jaren.
Jan
Jan R op 05/02/2019 16:51:16:
kijk eens op https://www.phpjunkyard.com/. Vandaar vertrekkende voor je cronjob kan niet moeilijk zijn voor jou :)
https://www.phpjunkyard.com/php-graphical-hit-counter.php heb ik gebruikt voor jaren.
https://www.phpjunkyard.com/php-graphical-hit-counter.php heb ik gebruikt voor jaren.
"It uses flat-text database so no SQL databases are necessary"
Dat zoek ik dus niet. Juist databases zijn hiervoor bedoeld.
"Requirements: PHP 4.4 or newer"
Als daar nog rekening mee wordt gehouden, is het script mogelijk behoorlijk gedateerd....
Ik zoek geen kant en klaar (bloated) script, maar ik wil weten of mijn opzet een mooie basis is. Of iets wat er op lijkt, als het bestaat.
Gewijzigd op 05/02/2019 16:59:36 door - Ariën -
- Ariën - op 05/02/2019 15:37:40:
session_regenerate
Een eerste ingeving zou zijn: sla een unieke hash op in de sessie. Maar ook dat gaat niet werken als de sessie verloopt. Sessies zou je ook niet kunstmatig in leven moeten houden, je moet gewoon voorzieningen treffen zodat deze naadloos kunnen doorstarten.
Wat is er mis met een tracking cookie?
Ik kan eventueel ook een cookie plaatsen met een randomID en de huidige begindatum erin, die ik kan gebruiken voor de hitcounter-table.
Gewijzigd op 05/02/2019 19:24:56 door - Ariën -
An sich zou het kunnen, en ook met een timestamp. Want na 3 minuten zou een item die her-bezocht wordt weer een nieuwe hit mogen zijn. Maar misschien ga ik deze tijd nog aanpassen. Ik weet nog niet echt wat een mooie waarde hiervoor is.
Maar het aantal unieke hits per item moet ook weer bekend worden bij het item. Dus of dit een idee is, betwijfel ik. Ik wil immers toch wat leuke 'Meest bekeken' algoritmes bouwen, waar een vaste waarde handig voor is...
Als je dit apart uit de hitcounter-tabel moet halen bij elk algoritme wordt het wel erg zwaar. Plus dat het niet heel accuraat hoeft te zijn.
- Ariën - op 05/02/2019 17:52:46:
Sessies leven niet oneindig, maar zolang je binnen 28 minuten een teken van laat zien met een refresh, blijft de sessie toch leven? Het is niet zo dat je vanzelf na 28 minuten opeens merkt dat je sessie niet meer werkt? Dat heb ik nooit gemerkt.
Hangt van garbage collection en platform af? Misschien is deze data achterhaald, maar vroegah detecteerde Windows platforms bijvoorbeeld niet de access time van een sessie-bestand (omdat deze simpelweg niet in het filesysteem wordt bijgehouden?), enkel de modification time. Dus als een actieve sessie niet inhoudelijk werd bijgewerkt werd deze op den duur toch geflagged als garbage.
- Ariën - op 05/02/2019 21:41:45:
Je verschuift de tijdelijke opslag van het aantal hits dus dan naar de sessie-kant in plaats van de database.
Een sessie is geen rijdend archief. Als dit bestanden betreft zou ik dit niet doen.
Nee, je houdt het gewoon in de database bij, maar gelijktijdig hou je in je sessie bij welk ID (pagina) is bezocht.
Dus stel jouw contactpagina heeft ID 8, dan tel je als iemand de contactpagina bezoekt in de database 1 op bij ID 8. Gelijktijdig sla je in de sessie van die bezoeker op dat ID 8 bezocht is, zodat als hij de pagina nogmaals bezoekt (binnen x minuten) het in de database niet wordt opgehoogd.
Gewijzigd op 05/02/2019 22:07:32 door Ozzie PHP
@Thomas: De session.gc_maxlifetime staat op 1440 en dit is op meerdere platformen zo (zowel Linux als Windows). Ik heb nog nooit gemerkt dat opeens een sessie afgekapt is door de 'garbage collector', altijd blijkt deze te werken als er steeds session_start() aanroepen is, en lijkt de de teller weer opnieuw te beginnen.
Quote:
Als dit bestanden betreft zou ik dit niet doen.
Hoe bedoel je? Een item is bij mij gewoon een database record. Of doel je op een tijdelijke opslag in bestanden in plaats van in de database.
Als je je website tussentijds aanroept start de teller weer opnieuw. De geldigheid betreft een periode van inactiviteit. In het geval van 1440 (seconden) betekent dit dat na 24 minuten niks doen de sessie is verlopen.
> Ik heb nog nooit gemerkt dat opeens een sessie afgekapt is door de 'garbage collector', altijd blijkt deze te werken als er steeds session_start() aanroepen is, en lijkt de de teller weer opnieuw te beginnen.
Oh, dus jij hebt nog nooit last gehad van formulieren waarvan de submit misliep door een sessie timeout (CSRF token weg)? Moet je eens een site van de overheid bezoeken :). Besef je wel dat alle inhoud dan ook weg is - het is echt een nieuwe sessie met een leeg sessie-bestand.
Aangenomen dat we het over de (standaard) sessie-implementatie met bestanden hebben.
@Thomas: Nee, die shizzle heb ik nooit meegemaakt. Ik denk zelf dat het inderdaad zinvoller is om de database erbij te betrekken, in plaats van met sessies te werken voor de opslag. Sessies zijn meer bedoeld om de bezoeker tijdelijk te identificeren. Mij boeit het niet wie de site gisteren en vandaag bezocht heeft, enkel het aantal hits.
maar een fingerprint die Ward noemt, kan ook een idee zijn.
Gewijzigd op 05/02/2019 22:43:16 door - Ariën -
Als je dan kijkt naar de tijd die je nodig acht om opnieuw te gaan kijken dan zou ik ze nog eens indelen in categorieën.
Je kijkt immers vaker naar een item die als LIVE bestempeld word( voetbal ) nieuwe data per 5 min , dan naar een item zoals bv reacties op jou Topic (10 min) .
Als je een script zou bekijken die vindbaar is op google en hier terecht zou komen, kan je kunnen stellen 1 dag per gebruiker.
Want diezelfde gebruiker, gaat immers diezelfde dag het script lezen meerdere keren . Die telt dus als 1 hit.
Vervolgens kan je per dag voor een artikel, indien deze een hit kreeg de counter bijhouden.
Dan kan je per artikel het gemiddelde nemen van bv 5 dagen en vergelijken met andere artikelen (topics,scripts)
Zo krijg je een zicht op verleden, heden ( x was een hot topic in jaar 2009 en herleeft nu in 2019)
Hopelijk ben je er wat mee :)
Gewijzigd op 05/02/2019 23:29:00 door - Ariën -