Prebid.js
Prebid.js copied to clipboard
Feature Request: expose an interface to inject impression trackers into VAST bids
Type of issue
Question
Description
Is it expected that an analytic module is able to alter a bid response ? I found out it could do so. I want to be able to use this but first I would need to be sure this is expected, allowed and won't be removed later.
Thanks.
Steps to reproduce
In file modules/bidwatchAnalyticsAdapter.js
add the following starting line 95 :
if (args.ad !== undefined)
args.ad = "<!-- removed -->";
Then the creative code sent by bidders is replaced by this and no ad is shown on the page.
We have some precedent of using event handlers as hooks for modifying data, so it's not necessarily disallowed, but without knowing more about the use case I'd find it surprising behavior if it comes from analytics.
Should what you are trying to do be in an RTD module? see https://docs.prebid.org/dev-docs/module-rules.html#analytics-adapter-rules
@matthieularere-msq - analytics adapters can't mess with the bids. This is a job for a a real-time-data module... https://docs.prebid.org/dev-docs/add-rtd-submodule.html
I understand analytics adapters are not supposed to do that and that's why I wondered. However what I am willing to do is related with analytics as I wished to insert video impression tracking in vast bids. I see I can do it, but I am unsure if it's ok to do so.
Before creating a reat-time-date submodule to supplement my analytic one, could you confirm me weither this would be accepted in an analytics module or not :
bid.vastImpUrl = bid.vastUrl !== undefined
? bid.vastImpUrl !== undefined
? getImpUrl(bid) + '&url=' + encodeURI(bid.vastImpUrl)
: getImpUrl(bid)
: bid.vastUrl;
// Vast XML document
if (bid.vastXml !== undefined) {
const doc = new DOMParser().parseFromString(bid.vastXml, 'text/xml');
const wrappers = doc.querySelectorAll('VAST Ad Wrapper, VAST Ad InLine');
if (wrappers.length) {
wrappers.forEach(wrapper => {
const impression = doc.createElement('Impression');
impression.appendChild(doc.createCbidSection(getImpUrl(bid)));
wrapper.appendChild(impression)
});
bid.vastXml = new XMLSerializer().serializeToString(doc);
}
}
I somehow feel in any case it's a rough solution: doing it in analytic adapter kind of break the rules but it's done for analytics purposes. But doing it by a rtd submodule makes analytics depend of another module while it should be a all-in-one solution.
Anyway, I believe that if analytics are not supposed to alter bids in any way, then it would be safier for them to receive derefenced copy of objects instead of the ones they currently get.
I am unsure of whether that pattern would be OK in an analytics adapter. (@patmmccann ?) But I agree that either option is not ideal. Here's a couple ideas for improvement:
- Prebid core - or possibly the new video module - could expose an interface for interested parties to inject their impression trackers into VAST bids; or
- Prebid could manage its own centralized impression tracker (probably through Prebid Server, similar to how it does video caching), inject it into VAST bids, and use it to generate normal BID_WON events.
I really like the idea of analytics adapters receiving dereferenced copies; that would seem to break this other code proposal.
Would that cause a substantial performance overhead?
Would that cause a substantial performance overhead?
Yes if we try to do it with any significant degree of exhaustiveness - it'd require a deep clone of almost every object.
@matthieularere-msq looks like this isn't going to fly from the analytics adapter, however, we're adding the injection interface to the feature request backlog so let's keep this one open
closing #9055 to consolidate discussion
Proposal:
- analytics adapters can define a method
getVASTTrackers(bidRespone)
- publishers can allow it with
pbjs.enableAnalytics([{allowVASTInjection: true}])
- if allowed, core will inject impression trackers in VAST bids
How about instead of letting the analytics adapter update the VAST themselves, we just get an array of URLs and core adds the
Letting them update it themselves is powerful, but we might end up with duplicate logic for injecting all of the other trackers.
...we did this as an AdServer module, it includes functionality to massage the VAST tag into a blob URI to avoid refetching it.
Closing this for now as it's quite old and isn't a priority at the moment.