DRAFT [Weborama RTD Submodule] Fix appnexus implementation

[peczenyj]

Type of change

• Bugfix
• Refactoring (no functional changes, no api changes)

Description of change

This Pull Requests finish the work started on #10005

Here we:

1. send data to AppNexus using site.content.keywords or user.keywords using the format key=foo,key=bar,...
2. remove the hard coded bidder name appnexus to use it as a default value. Other aliases can be added via configuration
3. check the bidder alias registry based on configuration

Today we check for appnexus and registered aliases and we don't want to remove this behavior without warn all of our customers. We plan some modifications to do in the next releases to avoid break backward compatibility.

[patmmccann]

The way you have this set up is a rules violation; please inspect 1plusX and Airgrid. I registered a segment taxonomy with the IAB on your behalf. If you write to segments, appnexus can pick them up now in 8.0 Thanks!

[peczenyj]

The way you have this set up is a rules violation; please inspect 1plusX and Airgrid. I registered a segment taxonomy with the IAB on your behalf. If you write to segments, appnexus can pick them up now in 8.0 Thanks!

Sorry, I am a little bit lost: what is the rule violation that I am doing here?
I am following what sirdata is doing right now.

Perhaps I lost something from the comments on the previous MR #10005

[peczenyj]

BTW if the correct development is just remove any code that handles bib.bidder === 'appnexus' I can provide it ASAP

[patmmccann]

Yes, please don't reference bid adapters in the module. However, feel free to append to this so appnexus picks up your segments

Prebid.js/libraries/appnexusKeywords/anKeywords.js

Line 5 in a35cda0

const ORTB_SEGTAX_KEY_MAP = {

[patmmccann]

@peczenyj is this ready?

Our goal here isn't to break your integration with any bidder, it's to move the handling so publisher data controls are not bypassed when publishers attempt to suppress parts of the bids request object using data or activity control features.

Are you satisfied this achieves that goal? If not, we're committed to assist

[peczenyj]

@peczenyj is this ready?

Our goal here isn't to break your integration with any bidder, it's to move the handling so publisher data controls are not bypassed when publishers attempt to suppress parts of the bids request object using data or activity control features.

Are you satisfied this achieves that goal? If not, we're committed to assist

To be honest, this is ready if Appnexus is ready to use the ortb2Fragment. I think it is not the case, based on the previous merge request #10005

[patmmccann]

@dgirardi @jsnellbaker any thoughts on how to push forward here? we'd love to restore all functionality

[peczenyj]

hello @patmmccann @dgirardi and @jsnellbaker

I was revisiting this subject, but after a long time I must rewind it to the begining and start again.

It seems the options for weborama here are:

1. use an IAB Taxonomy and register it on appnexus library to be collected and merged with their own data (and it depends on we start to work with such taxonomy and appnexus accept our vendor id in their library to be released at some point).
2. since appnexus supports ortb2.ext.data.keywords we can try to adapt our data to expose it as keywords (however this will be available to all bidders, so we will duplicate our data).
3. remove the specific code to appnexus -- and drop support to it

It seems the options for appnexus here are:

1. Do Nothing
2. start to handle ortb2.site.ext.data and/or ortb2.user.ext.data like many other bidders

From our side we start to talk about the possible solutions 1 and/or 2.

Regards

[patmmccann]

Option 1 seems quite workable, and has been accomplished by others. Why not persue that?

[patmmccann]

closing as stale, feel free to resubmit