I Built My Own Analytics + AB Testing Tool in a Weekend With Claude Code.

A developer built a custom analytics and A/B testing tool over a weekend using Claude Code, eliminating the need for cookie banners and per-seat pricing. The tool tracks pageviews, runs experiments, replays sessions, and provides AI-generated advice, with the entire pipeline relying on a lightweight JavaScript tracker and Postgres database.

I got tired of two things. Cookie banners, and paying per-seat for a dashboard nobody on my team opened twice. So I built the analytics tool I actually wanted: it watches my landing pages, runs A/B tests, replays sessions, and tells me in plain English what to fix. No banner. No per-seat bill. This three-part series is the whole build, with real code. Part 1 is the pipeline: getting events from a stranger’s browser into my database without slowing their page down. Part 2 is experiments and replays. Part 3 is the AI layer that turns it all into advice. Thanks for reading The GTM Hacker Subscribe for free to receive new posts and support my work. If you can write a <script tag and a Postgres query, you can follow along. Four moving parts, and only the first two run on the open internet: browser → tracker snippet → ingestion server → Postgres → dashboard + AI The tracker is a tiny JavaScript file that lives on your pages. The ingestion server catches what it sends. Postgres stores it. Everything else just reads. That one-directional flow is the reason the whole thing stays simple. Nothing downstream can slow down the part running in your visitor’s browser. I run it as a Turborepo: a tracker workspace, a Hono ingestion server, a Next.js dashboard, and a Drizzle/Postgres package. You don’t need that structure to start. You need a script and an endpoint. The tracker has one number it can’t break: under 5KB gzipped. It runs on real pages where every kilobyte is page-speed you’re stealing from someone. The moment you npm install a convenience library, you’ve blown it. So: vanilla JavaScript, no dependencies, and the recorder for session replay loads separately and lazily more on that in Part 2 . Install is one line: <script src="https://your-ingestion.up.railway.app/pp.js" data-site="site-xxxxxxxx" async </script The script figures out the rest from its own tag: the site ID off data-site, and the endpoint derived from where it was served: js var endpoint = currentScript.getAttribute 'data-endpoint' ;if endpoint { var src = currentScript.src; endpoint = src.substring 0, src.indexOf '/', src.indexOf '//' + 2 + '/api/events';} No cookies means no banner. So identity comes from two cheap tricks. A session ID lives in sessionStorage. It survives clicking around the site and resets when the tab closes: js function getSessionId { var sid = sessionStorage.getItem 'pp sid' ; if sid { sid = Math.random .toString 36 .slice 2 + Date.now .toString 36 ; sessionStorage.setItem 'pp sid', sid ; } return sid;} The visitor ID is a hash of boring, stable browser traits: screen size, timezone, language, a trimmed user-agent. It won’t single anyone out, and that’s the point. It’s just stable enough to tell “same person, second pageview” apart from “two different people.” Coarse, cookieless, no consent required. For conversion analytics, that trade is the right one. Every signal, whether a pageview, a click, a scroll past 50%, or a form field abandoned, is the exact same object. One shape keeps both the sender and the receiver tiny: function track eventType, data { queue.push { type: eventType, ts: Date.now , visitor id: visitorId, session id: sessionId, device: getDeviceType , page: getPageData , // url, referrer, title utm: getUtmParams , // source, medium, campaign... data: data || {}, } ;} Note it goes into a queue, not over the wire. That matters next. Here’s the bug that bites everyone who rolls their own. A visitor converts, then closes the tab. That’s the single most valuable event you’ll ever capture, and a normal fetch dies the instant the page unloads, taking the event with it. The fix is navigator.sendBeacon. The browser promises to deliver it even as the page goes away: js function flush { if queue.length return; var payload = JSON.stringify { site id: siteId, events: queue.splice 0 } ; if navigator.sendBeacon { navigator.sendBeacon endpoint, new Blob payload , { type: 'application/json' } ; } else { var xhr = new XMLHttpRequest ; xhr.open 'POST', endpoint, true ; xhr.setRequestHeader 'Content-Type', 'application/json' ; xhr.send payload ; }} setInterval flush, 5000 ; // batch every 5swindow.addEventListener 'beforeunload', flush ;document.addEventListener 'visibilitychange', function { if document.visibilityState === 'hidden' flush ; // the one that fires on mobile} ; Batch every 5 seconds so you’re not firing a request per click. Flush on the way out so you don’t lose the ending. And listen to visibilitychange, because on phones people switch apps instead of closing tabs, and beforeunload often never fires. The ingestion server is a Hono process and the whole entrypoint is about forty lines. The only non-obvious bit is CORS: the tracker runs on domains you don’t know yet, so early on you allow all origins. The events carry no secrets, so this is fine until you start charging, at which point you tighten it to a per-site allowlist. js app.use ' ', cors { origin: origin = origin || ' ', allowMethods: 'GET', 'POST', 'OPTIONS' } ;app.route '/api/events', eventsRoute ; The handler validates the envelope, flattens each nested event into flat columns, and batch-inserts. A couple of hard-won rules: drop events missing a type or session ID, clamp absurd numbers, and round anything headed for an integer column, because one fractional value will reject the whole batch, and you don’t want a single bad click to lose ninety good ones. It’s all best-effort and silent; the tracker never reads the response, so there’s nothing to say back. Everything lands in one wide, denormalized events table. Wide on purpose: analytics queries filter and group, they almost never join, and joins are where things crawl once you’re past a few million rows. js export const events = pgTable 'events', { eventId: uuid 'event id' .primaryKey .default sql gen random uuid , siteId: text 'site id' .notNull , visitorId: text 'visitor id' .notNull , sessionId: text 'session id' .notNull , eventType: text 'event type' .notNull , url: text 'url' .notNull , // utm , scroll depth, time on page, device type, ab test id, ab variant... metadata: jsonb 'metadata' , timestamp: timestamp 'timestamp', { withTimezone: true } .notNull .defaultNow ,}, t = index 'idx events site ts' .on t.siteId, t.timestamp , index 'idx events site type ts' .on t.siteId, t.eventType, t.timestamp , index 'idx events site visitor' .on t.siteId, t.visitorId , index 'idx events site utm ts' .on t.siteId, t.utmSource, t.timestamp , ; Four indexes, one for each way the dashboard slices: by time, by type over time, by visitor, by channel over time. There’s a JSONB metadata column as an escape hatch: new event types carry extra fields with no migration, and you promote a field to a real column once you’re querying it enough to want an index. I’ll end Part 1 on the thing I’d most want someone to tell me before I started. Do not let your dashboard query the events table directly. Put every read and write behind a handful of functions queryAggregatedStats, queryFunnelPaths, queryDeadClicks in one file. It feels like pointless ceremony on day one. Here’s the payoff. Postgres handles this table happily into the tens of millions of rows. After that you’ll want ClickHouse. With the seam, that migration is rewriting four function bodies. Without it, it’s hunting down every query in your codebase and praying. Pay the small cost now. That’s the pipeline: events leave the browser, survive the tab closing, and land in a table built to grow. In Part 2 https://markdowntorichtext.com/part-2-experiments-and-replays.md I’ll make it earn its keep: running A/B tests with honest statistics, and recording sessions you can actually watch back. This post is the story. The companion docs are the spec: the full version of every snippet above, with the parts I trimmed for readability put back, written precisely enough to build from: How to use them: two ways. Read a doc alongside this post for the full detail. Or drop it straight into Claude Code, say “build me this,” and let it scaffold the component, then use the doc to check what it gave you. They’re written to be unambiguous enough for either. I Built My Own Analytics + AB Testing Tool in a Weekend With Claude Code. https://pub.towardsai.net/i-built-my-own-analytics-ab-testing-tool-in-a-weekend-with-claude-code-c67f411602f7 was originally published in Towards AI https://pub.towardsai.net on Medium, where people are continuing the conversation by highlighting and responding to this story.