Calculate Time for Request Fulfilled

For engineers Tracking SDKs
1

Hi! I was just wondering what would be the best way to track how long a certain request takes? E.g. if a user clicked a button that said “refresh data”, and it was a large request so it took 10 seconds before that data was fetched and displayed on the page, is there some way I could track that that action took 10 seconds? Thanks so much!

2

There’s a couple of different ways of handling this but I’ll walk through the two that immediately come to mind.

The first (and simpler) option is to have a single event that is responsible for recording both the time of the click when the user selects the button and then sends once the response is either successful or produces an error. You could calculate the difference between the two timestamps client side or you could have this as two separate fields. This might look like a self describing event as follows:

{
"action": "refresh_data",
"request_ts": "2022-01-01 00:00:00.000",
"response_ts": "2022-01-01 00:00:10.000",
"response_time": 10.0,
"error": False
}

You could fire this event in a number of different ways (depending on your platform) but you may want to consider pushing an event to the dataLayer - or potentially using something like a MutationObserver which listens to when the chart (or table or whatever the control is) is rendered.

The second method is a bit more comprehensive but is a little bit more involved from the analysis side. In this model we’d track the start of the interaction and the subsequent result as two separate events.

          ┌──────────────────────────┐
          ├──────────────────────────►
          │ refresh            result│
Option 1  │                    event1│
Option 2  │ event1             event2│
          │                          │
          └──────────────────────────┘

We’d capture largely the same data here but we now need to match the events together in order to calculate the difference between event 2 and event 1. This seems like more work compared to option 1 so why would we want to do more work?

Other than greasing the wheels of the capitalist machine it also serves to potentially give us more information that we might miss otherwise if we are only relying on the event firing after the data has rendered.

This might include things like:

  • the user requesting the data to refresh and abandoning the page because it takes too long to load (in option 2 we would see event 1, in option 1 we wouldn’t see any event!)
  • the user clicking the refresh button repeatedly (before the data renders) which might indicate that the user isn’t aware that an operation is progressing (in option 1 we would see a single event1 and would need to pick how we measure the ‘start’ of the request, in option 2 we’d see multiple event1s and a single corresponding event 2).
  • instances where the data just doesn’t render at all (and might indicate a problem with the request, in option 1 no event (unless we capture error cases here))
  • we treat the interaction more as a timeline, so this allows us to more easily sequence other events that might happen in the interval e.g., does the user hit ‘refresh data’ and then background the tab while they wait for the chart to load?

Option 2 is the more complex to implement and may give more information depending on what you are after. One thing to consider is how to join these events over time (event1 + event2) for this reason I’d recommend considering having a unique key for a data request that is generated at request time (this could be a hash of parameters or just a persistent id) and attached two both events e.g.,

{
"action": "refresh_data",
"request_ts": "2022-01-01 00:00:00.000",
"request_id": "123"
}

{
"action": "refresh_data",
"response_ts": "2022-01-01 00:00:10.000",
"render_ts": "2022-01-01 00:00:10.300"
"request_id": "123"
}
1 Like