`adServerDomain` setup in creatives appears to be useless

[dgirardi]

In at least some of our docs we ask publishers to set up PUC-GAM creatives with adServerDomain:

<script>
  var ucTagData = {};
  ucTagData.adServerDomain = "";

PUC includes it as part of the message payload for Prebid, but the latter does not use it: https://github.com/prebid/prebid-universal-creative/blob/68d81fc8eba26c903149b9ce5592ea832fc003a2/src/renderingManager.js#L144-L151

From my testing, including or removing it makes no difference. I believe it should be removed together with the code around it, and the docs updated.

[jsnellbaker]

I think it used to be used on the Prebid.js side of things to help handle the postMessage request. But it seems that a while ago the logic was changed on the Prebid.js side through this PR: https://github.com/prebid/Prebid.js/pull/5285

It's likely it was just not cleaned up on the PUC side, and now (as you inferred) doesn't do much and can probably be removed.

[dgirardi]

Thanks for the detective work! That PR was merged in 3.22; is that old enough to be OK to break with a PUC update?

[jsnellbaker]

I'm not sure what you mean by break in this instance? Do you mean people that would still be using latest PUC (as that's how the creatives are setup) while also using a version of 3.x Prebid.js; as that would stop supplying the adserverDomain from updated PUC to that old version of Prebid.js?

[dgirardi]

Yes - with how we distribute PUC, we are implicitly promising unlimited backwards compatibility.

[jsnellbaker]

I think we need to review this with the larger group.

[dgirardi]

Agreed. Brainstorming ideas on how to escape this trap, we could try to tie breaking changes to Prebid major versions; the transition will take forever, but we could for example ask pubs to set up

<script src="https://cdn.jsdelivr.net/npm/prebid-universal-creative@%%PATTERN:hb_pb_majorversion%%/dist/creative.js" />

and start a new PUC branch (and release tag) for each new Prebid major version.