Door
Ariën
op 05-02-2019 15:37
gewijzigd op 05-02-2019 16:09
2.736 views
Voor mijn site zit ik met het idee om het aantal bezoekers van een artikel, review, video(pagina) etc.. (lees verder: 'item') te tellen. Uiteraard moet dit wel een beetje F5-proof zijn, zodat mensen die zich vervelen niet de boel omhoog kunnen proberen te kicken door op F5 te rammen. Aan de hand van het aantal hits wil ik uiteindelijk een simpel algoritme maken die bepaald hoe belangrijk een item is.
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 [php]session_regenerate[/php] een nieuw SessionID wordt uitgegeven. Dan zal dit idee niet mer werken.
Wat vinden jullie van deze opzet? Opmerkingen hoor ik graag.
>> Je verschuift de tijdelijke opslag van het aantal hits dus dan naar de sessie-kant in plaats van de database.
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.
@Ozzie: Ik zal er eens naar kijken
@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.
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.
>>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.
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.
Dat zeg ik dus, op sommige platformen was activiteit binnen deze periode niet genoeg. Je moet dan fysiek de inhoud veranderen anders wordt dit bestand nog steeds beschouwd als garbage (access time vs modification time).
> 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.
@Ozzie: dat klopt inderdaad
@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.
Stel dat jijzelf een item vind die je als belangenrijk bestempeld en ook nog eens om de zoveel tijd wil controleren of er niets nieuws verschenen is.
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)
@Bart: Handig om in het hoofd te houden. Het zijn voornamelijk items in de vorm van nieuwsartikelen, reviews, agendaitems of videopagina's. Dus ik moet kijken of het echt nodig is.
