Quick answer
A data dictionary is a reference document or table that lists every field in a dataset or system and records, for each one, its name, plain-language meaning, data type, allowed values, source and owner.
What is a data dictionary?
A data dictionary is a reference that lists every field in a dataset and explains it: what the field is called, what it means, what type of value it holds, which values are allowed, where it comes from and who owns it. It turns a column called plan_t into "the subscription plan at the time of the event: free, pro or business".
What each entry should contain
| Column | Example |
|---|---|
| Name | plan |
| Description | Subscription plan of the account when the event happened |
| Type | String (enum) |
| Allowed values / format | free, pro, business |
| Required | Yes, on subscription_started |
| Source | Sent from the server at checkout |
| Owner | Billing team |
| Sensitivity | Non-personal |
| Example | pro |
A sample dictionary for analytics events
| Event | Property | Type | Allowed values | Required | Description |
|---|---|---|---|---|---|
signup | method | string | email, google, github | Yes | How the account was created |
signup | referrer_code | string | 8 characters | No | Invite code, if any |
purchase | revenue | number | ≥ 0, project currency | Yes | Order total after discounts |
purchase | order_id | string | Billing system id | Yes | Also used as the deduplication key |
report_viewed | report | string | overview, pages, sources | Yes | Which report was opened |
(Illustrative entries.)
Data dictionary vs related documents
| Document | Describes | Typical owner |
|---|---|---|
| Data dictionary | Fields inside a dataset: meaning, type, rules | Data owner or analyst |
| Schema | The technical structure a database enforces | Engineering |
| Data catalog | An inventory of many datasets, with search and lineage | Data platform team |
| Tracking plan | Events you plan to collect, their properties and status | Product analytics |
| Business glossary | Business terms such as "active customer" | Business and data teams together |
For product analytics, the tracking plan and the data dictionary overlap: the plan says what should be sent, the dictionary describes what is stored.
Keeping it current
- No field without an entry. Add dictionary review to the same checklist as code review.
- Generate what you can. Types and recent values can be scanned automatically; meaning and ownership cannot.
- Retire dead fields. Mark fields that stopped receiving data as deprecated rather than deleting the entry.
- Flag personal data. A dictionary is the natural place to mark which fields identify people; this feeds data governance.
The property dictionary in TapCub
TapCub's property dictionary (All-platform analytics › Data › Property dictionary) scans person profiles, event properties from the last 7 days and account traits. It infers a type for each key and classes it as a direct identifier, an indirect identifier or non-personal; direct identifiers are masked in lists and exports by default. Once you edit a type or class and save, later scans do not overwrite it. Event definitions, with descriptions and required properties, live on the Definitions tab of the event inbox. See also event property.
See also
Was this explanation clear?
We use your answers to fix and expand this page.
Couldn’t send. Please try again in a minute.
Thanks for the feedback. We’ll use it to improve this page.You’ve already sent feedback on this page. Thanks.
Technical Engineer
Focuses on tracking code, SDKs, and API integrations, with practical guidance on implementation checks and troubleshooting.