Looking at My Website Through My Users' Eyes
Product Engineering •
I was checking the analytics for one of my websites when I noticed some of my visitors were coming from Brave.
Out of curiosity, I opened one of my own sites — mdxdocs.com — in Brave.
The lion icon immediately lit up.
Blocked 100+ trackers.
I just stared at it for a second.
I knew exactly what I’d installed on that site.
PostHog.
Google Analytics.
Two analytics tools.
So why was Brave telling me it had blocked over one hundred tracking-related requests?
I clicked the Shields icon, and that question sent me down a rabbit hole.
That number bothered me more than it might bother most developers because of what I spend my days building.
I’ve spent the last several years creating products where privacy isn’t just a feature—it’s part of the promise.
HyperPaste never sends your clipboard history to my servers.
Burn After encrypts files before they’re uploaded, so I can’t read their contents even if I wanted to.
Log Nutrients keeps your health data on your device.
Those choices aren’t accidental. They’re deliberate design decisions.
Which made that giant “100+” badge feel… wrong.
Not because I’d done anything malicious.
But because I’d never stopped to ask whether the analytics on my websites matched the products they were introducing.
Eventually, I learned what Brave was actually counting.
It wasn’t one hundred different trackers.
It was blocked tracking-related requests. Two analytics platforms can generate a surprising amount of activity over the lifetime of a page, especially when a browser is actively blocking them.
Technically, everything was working exactly as expected.
But somewhere in the middle of that rabbit hole, I realized the technical explanation wasn’t the interesting part.
My users were never going to investigate why the number was so high.
They weren’t going to learn how Brave counts requests.
They weren’t going to inspect my analytics configuration.
They were simply going to see this:
Blocked 100+ trackers.
And then they’d decide what they thought about my website.
Everything in this story is about websites—not the apps themselves.
Landing pages.
Documentation.
Blog posts.
The pages where someone decides whether they trust you enough to download your software.
Those pages are part of the product experience.
And for products built around privacy, they set the tone long before someone clicks “Download.”
Like a lot of developers, I’d added analytics because… well, that’s just what you do.
You launch a website.
You paste in a tracking snippet.
Maybe another one.
Now you have page views, funnels, heatmaps, session recordings, autocaptured events, and dashboards full of graphs.
Problem solved.
Except…
What problem was I actually trying to solve?
When I made a list, the answers were surprisingly simple.
How did people discover the app?
Which blog posts resonate?
Did my Product Hunt launch bring visitors?
Are people coming back?
Those are questions about my business—not about my users.
That distinction ended up changing how I think about analytics.
Around the same time, I had been building a small internal dashboard that pulls all of my Google Analytics properties into one place.
Every morning, I can see traffic, referrers, and trends across every website I run.
That data has a purpose.
I use it constantly.
Then I asked myself the same question about PostHog.
When was the last time I looked at the autocaptured events?
The click streams?
The behavioral data?
The honest answer was…
Almost never.
I had installed a tool capable of collecting incredibly detailed information about how people interacted with my websites.
But I wasn’t using that information to make better decisions.
So why was I collecting it?
I ended up removing PostHog from mdxdocs.com.
Google Analytics stayed.
I know that isn’t the “privacy purist” ending some people might expect.
Brave still blocks Google Analytics.
The shield still lights up.
If my only goal were to get that number to zero, there are privacy-focused analytics platforms—or even plain server logs—that would be better choices.
Maybe I’ll make that change someday.
But that wasn’t really the lesson.
The lesson wasn’t “remove every analytics script.”
The lesson was understanding why each one was there.
Google Analytics answers questions I actually ask.
PostHog, at least the way I was using it, answered questions I wasn’t asking at all.
That afternoon changed the way I think about analytics.
Not because Brave convinced me to remove everything.
And not because Google Analytics or PostHog are inherently good or bad.
It changed because, for the first time, I stopped looking at my website as the person who built it…
…and started looking at it as someone visiting it for the first time.
I’m the person who installed those analytics tools, and I still needed an afternoon of digging to understand why Brave was showing such a large number.
My users will never do that.
They’ll see the badge.
They’ll form an impression.
And they’ll move on.
That experience made me realize I’d been asking the wrong question.
Instead of asking,
“What analytics should I install?”
I should have been asking,
“How are my users actually experiencing this?”
Because in the end, people don’t experience the architecture behind your product.
They experience the product itself.