Enforcement in Meta Object

[gglas]

This is a feature request for added functionality within the meta object of bidresponses.

As a result of #3115 , we've implemented a standardized taxonomy within the Meta object in order to make gathering things like adomain and exchange provided metadata about their bidresponses easier to
ingest and index in the course of running a prebid auction.

Now, the inevitable next step is to take these values and allow publishers to apply logic across them. Currently available meta fields include :

meta: {
            networkId: NETWORK_ID,
            networkName: NETWORK_NAME
            agencyId: AGENCY_ID,
            agencyName: AGENCY_NAME,
            advertiserId: ADVERTISER_ID,
            advertiserName: ADVERTISER_NAME,
            advertiserDomains: [ARRAY_OF_ADVERTISER_DOMAINS],
            brandId: BRAND_ID,
            brandName: BRAND_NAME,
            primaryCatId: IAB_CATEGORY,
            secondaryCatIds: [ARRAY_OF_IAB_CATEGORIES],
            mediaType: MEDIA_TYPE
        }

It is conceivable that publishers could desire any number of functions to apply across any number of fields within this object, including but not limited to :

• Filtering bids based on a list of approved responses
• Filtering bids based on the presence or absence of a response
• Adjusting bids based on a list of approved responses
• Adjusting bids based on the presence or absence of a response

From what I can tell, the initial use case is that we would want to support would be filtering (ie. removing from the auction) bids based on the presence of advertiserDomains -- removing bids from auction that lack the field entirely. This removes significant complexity from the project, as when logic can exist on multiple fields you need a hierarchy and ordering -- but that's not to say that this won't need to exist in the future (or is potentially a valid role for a real time module?)

[patmmccann]

There may also be a use case in flooring, eg toss bids from a particular advertiser not above X.

[GLStephen]

It looks like clickUrl has been dropped out of this set. Just curious if that was intentional.

[patmmccann]

Check out the solution on #6453

[ChrisHuie]

@gglas would this fall under #6453 and we can then close this one out?

[bretg]

Status:

• There's documentation on how to do this with an event callback -- https://docs.prebid.org/dev-docs/examples/meta-bid-filtering.html
• The open item is to discuss:
  • is this sufficient? I would argue no -- the documented solution feels like a hack.
  • do we need an event structure so analytics adapters can tell what happened? I'm guessing yes -- that rejected bids should contain a rejection reason so analytics adapters can track it.
  • assuming we need more, someone needs to spec it. There's precedence for rejecting bids with a reason in the Price Floors module.

[bretg]

Here's a proposal: we define a general "bidresponse filter" module that allows publishers to set rules about which bids to accept:

• required metafields
• size validation - make sure the response fits a requested size (maybe core does this already?)
• native assets - make sure the response contains all the required native assets (maybe core does this already?)

pbjs.setConfig({
    bidResponseFilter: {
        sizeValidation: true,
        nativeAssetValidation: false,
        requiredMetaFields: ["advertiserDomains", "mediaType"]
    }
});

These are relatively simple handlers publishers could just build themselves, but the module would have some value-add:

• I think it's cleaner to do this with addBidResponseHook like in the currency module rather than an event callback
• a conventional way to do it (the easy button)
• we could extend the response codes and analytics

The currency module reports "NO_BID" right now when the bidResponse can't be converted. I think that could be improved by defining a new "REJECTED" status:

  "STATUS": {
    "GOOD": 1,
    "NO_BID": 2,
    "REJECTED": 3       // new
  },

And then adding a new "statusReason" field that could be used by analytics adapters.

export function createBid(statusCode, identifiers, statusReason) {
  return new Bid(statusCode, identifiers, statusReason);
}

Then we could update the currency module to use REJECTED instead of NO_BID with a statusReason of "unable to convert currency", which is a better response.

[patmmccann]

I think we should extend this allow rejections for banned advertiser, banned dsp, missing dchain, incomplete dchain, regex's on the markup. Potentially the new module could allow submodule(s) or plugins from vendors.

[patmmccann]

I think the last two comments sounds like requirements, marking ready for dev. Note all of this functionality could likely be acchieved with event hooks, the goal of the module is to simplify implementation.

[dgirardi]

Alternate proposal: an optional module can enforce ORTB "b" fields against what's in meta:

badv -> meta.advertiserDomains
bcat -> meta.primaryCatId
battr -> meta.attr ? (we'll probably need to define this fields)

Also, update ORTB conversion library to populate those meta fields;

for enforcing the presence of some fields (or sizes, etc) without necessarily having a "banned" list to filter, we could give publisher the option to filter bids via JS.

[patmmccann]

Marking ready for dev with the proposal in #6345 (comment) and the additional requirement that it is compatible with request or ad unit level 'b' fields

[patmmccann]

Additional requirement, the ortb convertor response processing should cody seatbid.bid.attr into meta.attr as an array of integers

[patmmccann]

inspiration https://docs.prebid.org/prebid-server/pbs-modules/ortb2-blocking.html#ortb2-blocking-module

[patmmccann]

tbd: how do we figure out bseat? should ortb convertor make meta.networkid = to something in the response?

[patmmccann]

related: pbs will preserve seat some day prebid/prebid-server#2424

[patmmccann]

Seat can be repeated within a dsp, so bseat might be very hard to apply as it would only make sense within a given dsp.

Proposal: don't add support for bseat, nor do we support networkid. Later feature requests may cover these functions