Client-side Tracking

For a long time the only record a company had was the server access log. It showed which address was requested and how often, and nothing about what the person did once the page was open. You could see that someone opened the pricing page. You could not see whether they clicked over to the annual plan and backed out, or scrolled to the bottom and closed the tab.

So every meeting about fixing a screen ran on guesswork. Noa would say the checkout button was buried too far down for anyone to notice it, and Theo would answer that requests to that page were flat compared with last month. One of them was talking about what happened inside the screen and the other about what reached the server, and the same data set gave them nothing to argue with.

Client-side tracking closes that gap by moving the recording point from the server into the screen. A short piece of code sits inside the browser or the app, and the moment someone presses a button or finishes typing, it builds one event right there and sends it. An event is a single line that records who did what and when. Actions that never produce a server request get written down this way.

Wiring it up is more than pasting one line of code. It usually takes five steps.

1. Write down what you want recorded. This is the tracking plan — a document that fixes which actions get logged and under which names. Start instrumenting without it and the same action goes in under a different name on every screen.
2. Install the snippet the analytics tool gives you. On the web it goes wherever every page loads shared code; in an app it goes in the startup path that runs once. This snippet is the pipe that collects events and ships them to the tool's servers.
3. Add a call at each point where the action happens. Next to the code that handles the share button, you add one line that sends an event name along with its event properties. Event properties are the details attached to that action — whether the share was a link or an email invite, for instance.
4. Tie the events to a person. For a signed-in user you hand the tool a user identifier; before sign-in, a temporary value the tool stores on the device stands in. Skip this and events pile up with no way to tell how many people produced them.
5. Confirm delivery, then open it up. Most tools have a live view of events arriving, so click the button yourself and check that the name and properties came through as specified. Skip that check and you find the hole a month later while reading a chart.

To avoid routing step 3 through an engineer every time, teams often pair this with a tag manager, a tool for attaching and removing tracking code without a deploy. It is fast when you're in a hurry, and it makes it harder to know who put what where.

It fits wherever the behavior never reaches the server. Whether someone scrolled through the whole pricing table, typed a query and deleted it, or stopped halfway through entering a card number produces no request at all, so the screen is the only place to catch it.

There are three limits. First, some of it never arrives. Ad blockers stop requests headed for analytics tools, and closing a tab on the subway kills an event mid-flight. What makes this data loss awkward is not the shrinkage but its unevenness. Blockers cluster among technical users, so it is that group's behavior specifically that fades out of the picture you're reading.

Second, the values are not trustworthy. They are assembled on the screen, which means anyone determined enough can hand-craft an event claiming a $750 purchase. Anything with money attached does not belong here.

Third, it sees nothing that happens off-screen. A payment refunded later, or a subscription that renews automatically a month from now, happens while the user's browser is closed.

This is why teams don't pick one method over the other. Movement inside the screen goes out from the client, and facts about money and contracts go out from the server.

"Instrument this button click on the client. It doesn't hit the server at all."

The action ends inside the screen, so the collection method has to sit there too.

"Completed-checkout counts don't match our own numbers. Probably because it's client-side."

The first suspicion is that blocking or drop-off kept some events from arriving.

"Read the client numbers as a trend and settle the invoices off the server record."

Use one source to make judgments and a different one to move money.

At Pagedeck this method went in first when the team reworked the pricing screen. Mia wanted to know where people stalled, so Theo instrumented three points: opening the screen, tapping the annual tab, and pressing the checkout button. A week later the numbers showed that half the people who tapped the annual tab never reached checkout, and Noa redrew that stretch of the flow.

Successful payment counts for the same screen, though, Theo pulled separately from the server record. The client figure Mia was looking at came in about 3 percent low every month.

The most common assumption is that once client-side tracking is in place, every user action gets recorded without exception. Sending directly from the screen sounds like there's nowhere for anything to leak. In practice, ad blocking, dropped connections, and the order the instrumented code runs in leave roughly 5 percent missing at all times, and the missing share is not scattered at random. Teams that don't know this put client numbers straight into a revenue report, watch them disagree with finance, and lose trust in the whole data set.

The other frequent misreading is that one snippet collects everything on its own. Tool documentation opens with the snippet, which invites that reading. What arrives automatically is little more than a record that a screen was opened; what someone clicked shows up only if a person put a line of code at that spot. Put it off and six months later, when the question finally comes up, there is no history to look back at.