is there a method to check if open measurement integration is present only for video and not for display?

[svitel11]

on a web page we have integrated bitmovin player with the omsdk module.
but on the same page, omsdk for display ads is not integrated. can for example ias, doubleverify, etc. recognize that for display omid is not present but for video it is?
in the web page, an iframe is created with the id 'omid_v1_present' and from what I have seen, this iframe is the same for video advertising and display advertising.
thanks in advance

[nlehrer]

There are a couple of options:

1. Indicate in the display ad request that OMID is not supported; then, ias, doubleverify etc. should not include their OMID scripts in the response.
2. Put the OMID service (omsdk-v1.js) inside of an iframe. That will prevent the omid_v1_present iframe from being detected by scripts in the outer window. This option is documented here, but I think we could probably improve that guide to have more details. This would need to be done by bitmovin in their OM SDK module.

There may also be some other workaround I'm not thinking of.

I understand that it may be difficult to achieve either of those, and I think this is an important question that I've seen come up before, so I'll check with the OM working group as well to see what they think.

[svitel11]

thanks for the quick response @nlehrer. unfortunately, the first option is difficult to put into practice, at least in our case. about option 2 I will talk with bitmovin.

otherwise, there is a setCreativeType() method...
for me, it would be logical for bitmovin to set the creative type with this, so setCreativeType('video')
and then the verifier can read this value (with another getCreativeType() method for example) to avoid situations like this.

it's just an opinion, but I think a better solution than the two described by you is necessary.
because of this problem, the company I work for has lost a lot of money in the last two months (a 6-digit amount) and the problem still persists.

more precisely, the banners were delivered by ssp/dsp but because the verifier detected omid in the website/applications (which came from the video player) it did not display the banners because a specific event was not issued by omid. if the omid was completely missing, we would not have had this problem.
I hope you find a more intuitive solution for this.

[nlehrer]

Yes, adding something like a getCreativeType method could be a reasonable third option. I guess that would require the verification script to know that it is only meant to measure display ads, so it will not use OMID if the creative type is video. Also, the verification script might register for events after omid_v1_present is created in the video integration but before the creative type is set. So I'm not sure if it would work exactly, but maybe something similar.

The iframe option (2) is what the IMA SDK (Google) uses, for what it's worth. It is a little harder to set up but prevents issues like this. If we think that is the only viable solution then we would want to update our documentation to strongly encourage that kind of setup / deprecate the non-iframed setup.

In any case I agree we should find an intuitive solution to this to prevent bugs like this, especially if they are revenue-impacting. I'll keep you updated.

[nlehrer]

We discussed this in the OM SDK technical team. It seems like we may be able to fix this by simply removing the omid_v1_present iframe on Web, since no verification scripts should be using it on web anyway (it is only used for side-loaded verification scripts which would be display ads on app). I would need to get final approval on this decision next week before I can implement it.

[svitel11]

I'm glad to hear that. in the meantime we disabled omsdk because money was being lost daily, and we were waiting for an update to be able to activate omsdk again. I am waiting for news from you about this.

[garohussenjian]

@svitel11 Based on some recent discussion, we don't think it's possible to remove omid_v1_present iframe since it's a breaking change for older session clients. I suspect that option 2 (isolating the video player & OM web in an iframe) is currently the most straightforward way to solve this. We are exploring other options, but these will likely require some more time to sort out.

[svitel11]

hi @garohussenjian,
i understand in fact, I think that just removing that iframe is not enough to stop having that problem. in any case, I think that at least in the documentation it should be specified that the integration of omsdk only for video or only for display in window.top is not recommended and the risks that may arise. this information would have helped us identify the problem in time and avoid financial losses.

[renebaudisch]

Hi. Removing the iframe is what we did, but that stopped working in sept '23.