+1 on baseline inflation
We will have a hard time to connect historic and future pageview counts anyway, now that
we migrate to new infrastructure (mostly because historic counts didn't exluded
crawlers).
But at least the concepts of 'page' and 'view' haven't changed much in
all these years.
Erik
From: analytics-bounces(a)lists.wikimedia.org [mailto:analytics-bounces@lists.wikimedia.org]
On Behalf Of Dario Taraborelli
Sent: Wednesday, August 19, 2015 21:23
To: A mailing list for the Analytics Team at WMF and everybody who has an interest in
Wikipedia and analytics.
Subject: Re: [Analytics] Pageviews definition + measurement for apps adding link previews
+ using RESTBase
On Aug 18, 2015, at 6:32 PM, Kevin Leduc <kevin(a)wikimedia.org> wrote:
We briefly considered counting views of Hover Cards as Pageviews, but it was quickly
dismissed. First, the feature is not widely used enough to justify Changing the pageview
definition.
I second that, these are “impressions” and they should be measured separately. I would be
very worried about inflating our baseline PV numbers with all sort of features revealing
snippets of content.
I’m still open to counting previews as pageviews, but I think the Readership team and
their product managers need to weigh in heavily as Pageviews is a key metric for them.
Finally, counting Pageviews served through RESTBase sounds like a new project and I'd
like to hear more about the effort needed from the analytics engineers.
On Tue, Aug 18, 2015 at 4:58 PM, Oliver Keyes <okeyes(a)wikimedia.org> wrote:
On 18 August 2015 at 19:11, Bernd Sitzmann <bernd(a)wikimedia.org> wrote:
This discussion is about needed updates of the
definition and Analytics
implementation for mobile apps page view metrics. There is also an
associated Phab task[4]. Please add the proper Analytics project there.
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:
We'll add a link preview when someone clicks on a link from a page.
We're planning on switching over the using RESTBase for loading pages and
also the link preview (initially just the Android beta, ater more)
Woah woah woah woah woah. By RESTBase do you mean Gabriel's RESTful service API?
Last time I checked that wasn't even consumed by HDFS. Is it now being
consumed by HDFS?
More importantly the actual URLs are going to look /totally/
different. If we do not include RESTBase requests, we will miss the
apps. If we /do/ include RESTBase requests we will not only have to
rewrite the pageview definition for the apps to recognise the new URL
scheme, we will also potentially have to rewrite every /other/ bit of
the definition to /not/ incorporate those requests.
(I use "we" in a collective sense. This isn't my baby any more,
although if Joseph et al want help with the refactor here I'm happy to
spend my volunteer time on it).
But basically every other bit of your email is important but now
secondary: this is a potentially massive change, all on its own, even
without the link preview, even if the substance of the requests going
to RESTBase were identical.
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[1] instead of the PHP API mentioned
above. Then it would call [2].
Link preview: Instead of action=query&prop=extracts it would call the lead
request[1], 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.
[1]
https://en.wikipedia.org/api/rest_v1/page/mobile-html-sections-lead/Dilbert
[2]
https://en.wikipedia.org/api/rest_v1/page/mobile-html-sections-remaining/Di…
[3]
https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/RESTBase_services_for_ap…
[4]
https://phabricator.wikimedia.org/T109383
Cheers,
Bernd
_______________________________________________
Analytics mailing list
Analytics(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/analytics
--
Oliver Keyes
Count Logula
Wikimedia Foundation
_______________________________________________
Analytics mailing list
Analytics(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/analytics
_______________________________________________
Analytics mailing list
Analytics(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/analytics