Prebid Publisher-Provided User IDs

[bretg]

Type of issue

Proposed Convention

Description

Note: major update to the proposal here -- replacing the original First Party Data-based proposal with a new UserID sub-module.

Recent identity discussions have suggested there would be value in allowing Publishers to communicate their own first party user IDs (PPUID = Publisher Provided User ID) to some or all bidders.

The precise use cases aren't fully worked out, but this proposal takes on a meta-goal of enabling publisher flexibility:

• ability to choose which bidders receive their ID(s)
• ability to support multiple IDs (e.g. multiple data sets, transition phases)

If we've learned anything about User IDs in the past year, it's that the space changes quickly, so flexibility seems warranted.

Add another user ID sub-module, call it the "PubProvidedId" module. It takes values from two places:

static eids values e.g.

pbjs.setConfig({
    userSync: {
        userIds: [{
            name: "pubProvidedId",
            params: {
                eids: [{
                    source: "example.com",
                    uids:[{
                      id: "value read from cookie or local storage"
                      ext: {
                        stype: "ppuid"
                      }
                  }]
                },{
                    source: "id-partner.com",
                    uids:[{
                      id: "value read from cookie or local storage"
                      ext: {
                        stype: "dmp"
                      }
                  }]
                }]
            }
        }]
    }
});

a publisher-provided function that produces eids-style output

pbjs.setConfig({
    userSync: {
        userIds: [{
            name: "publisherProvided",
            params: {
                eidsFunction: getMyId  // any function that exists in the page
            }
        }]
    }
});

After consent is checked, the resulting eids structure is simply passed to bid adapters as bidRequest.userId.pubProvided.

{
                eids: [{
                    source: "example.com",
                    uids:[{
                      id: "value read from cookie or local storage"
                      ext: {
                        stype: "ppuid"
                      }
                  }]
                },{
                    source: "custom-id-partner.com",
                    uids:[{
                      id: "value read from cookie or local storage"
                  }]
                }]
}

It's also available from the getUserIdsAsEids() function.

AMP

It's come to our attention that passing dynamic data through AMP is a problem. See prebid/prebid-server#1404

So even though we don't know that it's currently possible to handle User IDs in AMP at all, I think it makes sense to change the proposed (theoretical) AMP proposal to removing User IDs from the targeting and making a new path for it:

  <amp-ad width="300" height="50"
    type="doubleclick"
    data-slot="/1111/amp_test"
    data-multi-size-validation="false"
    rtc-config='{"vendors": {"prebidrubicon": {"REQUEST_ID": "blah", "USER_EIDS"="eids-json"}}}' >
  </amp-ad>

This would require specific support from the AMP Project to allow for dynamic values.

Community input needed here.

[patmmccann]

@jdwieland8282 not sure if you're aware but I think you pinned the issue for everyone, not just yourself

[patmmccann]

Appears to somewhat be a duplicate of #4175

It seems publishers specifying a ppuid should also be adding metadata, is this an email, is this hashed, etc. Perhaps this proposal should include some conventions on 'type'

Also, implementing this closer to the suggestion in 4175 would allow for some consent checking to be coded in, where this proposal would rely on the publisher to check consent before setting the Id.

[bretg]

Discussed an alternate solution in committee that addresses the consent management piece.

Add another user ID sub-module, call it the "PublisherProvided" module. It could take values from two places:

1. static eids values e.e.

pbjs.setConfig({
    userSync: {
        userIds: [{
            name: "pubProvidedId",
            params: {
                eids: [{
                    source: "example.com",
                    uids:[{
                      id: "value read from cookie or local storage"
                      ext: {
                        type: "ppuid"
                      }
                  }]
                },{
                    source: "id-partner.com",
                    uids:[{
                      id: "value read from cookie or local storage"
                      ext: {
                        type: "dmp"
                      }
                  }]
                }]
            }
        }]
    }
});

2. a publisher-provided function that produces eids-style output

pbjs.setConfig({
    userSync: {
        userIds: [{
            name: "publisherProvided",
            params: {
                eidsFunction: getHashedEmail  // any function that exists in the page
            }
        }]
    }
});

After consent is checked, the resulting eids structure is simply passed to bid adapters as bidRequest.userId.pubProvided.

{
                eids: [{
                    source: "example.com",
                    uids:[{
                      id: "value read from cookie or local storage"
                      ext: {
                        ...
                      }
                  }]
                },{
                    source: "custom-id-partner.com",
                    uids:[{
                      id: "value read from cookie or local storage"
                  }]
                }]
}

It's also available from the getUserIdsAsEids() function.

AMP

It's come to our attention that passing dynamic data through AMP is a problem. See prebid/prebid-server#1404

So even though we don't know that it's currently possible to handle User IDs in AMP at all, I think it makes sense to change the proposed (theoretical) AMP proposal to removing User IDs from the targeting and making a new path for it:

  <amp-ad width="300" height="50"
    type="doubleclick"
    data-slot="/1111/amp_test"
    data-multi-size-validation="false"
    rtc-config='{"vendors": {"prebidrubicon": {"REQUEST_ID": "blah", "USER_EIDS"="eids-json"}}}' >
  </amp-ad>

Community input needed here.

[wqi1972]

@bretg, would you please clarify a bit more about

   params: {
                **eidsFunction**: getHashedEmail
            }

Is getHashedEmail a customer js function defined on publisher web page, which returns publisher customized user id?

Also for this setting, it doesn't need to check consent inside prebid code, since that customized function (getHashedEmail in this example) suppose already take care of user consent check.
(publishers won't share any first party user ids without user consent to any external partners including prebid, at least we won't :) )

[bretg]

Is getHashedEmail a customer js function defined on publisher web page

Correct

Also for this setting, it doesn't need to check consent inside prebid code, since that customized function suppose already take care of user consent check.

Any user-id submodule gets consent checks.

The sense I got from the committee meeting was that it's not cool to throw the consent problem onto pubs in general, even if some of you can handle it.

FWIW - re-thinking the AMP portion of this - will update the alternate proposal soon.

[wqi1972]

Make sense.

[ian-lr]

Would just like to specifically +1 the ability to choose which bidders receive their ID(s) part of your proposal. I hear frequently from publishers that they would like to be able to explicitly configure this rather than treating all bidders the same.

[smenzer]

Would just like to specifically +1 the ability to choose which bidders receive their ID(s) part of your proposal. I hear frequently from publishers that they would like to be able to explicitly configure this rather than treating all bidders the same.

Is this in relation to specifically the publisher's ID and which bidders get access to it? Or are you suggesting that all User ID submodules be configurable by the publisher to indicate which bid adapters have access?

[ian-lr]

@smenzer Ah, good question. I was thinking of the latter and understood it to be a broader userId dependency of this proposal, not specific to PPUIDs.

[bretg]

Since we've deployed the PubProvided module, going to close this issue out. The permissions scheme is being discussed in #5814