Page MenuHomePhabricator

[SPIKE] Explore instrumentation for ToC
Closed, ResolvedPublic

Description

Background

The goal of the new table of contents is to make ToC navigation usually found at the top of the page more easily accessible from everywhere within the page, as well as to provide context on the the article throughout the reading experience, from the location where a reader is reading to larger context on the topic and individual sections.

We would like to measure the effects of introducing the change and the success of the goals stated above quantitatively.

Questions

  1. Is the new table of contents is used more frequently than the previous table of contents
  2. Does the new table of contents reduce the need to scroll back to the top of the page
  3. Does the new table of contents decrease the time people spend scrolling/scrolling quickly (if possible)
  4. How does the new table of contents affect the time spent on a page
Data instrumentation process step (bolding indicates current step)
  1. PM and Data Analyst coordinate to identify research questions, hypotheses, and guardrails for the new feature and associated metrics.
  2. Data analyst creates a list of events that need to be tracked to calculate each metric
  3. Engineers review the event list and comment on whether we’re already tracking with existing instruments and if new instrumentation is required. New tickets created for any new instrumentation needed.
  4. Data analyst works with engineers to figure out what the new instrumentation should look like and where to store the events.
  5. Data analyst documents all of the above in the instrumentation spec
  6. PM signs off on the plan
Documentation

Instrumentation spec for table of content

Event Timeline

  1. Action items
  2. Extend scroll schema to support "scroll to toc" and possibly "scroll to subsection" events. For subsections it might make sense to use the onhashchange event
  3. Extend click tracking to capture clicks in table of contents (new and old)
  4. Spike ways to do an A/B test for anonymous users. Review all possible options:
    • We could show both the new and the old in one variant of the test, and in the other just show the article (it's not a performance issue to show/hide new table of contents via JavaScript),
    • Talk to traffic about disabling caching on certain pages and using those for the experiment e.g. top ten articles
    • Talk to traffic about disabling caching for a (small) project and run A/B test there
    • A/B sampled by page
    • A/B only enabled on subsequent page views (to allow hiding variant A or B without a reflow)
    • A/B on logged in users
  5. For time spent on page we can enable ReadingDepth on desktop improvements project, maybe disable on English Wikipedia as volume is a concern. We can join this with the AB enrollment test

@Jdlrobson , @ovasileva I have created an instrumentation spec and documented the events that need to be tracked to calculate each metric.

Resolving, instrumentation will be completed in T299513: Instrumentation needs for ToC