When the event name is already PII

In week one of the Analytics Data Contract we ask students to paste twenty event names from a live stream, with no properties attached. Then we read them aloud. It is a dull exercise until someone hits order_inv_88421_paid or cs_ticket_6681_opened. Those strings are identifiers wearing an analytics costume.

Schema documentation rarely flags this. Catalog tools that scan column types will happily mark the event name as a harmless string. The harm appears when that string is joined to a user table, exported to a marketing tool, or left in a Looker explore that interns can download.

Why titles get dirty

Engineers name events under time pressure, often by concatenating whatever is in scope: ticket id, invoice number, sometimes a truncated phone. Product managers copy the pattern because it makes funnels “readable” in a debug view. Nobody owns the naming surface, so the pattern spreads.

App analytics data governance has to treat the event name as a control surface, not a comment. If a new analyst can invent a title, they can invent a leak.

A hunt that fits in an afternoon

We use three passes, none of them clever. First, regular expressions for long digit runs, email-shaped tokens, and Thai national-id shaped strings. Second, a human pass for words that imply a person in a sensitive context — symptom, salary, religion, child. Third, a downstream pass: where does this name appear besides the primary warehouse? Reverse-ETL and laptop CSVs are where titles survive longest.

Renaming is the cheap fix. The expensive fix is deciding who may mint a new name. That is an owner-map problem, which is why this essay sits next to our note on owner maps.

What we do not claim

Finding a dirty title is not a PDPA assessment. Deleting it is not a full erasure programme. If counsel asks whether a partner feed still holds the old string, you need lineage, not a blog post. Bring that question to the flagship path or the Governance Desk.

← Journal