User properties vs. event properties
Traits that stick to a person (plan, country, signup date) versus details attached to a single action (button, price). Two different buckets.
See it
What it is
A user property lives on the person record and gets overwritten: plan tier, company size, signup date, current country. An event property lives on one action and is frozen the second it fires: which button, which price was shown, which search query. Most tools keep the two in separate calls, so identify() sets user properties and track() sends an event with its own properties (Amplitude, Mixpanel, PostHog and Segment all work this way).
Quick test for which bucket something belongs in: if you would ever ask 'how many users have this' or slice a whole chart by it, it is a user property. If you would ask 'what was going on during this specific action', it is an event property.
Gotcha: how much history a user property keeps is a tool and query decision, not a universal rule. Some tools stamp person properties onto each event as it arrives, so a breakdown reflects what was true back then. Others store only the current profile, so flipping someone from free to pro makes every event they ever sent report under 'pro' and quietly rewrites your past. Several offer both and let you choose per query (PostHog's person-properties mode is the obvious example). Find out which one you are looking at before you trust a historical breakdown. The safe move either way: when the value matters at the moment of the action, stamp a snapshot on the event too (plan_at_event), which is the fix for the classic 'why did last quarter's numbers change' mystery.
Ask AI for it
Design the analytics schema for [feature] and split it into two explicit lists. List A: user properties set with identify(), one row per trait, with type and example value, covering durable traits like plan, signup_date, company_size and locale. List B: event properties sent with each track() call, giving the event name in snake_case plus 3 to 6 properties that describe that specific action. For any trait that can change over time and would distort historical reporting, also snapshot it onto the event (for example plan_at_event) and say why. Output both as markdown tables, no prose.