I built a weekly analytics routine for timurtek.com in an afternoon. The first run caught a newsletter form leaking 80 percent of intent, a LinkedIn preview bug that had been killing referrals for three weeks, and five 404 URLs with real inbound traffic nobody had noticed. Here is the routine, the actual numbers, and why most solo marketing sites are flying blind in exactly these places.
GA4 was wired. Nobody was reading it.
The site went live with Google Analytics 4 wired in correctly. Pageviews, events, conversion goals, the whole panel. The number was technically being captured. It was not being read.
This is the default state for most solo marketing sites. The dashboard exists. The numbers update. The owner opens it once a week, scrolls for thirty seconds, sees a flat line or a spiky line, closes the tab. No decision gets made. No experiment gets queued. The dashboard is a wallpaper.
The fix is not a prettier dashboard. The fix is a routine that turns raw numbers into a question the operator has to answer that Monday morning. Raw numbers in an inbox are not a routine. They are noise.
The architecture: snapshot, analyze, email, schedule.
Four moving parts. Each one boring on its own. Together they are the operating loop.
First, a snapshot script pulls the prior week from GA4 and writes a JSON blob to the repo. Same shape every week. Versioned. Diffable.
Second, an analyzer reads two snapshots, takes the deltas, and runs a small set of heuristics against the result. The heuristics are the judgment layer. They live in Python because interpretation is judgment work, and judgment work belongs in versioned code I can edit and review, not in an n8n Code node I open once a quarter and squint at.
Third, the analyzer writes a markdown report and an n8n webhook pushes that report into my inbox.
Fourth, a GitHub Actions cron triggers the whole thing every Monday at 8 a.m. ET. The email is waiting when I sit down. Thirty minutes of work and one decision later, the week has a queued experiment.
The whole thing took an afternoon. The hard part was not the code. The hard part was deciding what the heuristics should say.
The heuristics. What counts as a leak.
A leak is a place where intent shows up and conversion does not. Concretely, the heuristic the script uses is: form start to conversion under 20 percent. If a hundred people start the form and fewer than twenty finish it, the form is leaking. Something between the first field and the submit button is killing the intent.
A working page is the inverse: average session over 120 seconds with at least three pageviews from that landing. People landed, read, kept reading, clicked into something else. The page earned the visit.
Bounce rate is a trap below 500 sessions a week. It moves on noise at low traffic. Below the threshold, the heuristic ignores it entirely and writes a one-line note that says traffic is too thin for bounce to mean anything yet. I would rather the report admit the data is thin than print a number that pretends otherwise.
The whole heuristic set fits on one screen. The point is not sophistication. The point is consistency. The same questions get asked every Monday. The answers move week over week. Trend lines beat snapshots.
What the first run found.
Three findings. Each one a real dollar amount of work that had been quietly draining.
The first was the newsletter form. 32 starts. 6 signups. 19 percent completion. The script flagged it as a leak before I even read the report header. I had been watching the signup number climb slowly and feeling fine about it. The completion number changed the frame entirely. The form was not converting. The form was bleeding. There was a working version of the asks and a broken version of the form between them, and only the second number told me which was which.
The second was LinkedIn previews. The report flagged a referral drop from LinkedIn that had been happening for three weeks. I had not looked because LinkedIn is not the biggest traffic source, so a drop there reads as noise. The root cause turned out to be a metadata serialization quirk: the page-level openGraph object was replacing the layout-level images metadata instead of merging with it. Every new blog post shipped with no preview card. LinkedIn was scraping the URL, finding no preview, and posting a bare link with no thumbnail. Three weeks of LinkedIn traffic lost to a metadata bug nobody would have noticed by reading dashboards.
The third was the 404 audit. Five URLs with real inbound traffic landing on dead routes. Webflow leftovers, a plural-vs-singular typo on one blog slug, a deleted post somebody had bookmarked. None of these would have surfaced from looking at the conversion funnel. They only surfaced because the script reads the referral table and cross-checks against actual rendered status codes. Boring discipline. Real recovered traffic.
The OODA loop. Monday email. Thirty minutes. One experiment.
The routine has four moves. Observe the report. Orient on the biggest leak. Decide on one experiment. Act, ship it that day.
Then the discipline. Next Monday compares. If the experiment moved the number, keep going. If it did not, kill it and pick the next leak. One cycle per week. No experiment runs past two cycles without proof.
The trap on solo marketing sites is the opposite move: ship three experiments at once because they all look reasonable, then a month later not know which one moved anything. The script forces one-at-a-time because the heuristics surface one biggest leak. Pick that one. Ship that one. Wait a week.
Discipline is killing what did not work after one cycle. Most teams skip the kill step. They keep both experiments running because both are technically still moving in the right direction. By month three the dashboard is a soup of half-results and nothing is attributable. The kill step is what makes the loop a loop instead of a pile.
Why this is a fractional AI move, not just a marketing tip.
Production AI ops surfaces work the same way as a marketing site dashboard. A number on its own is not an answer. A number on its own is a question.
The eval suite that returns 87 percent accuracy is a question. Which 13 percent is the script wrong about. Are the wrong answers spread evenly or clumped on a specific intent. Is the wrong-rate climbing week over week against a fixed test set, or is the test set drifting.
The script writes the question. The operator picks the experiment.
This is true for analytics. It is true for evals. It is true for cost dashboards on model spend. It is true for latency p95 charts. The pattern compounds: build the layer that asks the right question every cycle, then spend your judgment time on the answer, not on remembering to ask.
The teams that ship AI in production are not the teams with the biggest model budgets. They are the teams that built the smallest, dumbest, most consistent question-asking routine and then ran it for a year. Same shape as a Monday analytics email. Different surface.
Most solo marketing sites are flying blind in the same three places mine was. A leaking form. A broken preview. A handful of 404s nobody noticed. The fix is not better tooling. The fix is a routine that catches them once a week, every week, without you having to remember to look.
That is the part that compounds. Pretty much that.