You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is an increasing number of adapters that interface with ORTB backends. Currently, each needs to replicate logic to convert PBJS bid objects to ORTB and back again; a dialect of that logic is also implemented in the PBS adapter.
We should extract that into one canonical implementation, and make it trivial to add a new adapter if it talks to an ORTB backend.
Proposal
Move the enrichmentFpdModule logic into core and extend it to populate any ortb2 field that is not specific to the impression or bidder (for example, device.ua). Currently this is left to each individual adapter, but they rarely should have a reason to differ in their implementation. This is true for "traditional" (non-ORTB) adapters as well; consolidating these items into first-party data should allow some simplification in that regard too.
Implement utilities bids2ortb and ortb2bids such that an adapter may use them in this manner:
these utilities should handle everything that the PBS adapter now understands, namely:
banner, video, and native mediatypes
coppa / gdpr / usp
price floors
multibid
schain
gpid / pbadslot
any others?
Adapter-specific customization
Current ortb bidders are surprisingly similar, but not identical. Adapters are free to modify the return value they get from bids2ortb / ortb2bids, but that pattern is not ideal for some cases.
Bid filtering
The Rubicon adapter wants to create a separate ortb request for each one in a set of particular bids:
Because it makes practical sense to separate the ortb implementation of individual features (e.g. bidfloor should only be populated if the priceFloors module is installed), it would be relatively straightforward to allow adapters to override their translation. I have not found a great use case for this yet but I'll use the OpenXNew adapter as inspiration:
Suppose that logic was changed to say "if bid.params.customFloor is defined, use that instead of the 'real' floor". We could allow that with something like:
which would mean "override the ortb translation logic for the bidfloor feature with this custom logic instead". The difference with simply overwriting the contents of imp like we did in the previous example is that:
the original logic would not run at all - which could conceivably help performance if the feature is complex enough;
related fields are grouped together under a single feature name, which allows adapters to treat them as a logical entity without worrying about changes in core. For example an adapter that is not interested in GPDR could disable it with:
Type of issue
Feature
Description
There is an increasing number of adapters that interface with ORTB backends. Currently, each needs to replicate logic to convert PBJS bid objects to ORTB and back again; a dialect of that logic is also implemented in the PBS adapter.
We should extract that into one canonical implementation, and make it trivial to add a new adapter if it talks to an ORTB backend.
Proposal
Move the enrichmentFpdModule logic into core and extend it to populate any ortb2 field that is not specific to the impression or bidder (for example,
device.ua
). Currently this is left to each individual adapter, but they rarely should have a reason to differ in their implementation. This is true for "traditional" (non-ORTB) adapters as well; consolidating these items into first-party data should allow some simplification in that regard too.Implement utilities
bids2ortb
andortb2bids
such that an adapter may use them in this manner:these utilities should handle everything that the PBS adapter now understands, namely:
Adapter-specific customization
Current ortb bidders are surprisingly similar, but not identical. Adapters are free to modify the return value they get from
bids2ortb
/ortb2bids
, but that pattern is not ideal for some cases.Bid filtering
The Rubicon adapter wants to create a separate ortb request for each one in a set of particular bids:
Prebid.js/modules/rubiconBidAdapter.js
Lines 179 to 183 in 48ad719
Proposed solution - accept an optional list of bid requests in
bids2ortb
:Bid-level parameters
For example, from the ADF adapter:
Prebid.js/modules/adfBidAdapter.js
Lines 107 to 120 in f7dca5b
Proposed solution - provide an imp-level override in
bids2ortb
:The same idea can be applied on the response side - for example ADF's video renderer:
Prebid.js/modules/adfBidAdapter.js
Lines 272 to 275 in 48ad719
could look like:
Feature override
Because it makes practical sense to separate the ortb implementation of individual features (e.g.
bidfloor
should only be populated if thepriceFloors
module is installed), it would be relatively straightforward to allow adapters to override their translation. I have not found a great use case for this yet but I'll use the OpenXNew adapter as inspiration:Prebid.js/modules/openxOrtbBidAdapter.js
Lines 90 to 95 in df48483
Suppose that logic was changed to say "if
bid.params.customFloor
is defined, use that instead of the 'real' floor". We could allow that with something like:which would mean "override the ortb translation logic for the
bidfloor
feature with this custom logic instead". The difference with simply overwriting the contents ofimp
like we did in the previous example is that:The text was updated successfully, but these errors were encountered: