We did this.

Done :)

Done

Correct, this is to add that to the webrequest class in refinery core that tagging relies on.

Current plan is for me to work on this after I finish T172581 in July, and will most likely be able to begin in August.

Thank you!

In T196761#4296594, @Charlotte wrote:

@mpopov - Did the user ever get back to you on the ticket? If not let's close. I think @Dbrant has correctly pointed out the issue.

In T197896#4313361, @Ottomata wrote:

oauth2client and oauthlib were easy because they already have .deb packages in Debian. We'll have to make a .deb package for google-auth.

In T197897#4308523, @mforns wrote:

Hey @mpopov, sure I can try.

I don't know the details of the data, but both scripts look good to me!

In T197897#4306395, @mforns wrote:

Did you mean to tag this task with Product-Analytics or with Analytics?

There haven't been any updates to this in over a year and it's not entirely clear what needs to be done, nor how my team should be involved (if at all).

In T190767#4092654, @Ottomata wrote:

Done!

Yay! Everything is working correctly now. We ran into a problem with file ownership but the ever-excellent @Ottomata fixed that up and we are now fully puppetized.

Everything is all good now! Sorry for the interruption.

Okay, theoretically things should start working again tomorrow.

Sorry about that! These datasets and others are currently not updated because T170494 did not go as smoothly as I had hoped. Andrew and I are on it.

Excellent work, @Sharvaniharan!!!

According to T194424#4298147 this is resolved by 440969

Disabled the cron job in my account's crontab on stat1005. Will check tomorrow if everything works as it should and the metric calculation by the analytics-search (system) user goes without problems then this task will be done.

In T190931#4276351, @Sharvaniharan wrote:

• (B) Or send just one event with multilingual data. Since enabledList and orderList can be arbitrary strings, they could be JSON representations with the lists of values for each language. For example, orderList could have the value of {"en":[0,1,2,3,4,5,6,7,8],"de":[8,7,6,5,4,3,2,1,0]}. Then languages would be the JSON array of languages in the order they're set – e.g. ["de","en"] (notice that is where we have to make sure to have the correct order, the array in the enabledList & orderList fields can have any order) -- I would prefer if the instrumentation implemented this approach.

Currently, the enabledList & orderList are just plain strings. Do you need them to be valid json? in which case, should it be a string:string hashmap looking like {"en":[0,1,2,3,4,5,6,7,8],"de":[8,7,6,5,4,3,2,1,0]} , or JSONArray of JSONArrays, looking like this {"en":["0", "1" , "2" , "3" , "4" , "5" , "6" , "7" , "8" ] , "de":[ "8" , "7" , "6" , "5" , "4" , "3" , "2" , "1" , "0"]}?

1. Funnels part of multilingual analytics

In T190931#4273933, @Sharvaniharan wrote:

@mpopov For the cards that do not have different languages, like the FeaturedImageCard, should it be null?

@Sharvaniharan: I just remembered the analytics for the feed! I've updated the MobileWikiAppFeed schema (Revision 18115458) to include a language field, which should contain a language code for action = 'cardShown' and action = 'cardClicked' events. Also ,per T196783, the following field names have been renamed:

@Bstorm: thank you very much!!!

In T196783#4268407, @Sharvaniharan wrote:

@mpopov also the timeSpent property please. Shoudl it be 'duration' from now on?

In T196668#4267637, @Bstorm wrote:

Good news! Asking for more memory from gridengine did succeed in not getting a memory error so far (got past the whole JSON deserialization).

I wonder if we can make it so that a user can export and then share over email/SMS so when someone else opens it it goes to the app and there's a prompt to import the list. Or maybe this is the start of Shared/Subscribe-able Reading Lists discussion???

What do you think, @RHo @Charlotte?

In T190931#4266665, @Sharvaniharan wrote:

1. Is one delete one interaction count or one count per language deleted

@Sharvaniharan: the schemas have been updated according to recommendations above. Please verify that the schemas and the instrumentation agree.

Changing status as system users can now have private data access thanks to Andrew.

Awesome!!! Thank you so much, @Ottomata! :D

Okie dokie, here's where I ended up:

Dmitry brought up some good points on using a summary event approach instead so I'll redesign the schema. @Sharvaniharan: I'll ping you when it's ready. I'm sorry you'll have to reinstrument.

In T190931#4258916, @Sharvaniharan wrote:

In T190931#4254838, @mpopov wrote:

• In case of action = 'search':
  • extras is "<cancelled>" if user backs out without typing anything in the search bar
  • extras is the search string if user searches for a language but doesn't add and just backs out (e.g. "Spanglish")
  • extras is "<added> if user concludes interaction with searching for languages by adding a language they found

Just to be clear here... we are only mentioning 'added', and not which language was added?

Sounds good, @Ottomata! Updated and I'll keep this in mind going forward.

In T191859#4254905, @Ottomata wrote:

ts field for client-side timestamps in case the device goes offline and the event is queued up for a future opportunity

Orrrrr maybe dt in ISO-8601 ? :D

Thanks for the excellent feedback @Sharvaniharan & @RHo! Additional recommendations per our discussion:

My team was in disarray and restructuring when bulk of the work happened on this (hence the delayed responses and lack of CR) and now we don't have the need or the bandwidth for this. We will continue testing changes locally as we have been doing for years, although these days we're not even actively working on any repos/packages listed.

In T191859#4178146, @Tbayer wrote:

The reason to hash app_install_id is because these events would end up somewhere where we would be able to join with behavioral data sent by mobile apps, which we DON'T want

To clarify just in case, it's fine to log app_install_id in connection with user actions, it has been done in many different schemas for years. And "behavioral data" would seem to describe this data here too.
So I guess the "don't want" here refers to connecting users IDs with those other schemas via the app install ID, right? (in which case, fully agreed, although it seems we had been trying to prevent that with Method 1 or Method 2 anyway)

Done for Android.

Having reviewed this, I have the following recommendations:

In T186768#4228658, @NHarateh_WMF wrote:

@mpopov

date, time in UTC, timezone (including daylight savings) offset from UTC

ISO 8601 specifies that it’s the local time with the offset to UTC - is that acceptable?

Just uploaded the data to Go Fish Digital.