Custom events: measuring what actually matters in your business

Every analytics tool ships with the same default events: page view, add to cart, begin checkout, purchase. They're the right events for a generic ecommerce store, which is to say they're the right events for nobody in particular.

The events that predict a sale in your business are usually more specific, and almost always unmeasured — which means the experiments that could move them are unmeasurable too.

The question to ask is: what does a customer do on our site that makes them dramatically more likely to buy?

For a furniture brand it might be opening the dimensions tab — people who check whether it fits are people who are seriously considering it. For a fashion brand, viewing a second colourway. For a B2B tool, visiting the pricing page twice. For a supplement brand, reading the ingredients panel.

These are rarely obvious from the outside and they're easy to find from the inside: look at what converters did that non-converters didn't. Even a rough comparison on a few hundred sessions will surface one or two behaviours that stand out.

That behaviour is your leading indicator. It happens far more often than purchase, which makes it a viable primary metric on small traffic, and it's specific to how your customers actually decide.

The sample-size problem is a frequency problem. Purchase might happen 40 times a week on your site. "Opened the dimensions tab" might happen 400 times.

An experiment measured on the second reaches a conclusion ten times faster. That's the difference between a test you can run in three weeks and one you can't run at all.

The condition is that the event genuinely predicts the outcome. If dimension-tab openers convert at 12% and non-openers at 2%, moving that behaviour is worth something. If both convert at 3%, you've found a busy-work metric and optimising it will produce exactly nothing.

Check the correlation before you build on it. It takes one query and it saves you a quarter.

The usual blocker is that adding an event means a ticket, a deploy and a wait. That's how sites end up measuring only what the platform gave them for free.

In Bixlow you describe the event in the chat — "record an event when someone opens the dimensions tab on a product page" — and it generates the workflow with the selector and the trigger. You review the blueprint, publish, and the event is available as a metric on your next experiment. If the selector it chose is fragile because your theme renames classes on build, you fix it in the editor.

The practical consequence is that instrumenting a new metric stops being a project. You can go from "I wonder whether people read the ingredients" to having three weeks of data in an afternoon.

The opposite failure is equally real. A site with sixty custom events has an analytics implementation nobody maintains, half of which broke on the last theme update and none of which anyone looks at.

A useful rule: an event earns its place if you can name the decision it would inform. "We'd know whether to move the size guide up" is a decision. "It might be interesting" is not.

Start with two or three. Add one when a specific question needs it. Delete the ones nobody has looked at in six months, and make sure someone checks periodically that they still fire — a silently broken event is worse than no event, because it looks like a real zero.

Custom events are close, frequent and easy to move, which is exactly the profile of a metric that can be gamed without helping the business. Everything from the guardrail article applies with extra force here.

If your primary is "opened the dimensions tab", your guardrail is revenue per session. A variant that gets more people poking at tabs while fewer of them buy is a loss dressed as a win.

• The events that predict a sale in your business are specific to it and usually not tracked by default.
• A frequent leading indicator makes experiments viable at traffic levels where purchase never would.
• Verify the correlation with conversion before building on the event. Uncorrelated metrics are busy work.
• Two or three events you can name a decision for, not sixty nobody maintains.