Anonymization

Analytics tables carried names, email addresses and phone numbers for a long time. They were copies of the signup records, so of course they did. The problem is how many people in a company need those tables to do their jobs. Someone after a single churn rate ended up looking at the contact details of thirty thousand customers.

Plenty of teams get as far as labeling which columns hold personally identifiable information (PII) and narrowing who can read them. That is where they stall. Tighten the permissions and analysis stops; run the analysis and the permissions have to open again.

In practice it showed up like this. A marketer asks for a list of everyone who cancelled last month, an engineer runs the query, downloads a CSV and sends it over chat. The file has names and emails in it, and it stays on somebody's laptop long after the analysis is done. A month later nobody knows how many copies exist or where.

Anonymization changes the question being asked. What churn analysis actually needs is not who cancelled but how many accounts of each kind did. The starting observation is that the information analysis runs on and the information that identifies a person are not the same, and the work is pulling the two apart.

Start by going through the table column by column and pulling out the ones that point at a person. There are five steps.

1. List the identifiers. Name, email, phone number and account ID are direct identifiers: each one singles out a person by itself. Date of birth, sex and postal code are quasi-identifiers — thousands of people share any one of them, which is exactly why this group gets missed. Put three of them together and the set often narrows to one person.
2. Decide how much of each column to keep. If the analysis needs age brackets, the date of birth can be cut down to the birth year. If it compares regions, a province is enough and the street address is not. Everything past that line gets dropped.
3. Pick a method per column. Common ones are deletion, masking that keeps only the edges of a value (010-****-1234), generalization that folds values into ranges (34 becomes "30s"), and hashing, which replaces a value with one that cannot be computed backwards.
4. Decide whether you still need to count the same person across rows. Answering "how many times did one customer pay?" requires knowing that two rows belong to the same person, even without knowing who that is. For that, the account ID is swapped for an arbitrary value and the mapping table is stored separately. Because the mapping still exists, this state is pseudonymous rather than anonymous, and the law still treats it as personal data.
5. Check whether the rows can be re-identified. Count how many people fall into each combination of the remaining columns, and where a combination holds only one or two people, blur that column further. If "born 1995, female, one city district, Pro plan" matches two accounts, roll the location up from district to city.

Finally, pin the procedure into a pipeline. Stripping columns by hand on each request means the rules drift every time, and on a busy day one column gets missed. Build the processed table once, point the analytics tools at that table only, and take back read access to the raw one. How far each column gets blurred follows the rules set in data governance.

It fits aggregate work well. Churn by plan, feature usage frequency, anything that counts people in groups works without knowing who anyone is. Data handed to an outside party, sample data for sales demos, the test database developers work against, and records under long retention all belong here too.

It does not work when you have to get back to the individual. Answering a support ticket means reading that person's usage history, and personalized recommendations or email sends need to know who is receiving them. Those flows are handled with access control and encryption instead. Encryption is built to give the original back to anyone holding the key, which is a different goal.

There are two limits. The first is that information is lost. Blur a date of birth down to the year and a birthday campaign by month becomes impossible forever. Once the detail is gone there is no way back to it.

The second is that identity can come back. Hashing is a one-way computation, but for a column with a limited set of possible values — phone numbers, for instance — hashing every candidate and comparing produces the original. A hashed phone number is therefore not anonymous. That distinction matters because pseudonymous data still carries rights like the right to erasure, while fully anonymized data falls outside such a request because there is nothing left to erase.

"Analyst accounts only see the anonymized tables. Raw access is a separate request."

Everyday analysis and looking at personal data have been split onto two different paths.

"This is only hashed, so I wouldn't call it anonymized."

The data is still reversible, so it has to keep being handled as personal data.

"Run the demo sample through anonymization before you export it."

Real customer data has to be processed before it leaves the company.

At Pagedeck this started when Ravi, the growth marketer, asked for a list of accounts that cancelled over the past six months so he could look into why. Theo built a table without names or emails and rounded the signup dates to the week. Mia counted the rows by plan and region, found groups of three accounts, and rolled the region column up from district to city.

When Grace asked to reuse the same table on a screen for an investor meeting, Theo could say yes on the spot. That is what the work buys. The procedure lives in the pipeline, so nobody has to check what was stripped each time.

The most common mistake is thinking the job is done once names and emails are gone. People learn that a name is what identifies someone, so it's a natural assumption. But the combination of the remaining columns stands in for the name. Signup date, plan, region and device type together often narrow to a single account. Treat that state as non-personal data and share it outside, and a leak of it is a leak of personal data.

Believing that hashing makes data anonymous has the same root — it was described as a computation that can't be reversed. In practice, a one-way computation and an unrecoverable value are two different things. Mobile numbers come from a fixed set of possible values, so computing all of them produces a lookup table. Miss that difference and pseudonymous data gets treated as anonymous, which ends with someone answering an erasure request by saying there is nothing to delete and being proven wrong later.