Thanks Asher for tying this up! I was about to write a similar email :) One final question, just to make sure we are all on the same page: is the X-CS field becoming a generic key/value pair for tracking purposes?
D On Fri, Feb 15, 2013 at 11:16 AM, Asher Feldman <afeld...@wikimedia.org>wrote: > 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 > _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
