Add functionality to set the Network User Id

[RobertJamesEllison]

Is your feature request related to a problem? Please describe.
I need to set my own Network User ID. The advantages of setting a seperate value is that it is one defined by the platform to give a common anonymous user ID. This way different tools can have a same user definition.
Another major advantage is guarding against Apple ITP resetting the user ID on every return visit.
The collector cookie (Network user ID) is designed to solve this but another difficulty is that we use an API gateway that is on a seperate domain to our customer facing sites. If we did get the header cookie to be forwarded it would not resolve our issue.

Describe the solution you'd like
A new function setNetworkUserId and/or setNetworkUserIdFromCookie that sets the tnuid value in the tracker protocol.

Describe alternatives you've considered
Setting a new custom context including the value. The main disadvantages with this are:

1. We would need to do this everywhere with every request adding unnecessary bloat to the payload and making for a more complex implementation for all FE engineers.
2. The data is less accessible and something this important should be available on root level.

Additional context
The tracker protocol offers a network user override here. It would make sense give the option to use this.

[miike]

I like the flexibility of this approach but I'm a little wary of overriding a tracker protocol parameter when the network_userid has quite a well defined definition that downstream things depend on (the collector, and to a lesser extent the enricher and data models).

We would need to do this everywhere with every request adding unnecessary bloat to the payload and making for a more complex implementation for all FE engineers.

Have you considered using a global context for this? This should only require defining once and then will get attached to all subsequent requests.

[RobertJamesEllison]

HI @miike, yes the global context is also what I was referring to. We'd prefer to use network user ID as that is it's intended purpose. A custom context added to every hit would also increase the size of the payload much more than the network user ID would.
Also given this is supported in other trackers and in the tracker protocol it would be good to be able to leverage it.

The parameter would only be overridden if you use this function otherwise the tracker would take the default behaviour.

[miike]

Thanks - I think if the end user is aware of any downstream impacts of overriding the network_userid then that's fine.

@igneel64 We could probably just wrap addPayloadPair for tnuid in a nicer function?

[Jack-Keene]

Hi @RobertJamesEllison,

We would be happy to add a setNetworkUserId function, however, this may not work as required as the NUID will not be persisted across pages. The function would need to be called on each page change, as represented in the image below.

.

At the moment we can't support persisting the NUID as this is a major change in the behaviour of the collector. Can you let us know if the proposed change works for you?

[Jack-Keene]

Hi @RobertJamesEllison,

Just following up on this, is this something that you would find useful or does this not fix your problem?

[RobertJamesEllison]

Hi @Jack-Keene,

Sorry for the delayed response. Yes the value is stored in a cookie set from in the HTTP header server response. This should always be present and should persist. I do get that this would need to exist on every hit if we wanted to join these hits together.

Thanks,
Rob