Unieke bezoekers tellen, best practice?

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

- Ariën -
Beheerder

- Ariën -

05/02/2019 15:37:40
Quote Anchor link
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 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 -
 
PHP hulp

PHP hulp

24/04/2019 19:02:05
Honeypot
 
Jan R

Jan R

05/02/2019 16:51:16
Quote Anchor link
Een groot gedeelte is warm water uitvinden :)
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
 
- Ariën -
Beheerder

- Ariën -

05/02/2019 16:55:38
Quote Anchor link
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.

"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 -
 
Thomas van den Heuvel

Thomas van den Heuvel

05/02/2019 17:46:10
Quote Anchor link
- 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?
 
- Ariën -
Beheerder

- Ariën -

05/02/2019 17:52:46
Quote Anchor link
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.

Ik kan eventueel ook een cookie plaatsen met een randomID en de huidige begindatum erin, die ik kan gebruiken voor de hitcounter-table.
 
Ward van der Put
Moderator

Ward van der Put

05/02/2019 18:00:08
Quote Anchor link
De finger print van user agent + IP-adres is redelijk uniek. Als je daar nog een cookie met een unieke ID aan toevoegt, kun je veel clients ook nog herkennen vanaf een ander IP-adres.
 
Rob Doemaarwat

Rob Doemaarwat

05/02/2019 19:16:32
Quote Anchor link
Waarom neem je de tussenstap van de hitcounter tabel? Bang voor (table) locks?
 
- Ariën -
Beheerder

- Ariën -

05/02/2019 19:24:40
Quote Anchor link
Nee, ik wil bijhouden of iemand al eerder het item bekeken heeft. Dan lijkt een hitcounter-table mij de beste oplossing, waarna je dan per item alle hits met regelmaat extraheert naar een aantal unieke bezoeken voor in de tabel van de items. Of weet jij wat beters?
Gewijzigd op 05/02/2019 19:24:56 door - Ariën -
 
Ozzie PHP

Ozzie PHP

05/02/2019 20:53:28
Quote Anchor link
Kun je iedere pagina niet een ID geven en dan als de pagina wordt bezocht het bezoekersaantal van die pagina met 1 ophogen in de database en in de sessie bijhouden welke ID reeds door de bezoeker is bekeken? (eventueel met timestamp)
 
- Ariën -
Beheerder

- Ariën -

05/02/2019 21:41:45
Quote Anchor link
Je verschuift de tijdelijke opslag van het aantal hits dus dan naar de sessie-kant in plaats van de database.

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.
 
Thomas van den Heuvel

Thomas van den Heuvel

05/02/2019 21:54:20
Quote Anchor link
- 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.
 
Ozzie PHP

Ozzie PHP

05/02/2019 21:59:12
Quote Anchor link
>> 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.
Gewijzigd op 05/02/2019 22:07:32 door Ozzie PHP
 
- Ariën -
Beheerder

- Ariën -

05/02/2019 22:15:34
Quote Anchor link
@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.

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.
 
Ozzie PHP

Ozzie PHP

05/02/2019 22:19:37
Quote Anchor link
>>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.
 
Thomas van den Heuvel

Thomas van den Heuvel

05/02/2019 22:31:13
Quote Anchor link
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.
 
- Ariën -
Beheerder

- Ariën -

05/02/2019 22:41:05
Quote Anchor link
@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.
Gewijzigd op 05/02/2019 22:43:16 door - Ariën -
 
Bart Smulders

Bart Smulders

05/02/2019 22:49:10
Quote Anchor link
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)

Hopelijk ben je er wat mee :)
 
- Ariën -
Beheerder

- Ariën -

05/02/2019 23:28:16
Quote Anchor link
@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.
Gewijzigd op 05/02/2019 23:29:00 door - Ariën -
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.