We did this.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jul 17 2018
Jul 12 2018
Jul 10 2018
Done :)
Done
Jul 9 2018
Correct, this is to add that to the webrequest class in refinery core that tagging relies on.
Jul 5 2018
Jul 3 2018
Jun 29 2018
Jun 28 2018
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.
Jun 27 2018
Thank you!
Jun 26 2018
In T196761#4296594, @Charlotte wrote:
Jun 25 2018
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.
Jun 22 2018
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!
Jun 21 2018
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!
Jun 19 2018
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.
Jun 18 2018
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
Jun 14 2018
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.
Jun 13 2018
Jun 12 2018
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"]}?
Jun 11 2018
- 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?
Jun 10 2018
@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:
Jun 9 2018
@Bstorm: thank you very much!!!
Jun 8 2018
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:
- 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.
Jun 7 2018
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:
Jun 6 2018
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?
Jun 4 2018
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:
May 31 2018
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.
May 30 2018
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.
May 25 2018
Having reviewed this, I have the following recommendations:
May 24 2018
In T186768#4228658, @NHarateh_WMF wrote: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?
May 22 2018
Just uploaded the data to Go Fish Digital.
I suppose this is as done as can be until we hire a manager to flesh out the page some more.
May 21 2018
Cancelling this request as I will be uploading the data to them instead.