If It’s Worth Building, It’s Worth Measuring

Most websites do not get measured properly. Not because anyone decided measurement was a bad idea, but because the site was never the thing that paid the bills. Until it was.

This is more common than anyone will admit, and I see it across very different businesses. A brand that does most of its volume through retailers but runs its own online store on the side. A wholesaler selling in bulk through distribution, with a small D2C shop bolted onto the website. A manufacturer whose orders come through a sales team, with a spare-parts store almost nobody in the building thinks about. In each case the real money moves through channels that have nothing to do with a browser. The website got built once, looked fine, and then mostly looked after itself. It’s a presence, not a pipeline.

So nobody loses sleep over it. And because nobody loses sleep over it, nobody ever asks the obvious question: is this thing actually working?

I keep running into sites that have run for years with no real measurement in place. Usually the analytics is installed and never configured past the default, which amounts to the same thing. The business kept selling, the site kept sitting there, and the whole time it was a black box. Money may have been moving through it. Customers were certainly passing through it. But what those customers did, where they gave up, and whether any of it was worth the effort was completely invisible.

If that sounds familiar, this post is for you.

Every other digital channel comes with analytics built in. Your website doesn’t.

If the website is your primary channel, you are probably already across this. Your revenue depends on it, which tends to focus the mind.

But most businesses run more than one channel, online and off. A sales team, a wholesale arrangement, an email list, paid ads, a social presence. And here is the thing about every one of those digital channels: the analytics come built in. Your email platform tells you open rates and click rates. Your ad platform tells you impressions, spend, and return. Your social channels have dashboards. You did not have to set any of that up. The platform has a commercial interest in showing you what it is delivering, so it does.

Your own website is the exception. It is the destination all those channels point to, and it is the one place in the stack where measurement is entirely your responsibility. Nobody is going to instrument it for you. When someone clicks through from a campaign and lands on your site, that is where the trail goes cold unless you have set something up deliberately.

A measurement plan is how you close that gap. And the good news is that it is not complicated.

What a measurement plan actually is

A “measurement plan” sounds like a bigger and more boring thing than it is.

A measurement plan is not a dashboard, a monthly report or analytics software. It is a short document that answers two questions:

1. What do we want this website to do for us?
2. How will we know whether it is doing it?

That is the whole thing. Everything else is detail.

The reason it matters is that without it, you measure whatever the software hands you by default. Analytics tools will happily tell you how many people visited and how many pages they looked at. That is a visitor counter. It tells you the building has foot traffic. It tells you nothing about whether anyone bought anything, abandoned a cart halfway, or walked out the door frustrated.

The decisions live in the actions, not the visits. So the measurement plan starts with the actions.

How to build one

Step one: list what matters. Write down the three or four things you actually want someone to do on your site. Not everything. The handful that represent real value. For an online store this is some version of: buy something, add something to the cart, start a checkout, or join the mailing list so you can sell to them later.

Step two: trace the path to each one. For each action, sketch the steps a person takes to get there. To buy, they have to find the product, add it to the cart, start the checkout, and pay. Keep it simple. You are looking for the moments where people drop off, because those are the ones you want to fix.

Step three: mark what you can track. Each of those steps is a candidate to measure. A page view. A button click. A cart action. A completed purchase. This becomes your list of events: the specific things you want the analytics to watch for.

Put it in a small table. Something like this:

What we want	How we will know	Notes
Someone is considering a product	Product page viewed (view_item)	Close to automatic, but worth confirming
Someone shows real intent	Item added to cart (add_to_cart)	Needs setup, will not track itself
Someone starts to buy	Checkout begun (begin_checkout)	Needs setup
Someone completes a purchase	Purchase, with order value (purchase)	If checkout runs on a third-party domain, this is where the trail breaks unless cross-domain tracking is setup.

That table is your measurement plan. It is also the brief you hand to whoever does the technical work.

One note on how these get captured. Most events can hang off a page view. If completing an action lands the customer somewhere specific, an order confirmation page for instance, the page view itself is the event, and that is the simplest version to set up. You only need to attach an event to a button when there is no page to catch it, or when you want to know exactly which button they clicked to get there, not just that they arrived.

