add Dichange Bid Adapter

[Chucky-choo]

Type of change

• New bidder adapter

Description of change

• contact email of the adapter’s maintainer: di-change@digitalmatter.ai
• test parameters for validating bids:

[
    {
        code: 'test-banner',
        mediaTypes: {
            banner: {
                sizes: [[300, 250]],
            }
        },
        bids: [
            {
                bidder: 'dichange',
                params: {
                    env: 'dichange',
                    pid: '40',
                    ext: {}
                }
            }
        ]
    },
    {
        code: 'test-video',
        sizes: [ [ 640, 480 ] ],
        mediaTypes: {
            video: {
                playerSize: [640, 480],
                context: 'instream',
                skipppable: true
            }
        },
        bids: [{
            bidder: 'dichange',
            params: {
                env: 'dichange',
                pid: '40',
                ext: {}
            }
        }]
    }
]

Other information

Docs PR: prebid/prebid.github.io#5591

[bretg]

Spoke about this with @ChrisHuie . There's an open question about what happens when PBJS sees the "bidderA" biddercode and finds both a base adapter and one or more aliases. We should document what it does: break? base adapter? first base adapter that has bidderA as an alias?

In any case, I would propose that PBJS should (A) not break, (B) choose the base adapter by default, and (C) allow the publisher to override this behavior with pbjs.aliasBidder().

That would make this kind of operation not breaking in general. Here are a couple of scenarios:

Aliased biddercode converted to a standalone base adapter

This is what @Chucky-choo is trying to do here, though I disagree with PR #12203 -- removing the alias does create a breaking change.

Time 1

1. The publisher's adunits refer to dichange as a bidder
2. The publisher has built their PBJS package with digitalmatterBidAdapter.js where dichange is an alias. Life is good.

Note that if digitalmatterBidAdapter.js stops listing dichange as an alias, the publisher would be forced to change their build, causing a breaking change.

Time 2

1. The publisher's adunits still refer to dichange as a bidder
2. The publisher has built their PBJS package with both dichangeBidAdapter.js AND digitalmatterBidAdapter.js where dichange is an alias. Prebid.js picks one of them (preferably dichange). digitalmatterBidAdapter might be wasted bytes in the package, but otherwise, life is ok. Yes, the request is now being processed by a different adapter, but that's fine because clealry the publisher started including the new adapter explicitly in their build. They must know what's going on.

Time 3

1. The publisher's adunits still refer to dichange as a bidder
2. The publisher has built their PBJS package with just dichangeBidAdapter.js. Life is good.

Formerly standalone biddercode converted to an alias in a new base adapter

This isn't what's happening in this PR, but for sake of completeness and because Magnite is going to do this next year, thought it worth working through.

Time 1

1. The publisher's adunits refer to rubicon as a bidder.
2. The publisher has built their PBJS package with just rubiconBidAdapter.js. Life is good.

Time 2

1. The publisher's adunits still refer to rubicon as a bidder.
2. The publisher has built their PBJS package with BOTH rubiconBidAdapter.js and magniteBidAdapter.js which also aliases rubicon. PBJS chooses the base adapter. Life is ok - the Magnite adapter isn't being utilized at this point.

Time 3

1. The publisher's adunits still refer to rubicon as a bidder.
2. The publisher has built their PBJS package with BOTH rubiconBidAdapter.js and magniteBidAdapter.js which also aliases rubicon.
3. The publisher is ready to try the new Magnite-based rubicon, so they call pbjs.aliasBidder('magnite', 'rubicon')
4. PBJS sees this explicit signal and invokes 'magnite' for adunits that refer to rubicon.
5. Life is good.

Time 4

1. The publisher's adunits still refer to rubicon as a bidder.
2. The publisher has built their PBJS package with only magniteBidAdapter.js which aliases rubicon.
3. PBJS only sees rubicon as an alias of magnite, so life is good.

[Chucky-choo]

@bretg Thank you for your attention to this matter. After internal discussions, we concluded that the most transparent approach is to keep the PBJS package with digitalmatterBidAdapter.js, where ‘dichange’ remains as an alias. Therefore, we’re withdrawing this PR, and in PR #12203, we won’t be removing the alias.
We hope this clarifies our plans and doesn’t cause any break. Feel free to reach out with any questions.

[patmmccann]

@Chucky-choo please let us know on #12001 if you want to do a change in the next version