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

Increasing the number of ad components entering the bid from 20 to 40 #810

Open
leobierent12 opened this issue Sep 15, 2023 · 5 comments
Open
Labels
Non-breaking Feature Request Feature request for functionality unlikely to break backwards compatibility

Comments

@leobierent12
Copy link

leobierent12 commented Sep 15, 2023

From CRITEO recommendation team

Request:

We propose increasing the limit on the number of ad components entering the bid from 20 to 40.

Background:

The current limitation on the number of ad components is causing several challenges in our advertising platform. As per the FLEDGE specification (https://github.com/WICG/turtledove/blob/main/FLEDGE.md#34-ads-composed-of-multiple-pieces), we are restricted to a maximum of 20 ad components entering the generate_bid function. This constraint has a significant impact on our advertising operations.

Rationale:

Limitation on Product Display:

The existing constraint severely restricts the number of products that can be displayed in our advertising banners. This limitation has the following consequences:

Impact on Performance: limiting the number of products in our banners to fewer than 20 results in significant missed displays and click opportunities.

Impact on Product Offering: We are constrained to offer only simple banners and cannot create carousels, paginations, animations, and other creative formats. These creative offerings account for a significant share of our HTML displays. Restricting these options limits our ability to engage users effectively.

Limitation on K Anonymity Checks:

We aim to ensure K anonymity for around 20 products minimum in our displays to maintain performance standards. However, the current constraint severely limits our ability to explore and evaluate K anonymity for a broader range of products.

Impact on Exploration: As we want to use around 20 product minimum for displays to keep performance, we have very little room for exploration for K anonymity. In a creative perspective, we want all the 20 components that are entering the generate_bid() function to be displayed. So, we will choose only products that have high chance to be K anonymous. By limiting the number of ad components to 20, we will have to limit very hardly the exploration to provide enough products to have a normal creative offering.

Proposed Solution:

To address the challenges mentioned above and to maintain a balance between creative offerings, performance, and exploration, we propose increasing the limit on the number of ad components from 20 to 40.

@JensenPaul JensenPaul added the Non-breaking Feature Request Feature request for functionality unlikely to break backwards compatibility label Oct 3, 2023
@michaelkleber
Copy link
Collaborator

FYI this was discussed in the WICG call on Oct 4, notes here.

@leobierent12
Copy link
Author

You would find below a summary of our rational, and an example of active ad, in order to maintain this discussion alive:

The current ad components limit of 20 is restricting our creative strategy, especially for banners featuring more than 20 products.

- Media Spend Allocation:

A significant percentage of our media spend involves displays with more than 20 products (less than 10%).

- Performance Metrics:

Banners such as "scroll," "carousel," or "shop-like" with more than 20 products outperform others, showing double-digit percentage increases in conversion compared to banners of the same size without a scroll and with fewer products on some scopes.

- User Experience and Brand Perception:

These banners contribute not only to conversions but also positively impact the advertiser's image. They provide an immersive user experience, giving users the feeling of browsing the advertiser's website.

Example of Active Ad:

ezgif-3-c6fb9db1ae

Request:

Increasing the ad components limit is essential to maintaining our creative strategy's effectiveness, enhancing campaign performance, and ensuring high user satisfaction.

Labels: Ad Components, Creative Strategy, Performance Metrics, User Experience

aarongable pushed a commit to chromium/chromium that referenced this issue Jan 18, 2024
To permit feature detection of it, generateBid() gets a new
browserSignals.adComponentsLimit signal; this is only added if the feature is actually on so behavior w/it off is completely unchanged.

(This CL does not cover feature detection of it for additional bids).

See WICG/turtledove#810

Change-Id: I52a358bfae86b0112929a012192ea59b6a963cd4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5205990
Reviewed-by: Russ Hamilton <[email protected]>
Reviewed-by: danakj <[email protected]>
Reviewed-by: Garrett Tanzer <[email protected]>
Commit-Queue: Maks Orlovich <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1248925}
aarongable pushed a commit to chromium/chromium that referenced this issue Jan 22, 2024
...for now only supporting looking up the value of adComponentsLimit.
It is enabled only when the feature customizing the value is enabled,
and is hidden otherwise, keeping with our goal of not changing
anything web visible by default.

Clients can use something like:
let componentAdLimit = navigator.protectedAudience?.
  queryFeatureSupport("adComponentsLimit");
if (!componentAdLimit)
  componentAdLimit = 20

Of course additional keywords can be added later

(See WICG/turtledove#810)

Change-Id: Ia5860f28da5bd89ad2b4956eb52e255ffeda6a96
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5213348
Reviewed-by: Russ Hamilton <[email protected]>
Reviewed-by: Mike Taylor <[email protected]>
Reviewed-by: Chris Harrelson <[email protected]>
Commit-Queue: Maks Orlovich <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1250185}
@morlovich
Copy link
Collaborator

So this is in canary/dev at 50%, and I should hit the switch on starting it to 50% in beta shortly, though rolling out takes a while since it happens when people restart.

@morlovich
Copy link
Collaborator

... Looks like I forgot to update this :(
So it went to 1% in stable for a bit, then we had problems with experiment setup, rolled it back to 50% canary/dev/beta only, and now it should be restarting 1% stable as well.

@morlovich
Copy link
Collaborator

This should be in progress of full launch now, though it will take some time (since people only get new config when restarting Chrome).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Non-breaking Feature Request Feature request for functionality unlikely to break backwards compatibility
Projects
None yet
Development

No branches or pull requests

4 participants