Add a refreshes option to userId module

[smenzer]

Type of issue

Feature request

Description

Today in the userId module, there is an option to set the expiration of the cookie that stores the provider's user ID. Some providers, though, may need to be called regularly (every hour, every day, etc) to refresh the user ID due to rotating IDs (e.g. the user's ID is encrypted per publisher, and the key used to do the encryption rotates every day for privacy and security reasons). The only solution to ensure prebid calls the provider every day (for example) is to set the expires to 1 day. But this means that every day the cookie will expire, and for some period of time, the user will have no ID and will miss the first impression (since user id calls are made after the bid requests are made). This also means the provider may have lost their master user ID for this user (since the cookie expired) and could result in a completely new user ID being generated, losing the consistency that is otherwise offered with the prebid solution.

Prebid should add a refreshes option next to the existing expires option that will force a user id request call to the provider at whatever time period is set. This value should support values down to the minute, rather than being in days like expires is today. It may make sense to name the variables (or at least the new one) according to their time unit (e.g. refreshesMinutes and expiresDays).

[jaiminpanchal27]

I think it is little confusing to keep refresh and expire together. If the user id needs to be refreshed in an hour doesn't it mean that it is expired. For instance, lets consider expire as 1 day and refresh as 30 min. In this case User id module should refresh the user id every 30 minutes and store it in cookie/localstorage. So What is the use for expire here ? What should happen after 1 day ?

Without making a breaking change, I think adding

• delayAuction
• storage as optional. Let id systems manage their own storage. Done in Criteo real time user sync #3930
  should work for all scenarios.

I had similar requirement with Criteo rtus module. Criteo's user id expires in 1 hour but as per current user id api, storage is a required param and expires is set in days. Hence to avoid breaking change, I made storage as optional and handled storage logic in the module itself.

Only concern with this implementation is that I am missing user id on first page load. That will be handled with delayAuction feature.

[smenzer]

@jaiminpanchal27 so if storage is marked as option, then within the ID5 submodule, we can dictate how the id is stored (cookie, local storage, etc (potentially via a param flag to give pubs control if they want it)) as well as when we need to refresh?

I want to make sure that even if we handle expiration on our own, that we still don't lose the cookie. Here's an example with the same refresh (30 min) and expire (1 day) that you gave.

First time we see the user t=0: auction happens (unless delayAuction is used) and sync occurs after. We create an ID5 ID = 123 with publisher key 001, resulting in a response to prebid of ABC, and this is stored in the cookie. Buyers will be able to decrypt ABC to 123.

We see the user t+10 min: prebid pulls ABC from the cookie and does not need to make a call to ID5.

We see the user t+40 min: prebid still pulls ABC from the cookie to use in this auction, but after the auctions will make a call to ID5 to refresh the ID. ID5 knows this is still user 123 but now encrypts with publisher key 002, resulting in a response to prebid of XYZ, and this is now stored in the cookie, overwriting ABC. Buyers will be able to decrypt XYZ to 123.

Let's say we don't see the user again for more than 1 day, so t+1 day+45 min: The cookie storing XYZ is now expired and doesn't exist. Prebid runs the auction and after, calls ID5 for an ID. We don't know this user anymore (assuming 3rd party cookies are blocked) and therefore we generate a new ID5 user 789. Buyers will no longer be able to decrypt this user back to 123, losing any capping or targeting data they collected to-date.

Does all of that make sense as to why I think refresh and expiration are separate things? It's really that t+40min use case that is what we want to support.

[jaiminpanchal27]

@smenzer Thanks for explanation. It makes complete sense how refresh and expire work together. If multiple id systems need refresh then adding refresh property and making it the responsibility of base user id module is a good idea.

Yes with optional storage you can dictate in module with cookie or localStorage. What you explained above can be done without adding refresh as well.
ID5.getId method will first check for existing cookie and return if it exists else return a callback function which will make the call to your endpoint to fetch new id. Once you receive id, store it in cookie for n minutes where n = refresh time.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[bretg]

@smenzer - this an interesting use case, but seems rather specific to your ID system, so would like to suggest that the fastest way to implement would be for you to open the PR.

[smenzer]

Hi @bretg I agree...we'll put in a PR for it for our own submodule. Thanks!