Almost every company has analytics installed. Almost none can answer the question that counts: which channel produced the last ten inquiries, and what did each of them cost?
The reason is rarely the tool. It is the order in which the setup came to be: first the tool, then at some point the question of what it was supposed to measure. This text describes how we do it the other way round — and which mistakes we find most often in existing setups.
First the question, then the event, then the tool
A usable tracking setup starts with a list of decisions you want to make. Not with a list of things that could be measured.
Typical decisions: which channel gets more budget next month? Is the landing page worth it, or should it go? Do the good inquiries come through the form or the phone? Each of those questions needs exactly the data that answers it — and nothing beyond that.
From there come the conversion steps: the three to five actions that actually mean money. Form submitted. Callback requested. Appointment booked. Proposal downloaded. Only once those steps are named does an event plan follow, and only then is a tool configured.
Mistake 1: counting what is easy to count
Page views, time on page, scroll depth — all of it is switched on in two clicks and says almost nothing about whether a visit becomes an inquiry. A report showing those numbers looks like activity and enables not a single budget decision.
The fix is reduction. Fewer events, but the right ones. A setup with four cleanly defined conversions is worth more than one with forty automatically collected interactions.
Mistake 2: the thank-you page as a conversion
The classic: the conversion is placed on the view of the page /thanks. That counts every reload, every back-click, every bot and everyone who opens the URL from history. Depending on the site, twenty to forty percent of those "conversions" are not.
Clean is an event fired at the moment of successful submission — confirmed server-side, not just on the button click. Done properly, a unique ID goes with it so the same inquiry can be recognised later in the CRM.
Mistake 3: the source gets lost along the way
Someone clicks an ad, reads two pages, comes back three days later via search and sends a form. The CRM then says "source: website". The ad click that triggered it has vanished.
The problem sits in the handoffs. Campaign parameters have to be stored on the first visit and passed along on submission — not only as an analytics event but as a field that arrives in the CRM. Without that chain nobody can say which channel produced a won inquiry, and every optimisation runs on leads instead of revenue.
Mistake 4: consent drops events and nobody notices
Since consent came before tracking, every setup is missing part of its data. That is unavoidable and fine. What is not fine is a setup that does not know about it: events fire into the void before consent, are missing after it, and the numbers in the report fluctuate with the consent rate without anyone knowing the cause.
We build the chain so events respect consent and are loaded cleanly only afterwards. And we document what share of visitors is visible at all — so a conversion rate is not compared against a number that came from a different base.
Mistake 5: double and triple
A tag manager container in which three generations of marketing managers left their tags. The form event fires twice, once from the container, once from the plugin. Google Ads receives conversions from two sources and counts both.
The fix is unglamorous: a single place where events are defined, a naming convention understandable without explanation, and a regular look at the debug view to check that exactly one event arrives per action.
Server-side, when it counts
Ad blockers, tracking protection in Safari and Firefox, shortened cookie lifetimes — the share of visitors a purely browser-side setup cannot see grows every year. For ad platforms that means they optimise against an incomplete picture.
A server-side setup passes conversions from your own server to analytics and ad platforms instead of hoping the browser does it. It is more work to build and pays off from the moment ad budget is involved. For a site without campaigns it is usually unnecessary.
Important: server-side does not mean "without consent". Consent applies just the same. What changes is the reliability of transmission after consent.
What a report has to do
In the end a report has to trigger a decision. Per channel, that means:
- number of inquiries in the period
- cost per inquiry
- share of inquiries that became a job
- from that: cost per won job
Everything else — impressions, clicks, click-through rate — is diagnosis for when one of those four numbers goes off track. It does not belong on page one.
Where you can start
- Write down the three actions that actually bring you money.
- Check in the debug view that each of them fires exactly one event — after consent, not before.
- Look at your CRM: do the last ten inquiries carry a source that says more than "website"?
- If any of those checks fails, that is the starting point.
How this ties in with SEO and campaigns is in SEO for more inquiries. If you want to know what your current setup can actually tell you, write to us briefly — a tracking audit is usually the fastest route to an answer. More on the SEO & Analytics page.
