@KCVelaga_WMF Is this ready for dev? Who needs to do what to define which option to choose?

I think the first approach would provide more reliable data because we want to calculate the duration that the user is actually interacting with the content. We could implement something on our own, but the same event will get triggered multiple times:

Rough example:

// Duration will change based on the time that the user has been active on the tab.
// When the user changes the active tab, we pause the duration and start it again if the our tab gains focus for X seconds or something like that.
logEvent( 'session_activity', { title: 'pagename', duration } );

The event can be logged every 30 seconds for example. If for some reason the browser is closed and our beforeunload or visibilitychange event doesn't trigger...we will only be off by 30 seconds.

The second approach is easier to implement and we should use the visibilitychange event instead of the beforeunload (see link for why). When using the visibilitychange event there are two cases to be aware of:

If the user comes back to our tab, should that be a new session?

1. If yes, it will inflate the session counts.
2. If no, we might submit the session_activity event multiple times and only the last one should be considered.

I think the second approach should be fairly accurate. We can start with that and change later based on our observation.

Also what happens if the user changes the target language etc? Should it start a new session?

@abi_ Here is my proposal for the events, let me know what you think.

Interaction data

action: visibility_change
action_subtype:
 hidden_state
 visible_state

Note:

• If the browser tab is closed completely, then it is session end event rather than visibility change.
• If there is no activity for 30 min, then we can consider it as session end.

Translation object (at the time of event being triggered)

• target_title: title of the page
• source_language: source language of translation
• target_language: target language of translation

We don't need to capture the duration, as I can easily calculate from timestamps.

Change #1126930 had a related patch set uploaded (by Abijeet Patro; author: Abijeet Patro):

[mediawiki/extensions/ContentTranslation@master] AX Instrumentation: Track session length

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

Change #1126930 merged by jenkins-bot:

[mediawiki/extensions/ContentTranslation@master] AX Instrumentation: Track session length

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

In T386680#10624028, @KCVelaga_WMF wrote:

@abi_ Here is my proposal for the events, let me know what you think.

Interaction data

action: visibility_change
action_subtype:
 hidden_state
 visible_state

Note:

• If the browser tab is closed completely, then it is session end event rather than visibility change.
• If there is no activity for 30 min, then we can consider it as session end.

Translation object (at the time of event being triggered)

• target_title: title of the page
• source_language: source language of translation
• target_language: target language of translation

We don't need to capture the duration, as I can easily calculate from timestamps.

This functionality has been implemented and deployed on https://language-cx.wmcloud.org/index.php/Special:AutomaticTranslation

To test, enable display of event logs in the browser:

mw.loader.using('mediawiki.api')
    .then(
        () => new mw.Api().saveOption('eventlogging-display-web', '1')
    );

Visibility changes events, hidden and visible are being logged as expected. ✅