A product cannot improve what it cannot see

A team launches a website. People visit, a few sign up, and the team starts changing headlines. It launches a product. People create accounts, and the team starts adding features. The team is working hard on both. Yet it knows too little about what happened between arrival and value.

That missing middle is why analytics matter. A website and a product each make a promise. Analytics show where people encounter that promise, what they try to do, where they struggle, and whether they get the result they came for. Without that view, improvement depends too heavily on opinion, anecdotes, and the loudest request in the room.

On a website, the useful questions go beyond traffic. Which pages bring in people who are a good fit? Do visitors understand the offer? Where do they leave before contacting you, booking, buying, or subscribing? A page can attract a crowd while failing to help the right people take the next step. Another may attract fewer visitors but lead to better conversations. Counting visits alone would make the first page look like the winner. Google Analytics' guidance on lead events^[1] distinguishes a submitted lead from one later qualified as a good fit.

Inside a product, the questions change. Do new users reach the first useful result? Which steps delay them? Do they come back because the product solves a recurring problem, or because a reminder brought them back once? What happens after an error or a failed attempt? Sign-ups describe interest. Activation, successful use, and continued use tell a more complete story about value. The GOV.UK Service Manual^[2] likewise recommends measuring whether people can complete the task a service is designed for, then using research to understand where they leave.

The strongest learning comes when those views connect. Imagine a website that promises to turn a messy weekly report into a clear summary in minutes. Analytics show that many people click through from that promise, but few finish their first report. The marketing page may be doing its job. The friction may sit in the import step, a confusing instruction, or an output that does not match the promise. Looking only at website conversions would miss the problem. Looking only at product completion would miss which expectation brought people in.

This is the beginning of a self-improving loop: observe, explain, change, and check again. First, define the outcome that matters to the person using the system. Then instrument the few steps that lead to it. Look for a specific drop-off or failure, pair the numbers with user conversations or session evidence where appropriate, and form a testable explanation. Make one focused change. Compare what happens afterward with the baseline, including any unintended effects. Where feasible, a controlled test helps separate the effect of the change from shifts in traffic or timing. Keep what helps; revise or roll back what does not. Microsoft Research's experimentation guidance^[3] calls for outcome, diagnostic, guardrail, and data-quality measures rather than one winning number.

For the report product, the team might learn that users abandon the import because the supported file types are unclear. It can clarify the instruction and test whether more users finish a report. But completion alone is not enough. If more people finish while the summaries become less useful, the change has moved a number without improving the experience. The team needs a measure of the result as well as the step.

Analytics do not make a system wise by themselves. Bad event definitions, duplicate events, tiny samples, changing traffic sources, and tracking that misses some users can produce confident-looking nonsense. A rising metric can reflect a seasonal spike, a different audience, or a broken denominator. Teams need clear definitions, privacy-conscious collection, and the humility to treat a chart as a clue rather than a verdict. They also need a way for qualitative feedback to challenge what the dashboard seems to say. Consent rules vary by jurisdiction and technology; the UK Information Commissioner's Office's April 2026 guidance^[4] is one example of why tracking choices need review.

That is why analytics should be designed alongside the website and product, not added after the first redesign. Decide what value looks like. Record the steps and outcomes that would reveal it. Make the data understandable to the people who can act on it. Review it regularly, choose a small number of changes, and keep a record of what was tried and learned.

A website can then get better at helping the right people understand and choose. A product can get better at delivering on the promise that brought them there. When the two are measured together, each improvement teaches the other. That is how a launch becomes a learning system, and how a learning system earns the chance to improve with every cycle.