Over 30 million sites use Google Analytics, so many brands no doubt have the same question: is Google Analytics PDPA compliant?
The answer is "yes", but you should ask for consent first.
To make your GA usage PDPA-compliant, then, there are a couple steps you need to take, which are detailed below. The information pertains specifically to Google Analytics browser/website tracking - not to Google’s Firebase SDK, a tool for in-app analysis.
Please note, we are not a law firm. Please view this as informational, not legal advice, and speak to a lawyer before coming to a conclusion.
Table of Contents:
1. Google Analytics and PDPA - what’s the issue?
2. Do you need consent for web analytics cookies?
4. Honoring the data rights
5. Limiting what you share with Google
What is PDPA, and why should I care?
Thailand’s new PDPA, or Personal Data Protection Act, is a comprehensive, opt-in data privacy law that guarantees individual rights to more than 48M Thai internet users (70% of its total population). It’s Thailand’s first consolidated privacy law and shares many of the same principles as the GDPR.
For a detailed overview, read our PDPA summary.
Google Analytics is a free website tool that collects anonymized data on site visitors, aggregates it, and offers reports on where the traffic is coming from, what pages they browsed, for how long, etc.
As such, since you are sharing your visitors’ PII with a third-party, this is information you must disclose to users.
The answer is likely "yes" - since it involves the collection/sharing of PII - but do know there's no 100% clear answer to this, as Google Analytics is not mentioned in the text.
Regardless of whether you choose to ask for consent or not, there are still steps you need to take to be fully compliant. Those actions are listed below.
Understanding the PDPA’s data rights isn’t difficult: if they ask to delete or see their data, you must do it. This includes any Google Analytics data you or Google has on them.
What’s more complicated is figuring out how to honor that request from a technical standpoint. Even this is doable, though, and below lists multiple ways to delete or access their GA data.
To access the data Google Analytics has on the user:
First, ask the user to provide their Google Analytics ClientID. To find this, they’ll need to go to their browser’s settings and manually look at what cookies are stored. They should find one named
_ga, which is the Google Analytics cookie, and within it is a string like
The user’s ClientID are the numbers before and after the final period (in this case,
318596131.1556642125). If they have multiple
_ga cookies on their browser, they should send all of the ClientIDs.
If you are relying on UserIDs instead of ClientIDs (the differences are here), then you must grab the ID yourself (for instance, if you know their email and have their UserID tied to it).
Next, use Google's User Explorer Report to pull any data associated with this ClientID or UserID, and then send that user this information.
Alternatively, you could use Google's User Activity API to pull the data. The API Response will look like:
To delete their data:
- Tell them to clear any
_gacookies on their browser. This would delete their cookie’s ClientID
- If you are storing a UserID tied to them, delete it
- Ask them for their ClientID (see above) and use Google's User Explorer Report to see what data Google has stored on them. In the report you'll see a 'Delete User' button in the bottom left panel. Google says that after you press this, the user's data is removed from the report after 72 hours, but it could take up to two months for the data to be deleted from their servers.
Alternatively you could use Google's User Deletion API and their ClientID/UserID to delete any data Google has on them.
Without doing this step, Google would store that user's data for 26 months, violating the PDPA deletion request. So you must manually delete their data via one of these steps should they request it.
To stop their data from being shared with Google at all:
This would be applicable if you are asking for consent before sending the user's anonymized data to Google. In this case, you would need to block the GA tag for non-consenting users.
|Use a third-party consent management platform||Work with a CMP that prompts for consent on page load, has a toggle option for Google Analytics, and can then block the GA tag if no consent is given.|
|Use your own consent tool||Build your own prompt. If the person doesn't consent to GA, you could write custom code that prevents the GA code from appearing on the page. Alternatively, you could use Google’s User Opt Out instructions to dynamically block their data being sent to Google.|
|Have them install the GA Opt-Out browser extension||Direct users to the Google Analytics Opt-Out browser extension. When enabled, the GA tag does not fire for the user across any site.|
Step #3: Have a data breach plan
What happens if Google Analytics somehow gets breached? Google would send an email to you first, but it’s on you to then contact your affected users. If you don't already have a plan in place, the UK’s Information Commission Office has a great guide on what you need to do. It was created for the GDPR but is just as applicable to the PDPA.
Fortunately, Google has been very proactive in regards to these laws, as noted in their security compliance page. Their actions include:
- Updating their GA Terms of Service to explain how they are a data processor
- Implementing a 24/7 Data Incident Response Process to assist with any potential data breaches
- Getting all the major security certifications (full list here). They also are certified members of the Privacy Shield Frameworks
- Writing up guidance on avoiding PII
Nonetheless, there are still actions to take to limit what data you send Google.
- Sign Google's DPA - Extremely important! Go to Admin → Account Settings and accept the Data Processing Agreement. DPAs are required from all Data Processors; otherwise, sharing data with them violates the PDPA
- Review your integration with Google Analytics for PII leakage - For instance, if you are sending internal UserIDs to Google, make sure they are anonymized and not actual PII, like an email. Also check that you aren’t appending PII to URLs, such as `https://email@example.com` after a form fill-out, as they would be sent to GA
- IP Anonymization - This removes the last octet of the IP Address before it’s sent to Google (aka 123.456.789.555 becomes just 123.456.789.0, which helps anonymize who it is)
- Reduce Data Retention Length - By default, Google Analytics stores data tied to an ID for 26 months. You can change this to 14 months in Admin → Tracking Info → Data Retention if you wanted to be more strict (the lowest option available)
- Turn 'Reset on New Activity' off - In the same spot as above, there is a toggle called 'Reset on new activity'. While this seems to be privacy-focused, it really just extends how long you track them, as every new time they visit your site, the 14 month retention period resets
- Disable Demographics and Interests Reports - Under Admin → Property Settings → Advertising Features, turn this off to prevent Google from making reports around user info
- Data Deletion Requests - Monitor your Data Deletion Requests tab in Admin. Google will flag any instances where it finds PII, and you’ll need to delete them as needed
- Turn Off Data Sharing - With Google Analytics, a lot of information is shared with other services. If you go into Account Settings -> Data Sharing, you can turn off these settings
- Unlink Google Ads / Ad Exchange - If you use Adwords/Adsense/Google Ads Manager, you may have set up linking between the two platforms. Under Admin --> Product Linking, you can turn this off, further limiting what data leaves GA (though this would impact your ad campaign efforts)
- Turn off Remarketing & Ad Reporting - Under Admin → Tracking Info → Data Collection, you could turn off Remarketing and Advertising Reporting Features, an additional way to limit what's shared
- Limit the Session Settings time - Under Tracking Seetings --> Session Settings, you can edit the timeout time for individual sessions and campaigns. For instance, if you set the session timeout to 5 minutes, that means that after five minutes of inactivity, that SessionID on the user is no longer tied to anything
- Reduce Cookie Expiration Time - Unless cleared, the `_ga` cookie lasts on the user’s browser for 24 months. Fortunately, you can set this expiration period to whatever you want via the `cookieExpires` parameter in the GA tag. For instance, hardcoding it to `0` turns it into a session-based cookie, and the ClientID will expire when they exit the site
To use Google Analytics and stay PDPA compliant, you'll need to:
- Ask Thai users for consent before dropping the GA cookie
- Have a process for deleting/accessing the user’s Google Analytics data upon request (instructions above)
- Have a data breach plan
- Sign Google’s DPA
- Limit the data you are sending Google by following the steps listed above
Of course, further rulings may make this information obsolete, so we’ll track and report on any obvious changes.
Are you ready for the PDPA? Join the discussion below to share your experiences with data compliance.
Join the Ad.Product community
Sign up for our monthly newsletter and to be notified of member-exclusive events and opportunities.
Ad.Product is the first community for product managers, engineers, and others to discover and discuss how to build innovative, user-first ad platforms.