Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Need support for different sharedIds for different bidders #9414

Open
renebaudisch opened this issue Jan 12, 2023 · 18 comments
Open

Need support for different sharedIds for different bidders #9414

renebaudisch opened this issue Jan 12, 2023 · 18 comments
Assignees
Labels

Comments

@renebaudisch
Copy link
Contributor

renebaudisch commented Jan 12, 2023

Type of issue

feature request

Description

We need to pass different values to different bidders using sharedId adapter but it turns out that only the first configuration for sharedId will be applied.

Steps to reproduce

userIds config we want to use

{
    name: "sharedId",
    bidders: ["bidderA"],
    storage: {
        type: "html5",
        name: "PreBidSharedId_bidderA",
        expires: 365,
        extend: true
    }
}, {
    name: "sharedId",
    bidders: ["bidderB"],
    storage: {
        type: "html5",
        name: "PreBidSharedId_bidderB",
        expires: 365,
        extend: true
    }
}

Test page

https://reports.asadcdn.com/demopages/2023/sharedId.html
Where bidderA = adf
and bidderB = teads

Expected results

Both bid requests are done with their own eids object

Actual results

Only bidderA holds a pubcid entry, while bidder B does not.

Platform details

v7.31.0

@patmmccann
Copy link
Collaborator

Why do you want to do this?

@patmmccann
Copy link
Collaborator

Linking as related #8429

#8499

@adtechnology
Copy link

@patmmccann This is a requirement for First Party Data Protection. We want to send different derivates of our First Party ID to the ssps to avoid ID leakage or non agreed matchings.

@renebaudisch
Copy link
Contributor Author

@patmmccann so this is already possible? Is there a documentation to that related PRs new option?

@patmmccann
Copy link
Collaborator

I believe is possible to do this with static config since #5767

@renebaudisch
Copy link
Contributor Author

I read #8499 today again and again and for me it seems like each idModule would need to be updated the way merkle was updated. They have a dedicated part of code for multiple ids.

Doesn't that mean, that the sharedIdModule also needs an update like the merkle one and do the adapters supporting those idModules like teadsBidAdapter or adfBidAdapter need to be updated?

@patmmccann
Copy link
Collaborator

@AramZS from wapo echoed support for this feature request (if it is indeed not currently possible by hacking the ppid module config)

@jdwieland8282
Copy link
Member

I'm onboard for adding this to the shareid roadmap. Have we confirmed whether it is already possible or not?

@dgirardi
Copy link
Collaborator

I am not aware of a way to do this in general. The closest I can think of is to setBidderConfig({bidders: ['bidderA'], config: /* pass ortb2.user.ext.eids */}), but it relies on the bid adapters picking that up. Currently the guidance for them is to look into bidRequest.userId and bidRequest.userIdAsEids, both of those are always identical across all bidders.

@jdwieland8282
Copy link
Member

thanks @dgirardi we will take this up in our next sprint.

@jdwieland8282
Copy link
Member

@renebaudisch I think we need to modify the config in order to support unique sharedIds per bidder. Specifically we think we need to add a booleen unique, that when received along side a bidder object would tell the sub module (sharedid in this case but we should extend this feature to all user id submodules), to generate a unique id for each bidder listed in the bidder object. For example given this config

{
    name: "sharedId",
    bidders: ["bidderA","bidderB"],
    unique:true,
    storage: {
        type: "cookies",
        name: "SharedId",
        expires: 365,
        extend: true
    }
}

bidRequest.userId & bidRequest.userIdAsEids would return

"eids":[
         {
            "source":"pubcid.org",
            "uids":[
               {
                  "id":"abc",
                  "atype":1,
                  "ext":"bidderA"
               },
               {
                  "id":"123",
                  "atype":1,
                  "ext":"bidderB"
               }
            ]
         }

@dgirardi
Copy link
Collaborator

dgirardi commented Feb 7, 2023

@jdwieland8282 shouldn't that have only one id, different for each bidder? otherwise it is not concealing ids; bidderA still can snoop into the id given to bidderB.

@jdwieland8282
Copy link
Member

thats a good point @dgirardi humm we'll have to think about this a little more. Thanks for pointing that out.

@renebaudisch
Copy link
Contributor Author

renebaudisch commented Feb 8, 2023

Please let me add, I would prefer to set this as config:

userIds = {
    name: "sharedId",
    bidders: ["bidderA"],
    storage: {
        type: "html5",
        name: "PreBidSharedId_bidderA",
        expires: 365,
        extend: true
    }
}, {
    name: "sharedId",
    bidders: ["bidderB"],
    storage: {
        type: "html5",
        name: "PreBidSharedId_bidderB",
        expires: 365,
        extend: true
    }
}

@jdwieland8282
Copy link
Member

Hi @renebaudisch the issue of concealing ids @dgirardi mentions would still apply

@patmmccann
Copy link
Collaborator

patmmccann commented Mar 27, 2023

@SKOCHERI @jdwieland8282 if this is actively in progress, pls let us know

@jdwieland8282
Copy link
Member

We're still thinking about an approach, we haven't come up with an approach that would conceal unique sharedids from bidders.

@patmmccann
Copy link
Collaborator

Different sharedids for different bidders imply to each ssp that they are a different user and breaks dsp frequency capping on the identifier. I think this should be a 'will not do' as it intentionally breaks the value of the identifier.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Needs Req
Development

No branches or pull requests

6 participants