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

New User ID Submodule: Rewarded Interest #12340

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

thede-ri
Copy link

Type of change

  • New User ID submodule

Description of change

Rewarded Interest is an identity provider that enables users to monetize and manage the exposure of their identity to various ad sources through the Rewarded Interest browser extension.

The Rewarded Interest browser extension exposes an on-page API window.__riApi.getIdentityToken(). This submodule obtains the identity token, wraps it into eid and passes it to the callback provided by the User Id module. If __riApi is not available - error will be logged (if debug is enabled) and no ID will be passed to the callback.

Note: no storage is used as Identity Token is refreshed frequently.
Rewarded Interest partners (such as DSPs, SSPs, and publishers) can use the Rewarded Interest Identity Resolution API to resolve the Identity Token into a CMAID (Consumer Mediated Advertising Identity). The CMAID is a durable, cross-site, cross-device advertising identifier that remains consistent across visits and devices enrolled by a Rewarded Interest user, unless they choose to reset or pause it.

Config example:

pbjs.setConfig({
    userSync: {
        userIds: [{
            name: "rewardedInterestId"
        }]
    }
})

@ChrisHuie ChrisHuie self-requested a review October 22, 2024 13:16
@ChrisHuie ChrisHuie self-assigned this Oct 22, 2024
@patmmccann
Copy link
Collaborator

why doesnt rewarded interst browser extension just inject into the eids object in place instead of relying on publisher moxule deployment?

@justadreamer
Copy link
Contributor

Hi Patrick, I guess injecting it into the configuration won't do as getIdentityToken() must be called before each auction as it may return a different token each time. Also there is a synchronization issue - the API is async in nature, while the configuration is executed synchronously and may be even before the API is available on the page. Injecting it into the raw requests seems a bit brutal, so publishing it as a module seems like a good way for publishers to opt-in.

@justadreamer
Copy link
Contributor

So in general the extension can indeed attempt to set the ortb2.user.ext.eids on page load (thanks for this suggestion!), like:

var pbjs = pbjs || {};
pbjs.que = pbjs.que || [];

pbjs.que.push(function () {
    pbjs.mergeConfig({
        ortb2: {
            user: {
                ext: {
                    eids: [
                        {
                            source: "rewardedinterest.com",
                            uids: [
                                {
                                    id: "<IdentityToken>",
                                    atype: 3
                                }
                            ]
                        }
                    ]
                },

            },
        },
    });
});

@patmmccann is this the way you meant by "inject in place"?

A couple concerns:

  1. The publisher may not even expose pbjs as global (I doubt it is widespread, but still a possible modification) - for such pubs it makes sense to add a module. Also pbjs may be renamed and the extension would have to track window.__pbjsGlobals to find an appropriate object and it may be a bit problematic to sync with pbjs loading, so for this case a module may also be an appropriate solution. Unless there are some callbacks that would signal the wrapper is loaded of which we are unaware.
  2. We don't have a way to guarantee that our ortb2 snippet will be merged in any particular order relative to other config snippets - thus we can be easily overwritten by publisher's setConfig call.
  3. We noticed that some bid adapters do not take stuff from ortb2.user.ext.eids, unless there is also at least one ID submodule that added its stuff into bidRequest.userIdAsEids - these might need to be patched as separate pull requests ofc.

Thus the module adds some additional reliability.

@patmmccann
Copy link
Collaborator

patmmccann commented Oct 30, 2024

@patmmccann is this the way you meant by "inject in place"?

yeah that's what i meant, you'll get a lot more uptake that way :) you are of course welcome to do both, but i think the injection path will be more successful

Also pbjs may be renamed and the extension would have to track window.__pbjsGlobals to find an appropriate object and it may be a bit problematic to sync with pbjs loading,

that's fairly easy to handle, you can just inject into all the prebid globals you find :)

We noticed that some bid adapters do not take stuff from ortb2.user.ext.eids, unless there is also at least one ID submodule that added its stuff into bidRequest.userIdAsEids - these might need to be patched as separate pull requests ofc.

I think this was solved in #12110 ; if not, we should open an issue. Cc @dgirardi

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants