Notification

يمكنك الحصول على نصائح مخصّصة حول التحسين والتعرّف على سلامة حسابك وإعداد اكتمالها في "صفحة AdMob المحسّنة".

الصفحة التي طلبتها غير متوفرة بلغتك حاليًا. يمكنك اختيار لغة مختلفة في أسفل الصفحة أو ترجمة أي صفحة ويب على الفور إلى لغة من اختيارك، وذلك باستخدام ميزة الترجمة المضمّنة في Google Chrome.

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.

Examples

  • An ads personalization setting opt-out from users in the EEA, the UK, and Switzerland would still be honored even if the Publisher Privacy Treatment API does not indicate that personalization has been turned off.
  • If indicated through the PPT API, users will be served non-personalized ads even if a TCF v2.2 string shows the user consented to ads personalization.

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).

For more information, review the Google Developers documentation:

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.

 

هل كان ذلك مفيدًا؟

كيف يمكننا تحسينها؟
true
Show your support to promote DEI in Gaming by turning intentions into action!

Check out the newly launched Diversity in Gaming website, where you can find video stories and written pledges from global gaming developers. This campaign centers on 3 pillars: diverse teams, diverse games and diverse audiences showing how diversity is not just good for gamers, but for business as well. Show your support by taking the pledge to promote DEI in Gaming and share it on social!

Learn More

Search
Clear search
Close search
Google apps
Main menu
15774000528065972273