Only available in Google Ad Manager 360.

About publisher provided identifiers

Only available in Google Ad Manager 360

PPID (Publisher provided identifier) is a Google Ad Manager 360 feature that might not be enabled for your network. Contact your account manager to activate PPID. 

The Publisher provided identifier (PPID) allows publishers to send Google Ad Manager an identifier for use in frequency capping, audience segmentation and audience targeting, sequential ad rotation, and other audience-based ad delivery controls across devices. #PPID

PPID is not currently supported in Ad Manager's reach reporting or conversion tracking.

Jump to:

How PPIDs work

  • The identifier sent to Ad Manager must be hashed or encrypted such that it is meaningless to Google, and it must not be raw personally identifiable information, a raw third-party ID, or a raw device ID.
  • If Google is aware that a user has opted out of personalized ads (for example, by using Ads Settings, EU user consent controls, or restricted data processing (RDP) settings), features permitting the use of PPID for targeting ads to the user's web browser will be disabled.
  • The user must have access to a mechanism to opt out of personalized ads.
  • If a user opts out of the publisher's use of PPID in connection with advertising, or deletes their account, the publisher must immediately stop sending Google the PPID associated with that user.

PPID deletion

If a user requests that the publisher delete their user data, the publisher may send the user’s data deletion request to Ad Manager to ensure user data is deleted from Google’s internal storage systems.

To request PPID data deletion, the publisher should initiate the request using this URL: 

https://securepubads.g.doubleclick.net/user_data_deletion?ppid={user's_PPID}&iu={publisher's_AdManager_network_code}

Example

https://securepubads.g.doubleclick.net/user_data_deletion?ppid=‘12JD92JD8078S8J29SDOAKC0EF230337’&iu=12345

  • Publishers may begin this process as soon as they receive a signal from their user requesting data deletion.
  • After successfully receiving this signal from the publisher, our internal systems immediately de-link existing user data from the PPID, and such data is subsequently fully deleted within 63 days.

Expected response

Successful requests return the HTTP response status code “200.” Unsuccessful requests return the HTTP response status code “400.” If the PPID data deletion API is not enabled, the HTTP response status code “404” is returned.

Set the identifier

If your sites/apps don’t send any Google Ad Manager ad requests (or audience pixel requests) with a given PPID for 180 days, requests need to be sent again to make the PPID valid. Google may remove PPIDs after shorter periods of inactivity to intelligently optimize PPID resources.

Google Publisher Tags

For websites, use the PublisherProvidedId method:

Method details for pubService

pubService.setPublisherProvidedId(identifier)

Sets values for publisher-provided ID for use in frequency capping and other audience-based activities.

Parameters

string identifier: An alphanumeric ID provided by the publisher with a recommended maximum of 150 characters.

Example

<script type="text/javascript">
       googletag.pubads().setPublisherProvidedId('12JD92JD8078S8J29SDOAKC0EF230337');
       googletag.enableServices();
     </script>

Google Mobile Ads SDK

The GoogleAdManagerExtras class contains a method called setPublisherProvidedId(string ID). See Google Mobile Ads SDK documentation for more information.

Google IMA SDK

The HTML5, iOS, and Android SDKs provide the following methods or properties to set the PPID.

Non-JS request (aka Tagless Request)

Requests made directly to Google Ad Manager using /adx or /ad+/jump must include a parameter ppid=.

Audience Solutions pixel tags

Requests made directly to Google Ad Manager using Audience Solutions pixel tags must include the parameter ppid=.

Example

https://securepubads.g.doubleclick.net/activity;dc_iu=/{ad-manager-network-code}/DFPAudiencePixel;ord=1;dc_seg={segment_ID};ppid={your_ID}

Learn more about passing a PPID into an Audience Solutions pixel tag.

Limits and requirements

Failure to meet the requirements described below might cause PPIDs to be ignored or discarded by our systems.

The PPID value must be:

  • Alphanumeric ([0-9 a-z A-Z]) or UUID HEX representation (8-4-4-4-12).

  • A minimum of 32 characters.

  • A maximum of 150 characters.

  • Hashed or encrypted, so meaningless to Google.

  • Only sent when a user can be identified for more than one session (for example, a first-party cookie available across multiple sessions may be used to generate a PPID).

Avoid changing the algorithm for generating PPID values. Doing so causes various features to be reset, including frequency capping, audience segmentation and targeting, sequential ad rotation, and other audience-based ad delivery features.

Enable PPID for programmatic

When enabled by you, PPID may be utilized by Google programmatic demand to support buyer frequency capping and interest-based ads personalization on programmatic traffic, when Ad Manager third-party cookies or device IDs aren’t available. This will potentially increase publisher programmatic revenue, while limiting user's activity tracking only within the same Ad Manager network:

  • Before sharing PPIDs with Google demand, Ad Manager turns them into per-publisher partitioned IDs, so users cannot be identified across other publishers’ sites and apps.
  • You can send your data (including first-party data) to the third-party bidders you choose using encrypted signals.

Follow these steps to enable PPID for programmatic:

  1. Sign in to Google Ad Manager.
  2. Click Admin and then Global settings.
  3. Next to “Ad preference settings,” enable the Publisher-provided identifiers for programmatic slider.
  4. Click Save.

Report on PPID

