Track activity per section

1

Hi! :wave:
I’m new to Snowplow. I want to implement it to track the time spend by users on different contents on a SaaS application.

On each page, I have sections like this:

<section id="ee89fca5-9a68-40e7-8b7f-7c028d3febd7">
  <p>Section 1</p>
</section>
<section id="3dea8034-72bf-44d3-8e39-9f094c5f9aad">
  <p>Section 2</p>
</section>

I want to be able to track the time spent on each of those sections.

It seems that activity tracking (enabled with enableActivityTracking ) could be a good way to track the time spent but it was made to track time on pages not specific items (sections in my case).
What would be the best way to do it ?

I was thinking about using enableActivityTracking and add a custom context containing the sectionId.
Then I would model the data with DBT to extract the time spend on each section from the page_ping events.

Does it seems like a right way to achieve my goal ?
Can the dbt package snowplow-web help me to do this ?
Any advice on how to do it and how to have the most reliable analytics ?

Thanks

2

Do you want to track active time in those sections (do they contain any interactive components?) or just the time these sections are in view for?

You are right - activity tracking is really designed for the whole page rather than individual elements - so you are best off defining (and then aggregating) your own ‘element’ pings for these elements when they are in the viewport / being interacted with. This is possible with a bit of custom code but is quite a bit easier using a tag manager (e.g., GTM) where you can trigger based on the viewability of an element.

There are likely to be a couple of factors to consider as you implement this:

  • Can multiple sections be viewable at once? (in which case you’ll want to aggregate against the element)
  • If a user scrolls the section back into view do you want to maintain the original time or reset from zero? How do you want to aggregate this data? Within a single page view, within multiple page views, within a single session, across a single user etc?
  • How much of the section has to be viewable (in the viewport) before you start / stop the timer?
  • How accurate do you need the time spent to be? (this will determine how often you’ll want to fire those pings)
  • How are these sections defined? (are they ordered in any way, how are they labelled?) A typical way to do this would be to use data-attributes in the markup for your sections and send this.
3

Do you want to track active time in those sections (do they contain any interactive components?) or just the time these sections are in view for?

I mainly want to track the time those sections are viewed

Can multiple sections be viewable at once? (in which case you’ll want to aggregate against the element)

Yes

If a user scrolls the section back into view do you want to maintain the original time or reset from zero? How do you want to aggregate this data? Within a single page view, within multiple page views, within a single session, across a single user etc?

I think that I want something similar to the engagement time for pages (cf. https://docs.snowplow.io/docs/modeling-your-data/modeling-your-data-with-dbt/dbt-models/dbt-web-data-model/#engaged-vs-absolute-time):

image
image786×227 8.04 KB

→ How can I acheive this with DBT?

How accurate do you need the time spent to be? (this will determine how often you’ll want to fire those pings)

I guess I would like to achieve an accuracy around 1 to 2 second. Is it reasonable in terms of performance/cost ?

How are these sections defined? (are they ordered in any way, how are they labelled?) A typical way to do this would be to use data-attributes in the markup for your sections and send this.

Not sure I understand the question, but I have a UUID for each section that I could store in any format I want (including data attributes)

4

I don’t want to derail where Mike was going, so won’t cover everything, but some info/features which might be helpful in looking at this:

Engaged time is calculated in the dbt web model the same way as other models. They’re all open source so you can look at the source code to discover how it’s done.

The models will aggregate to a page view level. If you have a UUID per component, one option is to track it as a global context, and run a similar logic to what I linked above, but grouped by your UUID rather than page view ID. You would have to do this separately as your own custom modeling logic which joins into the standard models.

Alternatively, if you like you can somewhat simplify the problem by manually tracking page views for each component and treating them as separate pages. This may or may not make sense.

Another approach would be to leverage edge analytics to achieve what you want using some clever javascript.

2 Likes