Understanding Data Redaction in GA4

In today’s regulatory environment surrounding the collection and management of customer data, safeguarding sensitive information is a paramount concern for organizations. As the most widely-used marketing analytics platform in the world, Google Analytics has often been the focus of debate in terms of how customer data should be collected, stored, retained, and used. As we’ve written about previously, Google has launched a variety of privacy-related features in Google Analytics 4 (GA4) which weren’t available in Universal Analytics (UA). Data Redaction is another recent addition to GA4’s privacy features, and represents an important step forward bolstering data privacy. In fact, we would go so far as to say that any client running GA4 client-side should be using Data Redaction. So how does this feature work, and why should  organizations be implementing it?

Understanding Data Redaction

Data Redaction within GA4 serves as a proactive, preventive measure against the inadvertent collection of Personally Identifiable Information (PII) like email addresses and other information that is often found in URL querystring parameters. While Data Redaction is enabled by default in newer GA4 properties, for properties that predate this feature, you’ll want to go in and manually enable the feature. Either way, GA4 Data Redaction operates by analyzing text patterns to identify — and subsequently redact — potential PII across both URL querystring parameters and any GA4 event parameters. This is helpful, as PII (or other sensitive information) present in querystring parameters can easily be passed “downstream” into GA4 event parameters.

Indeed, querystring parameters are probably the single most common sources of PII leakage in data platforms like GA4. For example, when shopping online, you’ve likely seen URLs with parameters like “first_name” and “last_name,” or “email.” There might be perfectly valid reasons for this kind of information to be visible in a URL, but Data Redaction attempts to step in to remove such sensitive information before data collection, helping to promote a more secure analytics deployment.

Without Data Redaction, organizations using Google Analytics (either UA or GA4) have had to rely on “after-the-fact” methods for keeping PII out of their datasets. For example, organizations would commonly rely on data filters — either in GA itself, or in a tag manager like Google Tag Manager — to purge PII from their data. And while we recommend the continued usage of these kinds of filters, the ability to proactively redact such information before it’s ever sent to Google is a welcome complement to those back-end filters.

Benefits of Implementing Data Redaction

Given the above, enabling Data Redaction provides organizations with a few notable benefits:

• PII Protection: Incrementally reduces the risk of inadvertently collecting sensitive information like email addresses.
• Regulatory Compliance: As the risk of inadvertently capturing sensitive information is reduced, the ability for an organization to comply with various data regulations is correspondingly increased. In addition, enabling Data Redaction allows an organization to show that it’s taking proactive steps to safeguard this information, rather than simply relying on a technology vendor to manage this issue for them.
• Operational Efficiency: Because it’s less likely that sensitive information will be inadvertently collected, it’s also less likely that the organization will be subject to “Data Deletion” requests from individuals, which can be challenging to resolve.

Limitations and Considerations

So, while there are some clear benefits to enabling Data Redaction, it’s important to note that Data Redaction currently has some notable limitations:

• Scope: Currently, Data Redaction applies only to web data streams, leaving other data collection methods unaffected. This means, for example, that data you’re pushing into GA4 via an app data stream, via Data Import, or via Measurement Protocol can’t yet be automatically redacted in the way web data streams can.
• Accuracy: Data Redaction occurs on a best-effort basis, and as with most similar tools, may result in inaccuracies or unintended redactions. To minimize the potential for this to affect you, be sure to test Data Redaction before fully enabling it.

How does Data Redaction fit into an overall approach to privacy with GA4?

Data Redaction is just one of GA4’s new capabilities intended to help organizations enhance their data privacy practices. Google has introduced several other privacy-focused features, setting GA4 apart from UA. However, it’s imperative to recognize that while Data Redaction is a valuable tool, it isn’t a “cure-all” for managing data privacy in GA4. Overall, we welcome the release of Data Redaction and strongly encourage organizations to take advantage of it. At the same time, client-side deployments of any analytics platform — whether GA4 or something else — are inherently prone to issues related to privacy, compliance, and governance. For organizations seeking more comprehensive control over data collection, transitioning to server-side tagging is recommended.

As such, we recommend that organizations see Data Redaction as a helpful “patch” on a data collection architecture that likely needs to be rebuilt for the long run. If moving to server-side tagging isn’t on your roadmap for the near future, Data Redaction will at least help you feel a bit more confident that PII and other sensitive information isn’t “leaking” into your instance of GA4.