datibase
try free

Migrate from Google Analytics to Datibase: A Step-by-Step Guide

A practical playbook — not a sales pitch. Most teams can complete the move in an afternoon.

9 min read

Migrating off Google Analytics has a reputation for being painful. In practice, for most SaaS sites, the technical work takes about an hour. The reason teams put it off is that there is no obvious checklist — you are juggling script tags, consent banners, GA4 property settings, and historical data export, and the order matters.

This guide is the checklist. It assumes you are moving from GA4 to Datibase, but most steps apply to any cookie-free alternative.

Before you start: decide what you actually need

GA4 collects far more than most SaaS teams use. Before you migrate anything, write down what you actually look at week to week. For most indie founders the list is short:

  • Daily and weekly visitor counts
  • Top pages and entry points
  • Referrer sources (organic, direct, social, ad campaigns)
  • Country / device / browser breakdown
  • Conversion events (signup, paid)
  • Revenue attribution if you sell something

If your list looks like that, a cookie-free tool covers it. If it includes multi-day funnels, audience segments, or cross-device user journeys, read Cookieless Tracking Explained first to understand the trade-offs before you commit.

Step 1: Export your historical GA data

Once you remove the GA tag, new data stops flowing — but Google will keep the old data for the property's retention period (default 14 months on the free tier). You can leave the GA property in place for read-only access, but exporting now is the safe move.

  1. 1In GA4, open Reports → Library and use the Share menu to export each report you reference regularly as CSV.
  2. 2For deeper history, use the BigQuery export if you have it configured. Otherwise the Data API can pull aggregated metrics for any date range.
  3. 3Save year-over-year acquisition reports separately — these are the only GA reports most teams miss after migrating, and they are easy to forget about.

Step 2: Install the Datibase script

Grab your site's tracking code from Dashboard → your website → install_tracker, then drop a single script tag into your site. The loader is async and tiny, so there is no measurable impact on page speed.

<!-- in your <head>, alongside or replacing the GA tag -->
<script async
  src="https://datibase.dev/api/tracker/<code>"
></script>

The site is identified by the <code> path segment, not by a domain attribute — copy it from the dashboard verbatim. For Next.js, drop it into your root layout using next/script with strategy="afterInteractive". For Vite/SPA frameworks, the plain <script> tag in index.html is fine. The dashboard has copy-pasteable snippets for React, Nuxt, SvelteKit, Astro, and Remix as well.

Open your site, hit refresh, and check the Datibase dashboard — the first pageview should appear within seconds. If it doesn't, the Network tab in DevTools will show a POST to /api/analytics/pageview; the status code tells you what's wrong (404 from /api/tracker/<code> means the tracking code is wrong, status 0 means an ad blocker).

Step 3: Run both side by side for a week

Resist the urge to remove GA immediately. Running both for 5–7 days gives you a comparison baseline so you can answer the inevitable "the new tool is undercounting" question with data instead of vibes.

Expect Datibase to show 5–25% lower visitor counts than GA on most sites. This is not undercounting — it is GA over-counting because of bot traffic GA fails to filter. If your numbers diverge by more than that, look for one of these:

  • Ad blockers: GA is the most-blocked script on the web. uBlock Origin and most privacy extensions block it but allow cookieless tools through. Datibase will look higher than GA for traffic from technical audiences.
  • Bot traffic: GA's bot filter is permissive. Cookieless tools tend to filter more aggressively because they require a real JavaScript engine. Expect headless / scripted traffic to disappear.
  • Sub-domains: GA4 properties often roll up multiple subdomains. Make sure the Datibase site config matches whichever domains GA was tracking.
  • Internal traffic: If GA had an IP filter excluding your office or VPN, replicate that in Datibase under settings → exclusions.

Step 4: Map your custom events

GA4 events translate one-to-one. The signature is nearly identical — the first argument stays as the literal "event":

// before — GA4
gtag("event", "signup", { plan: "pro" });

// after — Datibase
datibase("event", "signup", { plan: "pro" });

A common gotcha: dropping the literal "event" argument silently no-ops. The call goes onto the queue but does not match any handler, so nothing fires and nothing errors. If an event isn't showing up, check that first.

Two practical notes. First, you do not need to register events ahead of time — Datibase shows any event name that fires at least once. Second, keep custom property values low-cardinality (plan tier, country, source) and avoid putting raw user IDs or emails in there. Aggregations are computed across these values, so high cardinality both costs money and leaks identifiers.

Step 5: Connect revenue (if you sell something)

The most common reason teams migrate to Datibase specifically is to see revenue alongside traffic. Connect Stripe (or Polar) once and revenue starts appearing on your dashboard:

  1. 1Dashboard → Settings → Revenue → Connect Stripe.
  2. 2After login, call datibase.identify({ customerId }) once with the Stripe customer ID. This is the only line of code required for attribution.
  3. 3Revenue by referrer source appears on your dashboard within minutes of the next webhook event.

For the full picture, see How to See Stripe Revenue Alongside Website Traffic.

Step 6: Remove GA and the cookie banner

Once you trust the new numbers, remove the GA snippet. Then audit your remaining cookies — chances are the GA cookies were the only things triggering your banner.

# in DevTools → Application → Cookies
before: _ga, _ga_*, _gid, _gat (analytics)
after:  session, csrf-token (strictly necessary)

If your remaining cookies are all strictly necessary — auth sessions, CSRF tokens, checkout state — most jurisdictions allow you to drop the banner. See GDPR Compliance Without a Cookie Banner for the full audit. Don't forget to update your privacy policy to reflect the simpler tracking setup.

Common pitfalls

  • Forgetting Google Tag Manager: If you load GA through GTM, removing the GA tag is not enough — GTM itself sets cookies. Either remove GTM entirely or restrict it to non-cookie-setting tags.
  • Conversion tracking on Google Ads: If you run Google Ads, conversions from GA4 stop reporting once you remove it. Switch to Google Ads Enhanced Conversions or accept the attribution gap.
  • Server-side referral tracking: GA's referrer detection is opaque and includes manual exclusion lists. Cookieless tools do this client-side from document.referrer, so check your referrer report a few days in.
  • Country mismatch: Datibase resolves country from IP geolocation; GA uses both IP and account-level location signals. Expect ~5% disagreement, especially for users on VPNs.

The bottom line

Migrating off GA is a one-afternoon project for most SaaS sites. The technical work — install a script, map a few events, remove the old tag — is small. The harder part is letting go of metrics you rarely look at but feel obligated to keep, like multi-day funnels and audience segments.

Once it is done, you get a faster site, no cookie banner, a simpler privacy policy, and analytics that loads in under a second instead of three. For most teams, the only regret is not doing it sooner.

ready when you are

Try Datibase before you commit

Free during the trial period. Install the script, run it alongside GA, and see the numbers yourself before you remove anything.

Try Datibase free