Question about how the performance timing context work


I have just enabled the performance timing context for our company’s web application (after reading this post).

I understand how it works for pageview events, but not sure how to interpret the numbers when it comes to struct and unstruct events. Our app’s frontend use Vue.js.

  • Link click: In the following example, we first clicked on a link and that created a first struct event, then event was followed immediately by a page_view event. What does this mean?

    After that, they are also followed by another pair of link click - page view events with the same timings. Not sure what can possibly cause this.

  • Activities on a modal: In the following example, we opened a page, then clicked a button on the page to open a modal. On the modal we completed some tasks, then finally click confirm to close the modal. After than we opened some other modals, but it looks like everything that happens on these modal has the same timing with the first page_view event because opening amodal does not make a new page_view happen.

We want to capture the actual time spent on each of these modals, is it possible?

Thanks in advance!

Hi @hoanghapham

Firstly, your link click example:
This look like there is a link on the /home page which takes a user to a /dashboard page. So the link click happens first then the page view happens on the next page (/dashboard). Is there no page view tracking on the /home page perhaps?

As for the timings, is this a single page application (SPA)? We read these values on each event from the performance.timing API and the browsers will only populate these on initial page load. There isn’t a way for the Snowplow tracker to reset these values using the performance.timing API on virtual page views within a SPA. However, this is generally all that is required on a SPA because it’s the initial page load that is the most important one, however we have been thinking about utilising some of the newer browser features to improve our performance timing context lately, so you might see some improvements in this area.

Secondly, the model activity. Again the performance timing metrics aren’t really the right fields to be using for this. What you want to be doing is looking for the first page_view on the model and then the last unstruct event and then taking the difference between the derived_tstamp of the two.
Generally, I’d suggest building an aggregate table that will allow you look at each modal window “session” and get the lengths of them. You can take inspiration from our Web Model on how to build aggregates on Snowplow data. Take a look at the model and see how we aggregate page ping events to find out how long users have been active on a page.

Other than that, if you want to performance a query on the atomic data to work this out, you could use the analytic functions in BigQuery. for the docs, and there are lots of good examples scattered across StackOverflow that should offer some clues on how to solve this for your exact use case, just one example:

1 Like

Thanks for your answer Paul.

  1. Yes this is an SPA, I forgot to mention that. From your answer, can interpret that the timing does not belong to the initial link click event, but belongs to the following page_view event - is this correct?

  2. Thanks for the suggestion. For more context, on a single page of our application, the user can open multiple modals and perform different tasks (write something, click some buttons etc…) We want to check if users experience any slowness in any of these tasks. Some we can check using backend log, but there are delays after you click buttons that we think can only be checked from the front-end side.

As you can see in the following gif, the user opened the same modal twice but did things a bit differently.

However, every action will share the same timing of the initial page view so we won’t be able to know if any action has low performance.

We want to “stitch” activities on each modal instance together, so we are thinking to implement a custom “modal view” context along with Snowplow’s page view context. This context should generate a unique “modal view ID” just like the page view ID.
Is this possible?

The timings on the link click will be attributed to whatever timings were available from the browser based on the first page render of the SPA. The Page View event doesn’t really have much to do with it, we read the browser performance values and attach them as a context on each event.

As for page speed monitoring, you might find something like perfume.js useful. You could read the values from this library and attach them as a custom context when you fire events. You’d need to build a custom schema and upload it to your iglu repository to track this additional information.

1 Like

Thanks a lot Paul! Will check this out.

1 Like