This is also where plans go wrong in the other direction. I have seen plenty that tag everything in sight when the path is a straight line with no other way through. If there is only one route to the confirmation page, you do not need an event on every button and page along the way. The confirmation page view already tells you the journey finished. Tagging every event of a linear path top to bottom just buries the numbers you actually care about under a pile of events nobody will ever review. If Button A is the only way to get to Page B, just tag Page B.

The exception is if you are seeing significant drop off between the start and end points, or you have a process that runs across several screens, a multi-step checkout or a long form. There, each screen is a place someone can give up, so a marker on every step earns its keep, because seeing exactly which screen loses people is the entire point. The rule underneath both cases is the same: measure the moments where someone can drop off.

The funnel is where your revenue is hiding

If you are selling online, the single most useful thing to measure is the funnel: the path from browsing to buying, and the people who fall out of it at each step.

It runs in stages. Someone views a product. Some of those people add it to the cart. Some of those begin the checkout. Some of those finish and pay. At every step you lose people, and the gaps between the steps are where the money is hiding. A big drop between add-to-cart and checkout points at something in the cart experience. A big drop between checkout and purchase points at the payment step: a shipping cost that surprised them, a form that is too long, a payment method they wanted that you do not offer. When you recover this revenue, it’s like finding cash between the couch cushions. It was always there, you just didn’t know until you looked.

You cannot fix any of that until you can see the shape of the funnel. Once you can, the analysis almost does itself. Find the biggest leak, fix that one first, measure again. That loop is the entire job.

GA4 has these stages built into its ecommerce spec, the view_item, add_to_cart, begin_checkout and purchase events from the table above. The valuable part is that each one can carry the product and the price, so you are not just counting actions, you are seeing revenue, average order value, and which products actually sell versus which ones just get looked at.

Here is the catch, and it is the thing people most often get wrong: none of this is automatic. The basic page tracking switches itself on. The ecommerce funnel does not. GA4 does not “do ecommerce” out of the box. Someone has to implement those events deliberately, which is exactly why you want them written down before anyone starts.

Know what needs code before you ask anyone to write it

Here is something worth knowing before you ask anyone to build anything.

Some of what you want, the analytics will pick up on its own once it is switched on properly. Page views, scrolling, outbound link clicks, file downloads. Modern analytics has a feature, usually called something like Enhanced Measurement, that captures these automatically. You can turn it on yourself. While you are in there, set your data retention to the longest the tool allows and mark your important actions as conversions. None of that requires code.

The funnel is the part that does. The ecommerce events are not free, and there are two specific traps to know about.

The first is third-party checkout. Plenty of stores hand the final step to someone else: a hosted checkout, a payment provider, a separate cart system on its own domain. When that happens, you can watch someone add to cart and begin checkout on your site, and then they vanish at the exact moment they become worth money, because the purchase completes somewhere your analytics cannot see. Closing that gap is real work and needs to be asked for.

The fix is cross-domain tracking: your analytics needs to be told to follow the customer from your domain into the third-party checkout and back. It is a developer task, it requires access to both sides of the handoff, and it needs to be in the brief explicitly. If your developer does not know it is needed, it will not get done.

The second is modern web frameworks. To increase performance, your site may handle page navigation and form submissions without triggering a full page reload. GA4’s default tracking fires on page load – so if there is no page load, there is no event. Page views, form submissions, cart actions can all go unrecorded.

The fix is custom triggers: a developer needs to set up listeners for the framework’s own events and wire them to GA4 manually. This is not an edge case. It affects any site built on a modern stack and needs to be in the brief.

This is exactly why the measurement plan earns its place. Without it, you go to your developer and say “set up analytics,” which is vague enough that you will get the default install and not much else. With it, you hand over a specific list: these events, here is what each one means, here is which ones need building by hand and which ones break at the checkout handoff. The work is scoped, you know what you are paying for, and nothing important gets quietly missed.

Make the decision. Then start.

The honest reason most sites go unmeasured is that nobody ever made a clear decision about them. The site was worth building once, so it got built. After that it drifted into the category of things that are maintained but not examined.

You do not need the website to be your primary channel to justify understanding it. You need a few hours, a willingness to switch some settings on, and a one-page plan that says what good looks like.

If the site is worth keeping online, it is worth knowing what it does. And if it is worth building, it is worth measuring.

If you need help scoping or implementing a measurement plan, get in touch.