Ad Manager and Ad Exchange program policies
Best practices to avoid sending Personally Identifiable Information (PII)
In the interests of protecting end user privacy, Google ads product policies mandate that publishers must not pass any data to Google that Google could use or recognize as personally identifiable information (PII). This article addresses some best practices in various aspects of page design to reduce the risk that PII might be in the URL that you pass to Google.
- Form implementation (Use POST rather than GET)
- URL schemes
- Links in emails
- Keywords for targeting purposes
Form implementation (Use POST rather than GET)
Background: HTTP protocol allows forms to be submitted as GET or POST. POST is the preferred 'method' for submitting forms. If GET is used, the parameters of the form will end up as part of the URL in the address bar (detailed explanation). If there are Google ads on the post-submit page, the URL including the form’s parameters will be sent to Google as part of the ad request.
Classification check: The HTML for the FORM tag (visible through view source) will have
method=get. Note that the default method is
get if you don't see any method defined. In most cases, this can be checked by viewing page source. In addition, when the form is submitted, the entered values will show in the post-submit page's URL.
Solution: Update the page source or the component generating the HTML. Update the form tag to have
method=post in the attribute.
Background: Some sites, especially those with user profiles or user login, use URL patterns that include PII as part of the design. For instance, a log-in site might have a link "My Settings" page with a URL like
email@example.com. Ads on the resulting pages could end up sending Google the PII from such URLs.
Classification check: Navigate around the site and observe the URLs for PII. The most common links/pages with PII include profile pages, settings, account, notifications/alerts, messaging/mail, registration/signups, login, and other links that appear to associated with the user's information.
Solution: In most of these cases, the PII in the URL can be replaced with a unique site-specific identifier (background) or a UUID. For instance,
firstname.lastname@example.org could be changed to
43231 is a number that uniquely identifies the account with address
Links in emails
Background: Email is often used for verification as part of site registration/sign up processes. Some of these verification emails include PII in the confirmation/registration link. For instance,
email@example.com&token=413203. If the confirmation page’s URL contains PII and the page hosts ads, PII could end up in the ad requests. This is also found in newsletter signups and forgot password links.
Classification check: Sign up for an account. Check if the URL in the verification/confirmation email includes the email address or other PII.
Solution: The solution listed in the URL schemes section of this article also applies here. The site should remove the PII from the link and use identifiers or tokens to associate the verification email with the user account.
Keywords for targeting purposes
Background: Often, publishers use key-values and keyword targeting to target specific placements on a page or, in some cases, specific users. Because the parameters of keywords and key-values, along with the values passed into the parameters, are chosen by the publisher, publishers must take care to ensure that they do not include PII.
Classification check: Run a report in your ad server for the values of the key-values targeting field. Also, you can check the source code of your pages to see what you are collecting in the key-values in your tags.
Solution: Remove the targeting parameter from both the ad tags and the ad server or change the targeting values so that PII is not passed into the ad request.