"Adding highlight parameters to the EventLogging schema" can be done but it would capture only a portion of the user's interaction with the highlight feature since highlight operations don't send the URL to the server.

For instance, if a user starts by configuring filters, when he's satisfied with what he sees, adds highlights, deals with the changes and closes the page, we would never receive information about his use the highlight feature.

A different option is to log all highlight-related actions from the client-side. It's a bit more work but it's much more reliable.

It would be useful to know what kind of questions we would like to be able to answer with this data. This is probably not related with establishing the "RC baseline" since this feature is completely new.

Ping: @jmatazzoni, @Pginer-WMF, @Catrope

In T158344#3091069, @SBisson wrote:

It would be useful to know what kind of questions we would like to be able to answer with this data. This is probably not related with establishing the "RC baseline" since this feature is completely new.

It is related to task T158447 in the sense that we'd like highlighting to be part of the Tool Usage Profile. But you're right that this is a new tool so doesn't need to be done before launch. If instrumenting highlighting will take a lot of time, we can push this to Q4.

In terms of what we want to know, that is discussed in the task just mentioned:

Note that for Highlight tools, it will be important to know which filters users are highlighting. I.e., we can't just say the Highlight tool was used X times, though we will want to know that total too. But we'll especially want to know that users were, for example, highlighting Newcomers, etc. The combination, Highlight + Tool.

(We don't need to know what color someone is using, BTW. That would be a distraction.)

! In T158344#3091272, @jmatazzoni wrote:
...
If instrumenting highlighting will take a lot of time, we can push this to Q4.

I don't think it's going to take a lot of time. Also, we're running out of tasks that don't have a hard dependency on the filters definition work. But if there's something else that doesn't have dependencies and that's more pressing, I'm happy to switch.

My main point was trying to explain the limitations with the approach in the task description. It would miss some of the data in a not-quite-random but unpredictable way. I don't think it's acceptable. I'll take a stab at the click-side logging.

I mentioned this before, but please note that the names of filters have changed now -- instead of being the parameter/value (which may be duplicated) they are now prefixed by their group name. group1__filter1 and so the highlight should be something light group1__filter1_color=c1

The filter name prefix is defined per its group, in mw.rcfilters.dm.FilterGroup.prototype.getNamePrefix so it is consistent across everything in case we change the prefix.

Change 343615 had a related patch set uploaded (by Sbisson):
[mediawiki/extensions/WikimediaEvents] Schema for tracking usage of highlight feature

https://gerrit.wikimedia.org/r/343615

Change 343616 had a related patch set uploaded (by Sbisson):
[mediawiki/core] Track usage of highlight feature

https://gerrit.wikimedia.org/r/343616

Change 343616 merged by jenkins-bot:
[mediawiki/core] Track usage of highlight feature

https://gerrit.wikimedia.org/r/343616

Change 343615 merged by jenkins-bot:
[mediawiki/extensions/WikimediaEvents] Schema for tracking usage of highlight feature

https://gerrit.wikimedia.org/r/343615

Checked in betalbs - the highlghting event is recorded in the log

/srv/log/eventlogging$ grep 'ChangesListHighlights.*' all-events.log

{"event": {"action": "clearAll", "filters": []}, "recvFrom": "deployment-cache-text04.deployment-prep.eqiad.wmflabs", "revision": 16449602, "schema": "ChangesListHighlights", "seqId": 1016387, "timestamp": 1490200380, "userAgent": "{\"os_minor\": \"10\", \"os_major\": \"10\", \"device_family\": \"Other\", \"os_family\": \"Mac OS X\", \"browser_minor\": \"0\", \"wmf_app_version\": \"-\", \"browser_major\": \"10\", \"browser_family\": \"Safari\"}", "uuid": "1f32937b0fbb56bebe1e08abdc13031e", "webHost": "ca.wikipedia.beta.wmflabs.org", "wiki": "cawiki"}

Each change of highlighting triggers the log event, e.g. selecting/changing/discarding the highlight.

QA Recommendation: Resolve

@SBisson, @Etonkovidova, Does the info recorded enable us to track both "Highlight + tool" and total highlight usage, as described above?

...it will be important to know which filters users are highlighting. I.e., we can't just say the Highlight tool was used X times, though we will want to know that total too. But we'll especially want to know that users were, for example, highlighting Newcomers, etc. The combination, Highlight + Tool.

In T158344#3123272, @jmatazzoni wrote:

@SBisson, @Etonkovidova, Does the info recorded enable us to track both "Highlight + tool" and total highlight usage, as described above?

I'm not sure what "Highlight + tool" means. We log 3 user actions related to highlight: set, clear, clearAll. For each one, we log the name of the affected filters and the symbolic name of the colors, if any.

For instance:

• set, hidebot, c1
• set userExpLevel_newcomer, c2
• clear, hidebot
• set goodfaith_likelygood, c3
• clearAll, userExpLevel_newcomer, goodfaith_likelygood

One thing we don't log is enabling/disabling the highlight feature using the highlight button. Should we?

@SBisson wrote:

I'm not sure what "Highlight + tool" means.

It means that we want to know to know what tool was highlighted, not just that some highlight was selected. So it sounds like yes, we have that if we have "set userExpLevel_newcomer"

One thing we don't log is enabling/disabling the highlight feature using the highlight button. Should we?

I don't see a need for this, unless it could be a good proxy for "# of sessions that involved highlighting." A) there is probably a different way to get that, and b) I'm not sure it works well as that anyway, since as far as I can tell, when users click to other screens, the Highlight state persists. Does anyone else see a need for this?