Pourquoi mon rapport s’exécute-t-il avec les mêmes résultats depuis des mois ? Je génère un rapport basé sur l’activité depuis la création de la communauté. La communauté est de plus en plus active depuis tout ce temps.
Par exemple, un utilisateur apparaît dans les résultats de la requête comme ayant consulté 271 sujets, alors que le résumé de son profil indique 1,2k sujets consultés.
J’exécute rapidement la requête ici sur Meta, les statistiques se mettent à jour lorsque je modifie la valeur « durée », donc elle ne semble pas bloquée quelque part. Je l’ai également exécutée pour une durée de 90 jours et l’ai comparée à un utilisateur récent dont l’activité principale s’est déroulée pendant cette période, et ses statistiques correspondent à son résumé.
Y a-t-il autre chose que je pourrais vérifier pour voir si je peux reproduire le problème ?
Peut-être pourriez-vous clarifier quelque chose pour moi.
J’essaie d’exécuter une requête à partir d’il y a 439 jours (en examinant la date d’inscription d’un utilisateur spécifique comme test) et en choisissant la date de durée comme le même nombre de jours. Je pensais que cela inclurait toutes leurs données de participation depuis leur inscription. Cependant, les données ne le reflètent pas.
Comment y parviendrais-je ?
Il semble également qu’une requête de statistiques de participation des utilisateurs, datant d’il y a 439 jours jusqu’à aujourd’hui, n’inclue que les membres qui étaient déjà enregistrés et actifs à ce moment-là. Elle n’inclut pas les données de participation des membres qui se sont enregistrés après et qui étaient actifs pendant cette période.
Quelqu’un peut-il m’aider à personnaliser le rapport pour en créer un qui capture les données dont j’ai besoin ? Je ne connais le SQL qu’à un niveau superficiel.
En regardant le rapport, il semble être trié par visites, le plus élevé en haut - donc quiconque a rejoint à mi-chemin de la fenêtre de temps que vous sélectionnez sera quelque part plus bas dans la liste (et la liste visible est limitée à 1000, bien que je pense que vous puissiez en obtenir 10 000 si vous exportez les résultats en CSV).
Nous pouvons cependant créer une requête personnalisée. 
Quelles données recherchez-vous exactement ?
Nous n’avons même pas autant de membres… encore, donc tout va bien de ce côté-là.
Hourra
Une chose qui serait utile de clarifier, c’est comment chaque colonne est calculée. Il y a des divergences entre le CSV et ce qui se trouve sur la page de résumé du profil d’un membre (note : nous ne comparons ces deux ensembles de données que lorsque les dates de la requête correspondent au cycle de vie de l’inscription du membre).
Nous pensions, étant donné le cadre temporel :from_days_ago et :duration_days de la requête, que c’était ce que les données produisaient.
J’ai passé la matinée à explorer pour voir si je pouvais en savoir plus. La mienne expire quand j’essaie de revenir 498 jours en arrière (jusqu’à ma date de début 
), mais j’ai réussi à en obtenir une pour un an afin de pouvoir la comparer approximativement aux statistiques d’utilisateur. (à quelques heures près de données)
Il y a une différence pour posts_created, topics_created, likes_given et likes_received entre les deux - et en regardant de plus près le SQL, il semble que la requête de statistiques de participation des utilisateurs n’exclut pas les messages supprimés, les murmures ou les MP, ce qui pourrait expliquer cela.
Les topics_viewed et posts_viewed semblent assez précis pour les deux.
Je ne suis pas sûr pourquoi certains de vos utilisateurs n’apparaissent pas ? La seule critère d’exclusion que je pense voir est qu’ils doivent avoir lu plus de 0 message dans la fenêtre de temps - ce qui devrait inclure à peu près tout le monde, à part les utilisateurs staged.
pr AS (
SELECT user_id, COUNT(1) AS visits,
SUM(posts_read) AS posts_read
FROM user_visits, t
WHERE posts_read > 0
AND visited_at > t.START
AND visited_at < t.END
GROUP BY
user_id
Je continuerai à creuser et à voir si je peux trouver plus.
Mes écarts sont inversés : les numéros de requête sont plus petits, pas plus grands.
Lorsque j’entre 441 dans :from_days_ago et 441 dans :duration_days, j’obtiens ceci (ci-dessous). Comparé à ce rapport pour la même période (du moins… pour l’utilisateur mis en surbrillance).
Je pense qu’il faut mettre 0 et 441 si vous voulez la fenêtre d’aujourd’hui remontant à 441 jours ?
Je m’en suis rendu compte quelques minutes avant votre réponse, hahaha. Merci pour votre patience.
…
J’ai changé :from_days_ago à 0 et tout dans la vie a un sens !! 
Il semble que mon cerveau fonctionnait chronologiquement par rapport à ce que :duration_days signifiait. Je pensais que :from_days_ago était le premier jour où la requête extrairait des données, puis continuerait à le faire, en travaillant chronologiquement dans le temps (ce qui signifie des données d’il y a 441 jours, 440 jours, 439 jours, et ainsi de suite jusqu’à l’heure actuelle). Il semble qu’elle extrait les données dans l’ordre chronologique inverse. Compris !
Ha. Pas de souci. 
J’ai beaucoup appris en étudiant ce rapport, donc c’était quand même très utile.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
