Guide

Migrating from Google Analytics

The technical part takes an afternoon. The part that catches people out is that the two tools will never agree on a number, and deciding in advance which one you trust is what makes the switch survivable.

7 minute readCommands included

Start by running both

Put both scripts on the page and leave them there for a few weeks. It costs almost nothing, and it is the only way to build confidence before you turn anything off. Falorb's tracker is under three kilobytes gzipped, so the added weight is not the reason to hurry.

During this period, do not try to reconcile the numbers to the decimal. Establish instead whether the shapes match: do the same days spike, do the same pages lead, does the same channel dominate.

htmlsite head
<script defer
  src="https://a.example.com/t.js"
  data-project="prj_8Kd2mQ"></script>

Expect the numbers to disagree, and know why

Two analytics tools essentially never report the same figure, and the reasons are structural rather than bugs in either one.

  • Bot filtering differs. Falorb filters more than twenty-five signatures at collection and reports crawlers separately, so its visitor count is people.
  • Session definitions differ. Falorb uses a thirty-minute inactivity window, shared between the tracker and the server so the two never disagree with each other.
  • Consent handling differs. If you gate one script and not the other, they are measuring different populations by design.
  • Ad blockers hit vendor hostnames hardest. Serving the collector from your own subdomain usually means Falorb sees traffic Google Analytics does not.

Port the events you actually use

Most GA property configurations accumulate events nobody has looked at in years. A migration is the cheapest moment you will ever get to drop them. Open your reports, list the events something actually depends on, and port only those.

Falorb needs no event declared in advance. Send a name and it appears in the explorer, usually within a minute, and any custom property becomes a filter and a breakdown dimension.

javascriptin your app
falorb.identify(user.id, { email: user.email, plan: 'pro' })
falorb.track('checkout_started', { seats: 3 })
falorb.revenue(99, 'USD')
falorb.reset()  // on sign-out

Rebuild goals rather than importing them

A Falorb goal is an event name or a page path, with the conversion rate computed against the visitors actually in scope for the range and filters applied. There is nothing to import, and rebuilding takes minutes.

Revenue attribution ships with first-touch, last-touch and linear side by side, deliberately. On real data they produce genuinely different answers, and a tool that reports only one is making a strategic decision on your behalf.

What does not come across

Your history. Falorb starts counting when you install it, and there is no import that would make older figures comparable, because the underlying definitions differ. Export what you need from Google for your own records and treat the parallel-running period as the bridge.

The advertising integrations. If conversion data needs to flow back into Google Ads, no self-hosted analytics tool replaces that, and this is the honest reason to keep GA installed alongside rather than instead.

Questions

The usual questions

Do I still need a cookie banner after switching?

That depends on your jurisdiction and your configuration, and it is not a question a vendor should answer for you. Technically: Falorb sets no third-party cookies, stores no raw IP addresses, and has a cookieless mode that persists nothing on the device at all. Many self-hosted deployments run cookieless and drop the banner, but that decision is yours to take with your own advice.

How long should I run both?

Long enough to cover a full business cycle, which for most sites means four to six weeks. You are looking for the shapes to agree, not the totals.

Run it and see

The quickstart is five commands and needs no account anywhere.