Thanks, everyone!

Good job, @MNeisler!

Update: @chelsyx @Nuria and I met to discuss this and have come up Proposal 4 (which is really just an EventLogging-based version of Proposal 2).

In T191859#4146991, @Nuria wrote:

Note retention of this data is subjected to 90 days unless granted otherwise by legal, is the reading infrastructure ready to drop the data after 90 days of storing it? Currently there is no data dropping routines in cassandra which I think is the backend for this data.

Thanks @cooltey!

Apparently there is a limit on number of properties (sites/domains/URIs) that can be added to a single account (1000) and we just reached that limit.

Thanks for the recommendation! I've added eventlogging@127.0.0.1 as a user with the same password.

I am able to connect to the beta cluster, thanks! But when I try to connect to the mysql database (mysql -h 127.0.0.1 --user=eventlogging --password=68QrOq220717816UycU1 --skip-ssl) it fails:

Started: https://www.mediawiki.org/wiki/Product_Analytics

In T191859#4119016, @Tgr wrote:

This would happen on the client side, right? (i.e. the header would be set on the request, not the response.)

@atgo uhhhhhhh…possibly? I thought T191132 is to look at differences in search as a result of design changes leading up to the campaign, but if there's a misunderstanding then yeah.

@atgo just wanted to give you a heads up that @chelsyx and/or I will be tackling question 3 since we come from search :) I've spun that off into its own task over at T191354 so please check that out when you can and let us know if you have questions, thoughts, etc.

March 2018 search volume and ZRR by platform for baseline:

@chelsyx and I had a chat about this and came up with a possible solution that would work with a minor modification to the existing Reading Lists schema, and confirmed with @Dbrant that we can do it on Android no problem too. Specifically, there would be a new event action addtodefault:

In T172581#4086788, @Legoktm wrote:

In T172581#4085814, @mpopov wrote:

In T172581#4085488, @mforns wrote:

I think @Legoktm refers to the fact that @mpopov 's code lives in a private repo in his Github account.

Not anymore :) it's open now: https://github.com/bearloga/wmf-gsc

Thanks, I think we're pretty close, it just needs a license now: https://github.com/bearloga/wmf-gsc/issues/4

With respect to productionizing it and quotas, we're going to be fine. The only thing is that there's a delay of about 2 days before today's data is available in the search console, so we'd have to account for that.

In T172581#4085488, @mforns wrote:

I think @Legoktm refers to the fact that @mpopov 's code lives in a private repo in his Github account.

In T172581#4083106, @Legoktm wrote:

Errr, why are we running private code in production? Everything we do is supposed to be open source and free software.

Code is currently in a private repo under my GitHub account. @dr0ptp4kt @Tbayer @chelsyx: I added you as collaborators so you should be able to see it.

BTW I updated the comment T186768#4044717 to reflect actual implemention (which has no separator between the hours and minutes in the offset)

Mentioned this on IRC already but also mentioning it here :) In https://irkernel.github.io/installation/ it says:

Where possible, this can use ORES for article quality (only available on enwiki, frwiki, trwiki, ruwiki, and wikidata).

1. Part 1

@Dbrant thank you so much for clarifying!

In T189707#4051870, @Dbrant wrote:

@mpopov Just to make sure, we're calling it appInstallID (capitalized), and keeping it the same in the other schemas, correct?

In T186768#4051911, @Dbrant wrote:

@mpopov Any preference for the name of the timestamp column? I was thinking something really terse, in the interest of minimizing the payload size, e.g. time, or even t?

I'm thinking for this one we should follow ISO 8601 with a minor deviation: in case of UTC, we wouldn't use 2018-03-10T14:03:56Z but 2018-03-10T14:03:56+0000