Aptabase vs Moderok for Browser Extension Analytics

Yes, Aptabase works in a Chrome extension. It publishes @aptabase/browser, described in its own README as "A tiny SDK (1 kB) to instrument your Browser/Chrome extensions" (Aptabase, as of September 2026). The choice between it and Moderok is what each counts. Aptabase counts anonymous sessions and, by its README, "does not automatically track any events" (Aptabase, as of September 2026). Moderok counts a persistent anonymous profile and sends install, update, first open, daily activity and error events without you wiring them.

TL;DR: Both SDKs are written for the MV3 background service worker. Aptabase's browser source expires its session id after an hour of inactivity (Aptabase source, as of September 2026), and its README says "This SDK does not automatically track any events" (Aptabase, as of September 2026), so installs, updates and retention are yours to instrument. Moderok ships those lifecycle events by default (automatic events) and needs only the storage permission (manifest). Aptabase's project README offers a self-hosting path (Aptabase, as of September 2026); Moderok has no self-hosted build.

The 30-second comparison

Every Aptabase cell is what its own pages said when we opened them on 18 September 2026.

Round 1Does the Aptabase Chrome extension SDK run in an MV3 service worker?

Both are written for it, and Aptabase's source refuses anything else. It guards the entry point with const isWebContext = 'document' in globalThis;, and init() bails out with "@aptabase/browser can only be initialized in your background script." when that is true; trackEvent called from a popup or content script relays to the background through chrome.runtime.sendMessage instead (Aptabase source, as of September 2026).

One detail worth knowing: that file awaits chrome.management.getSelf() in init() and registers chrome.runtime.onMessage afterwards. Chrome's guidance is that service worker event handlers "should be at the top level of the script and not be nested inside functions", so "they are registered synchronously on initial script execution" (developer.chrome.com). A message that wakes a terminated worker can arrive before a listener registered after an await exists. Neither call costs a permission warning: Chrome documents that management.getSelf() does "not require the management permission" (developer.chrome.com), and the session id in that file lives in chrome.storage.local.

Moderok meets the constraint from the other direction: Moderok.init() goes at the top level of the background entry point before any await, so the chrome.runtime.onInstalled listener registers on that first synchronous pass (init). It also needs only storage (manifest), has zero runtime dependencies, and its minified build measured 5,671 bytes gzipped on 2 August 2026.

Round 2Sessions or users?

These two answer different questions, and this round should decide yours. Aptabase is session shaped: its browser source sets const SESSION_TIMEOUT = 1 * 60 * 60; (one hour), stores _ab_session_id in chrome.storage.local, and mints a new id once the gap since the last event exceeds it (Aptabase source, as of September 2026). That is deliberate. Its extension page says "Aptabase does not use device identifiers, cookies, fingerprinting nor long-term user identification" (Aptabase, as of September 2026). If nothing identifies a user beyond an hour, nothing tells you whether Monday's installer was still there on Friday. Sessions measure usage intensity, not population.

Moderok assigns a random anonymous id per extension profile and keeps it in chrome.storage (privacy). It may be recovered through browser sync, so read it as a profile, not a device count. On top of it sits __daily_ping, sent at most once per UTC day per user, which is what makes daily, weekly and monthly actives and engaged users possible in the dashboard. Net churn and uninstalls by tenure come from __install plus the opt-in uninstall ping below. If "how many people actually use this" is your question, how many users does my Chrome extension really have covers which denominator answers it.

Round 3The events an extension actually has

An extension's interesting moments are installs, updates, uninstalls and whether anyone came back today. With Aptabase, none arrive on their own. The README is direct: "This SDK does not automatically track any events, you need to call trackEvent manually", followed by the advice that "it's generally recommended to at least track an event at startup" (Aptabase, as of September 2026). The chrome.runtime.onInstalled listener, the branch on details.reason, the definition of a daily active and the chrome.runtime.setUninstallURL() call are yours to write: that README documents only init and trackEvent (Aptabase, as of September 2026).

Moderok sends __install, __update, __first_open, __daily_ping and __error with no track() call, and __update may carry previousVersion (automatic events). Uninstall attribution is an opt-in trackUninstalls: true on init() (uninstall tracking).

Round 4Error tracking

Aptabase's browser README documents two functions, init and trackEvent (Aptabase, as of September 2026). Crashes in your service worker are yours to catch and report.

Moderok records uncaught exceptions and unhandled promise rejections as __error in every context where init() ran, on by default, plus captureError() for handled failures and captureLastError() for callback style APIs, where Chrome puts the failure in chrome.runtime.lastError instead of throwing (error tracking).

Round 5Price and where the data lives

Aptabase's pricing page today lists a free tier of 20,000 events per month and eight paid tiers, from $10 for 200,000 events up to $450 for 50,000,000, with $140 at 10,000,000. Its FAQ says "You will not be charged any overage fees" and that past the monthly limit "we will temporarily disable your analytics until the start of the next month". All plans list "EU or US data residency", a "Live View Dashboard", "Session Timeline" and "Export to CSV" (Aptabase, as of September 2026). The project README also says "You can also host Aptabase on your servers. It's free, but you are responsible for maintenance and updates" (Aptabase, as of September 2026).

Moderok's free plan includes 1M events per month, Pro is $29 per month for 10M and Team $149 for 100M, and every plan carries Trends, Events, Logs and two years of history (pricing). Moderok has no self-hosted build.

When Aptabase is the right choice

Take Aptabase if any of this is you:

• You ship more than an extension. Aptabase publishes SDKs for Swift, Kotlin, React Native, Flutter, Tauri, Electron, Unity and more (Aptabase, as of September 2026). If your extension is one surface of a product that also has a desktop or mobile app, one dashboard across all of it beats extension metrics.
• You want to self-host. Moderok has no equivalent, so if your data must sit on your own infrastructure, that decides it.
• Your privacy stance forbids a persistent identifier. "Aptabase does not use device identifiers, cookies, fingerprinting nor long-term user identification" (Aptabase, as of September 2026) is a commitment Moderok's profile id does not make.
• You want session timelines. "Session Timeline" is listed on every Aptabase plan (Aptabase, as of September 2026) and is not something Moderok offers.

What you give up is the extension shaped half: installs and updates as events, uninstall attribution, retention by tenure, automatic error capture. For the wider field, see our roundup of Chrome extension analytics tools.

If extension lifecycle metrics are why you are shopping, that is what Moderok is built around: install @moderok/sdk, add the storage permission, call Moderok.init() in the background service worker, and installs, updates, daily actives and errors arrive without further wiring. Start with the getting started guide, or see what the dashboard shows.