Most reports we see at a first meeting look fine: traffic is up, impressions are multiplying, time on page is respectable. And then the owner says the sentence that makes the conversation honest: “The numbers look good, but there isn’t more money.”<\/p>\n
This is not a problem with analytics as a tool. It is a problem with an event set assembled on the principle of “let’s have something in place”: a counter was installed, a goal was set on form submission, and the rest was left to automatic collection. That kind of setup describes visitor behaviour reasonably well – and says almost nothing about where the money comes from.<\/p>\n
Metrics like sessions, impressions and scroll depth rise easily without affecting revenue at all. Referral spam, a change in search rankings, one lucky social post, a campaign simply restarted against a broad audience – all of it lifts the chart.<\/p>\n
The danger is not that these numbers are useless. The danger is that decisions start being made on them: scaling a channel that delivers plenty of visits and zero deals, or cutting one that brings five leads a month – all five of which close, at an average order value half again higher than everything else.<\/p>\n
A textbook case from practice: a client spent two quarters increasing budget on the channel responsible for 60% of all traffic. Once CRM statuses were finally connected, it turned out that channel accounted for 8% of revenue. The money was coming from a narrow segment that made up 4% of visits.<\/p>\n
The practical way to build analytics is to start not with tools but with the question “what exactly do we earn on”. Then work backwards along the chain: which customer action precedes payment, which precedes that one, and so on to the first touch.<\/p>\n
For a service business the chain usually looks like this:<\/p>\n
payment \u2192 invoice \u2192 meeting \u2192 qualified lead \u2192 lead \u2192 service or case study page view \u2192 first visit<\/strong><\/p>\n Every step in that chain is a candidate for an event. Anything that did not make it into the chain does not go into tracking. This is the main filter that saves you from a hundred unnecessary events and from a container nobody can navigate six months later.<\/p>\n For most service and B2B sites, seven events are enough. Not seventy.<\/p>\n The last event is the most important and the most frequently missing. Without it you optimise advertising for lead volume rather than for money. The gap between those two strategies is usually measured in tens of percent of budget.<\/p>\n The bare fact “a lead happened” gives you almost nothing. An event starts working when it carries three things with it.<\/p>\n UTM tags, referrer, campaign name – captured at the moment of the first<\/em> visit and preserved through to conversion. If the source is read at the moment of form submission, you will see “direct traffic” where advertising actually did the work: someone arrived from an ad, thought about it for three days, came back by brand name and left a request. Formally that is a direct visit. In reality the ad earned the money.<\/p>\n A single ID understood identically by the website, the analytics platform and the CRM. It is the bridge that carries closed-deal data back to the channel that produced it. Without it, analytics and CRM live in parallel universes and never agree on any figure.<\/p>\n At least approximate. A support request and a build-from-scratch enquiry are not the same event, and collapsing them into a single number means deliberately corrupting your own statistics. If the exact amount is unknown at lead time, substitute the average order value for that service category – that alone is an order of magnitude better than assigning one to everything.<\/p>\n Three channels, the same month, the same budget of 30,000 each. Here is how the picture looks in two different coordinate systems.<\/p>\nThe minimum set that answers 90% of questions<\/h2>\n
\n\n
\n \nEvent<\/th>\n Question it answers<\/th>\n When it fires<\/th>\n<\/tr>\n<\/thead>\n \n form_start<\/code><\/td>\nDoes anyone even begin filling the form?<\/td>\n Focus on the first field<\/td>\n<\/tr>\n \n generate_lead<\/code><\/td>\nHow many leads, and from which source<\/td>\n Successful form submission<\/td>\n<\/tr>\n \n contact_click<\/code><\/td>\nHow many enquiries bypass the form<\/td>\n Click on phone, email, Telegram<\/td>\n<\/tr>\n \n key_page_view<\/code><\/td>\nWhich services actually draw interest<\/td>\n Service or case study page view<\/td>\n<\/tr>\n \n content_engaged<\/code><\/td>\nIs the content read or closed<\/td>\n 60% scroll + 30 seconds<\/td>\n<\/tr>\n \n file_download<\/code><\/td>\nWho is at the evaluation stage<\/td>\n Price list or deck download<\/td>\n<\/tr>\n \n qualified_lead<\/code><\/td>\nHow many leads were real<\/td>\n Status change in CRM<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Three attributes without which an event is useless<\/h2>\n
Source<\/h3>\n
Identifier<\/h3>\n
Value<\/h3>\n
A worked example<\/h2>\n