How to Switch from Google Analytics to PostHog Without Losing Data

Three settings protect data from the first day. Make them before you change any tag:

1. Link the BigQuery export. In GA4 Admin, open Product links → BigQuery links and link a Google Cloud project with billing enabled. (+) The free BigQuery sandbox deletes tables after 60 days. (+)
2. Check the export cap. A standard property’s daily export is capped at 1 million events a day. If a property keeps exceeding it, Google pauses the daily export and doesn’t reprocess the missed days. Streaming export has no event limit and costs an extra $0.05 per gigabyte, roughly 600,000 events. (+ / +)
3. Raise event-data retention to 14 months. Explorations and funnel reports keep event-level data only for the retention period; standard reports aren’t affected. Raising it also applies to data not yet deleted. (+)

Then list what depends on GA4 and decide, for each item, whether PostHog replaces it, GA4 keeps it or it retires:

• Collection: the GA4 property, its data streams and every sender, including Google Tag Manager containers and server-side tags, with the person who can change each.
• Key events: each key event’s trigger, counting rule, value, currency and transaction ID.
• Reports: the metrics, filters, attribution settings, time zone and conversion windows behind the reports people use. Export the explorations you will need later.
• Google Ads: conversion actions imported from GA4 key events, audiences shared for remarketing and reports that rely on the Ads link.
• Other Google links: Search Console reports, Google signals demographics and anything else that exists only because GA4 is linked.

Use an event tracking plan for the event and metric definitions. A named owner and a decision beside each item stop a removed tag from silently taking a bidding input or a management metric with it.

Add PostHog alongside GA4 and leave GA4’s collection untouched until the switch. Create a project your company owns, in the region where your data must live, with the account setup guide, then choose one installation path for each surface:

• Shopify: follow the storefront and checkout installation, and check that the checkout outcome joins the visitor who started the journey.
• WordPress: use the WordPress installation, and check for an existing plugin, tag-manager or theme copy before adding another.
• ClickFunnels: use the funnel installation, and check every published step, including pages on another domain.
• Google Tag Manager: if GA4 runs through a container, you can add the PostHog snippet as a Custom HTML tag on all pages and capture custom events from tags fired by the triggers you already use. (+)

Follow a permitted test journey from the landing page to a completed action. In PostHog Activity, inspect the pageviews, event properties, visitor identity and outcome; repeat a refresh and a failed action to look for duplicate or premature conversions.

Apply the internal-user rules to the reports you will compare, and keep the UTM naming convention on campaign links. Test consent accepted, refused and withdrawn before sending customer traffic through the new setup.

Map the meaning and trigger of each event, then choose its PostHog name and properties. Recreate the business metric from that definition; copying the event label alone does not preserve the conversion.

These are mapping examples, not PostHog default business-event names. PostHog’s migration procedure maps GA4 page_view to $pageview, converts timestamps, and translates nested GA4 fields into event and person properties. (+)

For every important metric, test the numerator and denominator: purchases per eligible visitor is different from purchase-event count. Keep the conversion window, time zone, refunds and test exclusions explicit, then rebuild the reports from that contract.

Agree how historical GA4 identifiers relate to the IDs used by the live installation. Keep the original GA4 ID as provenance; use a stable internal customer ID for a known-person join only when your records establish the relationship. Do not manufacture a cross-tool identity from a similar timestamp or purchase value.

Expect PostHog to record more pageviews and visitors than GA4. Almost every ad blocker blocks Google Analytics, while PostHog’s requests are not always blocked. (+) Where Consent Mode is on, GA4 can add modeled activity for visitors who refused consent; PostHog counts only the events it collects. The GA4 comparison explains that modeling. Compare like with like:

• Collection: compare the same live pages, dates, consent states and device segments; inspect missing and duplicated events before interpreting a percentage gap.
• People and sessions: compare the identity unit and session rules rather than assuming a visitor in one report equals a user in another.
• Filtering: align internal and test exclusions, then investigate whether bot treatment explains a particular segment.
• Conversions: match unique transaction or lead IDs against the system that owns the outcome, then compare values and timing.

A reverse proxy sends PostHog’s requests through your own subdomain, which ad blockers block less often. PostHog says it typically raises event capture by 10–30%, and its managed proxy is free on PostHog Cloud. (+) Keep the same consent rules on that route. A proxy narrows the collection gap; it doesn’t make identity or reporting definitions identical.

