Publisher Privacy Treatment API (Beta)

The Publisher Privacy Treatment (PPT) API is a tool that publishers can use to transmit a user's privacy preferences. This article introduces the first treatment in a family of API tools we’re offering publishers to help manage personalization and data usage for their users.

The first treatment, PPT=1, allows publishers to turn off ads personalization per ad request, which could be learned from a publisher-offered control to their users. In reporting, PPT=1 distinguishes non-personalized ads traffic from other non-personalized ad serving modes like NPA=1 or rdp=1.

PPT=1 is not intended to cover use cases that require more specific ad serving modes. Learn more about our tools available for user privacy regulations, including non-personalized ads and restricted data processing.

For ad requests with multiple user privacy signals, the most restrictive signal will take precedence.

Google’s various ad tags and ads SDKs have been updated to begin accepting the first treatment value (PPT=1) to turn off ads personalization when set by the publisher. Publishers who serve ads without the help of our tags or SDKs may also choose to directly append treatment values (for example, PPT=1) as URL parameters onto ad requests. As more treatments are released in the future, publishers will be able to append multiple treatment values (for example, PPT=1,2,3).

How PPT=1 works

Ad requests containing PPT=1 indicate that the publisher wants ads personalization turned off for those specific ad requests. A common expected use case is for publishers to add PPT=1 to ad requests from users who have opted out of ads personalization through publisher-offered controls. When PPT=1 is included in an ad request, participating ad platforms recognize the user’s desired privacy treatment (to turn off ads personalization).

In Google Ad Manager, AdSense, or AdMob:

• PPT=1 turns off ads personalization on both a publisher’s direct sold campaigns and their Google programmatic demand.
• No user profiles will be used to target users whose associated ad requests include PPT=1.
• Ad requests containing PPT=1 cannot be used to update any existing user profiles for the associated user.

PPT=1 differs from non-personalized ads (NPA=1) and restricted data processing (rdp=1) in the following ways:

• When PPT=1, third-party vendor usage for ad serving and ad tracking is permitted.
• When NPA=1 or rdp=1, third-party vendor usage for ad serving and ad tracking:
  • Is not permitted for Google demand.
  • Is only restricted for non-Google demand when publishers turn on the "Check RTB (real-time bidding) partner creatives for ad partner consent" option.
  • Is only restricted for reservations with third-party vendors for users in the EEA, the UK, or Switzerland for NPA=1 when the "Check reservation creatives for consent" option is turned on.
• For users under the jurisdiction of LGPD, NPA=1 will only serve for reservations if there are no ad technology providers declared or detected.

When PPT=1 is included in an ad request, non-Google programmatic demand is also sent NonPersonalizedAdsReason.Publisher_Declared_NPA=1 in the bid request to indicate that the user wants personalization turned off for the given ad request. PPT=1 permits third-party vendor usage for ad serving and ad tracking, but there are limitations on the expansion of certain macros related to user IDs. User identifiers (such as google_user_id, hosted_match_data, any device advertising IDs, and session_id) will be removed from bid requests for non-personalized ads. This will help to ensure, but not fully guarantee, that the signal is respected when passed to authorized buyers and open bidders.