LiveIntent UserId module: Expose shared id

[3link]

Type of change

• Feature

Description of change

This PR introduces a new feature that will allow to provide the shared id via the LiveIntent user id module. The configuration below shows how to configure the location from which to pull the shared id:

"params": {
    "sharedId": {
      "strategy": "cookie", // or 'html5'
      "name": "foobar"
    },
    "requestedAttributesOverrides": {'sharedId': true}
}

The shared id will be exposed by the LiveIntent user id module as a separate id. There is also support for translation into EIDs. In case more than one module exposes shared ids, module prioritization should be used to define priority. For example:

{
    //...
    "idPriority": {
        pubcid: ['sharedId', 'liveIntentId']
    }
    //...
}

Other information

• based on the latest version of LiveConnect: https://www.npmjs.com/package/live-connect-js
  Release Notes:
  • [CM-1155] Send raw idcookie ([CM-1155] Send raw idcookie LiveIntent/live-connect#328) (LiveIntent/live-connect@4dc32a9)
  • Bump the npm-packages group with 8 updates (Bump the npm-packages group with 8 updates LiveIntent/live-connect#327) (LiveIntent/live-connect@f93738d)
  • Bump the npm-packages group with 4 updates (Bump the npm-packages group with 4 updates LiveIntent/live-connect#325) (LiveIntent/live-connect@6fcc6b2)
  • Bump the npm-packages group with 1 update (Bump the npm-packages group with 1 update LiveIntent/live-connect#324) (LiveIntent/live-connect@de91e1e)
• documentation changes: Liveintent UserId module: Expose shared id prebid.github.io#5163

[patmmccann]

Please provide full release notes in your pr description

[peixunzhang]

It's added. Please take a look. Thank you!

[3link]

@gwhigs Hi Graham, is anything missing in this PR that prevents it from being merged from your perspective?

[jdwieland8282]

I love the idea behind this PR, I do have a few questions.

1. How would SharediD enter the bid stream in this example?
2. A user should have many SharediDs, will you add all the users SharediDs or just pick one? If one how will you decide which one?

[deepthivenkat]

Thank you Jeff!

1. We expect it to appear in the following format in the eids array:
   User":{
   "Ext":{
   "eids": [{
   "source": "pubcid.org",
   "uids":[{
   "id": "ahsjdadjasldkasjdkakldaklda",
   atype: 3,
   ext: {provider: 'liveintent.com'}
   }]
   }

2. This feature focuses on allowing publishers to share their own first party cookie as shared id (they can specify the location from which they want us to pull this id from). Even for cases where there is multiple shared ids, our user id module will pick only one id from the location specified by the publisher. When there are several modules populating shared id, the priority defined above will be used to decide which id will make it to the bidstream.

[pycnvr]

Is there a reason why this functionality can't be added into shared id instead? Would you mind describing a scenario where publisher define their own id? AFAIK, that's already possible by toggling the create option to off in shared id.

[3link]

@pycnvr Hi Paul, the idea of the feature is that the cookie configured as shared ID will be sent to our backend and aid in identity resolution. Accessing the shared ID maintained by the shared ID module from another ID module is not possible, if I see it correctly. Also, in the next step we would like to add an option for "injecting" LiveIntent's first party cookie as shared ID and be the generator for the shared ID cookie. Both seems to be very much tied to our customers' needs and specific to our module. That was the reason for putting it all under the umbrella of LiveIntent's user ID module.

[pycnvr]

@3link, Hi Viktor, thanks for the explanation. I feel like this approach kinda goes against the spirit of the rule. Are there alternative solutions that can be explored? What happens when another ID vendor takes the same approach? Would that lock out one group of customers?

[3link]

@pycnvr I would say, this approach of providing an alternative way to populate the shared id is inline with how all other ids are handled in Prebid. For example, currently UID2 can be provided by the UID2 module as well as the LiveIntent module. Same is true for many other ids. But also, any other vendor can implement UID2 support in his module and be a provider for this type of ids. A customer then can pick freely between the available providers and even have a combination of providers and define their priority - as has been implemented in this PR a while ago: #9896.

I think this approach is very flexible as it allows customers to say "I would like to have this id from this provider" and switch to a different provider very easily if needed by adjusting the user id module configuration. There is no vendor lock-in.

[pycnvr]

@3link Hi Viktor, thanks for the reply. I don't have any additional comments but would be interested to hear from other folks.

[3link]

@3link Hi Viktor, thanks for the reply. I don't have any additional comments but would be interested to hear from other folks.

Thank you!

[jdwieland8282]

I'm in favor of this PR and the approach seems reasonable. Specifically this comment:

the idea of the feature is that the cookie configured as shared ID will be sent to our backend and aid in identity resolution.

embedding SharediD deeper into identity providers id resolution tech stack makes SharediD and by extension Prebid more valuable to publishers. We should encourage other id providers to use SharediD as a signal into their id graph.

[pycnvr]

Yes, that sounds great. Would it be possible to relax the restriction around shared id so that other id modules could access its value? This way more than one id modules could use shared id.

[ncollierepsilon]

Late to the party here, so forgive if I misunderstand something and please feel free to correct me...

When there are several modules populating shared id, the priority defined above will be used to decide which id will make it to the bidstream.

Sounds like it will become an arms race where each identity solution module will necessarily put themselves higher in the priority stream, no?

Accessing the shared ID maintained by the shared ID module from another ID module is not possible, if I see it correctly.

In the philosophy of SharedID and the spirit of it remaining industry/vendor agnostic, open and transparent wouldn't this in fact be a better solution to take here? It would provide a standard way for all modules to access the value and a single point of entry/attack in the case of potential bad actors and make documentation and direction unambiguous and consistent?

I also question the complexity being layered in for publishers here over time, and pulling it from the core module would be one less step for the publisher to grok and configure.

Also, in the next step we would like to add an option for "injecting" LiveIntent's first party cookie as shared ID and be the generator for the shared ID cookie.

So the longer term plan is to allow this module to overwrite/create the shared ID? How can we be sure future modules will conform to the format/standard of the original shared id module or not squash prior values?

[dmdabbs]

The SharedID concept is a single, simple, neutral, stable, unique value per site per device.
More than one site-unique "SharedID" seems counterintuitive.

[dmdabbs]

This feature focuses on allowing publishers to share their own first party cookie as shared id (they can specify the location from which they want us to pull this id from).

Why does the use case of the "publisher sharing a FP cookie value" need that value to "become SharedID?"
Why can this not be a distinct publisher-provided ID that has a recognised place in eids?

[jdwieland8282]

@3link re: #11118 (comment)

To clarify, we are ok with Liveintent's tech reading a SharediD from the page, and returning a Liveintent derived id back to the page/bid stream, but we do not want the SharediD UID overwritten by what your server returns. Does that make sense?

[robertrmartinez]

Looks fine to me, with understanding that other community members sign off on allowing it to set sharedId. From the looks of it, this will just populate another sharedId if one is already available in the stream if I am not mistaken which seems a bit weird. But I am not aware too much of the nuances of Identity Link + Shared ID, so would like more community input. (I have missed the last couple PMC Meetings unfortunately so maybe this has been discussed already)

CC @patmmccann @jdwieland8282 @pycnvr

[3link]

@jdwieland8282 Thank you for the info! We are currently in the process of deciding how to move forward with this PR.

[adammarkey]

Seeing the comments above, the intention is that the liveintent shared ID field will enter the bid stream as "atype: 3" which is a "A person-based ID, i.e., that is the same across devices".

Given sharedID guidance looks like this: "The SharedID ID system sets a user id cookie in the publisher’s domain. Since the cookie is set in the publisher’s first party domain it does not fall in scope of browser restrictions on third party cookies. Safari has restrictions on first party cookies set via document.cookie. "

It looks like this change is expanding the scope of a Shared ID. Am I wrong here? If it does, are we opening ourselves up for unintended consequences? IMO There are other ways to add these kinds of UIDs to the bid request that are more intentional.

[3link]

Seeing the comments above, the intention is that the liveintent shared ID field will enter the bid stream as "atype: 3" which is a "A person-based ID, i.e., that is the same across devices".

@adammarkey That is not the intention. The recipe for converting a shared ID into an EID has not changed: https://github.com/prebid/Prebid.js/pull/11118/files#diff-fa35d6d24c7b24a515da5e8b6df8d21bdc7f73367f7ad7a668e83969df7194f0

[3link]

Thank you all for the feedback! We decided to close this PR and change the approach.