Duration track

  • 26 July 2020
  • 1 reply

I have a certain event that I would like to track the duration of, and there are several user actions that could signal the end of said event. How do I (aka my developer) implement the track call so we receive the duration times correctly, no matter which way the user closed the event at matter?  

1 reply


Hey - I’m Rich and I’m an implementation manager at Mixpanel.

There’s 2 different ways that you can do this. One of them utilizes our Mixpanel time_event method and one relies on you/your dev team setting your own timer.  We’ll run through these options using a scenario where we want to time how long it takes a user to login until they either make a purchase or add something to a wish list. 


Using Mixpanel’s Time_Event Method:

Mixpanel’s time_event method takes an argument for a single event name. Essentially, the way that this method works is that you call the time_event method when you want the timer to start and tell us which event will be fired when the timer should end. Another thing to note here is that if the method is called a second time, it will overwrite the previous timer. 

In theory, we could just set multiple timers on login - one that listens for if a user adds something to their wishlist and one for if a user makes a purchase. However, the downside to this is if a user does both events, then we will have two sets of time for a single user. This isn’t likely what you really want as that single user will affect both the average time to make a purchase and aver time to add something to their wishlist even though they took longer to do one than the other.

So, to get around this problem, we need to create a single event that we can listen for that will end the timer when the first event is triggered. The easiest way to do this would be firing a single ending event for both flows. In this case, when we call the time_event method, we’d have it listen for an event like “conversion_flow_complete”. We would then fire the conversion_flow_complete event when a user made a purchase or added an item to their wishlist and would add a property to that event for which flow they finished. We would fire this event in addition to the event that you already fire as this event is only being used for timing purposes. So, the final flow would look something like this:

  1. User logs in at 9:00 AM; time_event method called with ending event “conversion_flow_complete”
  2. User makes a purchase at 9:05 AM; code triggers a “purchase” event and a “conversion_flow_complete” event with a “flow_completed” property set to “purchase”
    1. Since this is the first conversion_flow_complete event sent since the timer was started, the timer will calculate the duration between login and purchase and append that duration as a property to the event
  3. User adds an item to their wishlist at 9:10 AM; code triggers an “add_to_wishlist” event and a “conversion_flow_complete” event.
    1. Because the previous timer has ended, there will be no duration appended to this conversion_flow_complete event so you can filter it out of reporting based on that value being undefined.
    2. You can also wrap the conversion_flow_complete event in a logic block so that it only fires if no conversion_flow_complete_ events have fired since the user has logged in.

Using Your Own Timer:

You also have the option of setting your own timer to calculate the difference between the login timestamp and the purchase/wishlist timestamp and add that as a property to the purchase/wishlist event. However, you’ll need to build in some logic to ensure that you’re only counting the first conversion and not subsequent conversions as that would artificially drive your ‘average time to convert’ metric higher. So, the overall flow would likely look similar to the logic above, just with your dev team managing timers instead of relying on Mixpanel.