I Track Every Pageview Through a Cloud Function

I replaced Google Analytics with a single Cloud Function. The dashboard was telling me stories that weren't true, and the fix changed how I think about building.

I opened my analytics dashboard and stared at the number.

Ninety-one page views. In the last week. Across the entire site.

Now, ninety-one people visiting your personal website is not bad. It’s not nothing. But I had Google Analytics running on that page — the full GA4 setup, all the tags, all the event tracking, the whole machinery. And here’s the thing: I had built an industrial-grade surveillance system to tell me I got about thirteen visitors a day.

Does that feel right to you?

It didn’t to me. Not because ninety-one was disappointing. But because the system I built to measure it was wearing a spacesuit to cross the street.

I think we’ve all gotten used to this without really noticing. You put a piece of JavaScript on your site and suddenly you have dashboards. Lag reports. User cohorts. Demographics. Session replays, if you pay for it. All for a site that maybe a few hundred people visit per month. It’s like buying a commercial kitchen because you want to make toast for breakfast.

I took it down.

Not the site. The analytics.

I replaced it with a Cloud Function. A single function. A few dozen lines of code, a database write, and an endpoint. Every time someone loads a page on my site, a tiny HTTP call fires off to this function. It records the page path, a timestamp, and a hash of the visitor’s IP (for deduplication — nothing identifying ever gets stored). Then it moves on.

That’s it. No dashboard. No cohorts. No real-time user count in the corner.

Here’s the part I didn’t expect: removing the dashboard changed how I felt about building.

When GA4 was running, I would check it obsessively. Refresh the page. Look at the chart. Were numbers up? Down? Tilt the screen. Squint. The data was so rich and noisy that I could always find a story in it. Oh, visits dropped on Tuesday — maybe people didn’t like the post. Oh, visits spiked — the post is doing well! Except neither of those stories was real. The sample size was too small. The noise was louder than the signal. But the dashboard wanted me to find patterns, so I found them.

Now I have a database table. Sometimes I query it. Mostly I don’t.

And when I do, the numbers feel honest. They’re small, they’re quiet, and they don’t try to sell me anything. I can see which posts people are reading. Which pages they bounce from. That’s enough.

There’s a broader thing here, I think.

We build these intricate measuring systems for things that would be fine with a stick and a piece of chalk. And then the measuring system starts shaping what you build. You start optimizing for what tracks well — time on page, session length, re-engagement rate — rather than what’s actually good. The tail starts wagging the dog.

I noticed this with the Email Digest project too. Early on, I was obsessed with open rates. I’d check them every morning. That’s a vanity metric for a tool that has maybe twenty active users. A single person opening their email on their phone versus their laptop could swing the number by five percent. I was getting excited or anxious about something that was fundamentally random.

I turned that off too.

Now the only numbers I care about are: did the pipeline run, did it fail, and did anyone reply with feedback. That’s the measurement that actually informs decisions.

I realize this sounds like I’m arguing against data. I promise I’m not. Data is great. But there’s a difference between useful data and data that makes you feel like you’re doing something. A Cloud Function that writes row after row to a Firestore collection isn’t going to sell you a dashboard upgrade. It’s not going to send you a weekly report with charts that make you feel a certain way. It just sits there and tells you the truth when you ask for it.

And the truth is: building for a hundred people is fine. You don’t need a scale that handles a million. You just need to know if your hundred people are sticking around, and if the thing you built is helping them.

I think a lot of tools are designed for the version of your project that doesn’t exist yet. The one with thousands of users, enterprise customers, and a revenue graph that goes up and to the right. And using those tools before you need them makes you feel like you’re already falling behind.

But you’re not. You’re building something small. That’s okay. Small things can grow, and when they do, you can upgrade the measuring system then. But if you put the big system on too early, it starts telling you stories that aren’t true, and those stories can make you build for the wrong audience.

I still check the pageview table sometimes. Not every day. Maybe once a week. I look at the count. I see which posts are getting traction. I close the terminal. The whole thing takes thirty seconds, and then I get back to building.

It costs me about nothing to run. A few cents of compute per month. No third party loading on my pages. No cookie banners to maintain.

And the numbers feel like mine. Not some platform’s interpretation of my traffic. Just the raw truth of who’s reading what, one row at a time.

I don’t think there’s a right answer for everyone. If you have a thousand paying customers, please don’t replace your analytics with a Cloud Function. But if you’re building something small, for a small audience, and you find yourself checking the dashboard more than you’re checking in with your users — maybe ask yourself what you’d actually need to know.