Which events to track in your SaaS (start with twelve, not two hundred)

The hard question is not which events to track in your SaaS. It is which events to leave alone. Most teams do not fail by tracking too little. They turn on autocapture, collect two hundred event types nobody named, and end up with an event list they cannot read and a set of numbers they do not trust. Then they make the call on instinct anyway. This guide argues for the opposite: a deliberately small starter set, roughly a dozen events, each tied to a decision you will actually make this quarter.

The failure mode is tracking everything, not tracking too little.

It feels responsible to capture as much as possible. Storage is cheap, autocapture is one line of setup, and you tell yourself you will figure out what matters later. The problem is that later never comes with a clean slate. You come back to two hundred event types with names like button_clicked and element_viewed, three of which mean roughly the same thing, and no way to tell the pricing call to action from a footer link.

That noise has a cost you pay twice. You pay for it in storage or plan pricing, because most tools scale with the volume of data you send. And you pay for it in decisions you never make, because a report you do not trust is a report you do not open. A founder with twelve events they understand is in a far better position than one with two hundred they are afraid to interpret. Tracking less is not laziness. It is the thing that makes the data usable.

Start from the decisions, not the events.

The reliable way to arrive at a short list is to work backward. Do not start with a catalog of possible events. Start by writing down the two or three questions you actually need answered in the next quarter, then derive the events that answer them. Almost everything you need falls out of three recurring questions.

Are new users reaching value? That question needs signup_completed and your core action completed, so you can see the funnel from account to first real use. Which paying users are about to leave? That needs the absence of core_action_repeated, plus payment_failed and subscription_canceled. Where does revenue expand? That needs limit_reached and plan_upgraded. Three questions, and you have already derived most of a starter set without once opening a list of two hundred candidate events.

Twelve events cover most of a SaaS.

Here is a concrete starter set for a typical SaaS. The names use one consistent grammar, an object followed by a past-tense verb in snake case, so the list stays scannable as it grows. Adapt the names to your product, but keep the grammar fixed. The full case for a naming convention lives in the guide to event tracking naming conventions. What matters here is that each event earns its place by giving you one metric you will actually look at.

Notice what is not on the list: pageviews of every screen, every button, every hover. The core_action_completed event is the important one. It is the basis of your activation rate, and it is worth defining precisely rather than settling for "logged in". The mechanics of turning that event into a number are covered in how to measure user activation.

What not to track yet.

The events you skip are as deliberate as the ones you keep. Three categories are worth naming so you can recognize the temptation. First, pageviews of every internal screen: the settings tab, each sub-tab, each modal open. Autocapture will grab all of them, and almost none change a decision you make. Second, micro-interactions: every dropdown open, every field focus, every hover. Third, vanity clicks: "opened the menu," "clicked the logo." They inflate your event count and tell you nothing about whether the product is working.

The reason to hold off is not just cost. It is that a noisy event stream quietly erodes trust in the numbers that do matter. When your event picker has three hundred entries, the twelve that would actually inform a decision are buried, and cleaning it up later is worse than never capturing it, because dashboards and automations already reference the noisy names. You can always add an event the day a question needs it. You cannot easily un-instrument two hundred of them once your reports depend on the mess.

Add a property before you add an event.

Most of the pressure to grow your event list is a property in disguise. You do not need payment_failed_visa and payment_failed_mastercard and payment_failed_expired. You need one payment_failed event carrying a card_type property and a decline_reason property. The event name stays stable, the detail rides along in properties, and your automations and reports can branch on the property when they need to.

This one habit is what keeps a dozen events from becoming sixty. Before you name a new event, ask whether the thing that changed is really a new action or just a new variation of an existing one. A card that expired and a card that was declined are the same event with a different reason. A trial signup and a paid signup are one signup_completed with a plan property. Reach for a property first, and reach for a new event only when the action itself is genuinely new.

Expand only when a real question is unanswerable.

A short starter set is a starting point, not a cage. The rule for growing it is simple and strict: add an event only when a real question about your product cannot be answered with the events you already have. If someone asks how many users have tried the export feature and you cannot tell, that is a legitimate reason to add export_completed. "We might want it someday" is not.

Speculative instrumentation is exactly how teams end up back at two hundred events. Every "just in case" event is one more line in a picker nobody reads and one more thing that can drift out of sync with your code. Let real questions pull events into existence. When you do add one, name it with the same grammar as the rest and, ideally, watch it in your analytics for a couple of weeks before you build anything on top of it, to be sure it fires when and how you expect.

Every event you track is also an email trigger.

Here is where the small-set argument pays off in a way that is specific to how GetFluxly works. Because analytics, customer profiles, and email automation live in one tool, the same twelve events do double duty. They are the metrics on your charts and the triggers for your lifecycle email at the same time, with no second schema to maintain and no events to sync between systems.

The core_action_completed event is your activation rate on a chart and the entry point for your user activation email. The payment_failed event is your involuntary churn number and the trigger for a dunning sequence. The limit_reached event is upgrade intent in a report and the trigger for an upgrade nudge sent within minutes. Choosing events for the decisions they inform and choosing them for the emails they fire turns out to be the same exercise. If your goal is the email side specifically, the companion guide to product event tracking for email automation walks through the trigger setup in detail.

Which events to track, answered.

Which events should I track first in a SaaS?

Start with the events that map to decisions you already make: whether new users reach value, which users are about to leave, and where revenue expands. In practice that is roughly a dozen events: signup_completed, onboarding_completed, your core action completed and repeated, project_created, invite_sent, integration_connected, limit_reached, plan_upgraded, payment_failed, subscription_canceled, and support_requested. Name them with one consistent grammar and instrument those before you add anything else.

How many events should a small SaaS track?

Fewer than most teams expect. A dozen well-chosen, consistently named events cover the questions a small SaaS actually asks in a given quarter. The failure mode is almost never tracking too little. It is tracking hundreds of auto-captured events, ending up with a picker you cannot read and numbers you do not trust, then making decisions on gut feel anyway. A short list you look at beats a long list you ignore.

Should I use autocapture and track everything?

Autocapture is useful for a quick first look, but leaving it on for everything creates noise you pay for twice: once in storage or plan cost, and once in the decisions you avoid because you do not trust the data. You end up with hundreds of auto-named event types where a single button_clicked could be the pricing call to action or a footer link. Capture the events you named on purpose, and use autocapture only to explore before you decide what deserves a real name.

When should I add a new event versus a new property?

Add a property first. If you are tempted to create payment_failed_visa and payment_failed_expired, that is two properties (card_type and decline_reason) on one stable payment_failed event, not two new events. Properties carry the detail while the event name stays clean, which keeps your list of a dozen events from quietly becoming sixty. Add a genuinely new event only when a real question about your product is unanswerable with the events you already have.

What is minimum viable analytics for a SaaS?

Minimum viable analytics is the smallest set of events that lets you answer the two or three questions you need answered this quarter, and nothing more. You write the questions down first, then derive the events from them, rather than instrumenting everything and hoping a question emerges. It is deliberately small because a set you review weekly and trust is worth more than a comprehensive set you never open. You expand it only when a real decision is blocked for lack of data.

The teams that trust their analytics are usually the ones that track the least. They wrote down the questions first, derived a dozen events from those questions, and left the other one hundred and eighty alone. Twelve well-named events you review every week will do more for your product than two hundred you are too overwhelmed to open. Start small, name things consistently, and add the next event only when a real decision is waiting on it.