This is the thirty-first post in the LocalPapa Notes dev-log series. It is about what to actually look at, once Google Analytics is installed, if you want the site to get better.
The conclusion first, because it is where we nearly went wrong ourselves: Analytics cannot tell you what to fix. It tells you what happens after people arrive. And a site's biggest problem usually happens before anyone arrives.
Analytics opens on a leaderboard — that is not a to-do list
The pages report lists your highest-traffic pages. It is easy to read that as a priority order: high traffic means important, so fix that first.
But think about what the table is actually saying: a page with visitors is a page that already works. The leaderboard is a result, not a to-do list. The pages that need work are usually the ones that should have visitors and don't — and in Analytics those look exactly like pages nobody ever wanted. Both are zero.
There are two kinds of zero: nobody searches for it, and people search but don't click. Analytics cannot tell those apart. Search Console can.
The two reports meet at the moment someone clicks
Impressions and clicks belong to Search Console; page loads and button events belong to Analytics. The seam is the instant the visitor clicks the link.
The numbers in that diagram are real, from one of our own tool pages: shown in search results 2,822 times in a month, clicked 15 times.
Analytics only ever sees those 15 people. The other 2,807 — saw it, didn't click — leave no trace at all. From Analytics this page is a tool nobody uses; from Search Console it is the second most-seen page on the entire site. Same page, opposite conclusions.
The reverse holds too. Search Console stops at the click. Whether the people who did arrive actually finished using the tool is a question only a custom Analytics event can answer.
What you want to know
Which report
How many people saw me and didn't click?
Search Console (impressions, CTR)
What words did people find me with?
Search Console (queries)
Where do I rank?
Search Console (average position)
Did visitors actually use the feature?
Analytics (custom events)
Where do people give up?
Analytics (event funnel)
Is mobile bouncing harder?
Analytics (device dimension)
Neither replaces the other. With Analytics alone you will carefully optimise the experience of people already willing to come in, while ten times that number turn around at the door without you ever knowing.
A worked case: ranking sixth, clicked 0.53% of the time
In Search Console's Pages report we sorted by impressions, not by clicks — this step matters, because sorting by clicks just shows you your successful pages again. Second on the list was our name-numerology tool: 2,822 impressions, average position 6.34, 15 clicks, CTR 0.53%.
A number only means something next to a comparison. A site-wide average is useless here, because CTR varies enormously by topic. The comparison that counts is neighbours at a similar rank:
Sorted by average position, best at the top; bar length is click-through rate. The name tool sits second-best on position, with the shortest bar on the chart.
The Palm Sutra tool ranks 3.38 with 13.70% CTR; BaZi ranks 7.03 with 7.81%; the inclinometer 6.45 with 6.10%; Zi Wei 9.38 with 4.34%. Name numerology ranks ahead of three of those, and gets a tenth of their clicks.
That comparison rules out a whole class of explanation: the problem is not the ranking. Ranking well but not being clicked is a different problem from not ranking, and the fixes have nothing in common. The first is about the three lines of text in the search result; the second is about content and links. Confuse them and you can spend weeks doing things that cannot possibly help this page.
Data points at the anomaly; it will not tell you why
That is as far as the data goes. It says this bar is out of line. It does not say what is broken.
So the next step is not more reports. It is to go and use your own tool once.
We assumed the job was "write a more appealing title". Using the page proved otherwise: typing just the surname and given name and pressing Analyse, the tool filled in the Kangxi stroke count for every character and produced the five grids immediately. The tool had been looking the strokes up automatically all along.
But the three things a searcher sees before clicking all said the opposite:
Where
Before
What a searcher reads
Title
"Free name numerology — five grids, three talents, 81 numbers"
All jargon; no idea what to type
Description
"Enter the Kangxi stroke counts of the name…"
I have to look strokes up myself
First FAQ
"Why strokes, not the name?"
Confirmed: it won't take a name
The third one is the damaging one. That question lives in the page's FAQPage structured data (JSON-LD), and structured data can be displayed directly in the search result by the search engine. So that question and answer were not on-site help text. They were a discouraging notice we had hung on the search result ourselves, telling people to go away before they ever clicked.
Meanwhile the search queries bringing people in ("three talents five grids calculate online") say plainly that what they want is to type a name and get an answer.
So the thing to fix was not the tone. It was a sentence that had stopped being true. Copy falling behind code is the most common failure mode for pages like this, and the only way to find it is to use the thing — the code looks fine, because it is fine, and the copy reads fine on its own.
What changed
The title now describes the actual behaviour: "Free name numerology — type a name, Kangxi strokes filled in automatically".
The description and social sharing text now say "type the Chinese name; Kangxi strokes are filled in for you and can be checked character by character".
The first FAQ became "Do I have to look up Kangxi strokes myself?", answered "No" — updated in all three places at once: the visible text in both languages, the language dictionary, and the JSON-LD. Fixing the visible page but not the structured data means the page is right and the search result is still wrong.
We also fixed the on-page "How to use" steps, which still read "1. Look up Kangxi strokes → 2. Enter strokes". They do not affect click-through, but they were wrong — fix the errors you walk past, rather than leaving them because they are not this task's target.
What Analytics is genuinely good at: separating "arrived" from "used"
Back to Analytics itself.
Every tool on our site fires a custom event, tracked centrally in ANALYTICS_EVENTS.md. A pageview tells you someone opened the page; an event tells you whether they pressed the button. The gap between the two is the single most valuable signal there:
Many views, few events → the page is fine, the tool itself is where people get stuck (too many fields? unclear what to enter?)
Few views, high event ratio → the people who arrive are happy; the problem is at the door (back to Search Console)
Both low → there may be no demand for this page at all
That ratio, not the traffic leaderboard, is what we actually use Analytics for.
Privacy: measure pages and buttons, never content
We are a site that promises your files never leave your device, so the measurement boundary has to be drawn explicitly: events record which button on which page was pressed, and carry no content parameters.
Birth dates, names and uploaded files stay in your browser. They do not get sent anywhere because we were curious about usage. To know how many people used the name tool, a name_analyze count is enough; no one's actual name is needed. A measurement need can almost always be met without touching content — if it seems it can't, the question is usually the wrong question.
Five ways to misread the data (all of which we did)
The leaderboard is a result, not a to-do list. High-traffic pages are the ones already working. Look for pages that should have traffic and don't.
Averages lie. A site-wide average CTR means nothing. Compare against pages at a similar rank, because CTR swings hugely with position.
A small sample is not a signal. Five impressions and one click is not "a 20% click-through rate". Our own report has several rows like that; we ignored all of them. Three-digit impressions before you draw conclusions.
Changing copy does not guarantee the number moves. CTR depends on your title, your description, what your competitors look like, and whether the search engine rewrites your title anyway. The one thing we can be sure of: the old copy described something the tool no longer does, and that was worth fixing on its own terms. Whether it works, we find out in a few weeks.
Change one variable at a time. We have another item outstanding on the same page (both the .html and extensionless URLs are indexed separately). Ship both and a change in the numbers tells you nothing about which one did it. Deliberately deferring the other one is what makes this one measurable.
A checklist you can follow
Open Search Console → Performance → Pages and sort by impressions, not clicks.
Find pages with three-digit impressions, an average position inside the top ten, and a CTR clearly below similarly-ranked neighbours.
Search that keyword yourself in a private window and look at how your title and description actually appear. You will see what users see, rather than what you think you wrote.
Use your own tool once, and check that what the copy claims is still true.
Check the page's structured data (FAQPage, HowTo and friends) for stale sentences — those can be shown directly in the search result.
Back in Analytics, look at that page's event-to-pageview ratio to confirm arrivals can actually get through the tool.
Change one page at a time, write down the date, and come back to the same report in two or three weeks.
Finally
Data will not tell you what to fix. It tells you where it is worth looking.
The value of that one out-of-line number was not that it was a problem. It was that it made us do something we would not otherwise have done: use our own tool. The real answer was there, not in the report.