To access the Privacy Sandbox relevance and measurement APIs on Chrome and Android, developers need to enroll with the Privacy Sandbox. This includes Attribution Reporting, Protected Audience, Topics, Private Aggregation, and Shared Storage. Developer enrollment provides a mechanism to verify the entities that call these APIs, and to gather the developer-specific data needed to properly configure and use the Privacy Sandbox APIs. This enrollment process adds an additional layer of protections on top of the structural restrictions enforced within each API, by adding transparency to who is collecting data, and mitigating attempts to misuse the APIs to gather more data than intended. To provide auditable transparency, enrollment information about the company will be made public. Companies should plan at least five weeks to complete the enrollment process, from the time they submit the enrollment form. This includes time to address any issues with the form submission or other issues that may arise. This doesn't include any additional lead time companies may need for internal preparation prior to submitting the form.
Before you begin
Before starting enrollment, make sure you have a D-U-N-S number for your organization. This is a unique nine digit number provided by Dun & Bradstreet that is used to identify your business, and is checked as part of the Privacy Sandbox enrollment verification process. If your company has been issued multiple D-U-N-S numbers, provide the highest level one that represents your overall corporate entity. If your business is not a legal entity, you won't be able to obtain a D-U-N-S number.
To check if your company already has an assigned D-U-N-S number, or to obtain a new D-U-N-S number, make a request using the enrollment form. Google has a complimentary, expedited Dun & Bradstreet request process available for this purpose. Once you've made the request, we will send you an email with a unique, one-time-only link to visit the Google-specific landing page to submit your business details. If you don't complete submitting your information, you will need to request another link from Google.
Get a D-U-N-S number as an individual
If you are an individual and not affiliated with an organization, or your organization is not able to obtain a D-U-N-S number, you may enroll as an individual on the enrollment form. All information (excluding personally identifiable information) collected during developer enrollment may be included in Privacy Sandbox reports. These reports will be publicly available.
How to enroll
To enroll, developers must complete the enrollment form. The form requests the following information:
- Business contact information
- D-U-N-S number for your organization
- APIs that you plan to use and API configuration information
Developers also need to agree to attestations about their usage of the enrolled Privacy Sandbox APIs.
Enroll your site, Android SDK, or Android app
During enrollment, you need to provide a site or SDK (or both) that you'll use to call the APIs.
How you enroll depends on how the Privacy Sandbox APIs are called:
- If you're a web developer and your site calls the Privacy Sandbox APIs directly, you should provide your site in enrollment.
- If you're an Android SDK developer, provide your SDK name in enrollment. If your SDK uses the Attribution Reporting, Protected Audience, or both APIs, provide your site in enrollment as well. Apps that use your SDK don't need to enroll separately, unless they call Privacy Sandbox APIs directly from their own code. If you're testing Attribution Reporting APIs on Android at scale immediately, you will need to provide all the origins you use.
- If you're an app developer and your app calls the Attribution Reporting, Protected Audience, or both APIs directly, you should provide your site during enrollment.
- If you're an app developer and you delegate your ads functionality entirely to an SDK, you don't need to go through the enrollment process.
Every site or SDK that calls the Privacy Sandbox APIs requires a unique enrollment and needs to attest individually. Apps that call the Privacy Sandbox APIs directly may be included in a single enrollment. If you plan to call multiple APIs, specify each one during the enrollment process. Note: The site you enroll with is the same site that will be used to retrieve the encryption keys for use of Topics on Android and the signing key for your use of Protected Audience on Android. More information on the encryption endpoint for Topics on Android and more information for signing keys for Protected Audience.
Update enrollment information
You can update your enrollment information using the enrollment form. Updates will replace previous responses.
Enrollment timeline
After your enrollment form has been submitted, we'll review and process your application. Once the review is complete, you will be sent a confirmation email with a unique developer enrollment account ID and attestation file. The file must be made publicly available from the /.well-known path on the site for which it was enrolled within 30 days of receiving the account ID and attestation file. Android developers can provide the enrollment ID to app developers so apps can set granular access control. For more information, see Android's Configure API-specific Ad Services documentation.
Note: Enrollment reviews are completed once the enrollment form has been correctly filled out in its entirety. Entering correct information on your original submission and responding to any inquiries from the Google tech support team in a timely manner helps speed up the process.
Enrollment for different development environments
Your staging, beta, QA and test environments will be automatically enrolled if they use the same site as your production environment. You can test locally without going through enrollment. For local testing, we are providing developer overrides from Chrome 116 with a Chrome flag and CLI switch:
- Flag:
chrome://flags/#privacy-sandbox-enrollment-overrides - CLI:
--privacy-sandbox-enrollment-overrides=https://example.com,https://example.co.uk,...
Limitations
Note the following developer enrollment limitations when determining your organization's enrollment structure:
- One site can only be linked to one enrollment.
- One enrollment contains only one site.
- SDK specific limitations:
- One enrollment may contain multiple SDKs.
- A given SDK can only be linked to one enrollment.
- Additional enrollments are allowed, but they need to be for independent products or lines of business that are clearly established and publicly verifiable (that is, there is a corresponding public website that explains the specific product). You can't have multiple enrollments for the same product. The attestations apply to each enrollment individually.
- With site-scoped enrollment, a single enrollment can cover unlimited origins, as long as they are same-site. However, the one reporting origin per source rate limit (Chrome, Android) means that you are generally limited to one origin per publisher.
Multiple enrollments for a single entity
More complex entities that have multiple, unique products may apply for more than one enrollment. For example, if your company has an SSP and a DSP line of business you may qualify for multiple enrollments.
Each product must have separate sites from which to call the APIs. You will be required to provide public representation for each product you are requesting to enroll (for example, link to a public facing website that explains the product).
If you want to enroll more than one site or SDK, fill out the Multi Enrollment Request Process form in addition to submitting the normal enrollment form for the first enrollment you are requesting. Once submitted, the application will be reviewed and you will receive an email when the review process is complete.
Submit multiple enrollments under the same D-U-N-S number
If you are applying for multiple enrollments using the Multi Enrollment Request Process form, you may use the same D-U-N-S number on each enrollment.
Redirect with Attribution Reporting
Consider a scenario where site A is not enrolled but site B is enrolled. ARA will ping URLs for redirects even if not enrolled. As a result, the redirection from siteA.com to siteB.com will work. However, sources and triggers will only be registered from enrolled ad techs.
Enroll for Aggregation Service
There is currently a separate enrollment process for server elements and the client APIs (for Chrome and Android). Both enrollment forms are required to use the Aggregation Service. We are looking to streamline the processes. For now, the Aggregation Service has a separate form. You will enroll an origin (scheme, host name) during Aggregation Service enrollment which must be part of the same site (scheme, eTLD+1) registered through developer enrollment.
Each Aggregation Service enrollment must include the AWS account's ID, in which the Aggregation Service will be deployed. Each AWS account may only be linked to one Aggregation Service enrollment.
Upload your attestation file
Once you've enrolled and passed the verification process, we'll send a file that contains the API-specific attestations to the email address you've provided. You will have a 30-day implementation period from the time you receive the account ID and attestation file, to finalize your attestation file placement. During this time you will still be able to call the APIs for 30 days, however it is expected that you adhere to the attestation language during this time.
To complete enrollment, you must make the file available from the public .well-known path on the site that was enrolled. For example, if you enroll https://example.com, place the attestation file at https://example.com/.well-known/privacy-sandbox-attestations.json. You can't use HTTP redirects to serve the attestation file. The attestation file must be located at the .well-known directory at your site. It cannot redirect to another location (for example, a subdomain, or another site.)
You must abide by the attestations and keep the attestation file in place for the duration of the enrollment. Attestation files are routinely verified, and prolonged failure to keep them in place will cause API calls to fail until the file is restored.
Note that:
- Privacy Sandbox will run a server side job to fetch the attestation file from enrolled ad techs, and construct an allowlist based on the contents of the file. This allowlist will then be synced with the browser as well as the OS. This job will fetch the file no more than once an hour.
- The intention is for the attestation file to be available publicly. The ad tech should expect some fetch requests from external parties, including researchers, regulators, and users (outside of the fetch requests from Privacy Sandbox infra). Ad techs must serve the same file to them that they serve to Google.
- Every API call won't trigger a fetch request for the attestation file.
For Topics on Android attestations, app and SDK developers need to agree to the attestation within the enrollment form and don't need to place an attestation file on their server unless they are using other Privacy Sandbox APIs.
Update attestation to add more APIs
If you decide to include more APIs in your enrollment at a later date, you will need to update your enrollment. As part of this process, you will receive an updated attestation file that must be made available from the .well-known path on your site, before you can call the new APIs.
Update to the latest version of the attestation file
All enrolled companies need to update to the latest version of the attestation file they have received from Google.
The attestation files don't expire after a set period of time. New or updated attestation files may be provided from time to time as the attestation framework evolves (for example, new API-specific attestations are added and so on).
One-off errors
Access would be cut off only if the server checking the attestation file is repeatedly unable to validate it. A single error or serving issue wouldn't cause access to be removed.
For more details, see the GitHub on attestations.
Android developer data
Entities that intend to use the Privacy Sandbox APIs on Android are sent an enrollment account ID, which can be included in an app's AdServices configuration. This allows app developers to have fine-grained control over the ad techs that their app or SDKs interact with.