Setting it up so it answers something

Most analytics setups are an installation rather than a configuration: the code goes on, the default reports appear, and nothing is ever defined. The result is a tool that can tell you how many pages were viewed and not whether anything happened.

Define the outcome before installing anything

The single decision that makes the difference. Write down the one thing a visit is supposed to produce, specifically enough to be counted: an order placed, an enquiry submitted, a booking confirmed, a file downloaded.

Then the near-outcomes, which are what you diagnose with: reached the pricing page, started the checkout, began the form. These are useful precisely because when the outcome falls, the near-outcomes tell you where.

What to configure, in order

1. 01The outcome as a counted event, fired by the thing actually happening rather than by arriving at a thank-you page, which can be reached and bookmarked without buying.
2. 02Two or three steps before it, so you have a funnel rather than a total.
3. 03Campaign parameters on every link you control: emails, social posts, anything printed with a short link. Without these everything arrives as direct and you cannot tell what worked.
4. 04Filter out your own visits, and anybody working on the site. A small site's numbers are dominated by its owner refreshing pages.
5. 05Check what the tool does with query strings and trailing slashes, because one page appearing as four is the most common reason reports look odd.

Keep the second source

Your own records are the truth: orders, invoices, enquiries in an inbox. The analytics tool is an explanation of how they happened, and it will always disagree with them.

So reconcile once a month, early. Count the orders in your own system and compare with what the tool reports. Establish the ratio while the numbers are small, because once the gap is discovered at scale it is a crisis rather than a known offset.

The things that break quietly

• A site redesign that drops the tracking code from one template. Nobody notices until a monthly comparison looks strange.
• A payment provider that takes the customer off-site and returns them, which can break the chain and attribute the sale to the provider.
• A consent banner installed later, which changes what is collected without changing anything in the reports to say so.
• A new subdomain or a shop on a different domain, which registers as a different site and a referral from yourself.

A monthly reconciliation against your own records catches all four, which is the practical argument for doing it.

Naming things so the reports stay readable

Unglamorous and it decides whether the data is usable in a year. Events accumulate, and a tool with forty inconsistently named events is a tool nobody can read.

• Pick one convention and keep it. Lower case, underscores, verb then noun: form_submitted, checkout_started, guide_downloaded. The convention matters less than its consistency.
• Name the thing that happened, not where it happened. A page can be renamed and moved; the event is still a form being submitted.
• Keep the number small. Five well-defined events beat thirty that overlap, and overlapping events are how two reports give two answers for the same thing.
• Write the list down outside the tool, with one line saying what each means and when it fires. In six months this document is the only thing that makes the data interpretable.
• Do not rename things later. Most tools do not retroactively rename, so a change splits one event into two series and quietly breaks every comparison that crosses the date.

That last point is the practical argument for spending twenty minutes on naming before installing anything: it is one of the few decisions in analytics that is genuinely expensive to reverse.