Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Triggering BID_WON event for outstream video / Custom renderer without URL #12425

Closed
EskelCz opened this issue Nov 7, 2024 · 8 comments · Fixed by #12437
Closed

Triggering BID_WON event for outstream video / Custom renderer without URL #12425

EskelCz opened this issue Nov 7, 2024 · 8 comments · Fixed by #12437

Comments

@EskelCz
Copy link
Contributor

EskelCz commented Nov 7, 2024

Type of issue

Question, maybe a feature request

Description

Currently we are in the process of integrating outstream video ads for our publishers. They are using a custom adserver, where they basically just need the VAST URL and they are capable or playing the ad themselves once it returns from the adserver.
The issue is, how do we trigger the BID_WON event, so that bid adapter and analytics modules can process the impression.

Based on this documentation, we could register a custom renderer (a function on window, provided by the publisher) to the adUnit and let them call renderAd as with banner ads. However it seems to require a url of the renderer script. That makes no sense in our case, since the rendering function is already available in the page.

I was also looking at using markWinningBidAsUsed which based on the description sounds like what we need, but it doesn't seem to trigger the BID_WON event, so I don't understand it's purpose.

So my question is, is there some other approach we could use to trigger the event, or do we need a feature of making the url parameter optional?

@patmmccann
Copy link
Collaborator

markWinningBidAsUsed which based on the description sounds like what we need, but it doesn't seem to trigger the BID_WON event, so I don't understand it's purpose.

The main purpose I am aware of is when prebid does not render the ad [bc the ad server responds with a vast and not an html snippet], the publisher may need to call this function to remove bids from the cache so they are not resued on subsequent calls of the ad unit

@patmmccann
Copy link
Collaborator

related / potential dupe: #5368 (comment)

@patmmccann
Copy link
Collaborator

patmmccann commented Nov 7, 2024

Would making this #9769 available to the publisher solve part of your concern?

@patmmccann
Copy link
Collaborator

Marking ready for dev: we'll add an option to markWinningBidAsUsed to fire the bid_won event and consider at another time making that the default. We'll make 9769 apply more generally.

@patmmccann patmmccann moved this from Triage to Ready for Dev in Prebid.js Tactical Issues table Nov 7, 2024
@patmmccann
Copy link
Collaborator

@robertrmartinez what do you guys do to have your analytics adapter hear when this is used?

@dgirardi
Copy link
Collaborator

dgirardi commented Nov 7, 2024

Bid adapters can pass renderNow: true instead of url to Renderer.install. This was introduced in #9769 but it looks like it's not used by anyone yet.

That option is not available to publishers yet. A workaround that should work right now is:

renderer: {
      url: 'data:text/javascript;base64,',
      render(bid) {
        // ...
      },
}

@EskelCz
Copy link
Contributor Author

EskelCz commented Nov 8, 2024

Would making this #9769 available to the publisher solve part of your concern?

Yes, absolutely, much cleaner than a dummy url.

Marking ready for dev: we'll add an option to markWinningBidAsUsed to fire the bid_won event and consider at another time making that the default. We'll make 9769 apply more generally.

That would be great, that would solve multiple headaches for us. (we could probably use that for instream as well, maybe even native, where we are relying on a specific postmessage)

@patmmccann
Copy link
Collaborator

@dgirardi let's leave this open to modify the function given the reported usefulness

I merged 12246, might need a docs pull

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

Successfully merging a pull request may close this issue.

3 participants