Triplelift: Add Instream support

[sdao-tl]

Type of change

• Bugfix
• Feature
• New bidder adapter
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Does this change affect user-facing APIs or examples documented on http://prebid.org?
• Other

Description of change

• Add support for instream video to TripleLift adapter

• official adapter submission

For any changes that affect user-facing APIs or example code documented on http://prebid.org, please provide:

• A link to a PR on the docs repo at https://github.com/prebid/prebid.github.io/

Other information

• Co-Author: Brandon Ling
• TL ticket: TL-16738

[Fawke]

@sdao-tl,

Thanks for the PR. Can you please make the following changes:

• Update the tripleliftBidAdapter.md file with an example of Instream video ad unit. We would require this so we can test whether we're getting a bid back or not when we send the request to your endpoint.

• Please update the docs at https://github.com/prebid/prebid.github.io/ to document support for the video, instream media type.

[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.

[sdao-tl]

@Fawke ,

1. tripleliftAdapter.md changes done
2. PR for docs update can be found here

[Fawke]

@sdao-tl,

Thanks for providing an example adUnit in the md file. I'm trying to test the sample instream adUnit that you shared in a test page and getting {status: no_bid} as a response from your endpoint. Can you provide the correct test params so we can test it?

Also, you would need to make another change. From Prebid v4.0 onwards, publishers configuring prebid for video should now be able to pass video params in mediaTypes.video object. Read the blogpost for more details.

So, a publisher can configure the adunit like this:

{
    code: 'instream-div-1',
    mediaTypes: {
        video: {
            playerSize: [640, 480],
            context: 'instream',
            mimes: ['video/mp4'],
            w: 640,
            h: 480,
        }
    },
    bids: [
    {
        bidder: 'triplelift',
        params: {
            inventoryCode: 'instream_test'
        }
    }]
}

You can read the video params from either location, mediaTypes.video or bidder.params but give more precedence to mediaTypes.video if both are defined.

[sdao-tl]

@Fawke
Thanks for the context, support for mediaTypes.video added.

RE: testing, unfortunately, we do not yet have a way to always return an instream ad so fill rate would depend on live auction. Would a cache bid work?

[Fawke]

@sdao-tl,

I'm fine with your first change: giving more precedence to mediaTypes.video.

We generally check few things for an instream bid response. If you can verify that the response passes these checks, we can get this merged.

• Bid response must have Content-Encoding set to gzip
• You are returning at least one of there params, bid.videoCacheKey, bid.vastXml, or bid.vastUrl.

It's also good to have some meta information about the bid. For example, advertiserId. Read the blogpost's meta taxonomy section for more details. It's not mandatory to do this part though.

[sdao-tl]

@Fawke ,

I have attached my chrome network logs which contain the request/response for the instream ad. In it, you can confirm our gzip encoding.

Regarding the params requirement: for instream responses we send the vast xml in the ad field and this gets mapped to the required param vastXml in our adapter (L245-247). Does this meet the requirement?

triplelift-instream-example.har.zip

[patmmccann]

this appears to be bad logic; multiformat outstream / banner / native units will be considered video units

[patmmccann]

the effect is you don't bid on them

[sdao-tl]

Hi Pat,

Thanks for surfacing! We will review internally and update.

[sdao-tl]

Hi @patmmccann ,

I've opened PR 5872 to resolve this -- thanks again!