I would advise against using "session" in the name. When Jason and I were writing https://docs.google.com/document/d/100B4c1GqHHCAGnWLbDrgMQIJzxNI8vuf7jEMKG7DKeg/edit?usp=sharing we surveyed the landscape of schemas/instruments and saw that everything was just a session and there being multiple levels of sessions: https://docs.google.com/document/d/11xTwL_j0BWgfdtZ_GOIlxg22rLP2lRraaA2c_-uMwJQ/edit#

I would recommend activity_token although personally I think that in essence it's just funnel_entry_token.

Could funnel_* keys be renamed to activity_* keys? In practice we rarely have funnels but we often need to link interactions in the same activity, not just on web but in apps too.

Per @mpopov's last comment:

I would recommend activity_token although personally I think that in essence it's just funnel_entry_token.

Could funnel_* keys be renamed to activity_* keys? In practice we rarely have funnels but we often need to link interactions in the same activity, not just on web but in apps too.

Given that the common fragment already has this property funnel_entry_token, is it problematic to use this field in lieu of either activity_session_id or activity_token?

I'm not sure what the plan is for making use of funnels in instruments in the future but since it's available now and afaik not being used, wouldn't this be a good case for using it?
(apologies if i'm missing context and this has already been discussed)

I thought the same at the beginning (about using the funnel field to use it in this case) but it seems that funnel_entry_token is more related to the user sessionId according to the description I have found on the common schema:

The token used to determine whether the performer could enter the funnel,
      if any.

      The token could be automatically generated by the Metrics Platform
      Client. It could also be the pageview (retrieved from
      `mw.user.getPageviewToken()`) or the session token (retrieved from
      `mw.user.sessionId()`).

When discussing with the Abstract Wikipedia team, they highlighted the importance of distinguishing between both fields (activity_session and user session). We even talked about the funnel* fields but they were discarded because they needed to distinguish different session for the same user in different tabs and activity_session does exactly that. So I assume we shouldn't use funnel_entry_token (if its description is still valid at this moment, of course).

As far as I understand what @mpopov is proposing, the main idea is to remove the session keyword to avoid confusion with all types of sessions we could consider. And at the same time, reading datahub, the session word appears all the time to describe this field. Could we change it despite that?

In T358758#9590401, @Sfaci wrote:

And at the same time, reading datahub, the session word appears all the time to describe this field. Could we change it despite that?

This is because the activity session ID is defined in relation to the session ID. They're both generated in the same way and stored in the same store. However, their lifetimes are different.

I'd be OK with switching to the _token suffix as long as we're consistent (which we're not yet because of funnel_entry_token!).

Let's go with activity_token then.
I'll modify the ticket details according to this decision

Change 1008541 had a related patch set uploaded (by Santiago Faci; author: Santiago Faci):

[schemas/event/secondary@master] Adding a new contextual attribute: performer.activity_token

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

sfaci opened https://gitlab.wikimedia.org/repos/data-engineering/metrics-platform/-/merge_requests/38

Added a new contextual attribute: performer.activity_token

Change 1008549 had a related patch set uploaded (by Santiago Faci; author: Santiago Faci):

[mediawiki/extensions/EventLogging@master] Added a new contextual attribute: performer.activity_token

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

After the discussion we had in slack (https://wikimedia.slack.com/archives/C01DFMX6QLB/p1709649082610799), some changes have been made in the ticket description and the changes we were reviewing according to the new name for the new contextual attribute: performer.active_browsing_session_token. Everything is ready to be reviewed again.

Change 1008541 merged by jenkins-bot:

[schemas/event/secondary@master] Adding a new contextual attribute: performer.active_browsing_session_token

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

Change 1008549 merged by jenkins-bot:

[mediawiki/extensions/EventLogging@master] Added a new contextual attribute: performer.active_browsing_session_token

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