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.
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 methodLook 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 methodUpdate 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.
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/sample@email.com.
Ads on the resulting pages could end up sending Google the PII from such URLs.
Check URLs for PIINavigate 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 UUIDsIn 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/sample@email.com could be changed to site.com/settings/43231, where 43231 is a number that uniquely identifies the account with address sample@email.com.
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/confirm?email=sample@email.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.
Check emails for PIISign up for an account. Check if the URL in the verification/confirmation email includes the email address or other PII.
Solution: update the URL schemeSolution: 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 purposesOften, 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-valuesRun 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 parametersRemove 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.
Was this helpful?How can we improve it?
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.3