Page MenuHomePhabricator

UI Logging
Closed, ResolvedPublic

Description

We want to get basic information about how the recommender tool is used. Here are descriptions for an initial set of EventLogging tables we would like to fill:

TranslationRecommendationUIRequests: Logs information about each request a user makes to the API:
timestamp: (required)
user_agent: (required)
s: source language [query param] (required)
t: target language [query param] (required)
seed: seed parameter used for searching [query param] (optional)
search: search algorithm used [query param] (optional)
user_name: the editors user name. Required for future functionality of getting user name based recs (optional)
user_id: unique user token/cookie (required)
request_id: cookie that gets set on each api request. Used as key into other tables. (required)
campaign: name of the campaign the user is in [query param] (optional)
condition: name of the campaign condition the user is in [query param](optional)

https://meta.wikimedia.org/wiki/Schema:TranslationRecommendationUIRequests

TranslationRecommendationUserAction: Logs what articles are having actions taken and how

request_id: generated upon the api request that fetched the data the user is seeing. (required)
page_title: title of the specific page the user is acting on (required)
action: action taken. Current options are in {flag_not_interested, flag_not_notable, create_from_scratch, create_using_content_translation} (required)

https://meta.wikimedia.org/wiki/Schema:TranslationRecommendationUserAction

Event Timeline

ellery raised the priority of this task from to Needs Triage.
ellery updated the task description. (Show Details)
ellery added a project: GapFinder.
ellery added a subscriber: ellery.
ellery renamed this task from UI Logging to Basic UI Logging.Jan 25 2016, 11:04 PM
ellery updated the task description. (Show Details)
ellery set Security to None.
ellery renamed this task from Basic UI Logging to UI Logging.Jan 25 2016, 11:12 PM
ellery removed schana as the assignee of this task.
ellery triaged this task as Medium priority.
ellery moved this task from Backlog to Next Up on the GapFinder board.

It seems that there is a lot of shared info between TranslationRecommendationUIRequests and TranslationRecommendationAPIRequests. Is one supposed to be client-side and the other server-side? Could we combine them?

@schana One schema tracks the API usage the other tracks the usage of our app. API usage would be logged from the server. The app usage would be logged from the client. Our app is only one of 3 current API consumers and there may be more consumers in the future. I think its cleaner to keep them separate: a joint schema would contain too many fields that only apply in one of the contexts.

@ellery I understand.

For TranslationRecommendationCXTranslations, would you want the behavior to be similar to the Flagging schema in having distinct options for how the user chooses to proceed expressed as an enum?

@ellery After our discussion, what do you want the schema name to be for when the user takes an action to translate the article? Here's a couple ideas:
TranslationRecommendationAction: this is a little generic, but could be combined with the Flagging schema
TranslationRecommendationArticleCreation: this could have an enum named something like method or tool that has CX or from scratch as options.

I think creating a combined 'user action' table makes sense.

For archive happiness, the changes can be seen in: deployment-eventlogging03.eqiad.wmflabs # /srv/log/eventlogging