FLEDGE is now Protected Audience. Learn more!

Enroll your platform with the Privacy Sandbox

To access the Privacy Sandbox on Android privacy-preserving APIs (Topics, Protected Audience, and Attribution Reporting), developers need to enroll with the Privacy Sandbox. Enrollment is required for both Beta and Developer Preview releases.

Enrollment provides a mechanism for organizations such as API callers and ad techs to verify developer identity and gather developer-specific data needed by the Privacy Sandbox APIs.

During enrollment, developers provide information that includes the following:

After your enrollment is processed, you will receive a confirmation email that includes an enrollment account ID. An enrollment account ID can be included in an app's or SDK's AdServices configuration to allow it to call the APIs. You should complete enrollment at least a month before you plan to call the APIs, to provide ample time for enrollment processing and the delivery of enrollment data to production devices.

Enroll for a Privacy Sandbox account

API-specific configuration

Each organization should enroll only once. Provide a site (eTLD+1) or SDK package name associated with your organization.

For Topics, provide the SDK or app package name from which you intend to call the Topics API from. You can provide multiple SDKs or app package names with your enrollment.

For Protected Audience and Attribution Reporting, provide a site (eTLD+1). If using both APIs, this site must be the same for Protected Audience and Attribution.

  • For Protected Audience, this eTLD+1 is used to identify your company in joinCustomAudience() or selectAds() API calls.
  • For Attribution Reporting, provide an origin within that site to use for calls to registerSource() or registerTrigger.
    • In the future, the Privacy Sandbox will allow you to use multiple origins within that site.

Organizations shouldn't need to enroll multiple sites. Reach out if you have a use case that requires enrollment of multiple sites.

Impact on the Attribution Reporting API

For Attribution Reporting, each organization enrolls a site, and then chooses an origin within that site to use as the Attribution Source and Trigger URIs. For example:

  • Ad tech enrolls https://adtech.example as their site.
  • Ad tech selects an origin within that site to call the Attribution Reporting API:
    • https://adtech.example/register_source is used as the attribution source URI.
    • https://adtech.example/register_trigger is used as the trigger URI.
  • Attribution scope is determined by the origin, and reports are sent to the origin's /.well-known/ endpoints.
  • See the following table and the article on how to check if a request is "same-site", "same-origin", or "cross-site" for more details.

Attribution Source URI

Trigger URI




Yes - same origin



Yes - same origin



No - different origin



No - different origin. Additionally this is not a valid enrollment (different sites).

Reports are sent to the origin's /.well-known/ endpoints. For example, if the origin is https://adtech.example, reports are sent to:


Enrollment form updates

The Privacy Sandbox enrollment form has been updated to reflect the following changes:

  1. DUNS number:
    1. This can be used as an optional verification step to validate whether your company or organization already has a Privacy Sandbox account enrolled. If provided, your DUNS number may be used in future Privacy Sandbox reports.
    2. Look up your organization's assigned DUNS number. If you don't already have one, reach out. Learn more about DUNS numbers.
  2. Attribution reporting settings
    1. List one URL per line (full URL minus parameters). Your server URL must support HTTPS, and URLs should belong to the same origin (scheme + host + port).
  3. Protected Audience on Android settings
    1. This is the eTLD+1 used to identify your company in joinCustomAudience() or selectAds() API calls. It needs to have the same eTLD+1 as any other URLs provided for enrollment.