On Tue, Jan 8, 2013 at 2:44 PM, Quim Gil <qgil@wikimedia.org> wrote:
> On 01/08/2013 02:39 PM, Erik Zachte wrote:

>> So please if you expect stats will be affected, drop us a line. Thanks
>> so much.
>
>
> Wouldn't watch the page and enable email notifications accomplish the same
> purpose?
>
> http://www.mediawiki.org/w/index.php?title=Extension:MobileFrontend/Deployments&action=history

The problem is that 99% of MobileFrontend changes should have no
effect on logging (either that, or you're doing it wrong). What Erik
is asking for (which I believe is reasonable) is for developers to be
aware of how the changes they make might affect pageview statistics,
and work with him and others when that's likely to happen.

I think it's reasonable for engineering teams to QA releases to ensure they don't mangle urls or do anything else that jacks up user roundtrip latency, or needlessly increases apache requests and db queries. Analytics shouldn't be the ones proactively looking for such things. The only time it makes sense for mobile, features, etc. to loop in analytics is when a deployment intentionally results in additional requests that look like pageviews. More likely though, such requests would be relative to the api or bits.

Analytics should also stop counting /wiki/article requests with a 301 response as pageviews, as it's pretty much always double counting. They should still be counted in a separate requests metric though, it's still important to see when things like mobile requests double, especially if unexpected.