About personally identifiable information (PII) in URLs

To protect user privacy, Google has specific policies for how advertisers can collect, use, and share personally identifiable information (PII). If Google tags pass any data to Google that could be recognized as PII, we'll send a breach notice to the advertiser and disable the remarketing list and other associated lists, such as custom combination lists or similar audiences, until the advertiser fixes the issue.

This article explains how the process works and how to avoid common scenarios where PII could be shared with Google.

How tags work

When a Google tag on a web page is triggered, it automatically passes the user's current URL to Google. Any tag can potentially collect PII even if the webmaster doesn't explicitly pass that data to the tag.

Google product tags that capture URLs include the Google Ads conversion tracking tag, Google Ads remarketing tag, DFP tag, Floodlight tag, and Google Analytics tag. Note that any tags on pages that have email addresses in their URLs could also be sharing PII with third parties.

Weekly breach notices

Advertisers who are passing PII to Google will receive weekly email messages from ads-noreply@google.com containing a list of URLs and remarketing lists where PII, such as email addresses and passwords, was detected.

For each email, investigate the list of URLs provided to determine the cause of the issue and then respond to our policy team using the form linked in the email. The email will include the specific URL group where PII is being detected, the number of times PII has been detected from a given URL over the past 7 days, and a sample URL corresponding to the URL group where PII was detected. PII is redacted from these samples.

No notifications will appear in the Google Ads interface. Breach notices are sent to Google Ads users with "Administrative" and "Standard" access to the affected accounts. Learn more about access levels in your Google Ads account and how to change your Google Ads sign-in information.

Removing PII in URLs

The best way stop passing PII is to change the way that data is handled in your site. The information below will explain how to keep PII out of URLs.

Note: To protect user privacy, content following a "#" in your URL won't be used for list rule evaluation. 

Avoid tag removal

While you can simply remove the tags that are passing PII, this is not the best solution. Without fixing the underlying issue causing PII to be included in your URLs, any other tags remaining on your site could still collect PII. Though you are not required to place the Google tag on all pages, we recommend doing so to take advantage of the user targeting features across all of your site traffic. If you don't have a tag on a page, you can’t specifically target or exclude users from that page.

Fill out the response form

If you receive a breach notice, it’s important to fill out the form linked in the email. The response form helps Google understand your progress and provide supporting details.

When filling out the form, include the customer ID exactly as it appears in the breach notice email. Then choose one of the three options below.

I took steps to fix the issue. Please send an updated report: If you select this option, the policy team will send an email confirming compliance status within two weeks.

I acknowledge the alert, and I will investigate accordingly: If you are still working on fixing the issue, select this option. The policy team will send you an updated list of URLs every week, to help your efforts to resolve the problem.

I believe I was contacted in error. Please re-review my account: If you select this option, the policy team will review your account again and send you a follow-up message. See the Misidentified PII section below for ways that PII could be misidentified in a URL.

Change how PII is handled

Usually, the only way to resolve the issue of PII in URLs is to change the way your systems handle user data. Below are some of the most common ways to address the problem.

Web forms: HTTP protocol allows forms to be submitted with the GET or POST method, but POST is preferred. If GET is used, the parameters of the form will end up as part of the URL in the address bar (Learn more about the form method). If there are Google ads on the post-submit page, the URL including the form’s parameters will be sent to Google.

Update the page source or the component generating the HTML so that the form tag has method="post" in the attribute. Note that the default method is GET if you don't see any method defined.

Login pages: 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 to the "My Settings" page with a URL like site.com/my_settings/sample@email.com. Ads on the resulting pages could end up sending Google the PII from such URLs.

Links or pages with PII can include profile pages, settings, account pages, notifications and alerts, messaging and mail, registration and signups, login, and other links that are associated with the user's information.

The PII in the URL can usually be replaced with a unique site-specific identifier or a unique user ID (UUID).

Custom email marketing campaign parameters: Custom campaign parameters are often added to URLs to track sources of traffic to your site, such as email marketing campaigns. If your URLs include PII terms as custom campaign parameters (example: site.com/todays_deals/?utm_source=email&utm_campaign_name=todays_deals&utm_user_email=sample@email.com), and the corresponding URLs contain Google tags, those URLs could pass PII to Google.

Send yourself a test email marketing campaign and examine the URLs generated by the campaign to see if email addresses or other PII are included in the URL parameters. If so, try assigning each user a unique site-specific identifier or a unique user ID (UUID) and tracking the UUID through URL parameters.

You can use a UUID in the place of user information to prevent PII from passing to Google. For example, site.com/my_settings/sample@email.com could be changed to site.com/my_settings/43231, where 43231 is a number that uniquely identifies the account with address sample@email.com. You can implement a UUID for a string using libraries available in Java, Python, and other languages.

Verify the solution

After you make changes to your system and respond through the form, Google will validate that your changes have resolved the issue. Within two weeks, you’ll receive another notice to confirm that the issue is fixed or let you know if PII is still being shared from URLs associated with your account.

Check a test site first

If you would prefer to verify that your changes work on a test site before pushing code changes to your live site, you can include your test website in the log scan. Tag your test site with tags from the same Google Ads customer ID that you use for personalized advertising. Once your test site shows up in the log scans we provide to you in email notifications, you can make test changes. If we stop detecting PII from your test site, it will drop off reports. Then you can push changes to your live site.

Misidentified PII

It is occasionally possible for false positives to cause Google Ads to incorrectly identify PII in URLs. If you confirm that you are not passing PII to Google, respond through the form in your breach notice and select the "I believe I was contacted in error" option.

Below are common causes for misidentifying PII.

Site contact email addresses

URLs might contain the advertiser’s business email address, usually the same email address available on the advertiser’s site, which could incorrectly trigger a breach notice.

To check if your site’s contact email address is causing the violation, follow these steps.

  1. Find the "url" and "ref" parameters in the the list of URLs sent in the breach notice. Both parameters should look like URLs. For example:
    url=http%3A%2F%2Fwww.examplesite.com%2Fcontact%2Fredacted@example.com and
    ref=http%3A%2F%2Fwww.examplesite.com%2Fcontact%2Fredacted@example.com
  2. Use an unescaping tool to unescape the URLs.
  3. Compare the URL and the email address to the URL of your site’s contact page and the email address that appears on that page. If the URL and email address match your contact page, you are not sharing PII.

URL stored on a user’s hard drive

Users have the ability to save a part of websites on their hard drive, using the "Save as" command in their browser. If part of the path associated with saving the site includes an email address, it could incorrectly trigger a breach notice.

To check if the user saving a page is responsible for the violation, follow these steps.

  1. Find the "url" and "ref" parameters in the the list of URLs sent in the breach notice. Both parameters should look like URLs. For example:
    url=file%3A%2F%2Fexamplesite.com%2Fpaget%2Fredacted@example.com and
    ref=file%3A%2F%2Fexamplesite.com%2Fpaget%2Fredacted@example.com
  2. Use an unescaping tool to unescape the URLs.
  3. Confirm that the URL looks like the file path from a computer. For example:
    file://examplesite.com/page/redacted@example.com
    If so, you are not sharing PII.
Was this article helpful?
How can we improve it?