The Record of What You Did
Friday's article on what your data export contains listed thirty-six sections and called one of them the least expected: product events, the record of what you did in the app. That is a fair description and a vague one. This is the precise version, read out of the code that writes the record rather than the code that exports it.
What One Row Holds
A product event is one row per thing that happened. Not one row per message, and not the message; one row per kind of thing, with a name from a fixed list. Each row can carry:
| Field | What it is |
|---|---|
| The event name | Which thing happened, from a fixed vocabulary the server enforces (more on that below) |
| When | A timestamp |
| Who | Your account id if you were signed in, otherwise an anonymous id the page keeps in your browser; and a session id that lasts one visit |
| Where | The page address and path you were on, cut to a fixed length |
| Context | Which role or companion the event concerned and your tier at the time, when the page supplies them |
| How you arrived | Campaign tags from the address you came in on, the click ids advertising networks attach, and the referring site, kept only when it was not our own |
| A purchase key | A key used to discard a duplicate row for the handful of events that are purchases, and nothing else |
| Details | A small bag of extra properties, which is the part worth the rest of this page |
What It Cannot Hold
The interesting rules are the refusals, and they happen twice: once in your browser before anything is sent, and again on the server before anything is written.
The page only forwards named keys
The function that sends an event does not pass along whatever it was handed. It copies a short list of known property names, one list of strings, one of numbers, one of true-or-false flags, and drops everything else. A string is cut to two hundred characters before it leaves. If some part of the app tries to attach a property the list does not name, it is silently discarded.
The server keeps a list of allowed event names
An event whose name is not on that list is not recorded at all, and the list is fixed in code rather than open-ended. As of the day this published it holds a hundred and fifty-one names, which is a smaller number than it sounds once you notice most of them describe a checkout step, a tutorial step or a screen being shown.
The server strips what looks like you
Before a details bag is stored it is checked again. A blocked list of keys is thrown away outright: name, email, phone, address, date of birth, message, text, content, body, password, token, secret and the address you connected from. Any string value that contains something shaped like an email address is thrown away too. Strings are cut to two hundred characters, at most ten keys are kept, and a bag over four kilobytes is dropped entirely rather than trimmed.
So the honest description of the details bag is: short labels, counts and flags, chosen from a list, with anything that resembles an identifier removed before it lands. That is what the code enforces, and it is enforced on every event that comes from a page.
The One Exception
A few events are written by the server itself rather than by a page. Most of them carry the same shape of thing, an id, a count, a label: which tier a checkout was for, how many preview messages remained, which reason a message was locked. Two are worth naming because they are the only places the record holds more than that.
When an email is sent to you, the delivery event keeps a redacted form of your address, so the record can show that a message went out without storing where. And when a message is flagged for moderation review, the event keeps a short excerpt of the flagged text, at most a hundred characters, alongside the review's own notes. That is the single place in this record where a fragment of something you typed can end up, and it is there so that a review can be checked afterwards. Your privacy, your control is the policy-level statement of why review exists at all.
Why we are not writing "never"
An article about a record that quietly holds more than it says would be the worst possible version of this page. We read every writer before saying what the record contains, and one of them keeps an excerpt. Saying so costs a cleaner sentence and buys a true one.
The Switch That Governs It
Whether a page sends any of this depends on where you are, and it would be dishonest to write it any other way. If the consent script has placed your browser in the European Union, the United Kingdom, the rest of the European Economic Area or Switzerland, nothing is sent unless you accepted analytics in the consent prompt; the sending function checks that stored answer and returns before it builds a row. Everywhere else the record is kept by default, without a prompt, which is exactly why it is worth knowing how narrow it is. Sending is also rate-limited on the server per address and per session, so a page that misbehaves cannot flood the record, and the anonymous id is a random value your own browser made up and keeps, not anything derived from you.
How to Read Your Own
It is in your export, as a section of the same name, one row per event, newest first. Because the vocabulary is fixed and the details are short, it is one of the more readable sections: you will see screens you opened, purchases you made and tutorial steps you completed, and you will not see a line of conversation in it. If you do, that is a bug and we want to hear about it.
The short version
One row per kind of thing you did, with a name from a fixed list, where you were and how you arrived, and a small bag of labels and counts that the page pre-filters and the server strips again. Nothing you typed, with one deliberate exception for moderation review; kept by default in most of the world, and in the regions with a consent prompt, not kept at all unless you said yes.
Take a Copy and Look
Settings, then Your Data, then Download my data. The product events section is the one this page describes.
Open Your Dashboard