In the interests of protecting end user privacy, Google's ad 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)
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.
Check the form method
Look at the form HTML for method="get". If no method is defined, the default method is get. In most cases, this can be checked by viewing the source code.
In addition, when the form is submitted, the entered values will show in the post-submit page's URL.
Solution: update your form method
Update the form tag to use method="post" instead of get. Be sure to validate that the form continues to work as expected after this change is made.
URL schemes
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 "My Settings" page with a URL such as: site.com/settings/[email protected].
Ads on the resulting pages could end up sending Google the PII from such URLs.
Check URLs for PII
Navigate around the site and observe the URLs for PII. The most common pages with PII in the URL string include profile pages, settings, account, notifications/alerts, messaging/mail, registration/signups, login, and other links that appear to be associated with the user's information.
Solution: replace PII with UUIDs
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, site.com/settings/[email protected] could be changed to site.com/settings/43231, where 43231 is a number that uniquely identifies the account with address [email protected].
Links in emails
Email is often used for verification as part of site registration and sign up processes. Some of these verification emails include PII in the confirmation/registration link. For instance, site.com/[email protected]&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.
Check emails for PII
Sign up for an account. Check if the URL in the verification/confirmation email includes the email address or other PII.
Solution: update the URL scheme
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
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.
Run reports to check key-values
Run a report in your ad server for the values of the key-values targeting field. Check the source code of your pages to see what you are collecting in the key-values in your tags.
Solution: remove targeting parameters
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.