Web Analytics

While visitor counts came only from server logs, there was one number and nothing else. Yesterday had 40,000 requests — but how many people that was, where they came from, and what they looked at before leaving are not in that record.

So a warning sign could appear with no way to answer the next question. Signups being down 300 this month is confirmable from payment records, but whether people turned away at the pricing page or gave up on the signup form isn't. In the meeting everyone offers a guess, and the loudest guess becomes next quarter's work.

Running ads in several places adds another layer. When three channels run in the same week and visits rise by 10,000, with no way to divide those 10,000 all three channels report the result as theirs. Web analytics exists to answer both questions by recording visitor movement screen by screen.

What web analytics solves is that nothing records what a person did between arriving and leaving. Four questions actually get answered.

1. Where they arrived from — search, an ad, or a link on another site. Attaching a distinct UTM parameter, the marker appended to a link to distinguish its source, to each ad splits arrivals even within one channel by which creative brought them.
2. What they looked at inside — which pages they passed through and where they closed the window. This is where a sentence like "4,000 people viewed the pricing page and 180 of them reached the signup screen" comes from.
3. Which step lost them — lay the steps out and attach a pass rate to each. Funnel analysis, reading how many drop out at each stage, is the main use of these screens, and the lowest cell becomes the next thing to work on.
4. Which groups behaved differently — split by device, region, and first-time versus returning, then compare the same flow. This is how an overall pass rate that looks unchanged reveals itself as halved on phones.

Installing the tool is quick. Drop one tracking snippet in and visits and page moves start accumulating that day. The time goes into what follows: listing which buttons and screens should be recorded, and getting the whole team to use those names with one meaning, which takes days. Instrument one signup button as "signup complete" while somebody else instruments it as "signup start," and every number downstream disagrees with every other.

The limits come from the structure. What this tool follows is a browser, not a person. Someone who looks at a work computer and returns later on a phone at home counts as two, and a visitor who declines cookies is not counted at all.

Several approaches answer the same questions, so the choice follows what you want to know. Four get compared.

1. Mobile attribution tools — connect an app install back to the ad that caused it. Because an app install routes through a store, the source information breaks, and a web tool can't substitute.
2. Customer data platforms — bundle scattered records under one person. A cookie in the browser, a device id in the app, an address in the email tool all resolve to the same individual. This covers the browser-level limit but costs considerably more to wire up and maintain.
3. Data warehouses — collect the records yourself and write whatever question you need when you need it. There is no fixed screen, so anything can be asked, but somebody on the team has to be able to write the queries. Teams usually move here once the questions the tool's screens can't answer start outnumbering the ones they can.
4. Server-side tracking — record and send events from the server rather than the browser. Blockers don't intercept it so gaps shrink, but anything that happens on screen without reaching the server leaves no record.

What's common is not picking one of the four but wiring two or more together. More tools means more connecting lines, and when one side renames a field, one of those lines breaks silently. A broken line doesn't raise an error; it shows up as a number that got slightly smaller, which is why it tends to be found weeks later.

"The rate from pricing page to signup screen is 4.5 percent. That's the lowest cell we have."

Attaching pass rates per funnel cell to locate what to work on.

"This channel has no UTM, so it landed in direct traffic. We need to tag it again."

A missing source marker put ad performance in the wrong column.

"The tool and the ad platform are 12 percent apart, and that's normal. Just read the trend."

The two count differently, so the absolute figures are expected to disagree.

At Pagedeck, Ravi reads pricing page through checkout as five cells in this tool. Last quarter the cell in front of the signup screen came in lowest at 4.5 percent, three form fields were removed, and it went to 7.1 percent afterward. Theo keeps the event names to be recorded in one document and edits that document before instrumenting anything new.

The most common mistake is reading the figures on screen as exact. They come with decimal places on a tidy layout, which is how that reading happens. But visitors running ad blockers and visitors who declined cookies leave no record, and depending on the site that share runs from 10 to 30 percent. A gap of more than 10 percent between the tool and an ad platform is ordinary too, because they count differently. Many teams spend days trying to reconcile the two, and reconciling absolute values never finishes. Used to compare last month against this month inside one tool, where the gaps apply similarly, the trend is trustworthy.

Believing that installing the tool starts the analysis is the other one. Setup takes half an hour, so the screens look like they will handle the rest. But what accumulates by default is visits and page moves; which button someone pressed is recorded only where somebody instrumented it. Open the screens without having decided what to record and you get a table of visitor counts and time on page, which cannot answer why signups fell. Event tracking, the work of turning user behavior into records, has to be designed first for the screens to start producing answers.