Measure what matters, not everything

The default analytics setup measures everything and answers nothing. Dozens of dimensions, hundreds of automatic events, and a dashboard so dense you close it without learning a thing.

A better habit: decide the question first, then track the two or three events that answer it. Everything below is that idea applied.

Start from the question, not the event

The failure mode is instrumenting first and hoping insight falls out later. It does not, because a number only means something next to a decision you were going to make anyway.

So write the question down before you write any code. “Is this launch working?” is a question. It maps to a small set of events:

window.sonex.track("signup", { plan: "pro" });
window.sonex.track("cta-click", { position: "hero" });

Now the funnel from visit to signup is a straight line you can read in one glance, and you know in advance what a good result looks like.

Contrast that with the usual approach: enable everything, then go looking. You end up with three hundred events, no baseline, and no idea which of them was supposed to move.

The four numbers most sites actually need

Before any custom event, four numbers cover most decisions:

• How many people came. The trend matters far more than the absolute value.
• Where they came from. Referrers and campaigns tell you which of your efforts is working.
• What they read. Top pages tell you what your site is actually about, which is often not what you think.
• How many did the thing. One conversion number, defined by you.

If you cannot articulate why a fifth number would change what you do next week, you do not need the fifth number yet.

Declarative when it is simpler

For a button, you do not need a script at all. Annotate the markup:

<button data-sonex-event="cta-click" data-sonex-event-position="hero">
  Start free
</button>

The extra data-sonex-event-* attributes ride along as event properties. This matters more than it looks: instrumentation that lives next to the element it measures does not rot when someone redesigns the page, because the person editing the markup can see it.

Analytics code that lives in a separate file quietly stops matching reality within about two redesigns.

Name events like you will read them in a year

You will. Pick one shape and hold to it:

• One casing, everywhere. Most analytics tools treat event names as case-sensitive, so Signup and signup become two rows that never add up.
• Verb-noun, past tense, lower kebab-case: signup-completed, checkout-started, trial-expired.
• Put the variable part in properties, not in the name. cta-click with { position: "hero" } stays one event you can total. hero-cta-click, footer-cta-click and sidebar-cta-click are three events you now have to remember to add up by hand.

The same discipline applies to campaign tagging — inconsistent casing in UTM parameters splits one campaign into several rows for exactly the same reason. If you tag links by hand, a UTM builder that normalises casing for you removes the whole class of problem.

Prune on a schedule

Instrumentation accumulates. Once a quarter, open the event list and ask of each one: has this changed a decision since I added it?

Delete what has not. This is not tidiness for its own sake — on a tool that bills per tracked event, unread events are a line item, and a shorter list makes the events that matter easier to find. An analytics setup should get smaller as your understanding of the product gets better, not bigger.

Fewer, sharper signals

Three deliberate events beat three hundred automatic ones. They load faster, they respect the visitor, and they leave you with a dashboard that answers the question you opened it to ask.

That is the whole point of sonex: fast to insight, quiet by default. Read custom events for the full API, or what the numbers count if you want to be precise about what a visit, a visitor and a view each mean here.