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@wikimedia.org wrote:
On 19 March 2015 at 19:06, Oliver Keyes okeyes@wikimedia.org wrote:
Okay. So, to summarise:
Android uses sections=all for refreshes
iOS uses sections=all for pageviews, generally
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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics