This discussion is about needed updates of the definition and Analytics implementation for mobile apps page view metrics.
==Background / Changes
As you probably remember, the Android app splits a page view into two requests: one for the lead section and metadata, plus another one for the remainder.
The mobile apps are going to change the way they load pages in two different ways:
1) We'll add a link preview when someone clicks on a link from a page.
2) We're planning on switching over the using RESTBase for loading pages and also the link preview (initially just the Android beta, ater more)
This will have implications for the pageviews definition and how we count user engagement.
==The big question is
Should we count link previews as a page view since it's an indication of user engagement? Or should there be a separate metric for link previews?
==Counting page views
IIRC we currently count `action=mobileview§ions=0` query parameters of api.php as a page view. When we publish link previews for all Android app users then we would either want to count also the calls to `action=query&prop=extracts` as a page view or add them to another metric.
Once the apps use RESTBase the HTTPS requests will be very different:
* Page view: Instead of `action=mobileview§ions=0` the app would call the RESTBase endpoint for lead request instead of the PHP API mentioned above. Then it would call .
* Link preview: Instead of `action=query&prop=extracts` it would call the lead request, too, since there is a lot of overlap. At least that our current plan. The advantage of that is that the client doesn't need to execute the lead request a second time if the user clicks on the link preview (-- either through caching or app logic.)
So, in the RESTBase case we either want to count the `mobile-html-sections-lead` requests or the `mobile-html-sections-remaining` requests depending on what our definition for page views actually is. We could also add a query parameter or extra HTTP header to one of the `mobile-html-sections-lead` requests if we need to distinguish between previews and page views.
Both the current PHP API and the RESTBase based metrics would need to be compatible and be collected in parallel since we cannot control when users update their apps.