Kargo Bid Adapter: page URL from topmostLocation

[jsadwith]

Type of change

• Feature

Description of change

Updates to pull page URL from topmostLocation with a fallback to page

• contact email of the adapter’s maintainer: jeremy@kargo.com

[jsadwith]

@patmmccann curious to get your thoughts on this. I noticed that some bidders use refererInfo.topmostLocation for page URL whereas others use refererInfo.page. Recently, we've noticed that for some of our partners on Prebid v7, we're no longer getting URL params as part of refererInfo.page whereas others are passing the full URL including params. I haven't found any pattern to this with regards to v7 minor versions, so I figured we should try refererInfo.topmostLocation as some others have done.

DSPs have requested us passing the full URL including params, so we want to make sure we're using the right Prebid.js property. Is topmostLocation more accurate in trying to retrieve the full URL, or does it come with downsides?

[dgirardi]

@jsadwith, this was changed with version 7, #8450

topmostLocation is the URL of the topmost frame that is accessible from Prebid. page is the canonical URL as provided by the publisher (if any), falling back to the location of the top frame if it's accessible. It should be missing only in cross-domain nested frame scenarios where Prebid cannot determine the URL that's shown in the browser address bar.

If it's preferable to always provide a value regardless of its validity, my suggestion is to use page || topmostLocation so that it still respects the publisher-provided canonical URL.

[patmmccann]

@dgirardi did 8450 change behavior on query string params being reported?

[dgirardi]

I missed that this was about URL params. #8450 did not remove them, but it gives precedence to the canonical URL, which may not have them.

[patmmccann]

should we give precedence to topmostlocation if topmostlocation has params and canonical is a substring of topmostlocation?

In other words, pass the params unless canonical overrides the host or page

[dgirardi]

I don't love that idea because a) it would break canonical URLs that are legitimately just changing the query params and b) it would still lose the query params when the domains are different. I don't have a better suggestion though.

[ncolletti]

lgtm

[jsadwith]

@patmmccann @dgirardi just a heads up that this caused an issue with us for a large publisher where the canonical URL maps to the original URL of an article even when reading syndicated versions of the article on other domains. TTD pointed it out to them that they're receiving incorrect domains from multiple bidders where the domain being passed in the bid request doesn't match the URL of the article itself (ie., xyz.com/original-article is syndicated to abc.com/original-article and def.com/original-article, but the canonical URL across all 3 domains is always xyz.com/original-article). Giving preference to canonical URL may not be the best bet in these types of cases.

[patmmccann]

@jsadwith sounds like fraudulent inventory to me; ttd shouldnt buy it. Why can't the syndicating pubs fix?

[jsadwith]

@patmmccann it's for SEO purposes so the same article isn't listed in search engines for each site that it's syndicated to. The publisher syndicates the article content across their brands but only wants the source site to be listed in search engines. A canonical URL is defined by Google as "the best representative page from a group of duplicate pages", so it's not a matter of being fraudulent and more-so a matter of how the publisher wants their content to be represented in search engines.

With regards to this particular publisher, it's a very premium one that TTD will happily buy.