Notre site auto-hébergé exige que tous les utilisateurs soient enregistrés, pas d’anonymes, et que tous les comptes soient approuvés par un modérateur, généralement dans l’heure ou les deux heures suivant la demande.
Nous avons remarqué deux nouveaux utilisateurs, l’un ayant 8 heures depuis sa création, signalé comme ayant visité pendant 2 jours. Un autre, créé il y a 1 jour, signalé comme ayant visité pendant 3 jours.
Nous avons cherché et trouvé le post « Anomalie des jours visités », mais cela ne semble pas pertinent. Que dois-je vérifier pour voir ce qui ne va pas, ou ce que nous faisons mal ?
Désolé pour ma réponse tardive. Un peu de pluie excessive à Santa Barbara m’a détourné.
Tous nos utilisateurs s’auto-enregistrent, donc les comptes sont créés de cette façon, puis nécessitent l’approbation d’un modérateur avant de pouvoir accéder au forum. J’avais pensé qu’il pourrait y avoir un problème de « passage à minuit » où un utilisateur s’enregistre à 21h00 puis est approuvé à 01h00, apparaissant ainsi sur deux jours, mais il y a l’utilisateur de 3 jours que j’ai posté.
Je ne sais pas depuis quand cela se produit, car je ne regarde pas d’assez près, mais l’un de nos modérateurs l’a fait. Je surveille nos enregistrements entrants pour voir si cela se produit avec chaque nouvel utilisateur.
S’il existe une requête Data Explorer qui pourrait aider ici, veuillez me le faire savoir, je l’exécuterai et je vous ferai un retour.
Merci pour toute aide / éclaircissement que vous pourrez apporter.
Mais l’utilisateur de 3 jours a été créé il y a plus d’un jour. Il pourrait donc aussi s’inscrire avant minuit (jour 1), visiter quelques heures plus tard (jour 2) et un jour plus tard (jour 3). Cela ferait moins de deux jours, donc afficher un jour est correct.
J’ai également vu une différence de 2 jours ici sur meta
Je n’en ai pas trouvé d’existante, mais peut-être quelque chose comme ceci :
SELECT u.id AS user_id,
u.created_at,
u.approved_at,
us.days_visited
FROM users u
JOIN user_stats us ON u.id = us.user_id
WHERE u.approved_at IS NOT NULL
ORDER BY u.created_at DESC
Ou une autre avec un peu plus pour la rendre plus lisible :
SELECT u.id AS user_id,
CONCAT(u.created_at::date, ' at ', to_char(u.created_at, 'HH:MM')) "user_created",
CONCAT(u.approved_at::date, ' at ', to_char(u.approved_at, 'HH:MM')) "user_approved",
us.days_visited
FROM users u
JOIN user_stats us ON u.id = us.user_id
WHERE u.approved_at IS NOT NULL
ORDER BY u.created_at DESC
Merci ! Un nouvel utilisateur vient de s’inscrire, j’ai donc eu l’occasion d’approuver l’utilisateur et de l’exécuter. Les modérateurs ont accès à la requête, j’espère donc que nous verrons des informations utiles à l’avenir.
Je pense que la valeur « Jours visités » change une fois qu’elle atteint exactement 00:00 UTC. Ainsi, un utilisateur peut se connecter avant qu’il ne soit 00:00 UTC, puis être actif jusqu’à ce que l’heure soit atteinte (ce qui augmenterait les jours visités).
Ravi de voir que cela se produit ici chez Meta. Je déteste ça quand je suis le seul, alors on sait qu’on fait les choses mal
J’ai interprété le « Créé : il y a 1 jour » comme hier, car il semble que l’horodatage de création du compte soit le moment où l’utilisateur s’est enregistré, et non le moment où il est approuvé (ce qui est logique puisque l’enregistrement est une visite). Je peux voir « 2 jours visités » avec un passage à l’heure UTC, mais je n’ai pas pu obtenir « 3 jours visités ». Si c’était le cas, « Créé » ne serait-il pas « il y a 2 jours » ?
Cet « utilisateur de 3 jours » n’est pas revenu depuis le 11 janvier, donc le rapport actuel semble correct - du 9 au 11 janvier.
Mais le Data Explorer montre une création le 10 janvier, et non le 9 janvier comme dans l’Activité utilisateur. Y a-t-il un problème d’heure locale par rapport à l’heure UTC ? Peut-être indiquer dans le rapport d’heure quel est le fuseau horaire ? Ces deux requêtes ont été exécutées à une minute d’intervalle.
Discourse enregistre-t-il ce qu’il considère comme une « visite » et sa durée ? Si oui, je pourrais interroger la date/heure d’un utilisateur sur le site ? Ce serait beaucoup de données sur un site fréquenté, alors peut-être ne conserver que les X derniers jours ? Cela permettrait une cartographie sur une chronologie.
Je pourrais créer quelques comptes de test et voir ce qui se passe dans les rapports. Ce n’est pas grave, mais cela fait s’interroger sur d’autres statistiques si nous ne comprenons pas la comptabilité derrière les rapports.
Oui. Lorsque vous affichez un profil, les heures sont affichées dans votre fuseau horaire local au lieu de l’heure UTC, sauf si votre fuseau horaire local est l’heure UTC, tandis que DE affiche la valeur UTC stockée
Edit : J’ai fait quelques tests sur l’utilisateur « 3 jours » que j’ai posté plus tôt, en modifiant la requête pour inclure la première et la dernière fois où il a été vu. Il était connecté pendant un peu moins de 44 heures, couvrant trois minuits UTC (00h00), d’où les trois jours.
Il semble que quelque chose d’étrange se produise lors de l’affichage de l’activité utilisateur, car indiquer « créé il y a 1 jour » tout en ayant « Jours visités 3 » est incongru. Cela semble être le résultat d’une simplification excessive des données.
À mon avis, il serait préférable de simplement afficher les horodatages UTC tels quels et de laisser l’utilisateur interpréter. « Il y a 1 jour » est indéterminé. Combien d’heures dans le passé faut-il pour atteindre un jour ? Il semble que le passage à 00h00 UTC suffise. Donc, un utilisateur créé à 23h59 UTC est « il y a 1 jour » lorsqu’on consulte l’activité utilisateur à 00h01 UTC ?
Cela peut être techniquement correct - si je suis dans le fuseau horaire UTC, cet utilisateur a été créé « hier, c’est-à-dire il y a 1 jour », mais n’importe où ailleurs, ce n’est pas correct, ou du moins pas comme cela serait compris. Je ne suis pas sûr que ce soit vraiment utile pour comprendre l’activité d’un point de vue administratif.
Et je réalise que ma compréhension est encore incomplète, alors merci à tous de continuer à m’éduquer. Pour l’instant, j’ai conseillé à nos modérateurs d’utiliser la requête DE pour comprendre les événements d’un utilisateur s’ils ont besoin d’une précision détaillée.
Je vais transmettre ceci à UX car rien ne semble être cassé (bien que l’information pourrait peut-être être affichée plus clairement). Mais si vous trouvez autre chose plus tard, nous pourrons toujours le renvoyer.
