== Background
In {T179426}, we used the current Page Previews EventLogging instrumentation to try to determine the typical time to first user link interaction (see T179426#3741809 and T179426#3741859). Unfortunately, the use of the server-side timestamp, which is only accurate to the second, was too high granularity in order to move forward with {T179426}.
@Gilles recommended that we specifically measure this metric with the high-precision (milliseconds accurate to 5 microseconds), monotonic clock exposed via [[https://developer.mozilla.org/en-US/docs/Web/API/Performance/now | performance.now()]].
== Plan
Per T180036#374696, we'll add a high-precision timestamp to the existing EventLogging instrumentation. So, we'll:
- Add an `event_timestamp` field to [[ https://meta.wikimedia.org/wiki/Schema:Popups | the Popups schema ]].
- In the client, set the field to `performance.now` for every event we send.
== Developer Notes
# The field could/should be added in [the `src/reducers/eventLogging.js#createEvent` function](https://github.com/wikimedia/mediawiki-extensions-Popups/blob/e1be05d73f308fcdc7723bcd8792b61fd6a69f77/src/reducers/eventLogging.js#L35-L59).
# All events have `event_timestamp` values added to them (in case of link interaction events, referring to the end of the interaction rather than its start). The timestamps should only be retrieved using `performance.now` when it's available.
- This is mostly a point of principle: the reducers should only be combining data with existing state.
- Per T180036#3749812, if `performance.now` is unavailable for some reason, send `undefined` or `null`.
== AC
* Whenever possible, high-precision timestamps are sent with all Popups events.
== Testing Plan
* EventLogging for popups is disabled on production so we will need to test this on the beta cluster
* On [[ https://en.wikipedia.beta.wmflabs.org/wiki/Test_previews?debug=true | the beta cluster ]] bucket yourself by passing the debug=true parameter
* Every event should include a `timestamp` field. To verify this open the developer console and inspect the network tab (you can filter by event). Check all possible event types to see if this is true and the number is always increasing.
== Sign off steps
[] Given EventLogging is disabled on production, what is the plan/card to re-enable it to actually collect the information we need...? Please create a card.