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 <okeyes@wikimedia.org> 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 <okeyes@wikimedia.org> 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 <gtisza@wikimedia.org> wrote:
>> On Thu, Mar 19, 2015 at 8:06 PM, Oliver Keyes <okeyes@wikimedia.org> 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
>> Analytics@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/analytics
>>
>
>
>
> --
> Oliver Keyes
> Research Analyst
> Wikimedia Foundation



--
Oliver Keyes
Research Analyst
Wikimedia Foundation

_______________________________________________
Analytics mailing list
Analytics@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/analytics