Page MenuHomePhabricator

Resurrect the Session Funnel.
Closed, ResolvedPublic2 Story Points


The SessionFunnel class (which is already built into the app, but currently unused) can provide extremely valuable insights into user behavior. Let's revisit this funnel, clean it up, and add a few more things to it: (comments welcome)

  • Number of pages the user visits, categorized by source (i.e. how many pages visited from History, how many from page links, how many from Search results, etc)
  • Total time that the user spends reading the page. If more than one page was visited, the average time per page will be taken.
  • Total amount that the user scrolls through the page (or what percentage of the page the user scrolls through). If more than one page was visited, the average scroll percentage will be taken.
  • Average load time (network latency) of page requests during the session.


Event Timeline

Dbrant created this task.Sep 4 2015, 5:00 PM
Dbrant raised the priority of this task from to Normal.
Dbrant updated the task description. (Show Details)
Dbrant moved this task to Next Sprint on the Wikipedia-Android-App-Backlog board.
Dbrant added a subscriber: Dbrant.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 4 2015, 5:00 PM
MBinder_WMF set Security to None.Sep 11 2015, 5:46 PM
MBinder_WMF edited a custom field.

It looks like the schema for this is MobileWikiAppSessions[0], emphasis on the plural.


Sorry, I'm not sure if this is ready to work on yet or not. @Dbrant, were there any changes needed to the schema? Apologies if I've missed an email.

Dbrant claimed this task.Oct 5 2015, 4:09 PM
Dbrant moved this task from To Do to Doing on the Mobile-App-Android-Sprint-67-Holmium board.
Dbrant updated the task description. (Show Details)Oct 5 2015, 8:55 PM

Change 244693 had a related patch set uploaded (by Dbrant):
[WIP] Revive the session funnel.

Change 244693 merged by jenkins-bot:
Revive the session funnel.

Tested on my 4.4 and 6.0 physical devices. It seems to be working fine. A few notes:

  • I wasn't able to verify any page views from an external link, since external links target the production app and session logging isn't yet in production. Likewise with the RESTBase API mode, which isn't yet in use.
  • Logged sessions with length of 1 second and zero pageviews are surprisingly common. Do we want to keep these, or should we consider filtering them out up front? They wouldn't seem to provide much insight.
  • This is more a question of schema design, but: is there any particular reason we're interested in how many pages were arrived at from a disambiguation link? Most of the logging concerns features available in the nav menu for which we want to know more about engagement, but do we care one way or the other about disambiguation pages for our purposes here?
Dbrant closed this task as Resolved.Oct 26 2015, 3:17 PM