Plan for two to four weeks of parallel collection, longer if purchases or qualified leads take longer to arrive. Use the PostHog audit to explain gaps by source and journey; a stable overall total can hide a missing checkout path.

Import the raw GA4 event rows from BigQuery, converted to PostHog’s schema, with historical migration turned on. The import needs PostHog’s pay-as-you-go plan, which has no base fee; imported events aren’t billed. (+ / +)

1. Find the dates you have. Query the earliest and latest daily tables and the streams they cover. That range is the history you can import; earlier dates stay in GA4’s reports. If the export isn’t linked yet, link it now: its history starts that day.
2. Use the daily tables. Allow for late-arriving events. Streaming export is best effort, and Google recommends daily tables for user-attribution data. (+)
3. Convert a sample. Apply the event map, flatten the nested fields you need, and carry the IDs, source fields, values and currencies your metrics use. Keep the raw rows.
4. Import into a separate validation project first. Use the Python SDK with historical_migration=True, the project token and the regional host. (+) Check event names, dates, property types and customer joins before importing the full range.
5. Set the boundary before the full import. Import only events from before live PostHog collection started, and at least 48 hours old. PostHog can’t delete imported events afterward, so exclude the overlap before sending, and record each processed date range so a retry doesn’t send the same days twice. (+)
6. Reconcile. Compare imported rows and unique business IDs with the export by day and event, in one time zone: GA4’s event_date follows the property’s time zone, while event_timestamp is in UTC. (+)

PostHog’s example import script is a starting point. (+) Change four things before you run it on a real property:

• Timestamps: GA4’s event_timestamp counts microseconds in UTC. Convert it as UTC; the example uses the machine’s local time zone, which shifts every event on a server not set to UTC.
• Ecommerce items: GA4 stores items as records with fields such as item_id, item_name and price. Map those fields explicitly; the example reads them as key-value pairs, which breaks on item records.
• Engagement events: GA4 sends user_engagement when a page has been in focus for at least a second. (+) Don’t map it to $autocapture as the example does; those events aren’t interactions.
• Sessions and channels: set $session_id as a UUIDv7 that follows PostHog’s rules, and carry the UTM and referrer fields. Without them, imported dates appear in trends and funnels but can’t be grouped into sessions or channels. (+)

Google’s export holds the raw events GA4 received; the GA4 interface can apply processing the export doesn’t contain. (+) Importing event rows doesn’t bring the old dashboards, key-event settings or modeled values, so keep the GA4 reports you need as an archive.

Partly. GA4 does three jobs for Google Ads, and each needs its own replacement:

• Conversions for bidding. Conversions imported from GA4 key events stop when GA4 stops collecting. (+) For purchases and leads completed in the same visit, replace them with a Google tag conversion action, which doesn’t need GA4. PostHog’s Google Ads destination suits outcomes that come at least six hours after the click, such as qualified leads, trials that convert to paid and renewals. It needs the click ID or hashed contact details, and it is experimental, without official support. (+) Our Google Ads conversion guide covers its setup and the six-hour limit.
• Campaign reporting. PostHog can’t use Google Ads auto-tagging for attribution, so add UTM parameters with a tracking template. (+) PostHog’s Marketing Analytics, an opt-in beta, can bring ad costs into the same reports. (+)
• Audiences and Ads-linked reports. Remarketing audiences built in GA4 and reports that depend on the Ads link stay in GA4. Keep GA4 running for them while you use them.

Don’t send the same conversion through two uncoordinated paths, and never send imported historical purchases as new ad conversions. Record which sender owns each conversion action, and move bidding to a new action only after it records conversions you can match to orders. Our ad-conversion overview compares the senders.

Make PostHog the default only when the required events and reports work, historical coverage is documented, count differences are explained, and every Google Ads job has a verified replacement. Agree those conditions before choosing a switch date.

• Trace a real outcome from the payment or CRM record back to its PostHog event, customer and acquisition context.
• Rebuild the reports people actually use, with the agreed filters, definitions and conversion windows.
• Document the imported range, live-collection boundary and any history that remains only in GA4 or the archive.
• Get the report and advertising owners to confirm their replacements work.
• Record the tags that can stop, the GA4 functions that stay, and how to restore collection if a gap appears.

Keep access to the GA4 property and raw exports after the switch. Remove only collection paths whose dependencies have been replaced, and review the first full reporting period in PostHog against the same business-system records.