Just to tie this thread up - the issue of how to count ajax driven pageviews loaded from the api and of how to differentiate those requests from secondary api page requests has been resolved without the need for code or logging changes.
Tagging of the mobile beta site will be accomplished via a new generic mediawiki http response header dedicated to logging containing key value pairs. -Asher On Tue, Feb 12, 2013 at 9:56 AM, Asher Feldman <afeld...@wikimedia.org>wrote: > On Tuesday, February 12, 2013, Diederik van Liere wrote: > >> > It does still seem to me that the data to determine secondary api >> requests >> > should already be present in the existing log line. If the value of the >> > page param in an action=mobileview api request matches the page in the >> > referrer (perhaps with normalization), it's a secondary request as per >> case >> > 1 below. Otherwise, it's a pageview as per case 2. Difficult or >> expensive >> > to reconcile? Not when you're doing distributed log analysis via >> hadoop. >> > >> So I did look into this prior to writing the RFC and the issue is that a >> lot of API referrers don't contain the querystring. I don't know what >> triggers this so if we can fix this then we can definitely derive the >> secondary pageview request from the referrer field. >> D > > > If you can point me to some examples, I'll see if I can find any insights > into the behavior. > > >> >> > On Mon, Feb 11, 2013 at 7:11 PM, Arthur Richards < >> aricha...@wikimedia.org >> > >wrote: >> > >> > > Thanks, Jon. To try and clarify a bit more about the API requests... >> they >> > > are not made on a per-section basis. As I mentioned earlier, there are >> > two >> > > cases in which article content gets loaded by the API: >> > > >> > > 1) Going directly to a page (eg clicking a link from a Google search) >> > will >> > > result in the backend serving a page with ONLY summary section content >> > and >> > > section headers. The rest of the page is lazily loaded via API request >> > once >> > > the JS for the page gets loaded. The idea is to increase >> responsiveness >> > by >> > > reducing the delay for an article to load (further details in the >> article >> > > Jon previously linked to). The API request looks like: >> > > >> > > >> > >> http://en.m.wikipedia.org/w/api.php?format=json&action=mobileview&page=Liverpool+F.C.+in+European+football&variant=en&redirects=yes&prop=sections%7Ctext&noheadings=yes§ionprop=level%7Cline%7Canchor§ions=all >> > > >> > > 2) Loading an article entirely via Javascript - like when a link is >> > clicked >> > > in an article to another article, or an article is loaded via search. >> > This >> > > will make ONE call to the API to load article content. API request >> looks >> > > like: >> > > >> > > >> > >> http://en.m.wikipedia.org/w/api.php?format=json&action=mobileview&page=Liverpool+F.C.+in+European+football&variant=en&redirects=yes&prop=sections%7Ctext&noheadings=yes§ionprop=level%7Cline%7Canchor§ions=all >> > > >> > > These API requests are identical, but only #2 should be counted as a >> > > 'pageview' - #1 is a secondary API request and should not be counted >> as a >> > > 'pageview'. You could make the argument that we just count all of >> these >> > API >> > > requests as pageviews, but there are cases when we can't load article >> > > content from the API (like devices that do not support JS), so we >> need to >> > > be able to count the traditional page request as a pageview - thus we >> > need >> > > a way to differentiate the types of API requests being made when they >> > > otherwise share the same URL. >> > > >> > > >> > > >> > > On Mon, Feb 11, 2013 at 6:42 PM, Jon Robson <jdlrob...@gmail.com> >> wrote: >> > > >> > > > I'm a bit worried that now we are asking why pages are lazy loaded >> > > > rather than focusing on the fact that they currently __are doing >> > > > this___ and how we can log these (if we want to discuss this further >> > > > let's start another thread as I'm getting extremely confused doing >> so >> > > > on this one). >> > > > >> > > > Lazy loading sections >> > > > ################ >> > > > For motivation behind moving MobileFrontend into the direction of >> lazy >> > > > loading section content and subsequent pages can be found here [1], >> I >> > > > just gave it a refresh as it was a little out of date. >> > > > >> > > > In summary the reason is to >> > > > 1) make the app feel more responsive by simply loading content >> rather >> > > > than reloading the entire interface >> > > > 2) reducing the payload sent to a device. >> > > > >> > > > Session Tracking >> > > > ################ >> > > > >> > > > Going back to the discussion of tracking mobile page views, it >> sounds >> > > > like a header stating whether a page is being viewed in alpha, beta >> or >> > > > stable works fine for standard page views. >> > > > >> > > > As for the situations where an entire page is loaded via the api it >> > > > makes no dif > > _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
