LiveIntent UserId module: Add support for magnite id

[3link]

Type of change

• Other

Description of change

This pull request adds eid mapping for the magnite ids that now can be resolved via the LiveIntent UserId module.

Other information

• repository of the backing live-connect module: https://github.com/LiveIntent/live-connect
• documentation PR: Add magnite id to examples prebid.github.io#4498

[3link]

The test errors seem not to be related to changes in this PR.

[patmmccann]

Okay so now we legit have two modules that are not the magnite module returning this with 33across doing the same. I think we need to hold this until you or they submit some sort of tie breaking mechanism to the userid module.

[3link]

Okay so now we legit have two modules that are not the magnite module returning this with 33across doing the same. I think we need to hold this until you or they submit some sort of tie breaking mechanism to the userid module.

Hi @patmmccann, you are referring to #9633, right? Will check with product next week and get back to you.

[deepthivenkat]

Hello @patmmccann Could you let me know for which of the following scenarios we are implementing the tie break for:
A) Magnite cookies are present from the magnite module and LiveIntent user id module also has a magnite cookie
B) Magnite cookies are not present in the magnite module but are present in both 33Across module and LiveIntent user id module

The reason i ask this is:
For scenario A) if the path in which the magnite bidder adapter looks for magnite cookies populated from magnite module is different from the user->ext->eids array, then it is cleaner to implement the logic to read magnite cookies from LI only if magnite cookies are not populated by magnite module from magnite's bidder adapter. If the path is same, then i need to understand a little bit more about how to check if the magnite cookies are already present

For scenario B) Which approach do you like better? Relying on the load sequence(this provides equal opportunity for both 33Across and Liveintent) or allowing for Magnite to define the priority to pick up this cookie when its own module doesnt have it?

[jdwieland8282]

The id PMC recommends an optional ext.provider field to reference the "source of the source"

"user":{
   "ext":{
      "eids":[
         {
            "source":"magnite.com",
            "uids":[
               {
                  "id":"d88c96-5cb6-410d-827d-b019e476",
                  "atype":1,
                  "ext":{
                     "source":"magnite"
                  }
               }
            ]
         },
         {
            "source":"magnite.com",
            "uids":[
               {
                  "id":"d88c96-5cb6-410d-827d-b019e476",
                  "atype":1,
                  "ext":{
                     "source":"magnite"
                  }
               }
            ]
         }

[deepthivenkat]

Thank you!

[3link]

@patmmccann @jdwieland8282 Can you please have a look at this proposal: #9896?

[3link]

@patmmccann Can you please have a look at the proposal for distinguishing providers for id types that can be exposed by multiple modules? #9896

[SKOCHERI]

@3link Can you update https://github.com/prebid/Prebid.js/blob/master/modules/userId/eids.md with magnite eids

eids.md needs update

[3link]

@SKOCHERI Done in 68aae95.

@SKOCHERI Please note, there is a concern that is blocking this PR. There is a proposal that might unblock it and requires a review: #9896.

[dgirardi]

this seems to go against #9896, as in including the liveintent module can populate magnite at the top level instead of inside libp. is there some other integration pending?

[3link]

this seems to go against #9896, as in including the liveintent module can populate magnite at the top level instead of inside libp. is there some other integration pending?

@dgirardi This is correct. This PR started the discussion about exposing the same type of identifiers via multiple user id modules. #9896 is meant to be a place where possible solutions are discussed. Once a solution has been found, I will update this PR.

It is possible to flag this PR as blocked? Alternatively, I can convert it to a draft so it does not confuse reviewers.