You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issues stems directly from #46, but for the sake of clarity i thought it would be better to spin off this particular point of discussion.
Assuming that the interest group bidding logic has to stay in the browser, I think it is fair to say that you expect it to be small enough in size to accommodate for the many, many interest groups each advertiser is likely to put their visitors in. And we should expect many interest groups.
A website like Walmart, having 100 000 000 monthly visitors and 43 000 000 products is likely to have in the range of 100 000 different interest groups. No users will be eligible to all of these interest groups, but it is realistic to assume that each visit on a product page would set the user in an additional interest group. After a few days of browsing, users could be in thousands of different interest groups.
Assuming the browser won’t want (or be able to) allocate more than a few megabytes to advertising (not including prefetched creatives), the space allocated to the interest group bidding logic would be in the range of a kilobyte. This kilobyte might seem to be more than enough to accommodate for a simple value and a few rules, but not so not for to account for the subtleties and synergies between a particular interest group and a particular contextual situation. Here are a few examples:
publisher-advertiser synergies: sports-related interest groups on Walmart would resonate more with sport blogs and photography-enthusiasts groups with photography blogs,
format-products synergies: vertical or horizontal banner size will be valued differently depending on the message/creative/product you advertise for,
location/time/weather: these will also be of relatively different value depending on the interest group
These subtleties and synergies account for a lot of the performance – and ultimately, the revenue publishers will ultimately receive.
The interest group bidding logic cannot embed all per-publisher synergies, unless we heavily bucketize them, and keep only the most extreme value to weight the bid – but that would be at the detriment of performance. And if we start to use the contextual signal at (contextual) bid request time to pass this information, we face another issue: in order to preserve performance, each and every advertiser would need for every advertiser to send a contextual bid for every single opportunity in a market they are addressing. This has the potential to create a huge infra burden for small advertisers (whose user base is small vs the total population in the market they operate in), and a huge revenue risk for newly created content, or long-tail of publishers who would be ignored from these inclusion / exclusion lists.
All in all, we should not neglect this aspect as this could heavily impact the resulting outcomes (advertising performance / ROI, and de facto budget spent in total). My estimate of the sizing is very poor, so a refined estimation on your side would be very much welcomed!
The text was updated successfully, but these errors were encountered:
Closing this issue as it represents past design discussion that predates more recent proposals. I believe some of this feedback was incorporated into the Protected Audience (formerly known as FLEDGE) proposal. If you feel further discussion is needed, please feel free to reopen this issue or file a new issue.
This issues stems directly from #46, but for the sake of clarity i thought it would be better to spin off this particular point of discussion.
Assuming that the interest group bidding logic has to stay in the browser, I think it is fair to say that you expect it to be small enough in size to accommodate for the many, many interest groups each advertiser is likely to put their visitors in. And we should expect many interest groups.
A website like Walmart, having 100 000 000 monthly visitors and 43 000 000 products is likely to have in the range of 100 000 different interest groups. No users will be eligible to all of these interest groups, but it is realistic to assume that each visit on a product page would set the user in an additional interest group. After a few days of browsing, users could be in thousands of different interest groups.
Assuming the browser won’t want (or be able to) allocate more than a few megabytes to advertising (not including prefetched creatives), the space allocated to the interest group bidding logic would be in the range of a kilobyte. This kilobyte might seem to be more than enough to accommodate for a simple value and a few rules, but not so not for to account for the subtleties and synergies between a particular interest group and a particular contextual situation. Here are a few examples:
These subtleties and synergies account for a lot of the performance – and ultimately, the revenue publishers will ultimately receive.
The interest group bidding logic cannot embed all per-publisher synergies, unless we heavily bucketize them, and keep only the most extreme value to weight the bid – but that would be at the detriment of performance. And if we start to use the contextual signal at (contextual) bid request time to pass this information, we face another issue: in order to preserve performance, each and every advertiser would need for every advertiser to send a contextual bid for every single opportunity in a market they are addressing. This has the potential to create a huge infra burden for small advertisers (whose user base is small vs the total population in the market they operate in), and a huge revenue risk for newly created content, or long-tail of publishers who would be ignored from these inclusion / exclusion lists.
All in all, we should not neglect this aspect as this could heavily impact the resulting outcomes (advertising performance / ROI, and de facto budget spent in total). My estimate of the sizing is very poor, so a refined estimation on your side would be very much welcomed!
The text was updated successfully, but these errors were encountered: