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

Question: Is client side session bid caching a viable idea? #1695

Closed
nodeful opened this Issue Oct 16, 2017 · 9 comments

Comments

Projects
None yet
6 participants
@nodeful
Copy link

nodeful commented Oct 16, 2017

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

@dbemiller

This comment has been minimized.

Copy link
Contributor

dbemiller commented Oct 16, 2017

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.

@bretg

This comment has been minimized.

Copy link
Contributor

bretg commented Oct 16, 2017

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.

@nodeful

This comment has been minimized.

Copy link

nodeful commented Oct 16, 2017

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.

@mkendall07

This comment has been minimized.

Copy link
Collaborator

mkendall07 commented Oct 16, 2017

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.

@bretg

This comment has been minimized.

Copy link
Contributor

bretg commented Oct 16, 2017

A hash would work.

@mkendall07 mkendall07 added the feature label Nov 10, 2017

@dmitriyshashkin

This comment has been minimized.

Copy link
Contributor

dmitriyshashkin commented Nov 16, 2017

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.

@ffeast

This comment has been minimized.

Copy link

ffeast commented Nov 16, 2017

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

@nodeful

This comment has been minimized.

Copy link

nodeful commented Nov 16, 2017

@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 :)

@stale

This comment has been minimized.

Copy link

stale bot commented Mar 6, 2018

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.

@stale stale bot added the wontfix label Mar 6, 2018

@stale stale bot closed this Mar 13, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment