FLEDGE API is a proposal to serve remarketing ads without third-party cookies. FLEDGE executes the ad auction between the buyers (DSP) and the sellers (SSP) locally, and receives real-time signals from the FLEDGE K/V servers. To learn more about
- FLEDGE for the Web: explainer and the developer guide.
- FLEDGE on Android: design proposal and the developer guide.
When the auction is executed, separate FLEDGE K/V servers are queried for the buyers and sellers. When a buyer is making a bid, the DSP K/V server can be queried to receive real-time information to help determine the bid. To help the seller pick an auction winner, the SSP K/V server can be queried to receive any information about the creative to help score the ad.
The current codebase represents the initial implementation and setup of the server. It can be integrated with Chrome and Android with the Privacy Sandbox unified origin trial and Privacy Sandbox on Android Developer Preview. Our goal is to present the foundation of the project in a publicly visible way for early feedback. This feedback will help us shape the future versions.
The implementation, and in particular the APIs, are in rapid development and may change as new versions are released. The query API conforms to the API explainer. At the moment, to load data, instead of calling the mutation API, you would place the data as files into a location that can be directly read by the server. See more details in the data loading guide.
The query API only supports the newer version of response format (accompanied by response header X-fledge-bidding-signals-format-version: 2) as described in the FLEDGE main explainer. The Chrome’s support of this format is expected to be available in Chrome version 105.
Currently, this service can be deployed to 1 region of your choice with more regions to be added soon. Monitoring and alerts are currently unavailable.
Attention: The Key/Value Server is publicly queryable. It does not authenticate callers. That is also true for the product end state. It is recommended to only store data you do not mind seen by other entities.
This codebase right now is in a very early stage. We expect frequent updates that may not be fully backward compatible.
The release version follows the [major change]-[minor change]-[patch] scheme. All 0.x.x versions may contain breaking changes without notice. Refer to the release changelog for the details of the breaking changes.
Once the codebase is in a more stable state that is version 1.0.0, we will establish additional channels for announcing breaking changes and major version will always be incremented for breaking changes.
- FLEDGE services overview
- FLEDGE K/V server API explainer
- FLEDGE K/V server trust model
- Local server quickstart guide
- AWS server user deployment documentation
- Integrating the K/V server with FLEDGE
- Operating documentation
- Data loading API and operations
- Error handling explainer (to be published)
- Developer guide
- Code of conduct
Contributions are welcome, and we will publish more detailed guidelines soon. In the meantime, if you are interested, open a new Issue in the GitHub repository.
The FLEDGE K/V feature set, API and system design are under active discussion and subject to change in the future. If you try this API and have feedback, we'd love to hear it:
- GitHub: For questions or feedback that are relevant to this proposal, open a new Issue in this repository. For questions that are purely relevant to browser-side logic, open an Issue in the Turtledove repository.
- W3C: You are welcome to attend the FLEDGE WICG meeting.
- Developer support: Ask questions and join discussions on
General announcements will be made on the FLEDGE mailing list on chromium.org and the Privacy Sandbox progress update page on the Android developer site, if needed, an accompanying article will be published on the Chrome Developers blog and Android Developers blog.