Feature request: page view ID

[acsbendi]

Page view ID is a simple unique ID that's generated when Prebid.js loads on a web page. It is already present in many different adapters, including ours. The main purpose of this ID is to prevent displaying the same ad on a specific page view multiple times, in the absence of user-related/personal data.

While the current adapter-specific solutions work well in general, having this ID generation in the common codebase would help future adapters to easily include this feature and it could also enable Prebid server adapters to access this data, which is currently not possible without adding extra custom code by the company running the Prebid server. Therefore, the page view ID should also be exposed in the prebidServerBidAdapter.

To prevent correlation of impressions across SSPs/exchanges, this identifier may be generated separately for each adapter. In the case of Prebid server, the client adapter can send a list of random IDs (perhaps configurable how many), from which the server can randomly assign one to each adapter it uses.

If the proposal looks fine and is accepted, I'll be happy to contribute the necessary, hopefully quite simple code changes.

[dgirardi]

What's missing is an extension name ($.ext.pageViewId?) and some clarification on Prebid Server.

In the case of Prebid server, the client adapter can send a list of random IDs (perhaps configurable how many), from which the server can randomly assign one to each adapter it uses.

Surely the assignment cannot be random or the ID won't stay constant across a page view. JS could populate these for each bidder it knows about, but there are some scenarios where server can add other bidders. I believe to be complete server would need to also have logic to populate this new ID.

[acsbendi]

Yes, $.ext.pageViewId works fine, or maybe $.ext.page_view_id (OpenRTB doesn't seem to use capital letters).

I believe to be complete server would need to also have logic to populate this new ID.

That sounds better indeed. Prebid server could generate a set of new UUIDs that are based on the client's UUID and the bidders' names (for example, using a deterministic cryptographic hash function) and give only these new UUIDs to its bidders.

[patmmccann]

It seems you have already solved this problem

Prebid.js/modules/koblerBidAdapter.js

Line 188 in 7ca73fd

page_view_id: pageViewId

; is your request largely confined to the pbs adapter?

[acsbendi]

@patmmccann Yes, mostly, the Prebid.js parts would be to support that, and perhaps clean up a few lines of adapter-specific code in the process (some other adapters have it already as well).

[acsbendi]

@patmmccann @dgirardi May I start working on implementing this? Or is there anything blocking that?

[dgirardi]

There's no blocker. Are you planning to also propose / contribute this into PBS?

[acsbendi]

@dgirardi Yes, I am. I can start working on it then!

[lcorrigall]

PMC:

• To improve adoption, we will need to get Prebid server to adopt this as well.
• for SPAs, publisher will want to have the ability to refresh the page id
• overall, positive reception, but more precise description of how this will work and the intended use-cases

[acsbendi]

@lcorrigall

more precise description of how this will work

My idea is that Prebid.js will generate a simple random UUID when it's loaded and it will keep that UUID as the page view given to adapters, including the Prebid server adapter. As you said, Prebid.js should also expose a method to refresh the page view ID.

As for the Prebid server, see my comment above:

Prebid server could generate a set of new UUIDs that are based on the client's UUID and the bidders' names (for example, using a deterministic cryptographic hash function) and give only these new UUIDs to its bidders.

intended use-cases

The primary intended use-case is to prevent showing the same ad multiple times on a single page (view) without relying on user data.