More flexible bid adjustment for multiformat units

[patmmccann]

The process of adjusting pbs bids is documented at https://docs.prebid.org/prebid-server/endpoints/openrtb2/pbs-endpoint-auction.html#bid-adjustments . This is much less flexible than pbjs, which allows for arbitrary functions. Publishers would prefer to adjust bids differently based on the media type of the bid response in a mutiformat auction. This is particularly pressing for publishers noting large outstream discreprencies on js issues eg https://github.com/prebid/Prebid.js/issues/5652

[SyntaxNode]

I don't see us matching the same arbitrary function approach as PBJS since we're running on a server and the performance and security aspects of running custom code / scripts is worrisome.

Would allowing the bid adjustments to differ based on the media type (banner. video, audio, native) be sufficient? Would this also need to include the channel, such as site vs app?

[patmmccann]

Media type would be enormously helpful. As for channel, I am not sure it is necessary as I believe one can specify different adjustments for channels now, as they would be different requests. This use case is a single multiformat request and a bid adjustment conditional on something in the response. I certainly understand the security concern.

On Wed, Dec 9, 2020, 3:39 PM Scott Kay notifications@github.com wrote:

I don't see us matching the same arbitrary function approach as PBJS since we're running on a server and the performance and security aspects of running custom code / scripts is worrisome.

Would allowing the bid adjustments to differ based on the media type (banner. video, audio, native) be sufficient? Would this also need to include the channel, such as site vs app?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/prebid/prebid-server/issues/1601#issuecomment-742035265, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAM25Z3VP3EGCQVT7TSONCLST7OATANCNFSM4UHXQCGQ .

[SyntaxNode]

Sounds good. Let's focus on adding media type qualifiers. The current structure is:

{
  "ext": {
    "prebid": {
      "bidadjustmentfactors": {
        "appnexus": 0.8,
        "rubicon": 0.7
      }
    }
  }
}

We need to remain backwards compatible, so I suggest exploring additions instead of alterations. We could add nested elements for each media type:

{
  "ext": {
    "prebid": {
      "bidadjustmentfactors": {
        "appnexus": 0.8,
        "rubicon": 0.7
        "banner": {
          "appnexus": 0.1,
        }
      }
    }
  }
}

I don't like this because we're introducing a conflict between a media type name and a bidder code, which also complicates the implementation. Perhaps we're better off with a new structure entirely:

{
  "ext": {
    "prebid": {
      "bidadjustmentfactorsmediatype": {
        "banner": {
          "appnexus": 0.1,
        },
        "native": {
          "appnexus": 0.2,
        },
      }
    }
  }
}

I don't like this either because the relationship between the two structures is odd. So, perhaps the first solution is best if we nest everything under a media types element and add "mediatypes" a new reserved bidder name?

{
  "ext": {
    "prebid": {
      "bidadjustmentfactors": {
        "appnexus": 0.8,
        "rubicon": 0.7
        "mediatypes": {
          "banner": {
            "appnexus": 0.1,
          }
       }
      }
    }
  }
}

In this case, the top level value would be used but will be overwritten based on the bid's media type as returned by the adapter.

[patmmccann]

I like the final proposed structure also, it seems to work well.

On Thu, Dec 10, 2020, 4:02 PM Scott Kay notifications@github.com wrote:

Sounds good. Let's focus on adding media type qualifiers. The current structure is:

{ "ext": { "prebid": { "bidadjustmentfactors": { "appnexus": 0.8, "rubicon": 0.7 } } } }

We need to remain backwards compatible, so I suggest exploring additions instead of alterations. We could add nested elements for each media type:

{ "ext": { "prebid": { "bidadjustmentfactors": { "appnexus": 0.8, "rubicon": 0.7 "banner": { "appnexus": 0.1, } } } } }

I don't like this because we're introducing a conflict between a media type name and a bidder code, which also complicates the implementation. Perhaps we're better off with a new structure entirely:

{ "ext": { "prebid": { "bidadjustmentfactorsmediatype": { "banner": { "appnexus": 0.1, }, "native": { "appnexus": 0.2, }, } } } }

I don't like this either because the relationship between the two structures is odd. So, perhaps the first solution is best if we nest everything under a media types element and add "mediatypes" a new reserved bidder name?

{ "ext": { "prebid": { "bidadjustmentfactors": { "appnexus": 0.8, "rubicon": 0.7 "mediatypes": { "banner": { "appnexus": 0.1, } } } } } }

In this case, the top level value would be used but will be overwritten based on the bid's media type as returned by the adapter.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/prebid/prebid-server/issues/1601#issuecomment-742796741, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAM25ZY3KZSLR4NNYQKIDHTSUEZMVANCNFSM4UHXQCGQ .

[bretg]

I'm good with the final option as well.

[bretg]

@patmmccann - should we support breaking out adjustments for video instream vs outstream?

The mediaTypePriceGranularity feature in PBJS supports 4 media types. Here's how they would translate in PBS:

• 'video': use when imp[].video exists and imp[].video.placement either doesn't exist or placement=1
• 'video-outstream': use when imp[].video exists and imp[].video.placement exists and is not 1
• 'banner': use when imp[].banner exists
• 'native': use when imp[].native exists

Algorithm outline:

1) first find the relevant mediatype for the bid response's original imp[]: banner, video, video-outstream, or native. 2) Look for ext.prebid.bidadjustmentfactors.MEDIATYPE.BIDDERCODE. If it exists, multiply the bidreponse price. 3) Otherwise, look for ext.prebid.bidadjustmentfactors.BIDDERCODE. If it exists, multiply the bidreponse price. 4) Otherwise don't modify the bidresponse price 5) Keep the original CPM as defined in https://github.com/prebid/prebid-server/issues/1526

[patmmccann]

I am not aware of multiformat instream units, so i find this question a bit confusing

[bretg]

PBS sees:

• instream-video as imp.video where imp[].video.placement=1
• outstream-video as imp.video where imp[].video.placement<>1

[bretg]

Implemented with PBS-Java 1.62

[stale[bot]]

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]

@patmmccann - we propose closing this issue in favor of whatever we wind up with in https://github.com/prebid/prebid-server/issues/2085

[bretg]

Discussed in committee and agreed to skip this feature for PBS-Go and directly build to #2085