Amplitude

## Amplitude's data model in one paragraph Amplitude is a product-analytics platform whose entire storage model is an event stream keyed by user. Every row is an event with a name (`event_type`), a timestamp, an identity (`device_id`, `user_id`, or both), and two dictionaries of key/value pairs: **event properties** and **user properties**. Everything the product does — funnels, retention curves, behavioural cohorts, segmentation — is a query over that stream, so the quality of the answers is bounded entirely by how disciplined those two dictionaries are. ## Event properties: facts about the occurrence An event property qualifies the single thing that just happened. `Song Played` carries `genre`, `duration_seconds`, `is_offline`; `Order Completed` carries `cart_total`, `currency`, `payment_method`. The value belongs to that moment and is meaningless outside it. In the Browser SDK you pass them as the second argument to `track`: ```javascript amplitude.track('Order Completed', { cart_total: 42.5, currency: 'USD' }); ``` On the HTTP API v2 payload the same thing appears as an `event_properties` object on the event JSON. ## User properties: state about the person A user property describes the human, not the click: `plan`, `account_type`, `signup_channel`, `experiment_variant`. You set them through an `Identify` object, whose methods are the whole vocabulary — `set` overwrites, `setOnce` writes only if the property has never been set (ideal for acquisition attributes like `first_referrer`), `add` increments a numeric counter, `append`/`prepend` push onto a list, `unset` removes it: ```javascript const id = new amplitude.Identify().set('plan', 'pro').setOnce('signup_channel', 'organic'); amplitude.identify(id); ``` The HTTP API equivalent is a `user_properties` object, either on a regular event or on an `$identify` event. ## The stamping rule that trips everyone up Amplitude records the user property values that were current at ingest onto each event as it arrives. It does **not** retroactively rewrite past events when a property changes. This is a feature, not a bug: it lets you ask "how did users convert *while they were on the free plan*" rather than only "how did users who are on the free plan *today* convert". But it surprises people who expect a profile-style database where the latest value wins everywhere. If you upgrade a user from `free` to `pro`, every event they sent yesterday still reads `free`, and a breakdown by `plan` will split one human across two series. When you genuinely want current-state segmentation, segment on the user rather than breaking down the historical events, and be explicit in the analysis about which of the two you meant. ## Choosing between them Ask what the value is *about*. If the same user could produce two different values in two events on the same day, it is an event property. If it is a state that persists until something changes it, it is a user property. Two practical constraints sharpen this further: - **Cardinality.** Property values feed dropdowns and breakdowns. Raw identifiers, timestamps, free-text and URLs with query strings blow up the distinct-value count and make a breakdown unreadable. Bucket them (`price_band`, `page_type`) or leave them out of the property and keep them in the warehouse copy. - **Mutability.** A user property you rewrite hourly (say, a live score) turns into a stream of profile updates and makes historical breakdowns noisy; that value usually belongs on the event. ## Groups sit alongside both B2B products often need an account dimension: many users belong to one organisation and the question is about the organisation. Amplitude models that with **groups** — `amplitude.setGroup('org_id', 'acme')` — and group properties that live on the account rather than the person. Group-based analysis is an account-level capability rather than something every project has enabled, so confirm before designing a taxonomy that depends on it. ## Taxonomy is the real interview subject The reason an interviewer asks this is that most bad Amplitude implementations fail on the split, not on the SDK. The standard shape is **few event names, rich properties**: one `Button Clicked` with a `button_name` property beats two hundred bespoke event names, because funnels and breakdowns can slice properties but cannot un-fuse event names. Amplitude ships governance for this — a tracking plan in Amplitude Data with planned-versus-observed schemas, and the Ampli CLI, which generates a typed wrapper from the plan so a typo becomes a compile error rather than a phantom event nobody notices for a quarter. Decide the split once, write it down, and enforce it in code review; renaming a property after six months of collection means either backfilling or living with two names forever.