Sending PII (personally identifiable information) to Google Analytics, Adwords or Remarketing can get your Google account suspended. A common scenario is for an email address to be passed in the query string by a CRM or Email Service Provider. But what if you need that to happen for business reasons, so it’s not an option to suppress the inclusion of that data getting passed in to your website?
Furthermore it can be hard to detect what you’re actually sending to Google using their own tools like the Google Tag Assistant, and the preview mode of Google Tag Manager.
When we first faced this challenge and the threat of suspension by Google we tried several things, like this approach from Simo Ahava to remove PII from Google Analytics. But Google kept telling us our Remarketing and Adwords were still receiving PII, which we eventually determined was because the raw URL was also being sent to those two regardless of what we tried to feed to them as “location” values and such through Google Tag Manager.
But finally our team member Jose Oronoz, with the help of Simo Ahava’s post on the Google Tag Manager History Listener, came up with a way to overwrite the URL stored in the browser history before any other calls are made, so there’s no chance of sending any PII to any external services. The approach uses a custom event trigger firing on the gtm.load event and then it searches for and replaces any PII and overwrites the value the browser stores using the history.replaceState method of the HTML DOM.
After implementing this solution our clients were cleared by Google.
Here’s a step by step explanation of how to implement this using Google Tag Manager.
Create a Custom Event Trigger
Create a new trigger of type “Custom Event”:
Then in the Trigger configuration set the “Event Name” to “gtm.load” which will result in this trigger firing every time Google Tag Manager is fired:
Create a New Custom HTML Tag:
Now we’ll create a new Tag of type “Custom HTML” and connect our trigger to it:
It will look like this:
We set our “Tag Firing Priority” to 100 to make sure it got priority to fire before any other tag:
Then in the “Triggering” section choose the Trigger you created in the previous step:
Verify PII is Being Removed
The final step is to test the removal of PII using the Google Tag Assistant - in our case we were removing the key “email” so we append a simple “email@example.com” to the URL of one of our websites running Google Tag Manager to see what the Google Tag Assistant will pick up:
Submitting that request to the website, and with Google Tag Manager in “Preview” mode, we see that our script is triggered in the windows load event, removing the email before any other tags fire:
Once you confirm that the script is being executed in the windows load event, you can review the values being sent to Google Analytics and Remarketing, using the Google Tag Asistant extension:
To check the URL being sent to Google Remarketing, click on “Remarketing Tag”, and then click “Requests”:
Then click on the URL and confirm that the PII you entered on the URL in the browser has been removed:
Wait For Your Policy Breach Resolved Email
Then hopefully a few days later you will receive a Policy Breach Resolved notice from Google, and you can breathe easier:
Some businesses have good reasons for passing personally identifiable information between various systems, and there are reasons that data can’t be passed via POST or easily encoded at origin. If you find yourself in this situation with Google please add your voice to ours in asking them to think about why they would suspend paying merchants for data that Google’s own scripts are sending. Instead of hacking the DOM history to get this done, Google’s scripts should be updated to only pass data that can be controlled within Google Tag Manager or by configuration changes to the tags themselves.
Please drop us a line if this helped you!