jlieb10
commented
2 years ago Dotcom/Data: what, when, and how to track
25 May 2022
Attendees
Ash, Max, Oliver, Joshua
Agenda
- How and where should we capture our documentation?
- What do we intend to have built and captured by the end of the quarter?
- What do we intend to have built and captured by the end of the year?
Notes
- How to structure things we want to capture:
- Page-level tracking: scroll depth, time-on-page
- Component-level tracking: data-link-name, data-component-name, possibly data-component-visibility (time-in, time-out)
- Scroll tracking
- ‘Markers’ on the page, marked with a timestamp
- ‘Start’ ‘Middle’ ‘End’ for all or some of components marked ‘data-track-scroll’
- Record the point that scrolling begins as a page-level article
- Milestones vs pixel-depth vs time
- Separate out
- Ensure we are designing in a way that satisfies 62kb-max sendbeacon size (apx. 62,000 characters)
- KR Realistic and desirable for end of next month (KR): Design and agree an API with the wider department, send anonymized scroll depth data to big query
- Difficult to know how far we are likely to get in the next year
Action Items
- Create a PR on GitHub to put a readme that describes the API we intend to build; instructions for future developers using the API via DCR (Oliver)
- Writing with inline documentation using JSDocs, continue (Max)
- Refine the model as is then share a sample of the payload with Guy and Lucy for feedback
- Add percentages (or start/middle/end) for editorial content
- Consider data for ‘visibility’ - time-in/time out
Next Action Items
- Did not yet get a chance to ask where we see the wider migration from tracker.js
We are need to design a general-purpose API that can sit next to tracker.js for the time being, and in time grow to replace the role of tracker.js on DCR.
The requirements are for it to be simple, lightweight, easily and readily used and expanded by devs on DCR. It needs to depend on consents (and needs to be agreed by the consents team) and also needs to be agreed with the Data team, as they will be carrying out the analyses in the first instance. Further requirements: it eventually needs to be able to do everything that tracker.js can do, and additionally we want this to be enhanced by at-minimum scroll tracking and give relative times for user interactions, so in a way this will be able to tell a rich story about the experience on the page.
In terms of tech, we will use big query and send beacon - implementations which are already in place, and can accept 62kb max payloads. Client-side code will be written in vanilla JS so it can be executed ahead of and separate from other scripts.
By the end of the quarter, we would view "success" on the KR as having an API agreed by the department and an implementation of the API for scroll depth, which may need to be anonymised at first if we have not yet come to an agreement with the consents team.
Meeting notes that inform this description, and more follow up items, are below