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?
On 19 March 2015 at 22:37, Dan Garry <dgarry(a)wikimedia.org> wrote:
On 19 March 2015 at 19:06, Oliver Keyes
<okeyes(a)wikimedia.org> wrote:
Okay. So, to summarise:
1. Android uses sections=all for refreshes
2. iOS uses sections=all for pageviews, generally
3. iOS is shortly to also use sections=all for refreshes
Yes, with the exception that there will always be some people who have not
updated their iOS app and will continue to use section=0 for their page
views. Alas, it is an app, so this happens.
...1, 2 and 3 will all look the same, minus UA differences between (1) and
(2,3)
IOW, there is shortly to be no visible difference, from server-side,
between a "refresh" and a "pageview", for iOS users. Do I understand
correctly? If so, I have some ideas for how we could mitigate this
problem and make pageviews viable again *purses fingers*.
I believe so.
What are your ideas?
Dan
--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
_______________________________________________
Analytics mailing list
Analytics(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/analytics
--
Oliver Keyes
Research Analyst
Wikimedia Foundation