Tag Archives: floc

Charting a course towards a more privacy-first web

It’s difficult to conceive of the internet we know today — with information on every topic, in every language, at the fingertips of billions of people — without advertising as its economic foundation. But as our industry has strived to deliver relevant ads to consumers across the web, it has created a proliferation of individual user data across thousands of companies, typically gathered through third-party cookies. This has led to an erosion of trust: In fact, 72 percent of people feel that almost all of what they do online is being tracked by advertisers, technology firms or other companies, and 81 percent say that the potential risks they face because of data collection outweigh the benefits, according to a study by Pew Research Center. If digital advertising doesn't evolve to address the growing concerns people have about their privacy and how their personal identity is being used, we risk the future of the free and open web.  

That’s why last year Chrome announced its intent to remove support for third-party cookies, and why we’ve been working with the broader industry on the Privacy Sandbox to build innovations that protect anonymity while still delivering results for advertisers and publishers. Even so, we continue to get questions about whether Google will join others in the ad tech industry who plan to replace third-party cookies with alternative user-level identifiers. Today, we’re making explicit that once third-party cookies are phased out, we will not build alternate identifiers to track individuals as they browse across the web, nor will we use them in our products. 

We realize this means other providers may offer a level of user identity for ad tracking across the web that we will not — like PII graphs based on people’s email addresses. We don’t believe these solutions will meet rising consumer expectations for privacy, nor will they stand up to rapidly evolving regulatory restrictions, and therefore aren’t a sustainable long term investment. Instead, our web products will be powered by privacy-preserving APIs which prevent individual tracking while still delivering results for advertisers and publishers.

Privacy innovations are effective alternatives to tracking

People shouldn’t have to accept being tracked across the web in order to get the benefits of relevant advertising. And advertisers don't need to track individual consumers across the web to get the performance benefits of digital advertising. 

Advances in aggregation, anonymization, on-device processing and other privacy-preserving technologies offer a clear path to replacing individual identifiers. In fact, our latest tests of FLoC show one way to effectively take third-party cookies out of the advertising equation and instead hide individuals within large crowds of people with common interests. Chrome intends to make FLoC-based cohorts available for public testing through origin trials with its next release this month, and we expect to begin testing FLoC-based cohorts with advertisers in Google Ads in Q2. Chrome also will offer the first iteration of new user controls in April and will expand on these controls in future releases, as more proposals reach the origin trial stage, and they receive more feedback from end users and the industry.

This points to a future where there is no need to sacrifice relevant advertising and monetization in order to deliver a private and secure experience. 

First-party relationships are vital

Developing strong relationships with customers has always been critical for brands to build a successful business, and this becomes even more vital in a privacy-first world. We will continue to support first-party relationships on our ad platforms for partners, in which they have direct connections with their own customers. And we'll deepen our support for solutions that build on these direct relationships between consumers and the brands and publishers they engage with.

Keeping the internet open and accessible for everyone requires all of us to do more to protect privacy — and that means an end to not only third-party cookies, but also any technology used for tracking individual people as they browse the web. We remain committed to preserving a vibrant and open ecosystem where people can access a broad range of ad-supported content with confidence that their privacy and choices are respected.  We look forward to working with others in the industry on the path forward. 

Posted by David Temkin, Director of Product Management, Ads Privacy and Trust

Announcing new Real-time Bidding experiments

Google is launching experiments that are intended to provide bidders with an opportunity to test and provide collaborative feedback on ads-privacy proposals–these are features intended to improve user privacy protections and provide mechanisms for testing Chrome Privacy Sandbox proposals. We strongly encourage interested bidders to sign up and participate! Three new experiments made available today are described below.

Experiment #1: TURTLEDOVE simulation

The RTB protocols and infrastructure have been updated to enable a server-side simulation of Chrome’s TURTLEDOVE proposal, as described in the TURTLEDOVE simulation proposal. Bidders interested in participating can reference the TURTLEDOVE RTB Simulation API guide to learn more about the specific API and protocol changes associated with this experiment. Along with these changes, a new biddingFunctions resource for managing bidding functions that are used in the server-side simulation was added to the Real-time Bidding API.

The goal of this simulation is to provide bidders with an opportunity to experiment with Chrome’s proposal before it is implemented in Chrome, so that participating bidders can provide feedback on its viability and effectiveness. The APIs and modified RTB workflow used in the server-side simulation are conceptually similar to the ones that Chrome may later implement for TURTLEDOVE, based on existing proposals and public design discussions. Feedback relevant to Google’s simulation should be directed to the ads-privacy issue tracker, whereas feedback relevant to the TURTLEDOVE proposal itself should be directed to Chrome’s TURTLEDOVE issue tracker. To report bugs or technical questions about this experiment, you may contact the [email protected] support alias.

