KPI Dashboard: Active forum contributors should discount answers on own thread


6 years ago
6 years ago


(Reporter: ibai, Assigned: rrosario)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: u=sumo-team c=kpidash p=1)



6 years ago
This is related to this:

Checking the numbers for contributors in the Forum I found out that we are counting the answers to own threads. In other words, a user following up on it's own thread could appear in the metric if there's a lot of back and forth.

Please, add a condition so the answers to your own thread are not considered answers.

For reference, in January we have 40 real contributors out of 54 appearing in the KPI dashboard.

If it helps, the query that i'm proposing is (I assume it can be polished):

SELECT answer.creator_id,
FROM `questions_answer` answer
INNER JOIN questions_question question
ON answer.question_id =
WHERE answer.created BETWEEN "2012-01-01 00:00:01" AND "2012-01-31 23:59:59"
AND answer.creator_id <> question.creator_id
GROUP BY answer.creator_id
HAVING COUNT(answer.creator_id) >= 10


6 years ago
Whiteboard: u=sumo-team c=kpidash s=2012.5 p=

Comment 1

6 years ago
I thought that was what the 10 was all about. If we add this condition can we lower or remove that minimum count? Or can we get the same effect by increasing minimum count?

Comment 2

6 years ago
After playing with the numbers and replies, the confidence level of measuring people answering questions is high if we do the following:

- Discard answers from threads started by replier.
- Have 2 or more answers in certain period. 

I'm playing with the weekly stats and it works really well. The 10 answers is a really random number that doesn't solve initial issue described by Ricky.

Also, having a simple (2+) method will make it really easy to move to weekly numbers.
Yeah, the reasoning was that a discussion that goes over 10 posts is really rare, so we'd only count real contributors, apparently not. Let's go with Ibai's suggestion. The time period remains at last 30 days.


6 years ago
Priority: -- → P2

Comment 4

6 years ago
Hoping we can get from where we are to this without ditching the ORM. Optimistically making it a 1pter.
Whiteboard: u=sumo-team c=kpidash s=2012.5 p= → u=sumo-team c=kpidash s=2012.5 p=1


6 years ago
OS: Mac OS X → All
Hardware: x86 → All

Comment 5

6 years ago
Pruning 2012.5 bug list.
Whiteboard: u=sumo-team c=kpidash s=2012.5 p=1 → u=sumo-team c=kpidash s=2012.6 p=1

Comment 6

6 years ago
Sprint based milestone :-)
Target Milestone: --- → 2012.6


6 years ago
Whiteboard: u=sumo-team c=kpidash s=2012.6 p=1 → u=sumo-team c=kpidash p=1


6 years ago
Target Milestone: 2012.6 → 2012.7

Comment 7

6 years ago
I already looked at this a bit. We probably have to switch to a raw sql query.
Assignee: nobody → rrosario

Comment 8

6 years ago
I played with the minimum number of replies and the result varies a lot based on it.

For February 2012, I get the following numbers:
2+ replies: 257
3+ replies: 135
4+ replies: 97
5+ replies: 72
6+ replies: 59
7+ replies: 50
8+ replies: 46
9+ replies: 45
10+ replies: 43
And so on.

Our current method (10+ replies including replies to your own question) is reporting 53.

Where should we make the cutoff to count the user as a contributor? It looks like we have 100-200 casual contributors (I am probably in that bucket) and 40-50 core contributors. What number do we want to count for the KPI?
We had agreed on 10 posts assuming it did not include replies to your own question, so I think we can move forward with that.

Comment 10

6 years ago
F() expressions saved me from needing a full raw SQL query \o/.

Landed on prod, it takes the caches up to 3 hours to update.
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.