我的报告几个月来一直运行相同的结果，这是为什么？我正在运行一个基于社区成立以来活动的报告。这段时间社区一直越来越活跃。
例如，一个用户在查询结果中显示查看了271个主题，而他们的个人资料摘要显示查看了1.2k个主题。
在这里对 Meta 运行查询，统计数据在我更改“duration”值时确实会更新，因此它似乎没有卡在任何地方。我也将其运行了 90 天的持续时间，并将其与一位主要活动在此期间的新用户进行了比较，他们的统计数据与他们的摘要相符。
我还能检查些什么来尝试复制吗？
1 个赞
也许您可以为我澄清一些事情。
我试图从 439 天前开始运行一个查询（以一个特定用户的注册日期作为测试），并将持续时间日期设置为相同天数。我原以为这会包括他们注册以来的所有参与数据。但是，数据并未反映这一点。
我该如何实现呢？
1 个赞
看起来，从 439 天前至今的用户参与统计查询仅包含当时已注册且活跃的会员。它不包含在此时间范围内注册并活跃的会员的参与数据。
有人能帮我自定义报告以创建我需要的数据吗？我对 SQL 的了解仅限于表面水平。
1 个赞
查看报告，它似乎是按“访问次数”排序的，最多的排在最上面——所以任何在您选择的时间窗口中间加入的人都会在列表的某个位置（可见列表限制为 1000，但我认为如果您将结果导出为 CSV，可以获得 10,000 条）。
不过，我们可以创建一个自定义查询。 
您具体在寻找什么数据？
1 个赞
我们甚至还没有那么多会员……但一切都还好。
太棒了
有一点需要澄清的是，每一列是如何计算的。CSV 文件与会员个人资料摘要页面上的数据存在差异（注意：我们仅在查询日期与会员注册生命周期匹配的情况下，比较这两个不同的数据集）。
- 参与统计数据，针对所有访问次数为 1 次或更多的会员，无论他们在查询期间何时加入。
- 每月月底拉取统计数据，以显示自我们新社区启动以来的累积参与度。
我们认为，考虑到查询的时间范围（:from_days_ago 和 :duration_days），这就是它一直在生成的数据。
1 个赞
我今天早上一直在探索，看看是否能找出更多信息。当我尝试回溯 498 天（到我的开始日期）时，我的系统会超时 
，但我设法获得了一年的数据，可以大致与用户统计数据进行比较。 （可能相差几个小时的数据）
posts_created（创建的帖子）、topics_created（创建的主题）、likes_given（给出的喜欢）和 likes_received（收到的喜欢）在两者之间存在差异——仔细查看 SQL，似乎用户参与统计查询没有排除已删除的帖子、悄悄话或私人消息，这可能是造成差异的原因。
topics_viewed（查看的主题）和 posts_viewed（查看的帖子）在这两者之间似乎都相当准确。
我不确定为什么有些用户没有显示出来？我认为我看到的唯一排除标准是他们在时间窗口内必须阅读了超过 0 篇帖子——这应该包括几乎所有人，除了暂存用户。
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
我会继续挖掘，看看是否能找出更多信息。
我的差异是相反的：查询数字较小，而不是较大。
当我输入 441 到 :from_days_ago 和 441 到 :duration_days 时，我会得到以下（下方）结果。与同一时间范围的此报告相比（至少……对于突出显示的用户）。
如果你想让窗口从今天开始回溯 441 天，我认为你需要将其设置为 0 和 441？
我在你回复前几分钟就意识到了，哈哈哈。感谢你的耐心。
…
我把 :from_days_ago 改成了 0，一切都说得通了！！ 
看起来我的大脑在处理 :duration_days 时是按时间顺序工作的。我以为 :from_days_ago 是查询会拉取数据的开始日期，然后继续进行，按时间顺序工作（意味着 441 天前、440 天前、439 天前的数据，一直到当前时间）。看起来它是按时间倒序拉取数据的。明白了！
1 个赞
哈。 没关系。 
我从研究那份报告中学到了很多东西，所以它还是很有用的。
2 个赞
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.