Chrome Extension Analytics: Why GA4 Fails and What We Use Instead

When I shipped the first version of Sublo — the Chrome extension that translates Netflix, YouTube and Disney+ subtitles in real time with Gemini AI — I did what most extension developers do on day one: I dropped a Google Analytics snippet into the popup, opened the dashboard a week later, and stared at numbers that made no sense.

Active users jumping wildly from one day to the next. Sessions counted twice for the same user. "Direct" traffic everywhere. Retention curves that looked like a seismograph. After a couple of weeks of trying to debug it I realized the data was not slightly off — it was structurally broken. GA4 simply was not built for the world Chrome extensions live in.

This post is the long version of what I learned. If you ship a Chrome extension and want to actually understand who is using it, this is what nobody told me before I had to figure it out the hard way.

Why standard web analytics breaks inside an extension

Every web analytics tool on the market — GA4, Mixpanel, Amplitude, Plausible — was designed around a website running in a normal tab, with a normal URL, served from a normal domain. None of those assumptions hold inside an extension. Four things break in particular.

Cookies and storage isolation. A Chrome extension does not run on your domain. The popup loads from chrome-extension://[id]/popup.html. Content scripts run on whatever website the user happens to be on — netflix.com, youtube.com, anything. Cookies set in one of these contexts cannot be read in the other. Tools that rely on a first-party cookie to identify a returning user will count the same person as a new visitor every time they switch contexts.

Service workers replace the page. Manifest V3 killed the persistent background page and replaced it with an event-driven service worker that gets terminated and restarted constantly. Most analytics SDKs assume a long-lived page where they can buffer events, batch requests and use timers. In a service worker, those timers fire into a void; the worker is already gone by the time the next event arrives.

Referrer headers go missing. When your content script fires an event, the request originates from the host page — or from the chrome-extension:// origin — depending on how it is sent. Referrer-based attribution falls apart immediately. You cannot tell that a user came from a Reddit post when half your events arrive with no referrer at all.

Tag managers and remote code are forbidden. Manifest V3 disallows remote code execution, which means Google Tag Manager and most of the heavier analytics scripts violate Chrome Web Store policy. If you bundle them anyway, expect a rejection email.

Combine all four, and you end up with a dashboard that technically shows numbers but does not let you make a single product decision. I spent more time arguing with the data than learning from it.

What I actually wanted to know about Sublo users

Before swapping out tools I wrote down the questions I actually cared about. This list ended up shaping every decision afterward.

• How many people install the extension after visiting the landing page, and which referral sources convert best?
• Of the people who install, how many actually use it within the first 24 hours?
• Which streaming platforms see the most translation activity? Netflix? YouTube? Disney+?
• Which language pairs are most popular? Where should I prioritize quality work?
• What is Day 7 retention — the single most important growth indicator for a freemium tool?
• When users churn, what was the last thing they did before disappearing?
• For users who upgrade to Pro, what is the typical path from install to first payment?

None of these are exotic questions. They are the standard SaaS metrics any indie founder needs. The problem is that getting them out of GA4 inside an extension is somewhere between hard and impossible.

What we use now: Crxlytics

After trying three different stacks I ended up using Crxlytics — an analytics platform built specifically for Chrome extensions. Full disclosure: I know the people behind it. But I would not be writing about it here if it had not solved the problem cleanly. The reason it works comes down to one thing: it was designed inside the extension constraints from day one, instead of trying to retrofit a website tool.

Concretely, this is what changed for me when I switched.

The SDK is service-worker-safe. The library buffers events using chrome.storage and flushes them whenever the service worker wakes up. Nothing relies on long-lived timers or background pages. When my popup, content script and service worker all fire events for the same user, they arrive correctly stitched into a single user profile.

Cross-context user identity actually works. The SDK uses an anonymous ID stored in chrome.storage.local — available across the popup, content scripts, side panel and offscreen documents. Users are no longer counted three times for one session. My DAU number finally matched my own intuition about how the extension was being used.

The footprint is tiny. Crxlytics ships at around 2 KB gzipped. For a tool that has to load on every Netflix or YouTube page, this matters. The previous SDK I used added 60 KB to my content script — in real-time-translation territory, that is the difference between a buttery-smooth subtitle render and a noticeable hitch on the first frame.

Real cohorts and retention. Day 7 retention, churn detection, and cohort tables are first-class features instead of something you have to build yourself with raw event exports. Within a week of switching, I could see exactly which install sources produced retained users versus one-day visitors.

Attribution that survives the install boundary. The biggest blind spot of GA4 for extensions is the gap between "user clicked Install on the landing page" and "user fired their first event in the extension." Crxlytics ties first-touch attribution to that first in-extension event, so I can finally see that, for example, the Korean K-Drama blog posts are converting at twice the rate of the Polish ones.

What changed in how we ship Sublo

Better data did not just give me prettier dashboards — it changed actual product decisions. Three concrete examples from the last few months.

Onboarding rewrite. The data showed a sharp drop-off between install and first translation event. Half of new users never enabled the extension on a streaming site. We rebuilt the post-install screen to walk people directly into Netflix with the dual-subtitle preset already configured. First-day activation went from roughly 50% to over 80%.

Language pair prioritization. I had assumed our top language pairs were the obvious European ones. The data said otherwise: Korean → English, Japanese → English, and Spanish → English dominated, with Polish and Turkish overperforming relative to their content libraries. We pushed quality work and blog content toward those pairs, and conversion improved noticeably across all of them.

Pricing tier validation. The free tier on Sublo gives 15 minutes of translation per day. I had been nervous it was too restrictive. The funnel data showed the opposite — users who hit the daily limit converted to Pro at roughly four times the rate of users who never hit it. The friction was working as designed. Without clean per-user usage data, I would have probably weakened the limit and lost revenue for no reason.

If you are building a Chrome extension

If you are an indie developer or small team shipping a Chrome extension, here is the short version of everything above.

Stop trying to make GA4 work inside an extension. The fundamental assumptions of web analytics — first-party cookies, persistent pages, referrer chains, tag managers — do not hold under Manifest V3. You will spend more time fighting your own data than learning from it.

Pick a tool that was designed for the extension environment from the beginning. Crxlytics is the one we use, and the one I would recommend to anyone in the same situation. It is free up to 10,000 monthly active users, which is enough to get a real product into real growth territory before you ever pay anything.

And measure the metrics that actually drive a freemium product: activation, Day 7 retention, time-to-first-value, and conversion to paid. Vanity metrics like installs are easy and meaningless. The real signal is what people do after they install you.

The tooling under Sublo

For anyone curious about the rest of the stack: Sublo is a vanilla TypeScript Chrome extension on Manifest V3, served from a static landing page hosted on Vercel, with subtitles translated through Gemini AI and a small Stripe checkout flow for Pro upgrades. Crxlytics handles all in-extension analytics; the landing page itself uses gtag for top-of-funnel attribution. That is the entire data layer.

Keeping this stack small has been one of the best decisions I made early on. Every tool that earns a place in it has to genuinely solve a problem that the others cannot. Analytics was the last gap that took the longest to fill correctly — and now that it is filled, the rest of the product loop runs cleanly.