@Manybubbles, @Jdlrobson, and I met to talk through whether we have enough information to estimate a spike. We're not there just yet.

An outcome is I need to do a pass through the schema and propose updates. @Deskana would prefer this stays within one schema (@Manybubbles and @Jdlrobson noted this does pose some challenages) rather than several, so I will try to figure out how this can be done.

Paraphrasing, @Jdlrobson and I think the JavaScript wireup could probably be done in a day long spike with two developers.

In T90518#1082350, @dr0ptp4kt wrote:

@Deskana would prefer this stays within one schema

Indeed. By having it in multiple schemas, it would be very easy to fall into the trap of generating data that is not comparable by having the schemas be different from each other. I'd rather have a minimal dataset with known gaps where the data is comparable between platforms, than fully comprehensive dataset where the data is incomparable between platforms... because with the former we've actually achieved our goal, whereas with the latter we have not.

@Tfinc to identify an engineer for JavaScript implementation for desktop web: first two weeks of April. I anticipate there will be sufficient data for querying in the last two weeks of April.

@Deskana and I spoke. The search field in the top right on desktop is the most consistent field when compared to mobile web (mobile web supports fulltext search, but does not show a search box for it) and apps (apps does not have a specific fulltext search feature, but rather integrates it automatically), so that will be the starting point. We will DO the following.

CREATE new field resultSetType:
prefix
fulltextonly
prefixmergedwithfulltext

CREATE new field numberOfResultsShowingWhenResultClicked

Update documentation for timeToDisplayResults to say events should *not* be fired in the case that the user's query wasn't actually sent to the server (i.e., the client side code timer decided not to send search because of fast typing).

action= click-cancel should be updated to handle navigation away from the site in any form

ADD action= click-onsite to capture that user navigated within site

Dwell time on suggestions can be inferred by database queries, so that doesn't need to be an explicit field.

DEFERRED

number of characters in field metadata:
numberOfCharactersInSearchField
numberOfCharactersEnteredInSearchFieldCorrespondingToResultSet

search subtype metadata:
fulltext search issued by mode on behalf of user
user implicitly issued fulltext search (hit enter)
user intentionally performed fulltext search

dwell time on fulltext search page

@dr0ptp4kt We could pull in someone from mobile web or Jeff from Zero.

I just emailed the mobile-tech list to solicit help.

We're also going to add a field called "userSessionToken" in order to correlate all events in a search session. The "searchSessionToken" will be associated with each fired API call requesting search results (or if locally cached, then the locally cached alternative).

Additionally:

numberOfResults needs to specify as pertaining to
action=impression-results: may be 0
action=impression-didyoumean: implies 1, but be explicit about that

timeToDisplayResults pertains to both
action=impression-results
action=impression-didyoumean

The "description" field and the actual enum values need to be made consistent for 'action'.

"click-cancel" will be renamed to something like "hide-search-suggestions" (user tapped on non-hyperlink part of page, user tapped on X, user tapped Back, user clicked a link in page).

Upon further reflection, let's not add action=clickonsite.

Instead of creating numberOfResultsShowingWhenResultClicked, we'll just reuse numberOfResults when a result is clicked.

click-onsite will not be used.

The following have been submitted for review:

https://gerrit.wikimedia.org/r/199179
https://gerrit.wikimedia.org/r/199178

I merged the JS patches. I've asked @bmansurov about the operations/mediawiki-config global change.

The operations/mediawiki-config change for the beta cluster seems to be working. Steps to reproduce:

1. Setup intercepting proxy client side.
2. Access http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page?debug=true
3. Modify the search.js response so isSampled = true.
4. Monitor EventLogging traffic with the intercepting proxy and on EventLogging in beta labs.

@bmansurov to create a new operations/mediawiki-config entry for production. We'll need to enlist help for sync'ing the change while merging it in.

Patch that enables event logging in production: https://gerrit.wikimedia.org/r/#/c/203250/

Stuff is now logging in group 0.