Why we built our own analytics instead of wrapping GA4

Every other AI search visibility tool wraps GA4 and calls it analytics. Plug in your GA4 property, get a "sessions from chatgpt.com" filter, ship it. The whole feature takes two weeks.

We didn't do that. Citare's Web Analytics, shipped this week, is a from-scratch first-party cookieless beacon — closer in shape to Plausible than to a GA4 plugin. It cost us four working days to build the MVP and a future of ongoing maintenance instead of a vendor-managed dependency.

Three reasons we paid that cost.

1. The marketing promise we made required it

Citare’s product copy says "cookieless first-party analytics, privacy-friendly out of the box." We shipped that copy onto every marketing page months before the analytics product existed. The honest options once we were ready to build:

Wrap GA4 and quietly retract the marketing claim. GA4 sets multiple cookies, lives behind a cookie banner in the EU, and routes visitor data through Google’s servers. None of that is "first-party" or "cookieless."
Wrap Cloudflare Web Analytics. CF’s product is cookieless and free but only works for sites already routing through a Cloudflare zone — which excludes most of our SMB target customers — and gives us no product control over the data shape.
Build our own.

Option 3 was the only one that lets the marketing page stay honest. Option 1 would have been a sales liability six months from now. Option 2 was a product compromise that constrained our roadmap.

2. The actual differentiation only works with owned data

Citare’s entire pitch is unified SEO + AI search intelligence — one dashboard for both jobs. The dashboard is only useful if the data sources can be cross-referenced at query time.

A concrete example: a customer’s Brand Radar shows an unusual citation spike on the query "best B2B HR tools" inside ChatGPT this week. What should they do? Useful answer: pivot to Web Analytics and check whether referral traffic from chatgpt.com also spiked, and which landing pages the citation surge directed visitors to.

That cross-reference is two clicks if the analytics data lives in our database. It’s a multi-hour engineering project if the data lives in a customer’s GA4 property we have to query via API every time someone opens the dashboard. We tested the API-shim approach in an early prototype and the latency was unacceptable.

The integrated dashboard is the product. Web Analytics had to be inside it.

3. GA4 is going the other direction

Google deprecates products. Universal Analytics shut off in mid-2024. GA4 itself has been through three major schema changes since launch. Every time Google ships a breaking change, every wrapper has to scramble.

More fundamentally: Google’s product-direction signals on GA4 point at deeper integration with Google Ads, BigQuery, and Google’s identity stack. The product Google is building is an attribution platform for paid media buyers. That’s a perfectly valid product — it’s just not the product an SEO-focused customer wants.

When we model the next five years, we want our analytics layer aligned with our customers’ trajectory, not Google’s. SEO teams want lighter privacy footprints, fewer third-party dependencies, and unified measurement across channels Google doesn’t own (ChatGPT, Claude, Perplexity, Brave). Owning the analytics layer is the only way to deliver that.

What we actually built

The technical shape, briefly:

Beacon endpoint on a dedicated subdomain (wa.citare.ai) so the snippet runs cross-origin from the customer site and zero cookies tag along. Same Plausible pattern.
1.5KB minified snippet, no dependencies, defers behind page interactive, fires on initial load + SPA pushState/popstate, honors Do Not Track and Sec-GPC before firing at all.
Cloudflare Analytics Engine for ingest. One event per pageview, ~$0.25 per million events. Worker free tier on the beacon route carries 10M req/day.
Daily salt-rotating visitor hash: SHA-256 of (daily_salt || ip || ua || property_id), truncated to 8 bytes. Same person on day 2 is mathematically a different visitor. IPs are never written to storage — only the hash and the ISO2 country code from Cloudflare’s edge.
Postgres rollup at 03:30 UTC daily — AE SQL queries aggregate yesterday’s events into seo_daily_metrics rows with source='citare-wa'. Dashboard reads from Postgres, never from AE directly. Same read path as every other Citare tile.
Real-time view at the dashboard level queries AE directly for the last 30 minutes — paid-tier hook because AE reads are the only expensive part of the system.
Opt-out endpoint at wa.citare.ai/wa-opt-out sets a cookie scoped to the beacon subdomain. One click covers every Citare-tracked site for a year.

Full technical writeup lives at /web-analytics.

What we deliberately did NOT build

Two things we passed on, and why.

E-commerce attribution funnels. GA4’s e-commerce module covers a real need. We’re not the right team to build that, and the customer who needs deep e-commerce attribution should keep GA4 and use Citare alongside. Our analytics is for SEO-driven sites where the question is "is search traffic working" — not "which paid funnel converted to revenue."

BigQuery export. Useful for enterprises with data teams. Out of scope for a v1 MVP serving primarily SMB + agency customers. We have a REST API and an MCP server for programmatic access; that covers the data-portability requirement without the engineering investment in BQ export pipelines. Will revisit if Enterprise customer demand surfaces.

The bet

Building owned analytics is a long-tail bet, not a short-term wedge. Three months in, customers won’t care. Six months in, the customers who care about cookieless + GDPR-clean + integrated will be self-selecting toward us instead of Plausible+Ahrefs+Profound. A year in, every team running serious AI search measurement will look at three-tool stacks (analytics + SEO + AI search) and ask why it’s not one product.

We’ve built our part of the answer to that question. The work shipped this week.

Try Citare Web Analytics free — 1 property, 30-day retention, full dashboard. No cookie banner required.