RTD Modules: segments added to a request persist into additional requests

[patmmccann]

Type of issue

Bug

Description

JW rtd module adding segments to ortb2 persist beyond the auction they were added on. The JW RTD module should only add segments to video requests, but when they do, it seems the method they use persists the segments into all subsequent requests.

Steps to reproduce

Examine prebid server outgoing requests for AdThrive_Content_1 unit

Test page

https://cafedelites.com/chicken-tikka-masala/

Expected results

JW segments added to the video request

Actual results

JW segments added to the video request and all other subsequent auctions

[karimMourra]

@patmmccann thanks for submitting this. Could you please provide more detailed reproduction steps ? On my end i've scrolled down and interacted with the video but I don't see a AdThrive_Content_1 ad unit, i see a AdThrive_Content_1_Desktop banner ad unit.

Is this the right ad unit ?

[patmmccann]

Can you look for requests that occur after the video request?

[dgirardi]

@patmmccann, I am also trying to reproduce and asking for better steps. That page makes a ton of requests and I am having trouble finding a video request for AdThrive_Content_1

[karimMourra]

@dgirardi my guess is that since the JW RTD module is writing to ortb2Fragments.global, those changes are persisting after the auction. Should the JW RTD module have to clean the ortb2Fragments.global after the auction ?

[dgirardi]

@karimMourra no, ortb2Fragments is generated anew each auction - or at least it should.

[patmmccann]

@mmoschovas can you please full steps to reproduce?

[mmoschovas]

Just to clarify, the issue impacts any ad unit after the JW targeting is applied. For example, we only apply the adunit targeting to the instream video unit but the segments are applied globally to every ad unit regardless if it has video mediatype or not. Here is an example that shows the Footer ad unit configuration (via the console) and the jw segments that are being applied to the network requests. The initial footer request (prior to the video request) does not contain the targeting. But once the targeting is applied for the instream request, it continues to persist for all ad units.

[dgirardi]

It would help to have steps to reproduce. That page is very busy and serves me a different bundle on each load which makes things really hard to debug.

@karimMourra, I suspect the issue might be that the jwplayer segments are added to ortb2Fragments.global if any adUnit in the request is related to a player:

Prebid.js/modules/jwplayerRtdProvider.js

Line 150 in bc68d77

const jwTargeting = extractPublisherParams(adUnit, fpdFallback);

But, if the pub does:

pbjs.addAdUnits([{code: 'video'}])
pbjs.requestBids({adUnitCodes: ['video']});
pbjs.addAdUnits([{code: 'banner'}]);
pbjs.requestBids({adUnitCodes: ['banner']})

then in the request you'd get both ad units, even though the pub does not intend to use the video one; you would need to filter them using request.adUnitCodes.

It may be better for core to do the filtering, but I'm not completely sure that it wouldn't break some other rtd modules - it's a larger project to double check that.

[dgirardi]

Discussed this with @bretg - we could not think of a reason why RTD modules should have access to adunits that have been added (through addAdUnits) but are not included in the current auction; we think it's OK to modify the RTD module API so that the adUnits and adUnitCodes they get as input only contain those adUnits that are relevant. It's still technically an API change though; what do you think @patmmccann - safe enough, or should it wait for version 8?

[patmmccann]

As discussed, the fix is not breaking