Page MenuHomePhabricator

Add local tracking for time spent on Article - iOS
Closed, ResolvedPublic8 Estimated Story Points

Description

Background

In 2024-2025 the iOS team built a personalized Wikipedia Year in Review feature T371946. During development and after release, we identified several improvements to the App's local tracking that need to be made in early 2025 so that we have data for the version that releases on Android and iOS in December 2025. that can be made if we iterate on this project with a version for 2025.

Total time spent on the app, or time spent on different articles was the 3rd most popular personalization request from users in the the feedback survey on iOS's year in review.

User stories
  • I would like to see my total time spent on the Wikipedia App so I can understand how much I depend on Wikipedia throughout the year.
  • I would like to see which articles I spent the most time reading, so I can learn more about my learning journey this year.
Requirements
  • Locally store the number of seconds a user spends on an article
  • Data should be accessible for use in a Year in Review report / slide, for statistics like
    • Total time spent in the App
    • Article they spent the most time on
    • Average time spent on an article
  • Information should be cleared whenever they clear History
Progress

Here's what I think re: subtasks. I can't remember if we discussed approach. Points in brackets.

  • Update WMFData core data database to accept new data.
  • Increment WMFData's core data database model version. In new version add a number of seconds field to CDPageView.
  • Persist initial number of seconds a user viewed article.
  • In ArticleViewController, upon disappearance (pushing to new screen, backgrounding, presenting new screen), calculate the number of seconds they were on that screen. Then update the article's page view core data record (will be created in persistPageViewsForWikipediaInReview) with those seconds
  • Append any subsequent number of seconds the user viewed the same article. For example, if they background the app from an article, then foreground it later, we need to start a new timer, then when they leave the article, append the new seconds to the initial seconds in the record from step 2.
  • Keep a separate track of "total time spent in the app". This is in the requirements, to me it's a different calculation from per-article seconds. We should maybe hook into SessionFunnel's logPreviousSessionEnd seconds and persist those values. I advise just incrementing a mega-basic UserDefaults value with the sessionMilliseconds in that method.
  • Clear step 4 data when "Clear history" button is pressed. Steps 2 & 3 data (CDPageView) should already be cleared when this button is press
Engineering Notes
  • We already have a boolean value “Was significantly viewed” true or false - if they are on an article for 30 seconds or more, we turn this on. This powers the "Because you read" explore feed card
  • We could start tracking the amount of time they spent on an article here instead of or in addition to the boolean value
QA Notes

Please keep an eye out for regressions article loads and in general app performance over time.

Event Timeline

Mazevedo set the point value for this task to 8.Mar 6 2025, 6:44 PM

@Mazevedo Android realized that they already had this tracking in place (https://phabricator.wikimedia.org/T388072) does that change the estimate at all if we can copy over from Android in any way?

@Mazevedo Android realized that they already had this tracking in place (https://phabricator.wikimedia.org/T388072) does that change the estimate at all if we can copy over from Android in any way?

@HNordeenWMF, not necessarily. It can help us match their business logic for recording these values but not the implementation.

With this task, we started using a Fibonacci scale to give us more granularity; 8 is an evaluation of complexity and not days of work. We're trying this new method to see if we can be more accurate; we want to check if this is more effective than using days.

Hi @HNordeenWMF,

Is it okay if article seconds continue to aggregate if a user goes down a modal flow, such as Article > Profile > Settings, or the editing flow? I'm having a difficult time with stopping (and especially restarting) the timer in these modal flows, when something is presented on top of the article, then is later dismissed and the article is revealed again. This is due to a limitation with the platform APIs - there's no single hook for communicating that any modal flow has completed and the article is revealed again (our typical viewDidAppear on article doesn't consistently fire for partial-view modals).

If it is not okay, it may be helpful if you could specify which modal flows must stop the article seconds from aggregating and must restart once those flows are complete. There are a lot of possible modals that could display on top of Article (something that we have not yet had time to fully audit), so if you could give me the top priority flows I could try to only fix it in those cases.

What I have working so far:

  1. Visiting Article 1 begins aggregating seconds on Article 1.
  2. Tapping a blue link to Article 2 stops aggregation on Article 1.
  3. Tapping Back on Article 2 restarts aggregation on Article 1.
  4. Backgrounding on Article 1 stops aggregation on Article 1.
  5. Foregrounding on Article 1 restarts aggregation on Article 1.
  6. Tapping Back on Article 1 stops aggregation on Article 1.

It's ok to have seconds continue to count if someone edits on an article, or opens a modal flow on top of the article.