Experiment #2: Federated Learning of Cohorts (FLoC)

Google will allow participating bidders to experiment with Chrome’s FLoC proposal by simulating FLoC cohorts on its servers, based on algorithms described in this Google Research & Ads whitepaper. To facilitate this experiment, a Floc message has been added to the BidRequest in the Google RTB protocol, and as an extension of the User object for Google’s OpenRTB implementation. The message is structured as follows:


message Floc {
    // The value of a cohort ID – a string identifier that is common to a large
    // cohort of users with similar browsing habits.
    optional string id = 1;
    // The type of the FLoC. See
    // https://github.com/google/ads-privacy/blob/master/proposals/FLoC/FLOC-Whitepaper-Google.pdf.
    enum FlocType {
      // Default value that should not be used.
      FLOC_TYPE_UNKNOWN = 0;
      // FLoC simulated using affinity hierarchical clustering with centroids
      // and feature extraction based on Topic categories as described in the
      // whitepaper.

      SIMULATED_AFFINITY_CLUSTERING_CENTROID_VERTICAL = 2;
      // FLoC simulated using SortingLSH clustering algorithm and Domain One-hot
      // encoding feature extraction as described in the whitepaper.
      SIMULATED_SIMHASH_SORTING_LSH_DOMAIN_ONE_HOT = 3;
      // FLoC simulated using a k Random Centers locality-sensitive hash
      // function as described in
      // https://github.com/google/ads-privacy/blob/master/proposals/FLoC/k-random-centers.md
      // with Domain TF-IDF feature extraction as described in the whitepaper.
      KCENTER_DOM_FILTERED_TFDIF = 4;
    }
    optional FlocType type = 2;
  }

Only web requests are in scope for the FLoC simulation experiment. In practice, only a small percentage of bid requests for bidders opted-in to the experiment would include this message, and those that do would not include pseudonymous user identifiers such as google_user_id and hosted_match_data.

Floc would also not be populated as a result of privacy controls, such as when users opt out of personalized advertising. Upon winning impressions, bidders can render creatives as usual and use their cookie-based identifiers to attribute conversions–for instance–to measure how well different FLoCs correlate with conversions.

We encourage participants to use the issue tracker to leave feedback on the simulated cohort algorithms. One useful metric to include would be the conversion rates for each FlocType in the experiment, possibly in comparison to regular traffic, where bidders may rely on cookie-based identifiers for targeting and optimization.

Experiment #3: Exchange-enforced frequency capping

The RTB protocols have been updated to enable an experiment for the exchange-enforced frequency capping proposal, which intends to support the critical frequency capping use case for the inventory provided by a single exchange without reliance on user identifiers provided in bid requests. A FrequencyCap message has been added to the BidResponse in the Google RTB protocol, and as an extension of the Bid object for Google’s OpenRTB implementation. The message is structured as follows:


  message FrequencyCap {
    // An ID that can represent a bidder's use-case for frequency capping; for
    // example, it could represent their campaign, ad, line item, etc. It should
    // not contain any user-specific information or identifiers.
    optional string fcap_id = 1;

    // The time units for which frequency caps can be enforced.
    enum TimeUnit {
      UNKNOWN_TIME_UNIT = 0;
      MINUTE = 1;
      DAY = 2;
      WEEK = 3;
      MONTH = 4;
      // When INDEFINITE is used, time_range will be ignored. INDEFINITE means
      // the frequency cap will be applied for a long period of time, (longer
      // than a month) but not necessarily forever.
      INDEFINITE = 5;
    }

    // The unit of time used to specify the time window for which a frequency
    // cap applies.
    optional TimeUnit time_unit = 2;

    // The length of the time window, in units specified by time_unit, for which
    // the frequency cap applies. For instance, if time_unit=WEEK and
    // time_range=3, then capping is applied for a three week period. If the
    // time_unit=INDEFINITE, this will be ignored.
    optional int32 time_range = 3 [default = 1];

    // The maximum number of impressions allowed to be shown to a user for
    // the provided frequency_cap_id within the time window described by
    // time_unit and time_range.
    optional int32 max_imp = 4;
  }


Additional information about this experiment can be found in the proposal, and we encourage participants to leave feedback in the issue tracker.

Mark Saniscalchi, Authorized Buyers Developer Relations