Discussion :

[Invité]

Bonjour,
je souhaite mettre en place un système de compteur de clics sur des liens, MAIS avec possibilité d'affichage de statistiques : nombre de clics par jour/mois/année...
Et je me questionne sur la façon la plus efficace d'y parvenir.

La simple incrémentation d'un compteur (ça, je sais faire) n'est pas suffisante.
Il faut aussi enregistrer la date (timestamp ?) au moment du clic (?)

J'ai penser à :

• créer une table T_STATS_URL_CLICS
  - id_lien (identifiant du lien cliqué)
  - url_lien (URL cliquée)
  - clic_time (timestamp du clic)
• et AJOUTER 1 LIGNE à chaque clic

Pour l'affichage par jour/mois/année, il suffira alors d'une requête sur un intervalle de temps donné. (ça, je sais faire)

INCONVÉNIENT : je risque de me retrouver rapidement avec des milliers, voire des millions de lignes !

QUESTION : est-ce la bonne méthode ? (+ le nombre important de lignes générées ne risque-t-il pas d'être un problème ?)

Sinon, avez-vous une méthodologie plus efficace à me proposer ?

Merci

[Spartacusply]

Pour limiter le nombre d'enregistrement dans ta bdd, tu peux te baser sur l'intervalle le plus court que tu souhaites afficher.

Si c'est à l'heure près par exemple au plus fin, tu rajoutes une seule ligne dans ta base par heure, avec un compteur que tu incrémentes sur cette heure là.

Évidemment si c'est à la seconde près ça ne sert pas à grand chose, mais même à la minute près, ça te limite à 1440 (24*60) enregistrements maximums par jour et par lien dans ta base, même si tu as des milliers de clic ce qui n'est pas négligeable. Avec quelques index bien placés, ça devrait tourner sans problème.

[Invité]

Merci pour vos réponses.

cela dit, est-ce la méthode la plus couramment utilisée et la plus efficace pour réaliser des statistiques ?

En l’occurrence, je souhaite connaitre les stats des clics sur les liens de produits, c'est-à-dire combien de fois on a cliqué :

• sur le lien du produit en page d'accueil ("produits phare")
• sur le lien du produit dans la liste des produits ("galerie de produits")
• sur le bouton de commande (dans la "fiche produit")
• ...

Bref : des stats sur des évènement précis et différents.

=> Ce qui risque de générer beaucoup de lignes en BdD... et qui m'inquiète donc, en terme de performance (des requêtes) et stockage des infos.

[Spartacusply]

Je me permet de rajouter que, si vraiment les nombres de clics sont importants et que le nombre de connexion avec la bdd pose problème, tu peux utiliser un système de cache pour php comme APC, MemCached ou phpredis qui possèdent des fonctionnalités pour incrémenter et décrémenter des compteurs de manière atomiques (c'est prévu précisément pour des utilisations comme celle là en fait).

Une petite cron lancée ensuite à intervalle régulié pour stocker tout ça en base et le tour est joué.

Ca revient en fait à la solution de Celira mais en utilisant le Cache en tant que table temporaire ce qui sera beaucoup beaucoup plus performant.

[Invité]

Utilisation du cache, cron... sont pour l'instant en dehors de mes compétences/connaissances...

N.B. J'ai vu qu'OVH propose une méthode simple pour les tâches automatisées :

• OVH - Comment exécuter un script automatiquement sur le serveur mutualisé (en CRON) ?

Je vais étudier ça de plus près. Merci.

[Celira]

Bon, je préviens tout de suite : je n'ai jamais mis en place ce genre de système. C'est une idée, mais pas sûre que ce soit une bonne idée.

Supposons qu'on veuille conserver des stats à l'heure près.

On fait deux tables :
une pour les données courantes (T_STATS_URL_CLICS_CURRENT) avec pour structure :
- id_lien (identifiant du lien cliqué)
- url_lien (URL cliquée)
- clic_time (timestamp du clic)
et une pour la conservation (T_STATS_URL_CLICS_MAIN) avec pour structure :
- id_lien (identifiant du lien cliqué)
- url_lien (URL cliquée)
- clic_time (timestamp du clic)
- compteur

A chaque fois que quelqu'un clique une lien, on fait une ligne lien/timestamp dans la table CURRENT.

On fait un traitement périodique (genre qui tourne à 3h du mat) qui lit les données de CURRENT datant de la veille, les regroupe par tranche d'une heure, insère les compteurs dans la table principale et supprime les données correspondantes de la table CURRENT.

De cette façon, on a plus que 24 lignes par lien et par jour dans la table principale (avec le compteur qui correspond à tous les clics de cette plage d'heure), et la table temporaire est purgée régulièrement.