There is an almost reflexive habit in data engineering: whenever you instrument an event, you attach a user ID. It feels natural. User IDs are how you join tables, track behavior, and measure engagement. The problem is that most teams attach them without ever asking whether they actually need them.

That habit is becoming expensive. Data privacy laws are tightening across every major market, and the organizations feeling the most pain are not the ones that made deliberate choices about what to collect. They are the ones that collected everything and are now facing the consequences of cleaning it up.

The Real Cost of Cleaning Up Later

When a privacy requirement surfaces after a data system is already built, the remediation touches every layer. It is not just the raw event tables. It is the aggregate tables built on top of them, the reporting layer built on top of those, and the dashboards that query the reporting layer. A PII field that was collected casually at instrumentation time has to be removed from every place it landed.

Projects like this require a dedicated team, separate compute and storage infrastructure so daily production workloads are not disrupted, and months of data migration and validation work. Most engineers find this kind of project deeply unrewarding. There is no new capability being built, no metric being improved. It is pure remediation, and it consumes significant engineering capacity.

All of it is avoidable with the right conversation at the start of a project.

Start With What the Metric Actually Needs

Before instrumenting any event that involves user identification, the right question to ask is what the downstream metric actually requires. In most cases, teams reach for a user ID out of habit when what they really need is a count of unique entities, not the identities of those entities.

Take daily active users as an example. The standard query looks something like this: count distinct user IDs from the daily fact table for a given date. The user ID is used as a proxy for uniqueness, but uniqueness is the only thing the metric needs. The actual identity of each user is irrelevant to the calculation.

Once you recognize that, two better approaches become available.

Approach One: Pseudonymization

The first approach is to replace direct user IDs with pseudonymized identifiers. Instead of storing the actual user ID in your data warehouse, you store a surrogate value that represents the same user consistently but cannot be resolved back to an identity without access to a separate mapping system.

The mapping system itself is kept separate and access-controlled. Data engineers and data scientists doing analysis never need to see the underlying user IDs. They can still perform joins, filters, and aggregates using the pseudonymized value, which is all the pipeline actually requires. The link between the surrogate and the real identity exists only in the mapping layer, and that layer supports both real-time processing and batch backfill jobs so it works across different pipeline architectures.

This approach meaningfully reduces exposure. Even if the data warehouse were compromised, there is no direct path from the data to the identity of any individual user without also compromising the separate mapping system.

Approach Two: Remove Unique Identifiers Entirely

The second approach goes further. If the goal is to avoid storing any personally identifiable information in the data warehouse at all, the right question to ask stakeholders is whether the analysis can be done without any persistent user identifier.

For many common metrics, the answer is yes. Session IDs, which are typically generated by the client and scoped to a time window such as 24 hours or a few days, can often serve as a sufficient proxy for uniqueness. A daily active user count built on distinct session IDs rather than user IDs still captures engagement trends and adoption curves without any PII in the dataset.

The tradeoff is worth understanding clearly. Session IDs inflate unique counts because a single user can generate more than one session within a reporting period. If the session lifetime is 24 hours and a user returns on day 14 after the session has expired, they get counted twice. For trend analysis and directional metrics this inflation is usually acceptable, as long as the caveat is communicated to stakeholders upfront. The numbers are consistently inflated in the same direction, which means trends are still meaningful even if absolute values are not precise.

For organizations where even pseudonymized identifiers are considered too much risk, this approach gives the analytics team the data it needs to do its job without the warehouse ever holding anything that could be traced back to an individual.

Make This Decision at the Start, Not the End

Both of these approaches work best when they are built into the initial project scoping conversation. Before instrumentation begins, the data team should sit down with product managers, data scientists, and business stakeholders and work through exactly what each metric needs to be useful. In most cases you will find that the analysis can be done with less sensitive data than everyone assumed.

That conversation is not just good privacy practice. It is good engineering practice. It reduces the surface area of your data collection, simplifies your schema, and eliminates a category of risk that would otherwise sit quietly in your warehouse until a legal or compliance question forces it to the surface.

Organizations that build these habits into their data culture end up in a much stronger position when privacy regulations evolve, audits happen, or legal questions arise. Instead of scrambling to understand what was collected and where it ended up, the answer is already clear: we only collected what we needed, and we can demonstrate exactly how we handled it.