About publisher provided identifiers
This feature might not be enabled in your network.
Table of contents
The Publisher provided identifier (PPID) allows publishers to send Google Ad Manager an identifier for use in frequency capping, audience segmentation and targeting, sequential ad rotation and other audience-based ad delivery controls across devices. PPID is not currently supported in Google Ad Manager's reach reporting or conversion tracking.
This identifier is used alongside any other identifiers that are available to Google Ad Manager, such as cookies. The identifier must be hashed, anonymous, and must not contain any personal information, third-party identifiers or device IDs.
If a user has opted out of personalized ads via Ads Settings, features permitting the use of PPID for targeting ads to the user's web browser will be disabled. If using PPID in a server-side ad serving setting the user must have access to a mechanism to opt out of interest-based advertising. If a user opts-out of the publisher's use of PPID in connection with advertising, or deletes his or her account, the publisher must immediately stop sending Google the PPID associated with that user.
Setting the identifier
Google Publisher Tags
For websites, use the
Method details for
Sets values for publisher-provided ID for use in frequency capping and other audience-based activities.
string identifier: An alphanumeric ID provided by the publisher with a recommended maximum of 150 characters.
Google Mobile Ads SDK
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.
HTML5 - ima.ImaSdkSettings.setPpid()
iOS - IMASettings.ppid (mutable object property, not a method)
- Android - ImaSdkSettings.setPpid()
Non-JS request (aka Tagless Request)
Requests made directly to Google Ad Manager using
/ad+/jumpcode> must include a parameter
Audience Solutions pixel tags
Requests made directly to Google Ad Manager using Audience Solutions pixel tags must include the parameter
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]).
A minimum of 32 characters.
A maximum of 150 characters.
Consistent across devices.
Hashed and meaningless to Google—do not send any PPID to Google that belongs to a third party or that Google could use or recognize as personally identifiable information or as a Google+ identifier.
Only sent when the user can be identified by the publisher. The publisher should not send a value in cases when the user cannot be identified.
- Representative of a 1-to-1 relationship with a signed in user across multiple visits; not newly generated for each user visit.
- In addition, identifiers may be deleted if their total number within your network exceeds certain limits.
Google Ad Manager behavior for requests with multiple identifiers
As previously mentioned, the PPID supplements, rather than replaces, other identifiers used by Google Ad Manager (e.g., 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.
A user visits a sports site or app that supports PPID, but is not logged 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 logged in, the secondary identifier is added to the audience segment. The user subsequently logs 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.
A different user visits the sports site from the previous example, and she is currently logged 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 logs 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.
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.
A different user visits the sports site from the previous example, and he is currently logged 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 logs 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.
A different user visits the sports site from the previous example, and she is currently logged 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 logs 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
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.
A different user visits the sports site from the previous example, and she is currently logged 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