Either use of a distinct header (e.g., X-WMF-Refresh: 1) or use of a distinct parameter (e.g., wprov=rfsi1 for "refresh from saved pages on iOS, version 1") from the client would work. The use of a distinct parameter is much easier.
Then the VCL code could be updated to look for the field and enrich the X-Analytics header accordingly. Okay? On Fri, Mar 20, 2015 at 11:37 AM, Oliver Keyes <[email protected]> wrote: > Just a note that I'm started on a related patch now, using the (we now > know, not-futureproof) logic of: > > 1. if it's got sections=0 it's a pageview; > 2. if it's got sections=all and is from iOS it's a pageview. > > Would appreciate some feedback on the idea of sending refresh=1 in the > x_analytics header, so we know what to expect there. > > On 20 March 2015 at 00:44, Oliver Keyes <[email protected]> wrote: > > In the long-term we'll just be relying on x_analytics, yes, because > > the app will be sending through the pageID and namespace in the same > > way as desktop and the mobile web do; so it'll be > > pageid=50;ns=0;refresh-1 or pageid=50;ns=0, respectively. That's a > > different patch. In the short-term I'm not seeing how building out a > > complex ecosystem for this is a valuable use of time given that we > > know what we'll be switching to (and that it's standardised not just > > across apps, but also for desktop and the mobile web, to boot). All we > > care about distinguishing that we won't get for free as part of > > already-scheduled work is refreshes from pageviews. > > > > On 19 March 2015 at 23:59, Gergo Tisza <[email protected]> wrote: > >> On Thu, Mar 19, 2015 at 8:06 PM, Oliver Keyes <[email protected]> > wrote: > >>> > >>> As I see it, we basically have two possibilities here: > >>> > >>> 1. Make the URLs distinguishable; > >>> 2. Add additional metadata in a non-URL place > >>> > >>> 1 is undesirable because it ruins caching, and we like caching. So we > >>> look at 2, which realistically means the x_analytics field. Why don't > >>> we add a parameter there? refresh=1. And then, our app check boils > >>> down to (in pseudocode): > >>> > >>> if(other_checks & urlContains("sections=(0|all)" & > >>> !xAnalyticsContains("refresh")){ > >>> return true; > >>> } > >>> return false; > >>> > >>> Nice and simple and easy. It'll require some coordination with > >>> Ottomata because it means modifying the UDF parameters, and we're > >>> using said UDF in production so it'll have to be synced to a change in > >>> the relevant Oozie job, but it should be totally doable, and I can't > >>> see an easier way of doing it. > >>> > >>> Thoughts, people? > >> > >> > >> Why use anything other than X-Analytics at all? Source of the pageview > is > >> exactly the kind of information it is meant for. Just set > >> source=AndroidAppPageView / source=IosAppSectionView / > >> source=AndroidAppSavedPageRefresh etc. (Or set up a mapping to > three-letter > >> acronyms if you want to be nice on the servers.) That puts logging > >> completely in the hands of the app developers, so there are no > information > >> flow problems and less organizational overhead; it also makes rules more > >> explicit (and thus harder to mess up / easier to spot errors). > >> > >> _______________________________________________ > >> Analytics mailing list > >> [email protected] > >> https://lists.wikimedia.org/mailman/listinfo/analytics > >> > > > > > > > > -- > > Oliver Keyes > > Research Analyst > > Wikimedia Foundation > > > > -- > Oliver Keyes > Research Analyst > Wikimedia Foundation > > _______________________________________________ > Analytics mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/analytics >
_______________________________________________ Analytics mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/analytics
