Analytics Setup That Answers Questions Instead of Collecting Numbers

Configure analytics from your decisions backwards. List the questions you actually act on: where does the funnel lose buyers, which source earns its spend, does mobile need work before desktop, which page should this month's change touch? For each question, name the count that answers it, the segment it must be split by, and the report you will open. Then set up exactly those events and views, verify them with a test order and a test enquiry, and write the definitions down. A setup built this way is small, accurate and used. A default setup is large, approximately accurate and ignored, which means the business is steering by memory while paying attention rent to a tool it never opens.

Write the inventory honestly, from your calendar rather than your aspirations. Most small businesses make six recurring site decisions: where to spend the month's improvement time, whether a campaign earned its cost, whether a change is kept, which product or page gets attention, whether a problem is mobile or general, and when something is broken rather than merely quiet. Each maps to a small set of counts: step rates, source tables, device splits, page-level funnels. Anything your inventory does not need, from scroll-depth vanity metrics to forty automatically collected events, can be left unconfigured without loss. The inventory also exposes the missing decision: if nothing on the list uses revenue per session, do not build your setup around it.

Mark as key events only the actions your funnel is built from: the purchase or qualified enquiry as the macro conversion, plus add-to-cart, checkout start, signup or form start as supporting steps, following the definitions in the foundations work. Use the platform documentation for your analytics tool to set them, since event names, key event settings and funnel report mechanics change between versions: Google Analytics support is the reference for that stack. Resist marking everything important. A key event list of fifteen teaches the reporting to treat a brochure download like a sale, and every downstream rate inherits the confusion. Few, defined once, and never quietly redefined is the whole discipline.

The two splits you will need on almost every number are device and source, so make them one click away in the reports you keep: saved comparisons or a small set of standard views you always open in the same order. Note how your platform counts: sessions or users in the denominator, how direct traffic is assigned, what a test order looks like in the data. Write those conventions beside the event definitions, because a rate is only interpretable with its denominator attached. This paperwork feels excessive in the setup week and priceless in the argument six months later about whether mobile really fell or the counting changed underneath it.

Never trust a fresh setup until you have watched your own actions land in it. Place a test order on a phone, submit a test enquiry, abandon a cart, sign up with a test address. Then check each event appears once, in the right report, with the right value or none, and that staff and test traffic can be filtered or at least recognised. Repeat the verification after theme changes, app installs and platform updates, because tracking breaks silently at exactly those moments. The guide on tracking traps lists the failures this routine catches. Fifteen minutes of controlled actions is the difference between a measurement system and a hope with a login.

Analytics alone cannot say why, so decide at setup time which question instruments the stack includes: session recordings on key pages, one post-purchase question, perhaps a short on-site survey on a page with a known puzzle. Configure their sampling and consent behaviour at the same sitting, using the comparison in choosing behaviour tools, rather than bolting tools on mid-argument later. When each layer is installed to answer a named question, the weekly routine in from data to decision can move between them without friction. When they are installed because they were free or fashionable, they produce three more dashboards nobody opens.

A setup is correct for a business at a moment. A new product line, a move into services alongside products, a second traffic source that matters, or a platform migration all change the decision inventory, and the setup should be reviewed against it, briefly, whenever one lands and at least annually. Delete events and reports the inventory no longer uses; an analytics account accumulates the archaeology of past intentions, and stale reports get quoted by accident. Keep the definitions document versioned with dates, so a change in counting is visible as a change. The goal across years is boring and rare: a small stack whose numbers mean the same thing this year as last, serving decisions its owner can name.