Use the “PPID presence” dimension in Ad Manager reporting to see coverage broken down by ad requests that do (“Present”) and don’t (“Missing”) have a PPID. This dimension covers both reservation and programmatic traffic.

  •  Use the “PPID Presence” dimension to troubleshoot PPID coverage across programmatic and reservation traffic. For example, to understand if some inventory is missing the correct PPID configuration, you can report on Total Ad Requests by Ad Unit and / or Request Type, adding the PPID Presence and then is any of and then Missing filter.
  • PPID for Programmatic only applies to the share of your traffic where third-party identifiers aren’t available. In other words, it has no impact on programmatic traffic where third-party cookies are available. Therefore, when analyzing programmatic performance in the presence of PPID, we recommend selecting the User identifier status (Beta) and then is any of and then Missing filter to limit your analysis on ad requests where third-party cookies or device IDs aren’t available.
  • The “PPID presence” dimension can’t be used to accurately determine revenue effects, but may be used as an indication of performance. To get a better understanding of revenue uplift, we recommend that publishers perform their own A/B tests, consider different inventory types, as well as the presence of a third-party identifier.

Requests with multiple identifiers

As previously mentioned, the PPID supplements, rather than replaces, other identifiers used by Google Ad Manager (for example, cookies on a desktop environment, or resettable mobile advertising IDs like AdID and IDFA). In most cases, this means that a PPID-enabled ad request made to Google Ad Manager will be a multi-identifier request—it will contain a primary PPID identifier and a secondary desktop/mobile identifier.

This can affect Google Ad Manager behavior in a number of ways, detailed below.

Audience segment targeting

Segment membership is maintained independently for the secondary identifier and the PPID. When a multi-identifier request is received, the request is eligible to serve line items targeted to any of the combined segment membership across the two identifiers.

Example

A user visits a sports site or app that supports PPID for signed-in users but is not signed in. This user visits pages on the site or app that cause him to be added to an audience segment for basketball fanatics (segment S1). Since the user is not signed in, the secondary identifier is added to the audience segment. The user subsequently signs into the site or app, triggering the addition of a PPID on further ad requests. This particular user is known to be in the 25-34 age range, and his PPID was added to an age-based audience segment (segment S2) through batch identifier uploads. For any of the user's multi-identifier requests, line items targeted to segments S1 and/or S2 will be eligible to serve.

Audience segment sharing

PPIDs are specific to a single network. That is, each network has its own PPID namespace, which protects against collision if two networks assign the same PPID to different users. Audience segments built from one network's PPIDs cannot be shared with other networks or products (more accurately, PPIDs on requests from one network will never match the PPIDs in another network's audience segment). Only segments built on top of cookie or device ids can be shared among multiple networks. An audience segment containing both PPIDs and secondary IDs could be shared, but ads targeted to this segment would only be eligible to serve to a multi-identifier request if the secondary identifier on the ad request matched a secondary identifier within the segment.

Audience segment membership

If a multi-identifier request is received, only the primary PPID is considered for the purpose of triggering or refreshing audience segment membership. Any secondary identifier passed in the request will not be considered for this purpose.

Example

A different user visits the sports site from the previous example, and she is currently signed in to the site (a multi-identifier request is sent to Google Ad Manager). This user also visits pages on the site that cause her PPID to be added to the basketball fanatics segment (segment S1), and to see line items targeted to this segment. The user then signs out of her account, but continues to browse the site. She is no longer eligible to view ads targeted to segment S1, unless she satisfies S1's membership criteria under her secondary identifier.

Frequency capping

If a multi-identifier request is received, only the primary PPID is considered for the calculation of frequency capping. Any secondary identifier passed in the request will not be considered for this purpose.

Example

A different user visits the sports site from the previous example, and he is currently signed in to the site (a multi-identifier request is sent to Google Ad Manager). This user views a line item L that is capped at one impression per 24 hours. The user then signs out of his account, but continues to browse the site. He is able to see L once more, which then triggers the frequency cap based on his secondary identifier.

Sequential creative rotation

If a multi-identifier request is received, only the primary PPID is considered to identify the next creative in a sequential rotation to serve. Any secondary identifier passed in the request will not be considered for this purpose.

Example

A different user visits the sports site from the previous example, and she is currently signed in to the site (a multi-identifier request is sent to Google Ad Manager). This user views (once) a line item L that has creatives C1 and C2 set for sequential creative rotation. The user then signs out of her account, but continues to browse the site. The next time the user views L, she will see creative C1 again (based on her secondary identifier).

Data transfer reporting

Data transfer reporting is available to Google Ad Manager 360 publishers only.

Both identifiers passed in multi-identifier requests flow through to data transfer reporting, but they are reported in an encrypted fashion. It is not possible for a publisher to reverse the encryption process (restoring the PPID or the secondary identifier to their original form). However, these encrypted identifiers can be batch uploaded to audience lists for later remarketing/targeting.

Example

A different user visits the sports site from the previous example, and she is currently signed in to the site (a multi-identifier request is sent to Google Ad Manager). The user's identifiers flow through to the corresponding data transfer reports. An encrypted representation of the user's primary PPID identifier appears in the PublisherProvidedID field, and an encrypted representation of the user's secondary identifier appears in the UserId field.

 

Was this helpful?
How can we improve it?

Need more help?

Sign in for additional support options to quickly solve your issue

true
Search
Clear search
Close search
Google apps
Main menu
Search Help Center
true
148
false