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

SpotX Bid Adapter: Add videoCacheKey #4706

Merged
merged 1 commit into from
Jan 14, 2020

Conversation

vseventer
Copy link
Contributor

Type of change

  • Bugfix
  • Feature
  • New bidder adapter
  • Code style update (formatting, local variables)
  • Refactoring (no functional changes, no api changes)
  • Build related changes
  • CI related changes
  • Does this change affect user-facing APIs or examples documented on http://prebid.org?
  • Other

Description of change

Adds videoCacheKey to SpotX bids, as SpotX already caches their bids (see vastUrl) and therefore we do not need to leverage Prebid Cache.

Other information

N/A

@khatibda
Copy link
Contributor

khatibda commented Jan 10, 2020

so here's a question about this, and other updates like this. if publishers don't update their GAM creatives immediately then when this goes live, will GAM still be serving the default cache urls (e.g. appnexus prebid urls), and therefore the creative will not render? or am i missing something?

@vseventer
Copy link
Contributor Author

@khatibda A publisher would only get this update if they would upgrade their Prebid.js version which, for a change like this, would probably be a minor (?) and I would hope one would consult the changelog before making the update.

Regardless, this PR follows the Prebid.js docs where videoCacheKey can be provided by the bidder to avoid re-caching by Prebid Cache. This works going forward, since SpotX caches their own bid.

Copy link
Collaborator

@robertrmartinez robertrmartinez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, agreed. This looks good as both vastUrl and videoCacheKey are sent back.

This is similar to how Rubicon handles video.

@robertrmartinez
Copy link
Collaborator

@vseventer Do you want me to merge this in before todays release?

@vseventer
Copy link
Contributor Author

@robertrmartinez Would be great, thank you for your review!

@robertrmartinez robertrmartinez merged commit 09ccc13 into prebid:master Jan 14, 2020
audiencerun pushed a commit to audiencerun/Prebid.js that referenced this pull request Jan 20, 2020
@josephtyler
Copy link
Contributor

@khatibda A publisher would only get this update if they would upgrade their Prebid.js version which, for a change like this, would probably be a minor (?) and I would hope one would consult the changelog before making the update.

Regardless, this PR follows the Prebid.js docs where videoCacheKey can be provided by the bidder to avoid re-caching by Prebid Cache. This works going forward, since SpotX caches their own bid.

I know I'm a bit late here, and I realize this change is in line with the specification. But I think what Danny is asking may be a higher level question. If we upgrade prebid, we will have to create new line items in GAM in order for spotx to continue working. Or is there a way to continue using the original cache?

@robertrmartinez
Copy link
Collaborator

robertrmartinez commented Feb 18, 2020

@josephtyler

You are correct, if you were using a prebid cache host like appnexus or rubicon, then unfortunately you would need to update spotX VAST creatives as it will no longer be fetch-able at those locations.

There is a way to "hack" this to work as before using some pbjs functions, but I would first take something like this up with SpotX. They made this change for a reason so I am sure they have some sort of an opinion.

hellsingblack pushed a commit to SublimeSkinz/Prebid.js that referenced this pull request Mar 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants