The numbers worth reading weekly

Hand it to an agent

/atlas:report — pulls the weekly slice from Search Console and your product data, works out the delta and names one action

The command is not in Claude Code out of the box — how to install the plugin.

What we are solving

My dashboard had forty numbers on it and every one of them moved last week. That sounds like a lot of information. It was none of it: at these volumes most of the movement means the volume is small, not that the project is alive.

What works is a short list you read on a fixed day of the week. Getting onto that list is hard. A number has to answer something none of the others answer, and if two numbers answer the same question, one of them is decoration and can go.

Steps

Does search consider me an answer to anything at all

Read impressions, in the Performance report. It opens from the property’s left-hand navigation in Search Console. Impressions move before clicks do, so a page you published on Monday shows up here first and nowhere else for a while.

Read the count of distinct queries next to them, because the pair says something neither number says alone. A rising query count means new demand found you. A flat query count with impressions climbing means the same page was shown more often, and that is a different event entirely.

Is this a ranking problem or a packaging problem

Read clicks and average position only as a pair. Impressions with no clicks at a decent position is a title and snippet problem. Rewriting the body is then the wrong afternoon of work, because the reader never got as far as the body to be disappointed by it.

Read the position here and not in a panel. On one of my queries an outside estimate said 20 while this report said 43.3. Where that gap comes from is written out in what a paid rank tracker measures.

How much of what I wrote can even rank

Count the share of your pages actually in the index. The denominator is the URLs you submitted. The numerator is the URLs the report says are indexed. A count of indexed pages on its own is fiction: it never says out of how many.

The Page indexing report gives you the shape of the problem. The URL Inspection API gives per-URL truth, and you go there when the question is no longer about the site but about one page.

Is there anyone in this traffic who wants the thing

Count signups with your own accounts taken out. Keep an explicit list of internal ids and subtract before you aggregate, not after, because after is where the founder’s own account quietly becomes a user.

Count people, not events. Three purchases by one person are one customer with a habit. A table that does not know the difference will tell you the opposite.

Did anyone actually get the thing

Activation is the first action after which a person has the value you built rather than an account. Creating the account is not it. Pressing start is not it either.

Name that one action out loud, in a sentence, before you measure anything, and the metric is then the share of arrivals who reach it. If you cannot name the action, there is no metric yet — there is a chart.

Do I have a product or a demo

Count repeat use on a later day, without a reminder from you: this is the number that separates something people use from something people tried.

Cohort it by the week of first contact. Pooling everyone hides falling retention behind new arrivals: the pooled line stays flat while every individual week gets worse than the one before it.

What do I compare today’s number against

Take one snapshot a week, same weekday, same window, and append it to a file you keep. A rolling 28-day window takes the weekday effect out. At these volumes a Tuesday and a Saturday can differ by more than a month of growth.

Keep the series. A number with nothing to compare itself against a month ago is decoration.

Why the total never tells me what to fix

Two readings changed what I actually worked on, and neither of them is visible in any total.

The first was breaking activation down by first action. On one project the two possible first actions came back at different rates, and that told me which of the two paths to put in front of new users. The aggregate had been saying nothing for months.

The second was counting the people who produced no event at all. They left after the first screen, so no event table contains them, and that is exactly why they never surface as a problem. Their absence is a verdict on the first screen.

Then fix the earliest large drop, not the most interesting one, because tuning payment while activation is broken is work on a step almost nobody reaches.

What did not work

• Reading the graphs every day. At these volumes two days can swing further apart than a real week of change. I shipped a fix on a Tuesday dip and reverted it on Friday, more than once, and neither the fix nor the revert had anything to do with the numbers that moved.
• Counting pageviews as traffic. The views in the report were mine. A founder-only panel I open several times a day sits in the same property as the public pages. Once I excluded the internal URLs and my own sessions, my growth story turned into a flat line.
• Treating signups as activation. The signup number looked healthy for months. People registered and never sent one real request — I had instrumented the door and left the room dark.
• Counting transactions instead of unique payers. Three purchases by one person read as three customers on my chart, and my own test account read the same way.
• Trusting an external traffic estimate. It did not cover one of the two search engines my audience actually uses, so the conclusion I drew from it was the reverse of the truth. One query typed by hand into that engine would have caught it, and I did not type it for weeks.
• Building the dashboard before writing the questions. I read panels that answered nothing, every week, and did not notice for a long time. In the end I deleted most of my event tables and rebuilt the panel around cost and exhaustion.
• Averaging over all users instead of cohorts. The average sat flat while signups grew, which I read as stability, and that panel could not tell me whether any single cohort was moving.

Verify

Run /atlas:report from Tools. It pulls the Search Console side, the index share and your own product numbers into one weekly block, and you paste that block into a log — only then does the series exist at all.

The rest of it a report cannot check for you.

• The signup number excludes your own accounts, so sign up as a test user and confirm the number does not move.
• The activation metric names exactly one action, and if you cannot say which action, the metric does not exist yet.
• The index share uses submitted URLs as its denominator, not the pages you remember writing.
• The series has more than one point in it, because one reading is not a trend and two readings are barely a line.

Knowing a number moved is useless until you know who moved it. Next: where the user actually came from.