What is event tracking?
Event tracking is the practice of recording the specific actions people take in a product or on a site as named events, each carrying properties that describe the action and the person, so a team can count what happened, group it, and turn those raw actions into funnels, retention, and paths instead of only knowing which pages loaded.
What is the difference between an event and a pageview?
A pageview is the narrowest kind of event: it fires when a URL loads and tells you which page someone saw. Count pageviews and you know your most-visited pages, your referrers, and your traffic over time. That is web analytics, and it is genuinely useful, but it stops at the page boundary.
A tracked event is any action you name: signed up, added to cart, invited a teammate, hit the aha moment, upgraded. These are the moments a business is actually built on, and none of them are a page load. Two users can view the exact same pages and one converts while the other bounces; only events tell them apart.
So the pageview is a subset of the event, not a rival to it. You want both: pageviews to see how people arrive and move, named events to see what they do and whether they stick. smolanalytics captures both from one snippet, so a referrer, a first click, and an eventual upgrade live on one timeline instead of in two tools that never agree.
What are event properties?
An event on its own is just a count. Properties are the attributes that make it answerable. There are two kinds, and both matter.
Event properties describe the action: { plan: "pro", value: 49, source: "email" } on a checkout_completed event. User traits describe the person and carry across their events: signup date, country, current plan. Because the event holds the first and the user id ties in the second, you can slice one event a dozen ways.
Properties are what turn "how many signups?" into "which plan converts best, from which source, in which country?" without adding a new event for every combination. The discipline is the same as with names: pick property keys once and keep them stable, or your breakdowns fragment.
Autocapture vs manual track(): which should I use?
Events reach a tool two ways, and the honest answer is that you use both, for different jobs.
Rule of thumb: let autocapture cover pageviews and clicks for free, then hand-place a track() call on the ten or so events that feed your funnels and retention. Breadth from the snippet, precision from the calls.
How should I name events?
Naming is the unglamorous part that decides whether your data is usable a year from now. A report is only as clean as the event names feeding it, so the goal is one canonical name per real action, forever.
Pick a single convention and never break it. A short verb-object pattern in snake_case works well: signup_completed, checkout_started, teammate_invited. The failure mode is drift, three names for one action (Signed Up, signup, user_signed_up) that split one funnel into three and quietly corrupt every count.
Write the convention down, keep a short list of the events that matter, and use event properties instead of new event names whenever you can (one checkout_completed with a plan property beats checkout_pro and checkout_team as separate events).
How smolanalytics does event tracking
smolanalytics captures events from one snippet or one endpoint and turns them into web and product analytics. The mechanics are deliberately small:
- 1Autocapture plus track(). The snippet autocaptures pageviews and clicks on day one, and you call track() for the key moments (signup, activation, upgrade) with names and properties you control. Breadth and precision from the same install.
- 2One endpoint. Every event, from the browser or from your server, goes through a single POST /v1/events. Client and server actions keyed to the same user id join into one timeline, one funnel, one retention curve, so payments and provisioning the browser never sees still land in the same report.
- 3Ask, do not build. Once events are flowing, you type "where do trials drop off?" into a dashboard bar, or into your own Cursor / Claude Code over MCP (47 tools, 13 prompts) using your own AI model, so the AI part is free. Answers are computed from deterministic reports, never generated by an LLM, and a CI agreement test fails the build if the AI answer ever differs from the dashboard.
- 4One binary. It is a single MIT-licensed Go binary, stdlib only, roughly 7 bytes per event, no Kafka, ClickHouse, or Postgres to run. Cookieless mode means no consent banner. Self-host it free forever, or use the hosted cloud.
It deliberately does not do session replay, feature flags, experiments, heatmaps, or surveys. It is for teams who want a straight, owned, cheap answer on what to fix. See every feature, the product analytics those events feed, or the install docs.