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

Browser-side recent advertising events #44

Closed
piwanczak opened this issue Jul 9, 2020 · 2 comments
Closed

Browser-side recent advertising events #44

piwanczak opened this issue Jul 9, 2020 · 2 comments

Comments

@piwanczak
Copy link

TD proposal briefly suggests a functionality for ad frequency control:

 'max-times-per-minute': 1,
 'max-times-per-hour': 6,

Instead of rigid browser-side rules we suggest supplying information on recent ad events to the bidding function. This way:

  • Much more flexible logic is possible allowing better user experience and bidding precision (in our experience with the CTR model, features based on recent ad events are among the strongest ones)
  • The browser API is much more generic (e.g. there’s no need to decide whether we need hourly or daily counters)
  • User privacy is not affected.
function(adSignals, contextualSignals, recentAdEvents) {
    # calculate the base bid:
    bid = contextualSignals.is_above_the_fold ? 
        adSignals.atf_value : adSignals.btf_value;

    # fine-tune the bid based on former user interactions 
    # with ads (or lack thereof):

    # slightly decrease bid after each impression
    for (imp in recentAdEvents.impressions):
        if (now - imp.timestamp < 1h) {
            bid *= 0.5;
        } else if (now - imp.timestamp < 24h) {
            bid *= 0.8;
    }

    # and increase after each click
    for (click in recentAdEvents.clicks) {
        if (now - click.timestamp < 24h) {
            bid *= 1.2;
        }
    }

    return bid;
}

In a basic version recentAdEvents related to an interest group could be exposed only to the bidding function of this interest group. Potentially, this can be extended to maximize utility.

What do you think?

@michaelkleber
Copy link
Collaborator

Yup, this was suggested as an aspect of #5 as well. This generally seems reasonable, though the time deltas would need some bucketing or granularity to prevent them from being used as an identifier for a single person.

@JensenPaul
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants