Media.net Adapter Improvements

[vedantseta]

Type of change

• Other

Description of change

Adding meta tags in Bid Request to bid optimally.

[vedantseta]

@snapwich @ndhimehta , can you please any post update on the PR ?

[snapwich]

@vedantseta we don't allow adapters to make arbitrary pixel fires; to allow such could result in a very chatty experience that could degrade the user experience and the results of the prebid auction. We allow pixels to be fired through the getUserSyncs function in the bidderFactory. This is allowed because, in this case, Prebid gets to determine when the pixels fire (after the auction) and the pixels can be configured to be turned off by the publisher giving them more control over pixels firing on their pages.

Until now that function has only been used for user syncs, but I think this is a valid use case (for tracking timeouts). If you would like, you can refactor your code to use getUserSyncs. If you decide to do this and have issues (as there might need to be changes to how the getUserSyncs function operates since this is a new use case for it) let me know and I might be able to assist you.

[vedantseta]

Hey @snapwich ,

Thanks for the update.

I understand the concern you have from publisher's standpoint, however its
detrimental for a bidder/adapter that it understands how it performs.

Having a chatty experience from visitor-syncs is one thing, and ensuring essential
telemetry engine works is another. We have already worked on #2254 with #2279 along
with @matthewlane

Publisher - Advertiser should have a transparent give-take relationship, however
if we do rely on userSync.syncsPerBidder, it'll be like the publisher is holding the
bidder at ransom. By moving the px out of the limited count actually is gonna
benefit the publisher as the adapter/bidder can optimize things at his end.
Additionally getUserSyncs doesn't seem the right place to slot in this data stream.

Thoughts?

[snapwich]

There are discussions about introducing improvements to getUserSyncs soon to cover more use cases and give publishers more fine-grained control over which pixels fire. We're hesitant to merge this change that would have a one-off condition for a timeout pixel and think we'd rather wait until we introduce the getUserSyncs enhancement (will probably change to getPixels or something). I can give you more information later as the plans are solidified. If you have any input on how you'd prefer it to act, feel free to leave it here and we'll consider it as the plan comes together.

[vedantseta]

@snapwich @ndhimehta , we have reverted onTimeout integration, can you please check and merge the PR ?

[snapwich]

LGTM

[vedantseta]

Thanks @snapwich for merging, can you please merge the same for legacy PR too #2432