Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I wrote up a <a href="http://www.kamsky.org/1/post/2013/10/aggregating-over-time.html" rel="nofollow">complete answer on my MongoDB blog</a> but as a summary, what you have to do is project your actions based on which ones you care about to map values of action field into appropriate key names, group by person aggregating for the three actions when they did them (and optionally how many times) and then project new fields which check if action2 was done after action1, and action3 was done after action2... Last phase just sums up the number of people who did just 1, or 1 and then 2, or 1 and then 2 and then 3. </p> <p>Using a function to generate the aggregation pipeline, it's possible to generate results based on array of actions passed in. </p> <p>In my test case, the entire pipeline ran in under 200ms for a collection of 40,000 documents (this was on my small laptop).</p> <p>As it was correctly pointed out, the general solution I describe assumes that while an actor can take any action multiple times that they can only advance from action1 to action2 but that they cannot skip directly from action1 to action3 (interpreting action order as describing prerequisites where you cannot do action3 until you've done action2).</p> <p>As it turns out, aggregation framework can be used even for sequences of events where the order is completely arbitrary but you still want to know how many people at some point did the sequence action1, action2, action3.</p> <p>The main adjustment to make on the original answer is to add an extra two-stage step in the middle. This step unwinds the collected by person document to re-group it finding the first occurrence of the second action that comes <em>after</em> the first occurrence of the first action.</p> <p>Once we have that the final comparison becomes for action1, followed by earliest occurrence of action2 and compare that to the latest occurrence of action3.</p> <p>It can probably be generalized to handle arbitrary number of events but every additional event past two would add two more stages to the aggregation.</p> <p>Here is <a href="http://www.kamsky.org/1/post/2013/10/more-on-aggregations-over-time.html" rel="nofollow">my write-up of the modification of the pipeline</a> to achieve the answer you are looking for.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload