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 held a hundred and fifty-one names, and a hundred and sixty-three as of September 26, 2026, 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. Three 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. When a check-in email's invisible image is loaded, an opened event records which check-in it was, how long after sending the image was fetched, and the first hundred and twenty characters of the user-agent string it was fetched with, the label a mail app or a mail provider's image proxy announces itself by; it is often a machine, not you. 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. Since the day this published there is also a switch of your own: Settings, then Privacy, then Product Analytics, which stops the record for your account on every device you sign in from; and a browser that sends the Global Privacy Control signal is treated as switched off without you touching anything. Both are checked before a row is built, and the server checks them again before it writes one. 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.
The switch and the signal govern what pages send, and only that. The events the server writes itself, the ones in the previous section, are part of running the service and are kept whatever the switch says. The check-in email's opened event is one of them: to stop it, block remote images in your mail app, or turn check-in emails off.
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. What pages send is kept by default in most of the world, not kept at all in the consent regions unless you said yes, and off everywhere the moment you flip the switch in Settings or your browser sends Global Privacy Control. The few rows the server writes itself, a check-in email being opened among them, are kept regardless.
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