Prebid.js: Question: Is client side session bid caching a viable idea?

Created on 16 Oct 2017  路  9Comments  路  Source: prebid/Prebid.js

Tried to search for a similar question in the open/closed issues but couldn't find anything similar.

Imagine user comes to your website.
Prebid runs an auction and renders the ads that won for each slot. However, you keep all the other bids that didn't win in the users session storage.
When the user goes to the next page Prebid runs another auction for the same adSlots, however, before sending them off to the AdServer you compare and inject previous bids if they were higher than the ones we got from the current auction. And you keep caching the bids throughout the users entire session.

Could this potentially increase the average winning bid cpm (and hence, revenue) for a Publisher?
What do you guys/girls think of this? Maybe someone already tried something similar

feature wontfix

Most helpful comment

Yes, it's definitely in the plan eventually. For the 1.0 API we're expecting bids to have a ttl parameter which tells us how long Prebid is allowed to keep the bid and consider it valid. See "the parameters of a bidObject section here.

None of the prebid code uses it yet... but the plan is to add that feature in the future.

All 9 comments

Yes, it's definitely in the plan eventually. For the 1.0 API we're expecting bids to have a ttl parameter which tells us how long Prebid is allowed to keep the bid and consider it valid. See "the parameters of a bidObject section here.

None of the prebid code uses it yet... but the plan is to add that feature in the future.

One potential issue would be with that some bids may be only good in certain page contexts. For instance, if there were a deal that scoped bids to the "mobile" section of a site, those bids aren't good on the "printers" section.

I guess this would have to be a Toggled / Configurable option.
I am looking at it from a perspective of a publisher that serves paged articles, in which case page context and/or logic doesn't change throughout the session.

we could just hash each bid on it's adUnit configuration. If the hash matches it's a valid bid for any given page view.

A hash would work.

It would probably also make sense to alter the way the timeout is currently applied. If bids are cached, it makes sense not to interrupt the request once the timeout is reached but wait until the bid is received. Even if it won't take part in the current auction, it can be cached and used later.

I am looking at it from a perspective of a publisher that serves paged articles, in which case page context and/or logic doesn't change throughout the session.

I don't think it's fair even in this case. I can get a high bid i.e. on the main page and serve it somewhere in a deeply nested article - looks like cheating

@ffeast as long as the user is the same person that started the session I don't think his impression value should be diminished, no matter how far into the site he travelled. As long as the website is the same :)

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jaiminpanchal27 picture jaiminpanchal27  路  3Comments

Rubioli picture Rubioli  路  3Comments

dugwood picture dugwood  路  4Comments

nyfer picture nyfer  路  5Comments

aszydlo picture aszydlo  路  6Comments