Webclat logoWebclat . | Amplitude Solutions

Guide - integration

Stream Amplitude events to Google Analytics 4

What it is, when you actually need it, how to implement it without the common mistakes, and how to confirm it worked.

In short

Amplitude's GA4 destination streams the same events you're already capturing in Amplitude out to Google Analytics 4 on web, iOS, and Android, so teams that need a GA4 record - for Google Ads integration, a stakeholder who lives in GA4, or a compliance requirement - don't have to instrument and maintain two separate tracking implementations in application code. It is an event-forwarding integration, not a two-way sync: GA4 does not send anything back to Amplitude through this destination.

What it is

This destination takes events already flowing into Amplitude and re-sends them to GA4's Measurement Protocol, separately for web and for the iOS/Android SDKs (they are documented and configured as distinct destinations, since the underlying platform SDKs and identifiers differ). The event and property names on the GA4 side follow whatever mapping you configure, since Amplitude's and GA4's naming and property models aren't identical.

It exists specifically so a single instrumentation effort (one tracking plan, one set of Amplitude SDK calls in your codebase) can serve two analytics destinations, rather than asking engineering to fire two separate SDKs from every tracked interaction - the classic dual-tagging maintenance burden this integration is built to remove.

When you need it

Implementation, done properly

  1. Treat your Amplitude tracking plan as the single source of truth and build the GA4 mapping from it - deciding case-by-case which Amplitude events and properties actually need a GA4 equivalent, rather than mirroring everything by default and inheriting Amplitude's full event volume (and its cost) on the GA4 side too.
  2. Configure the web and mobile GA4 destinations separately, since they're documented as distinct integrations with their own identifier and setup requirements - a web-only setup will not automatically cover your iOS or Android event stream.
  3. Map identity carefully: GA4's client ID and user ID model doesn't map one-to-one onto Amplitude's device ID and user ID model, so decide explicitly how anonymous and identified users translate across, rather than letting a default mapping quietly produce inflated or fragmented user counts on the GA4 side.
  4. Where the reason for streaming is Google Ads conversion import specifically, map only the true conversion events (not the full event catalog) to GA4 conversions, and set conversion values deliberately rather than leaving them unset - an unset or misconfigured conversion value breaks Google's value-based bidding even when the event itself streams successfully.
  5. Document, visibly, which system (Amplitude or GA4) is the source of truth for which stakeholder - a streamed integration that leaves two teams each trusting a different number for the same metric recreates the exact "our numbers don't match" problem a single-instrumentation setup was supposed to prevent.

How to verify it worked

  1. In GA4's DebugView (or the mobile SDK's equivalent real-time debug tooling), trigger a tracked action in your app and confirm the corresponding event arrives with the property values you expect, not just that an event of some kind shows up.
  2. Cross-check a day's event counts for a specific, well-understood event between Amplitude's Events explorer and GA4's own reporting for the same window - expect some variance from differing session and identity models, but a large unexplained gap points to a mapping or filtering issue in the destination configuration.
  3. If the integration feeds Google Ads conversion import, confirm in Google Ads' own conversion diagnostics that the conversion action is receiving events with non-zero counts and, where applicable, sensible values - a conversion action stuck at zero after setup almost always traces back to the GA4-side event mapping, not Google Ads itself.
  4. Re-check the mapping after any change to your Amplitude tracking plan - adding, renaming, or restructuring an event on the Amplitude side does not automatically update the GA4 destination mapping, so a tracking-plan change is a standing trigger to re-verify this integration, not a one-time setup step.

Related: Amplitude vs. Google Analytics · GA4 to Amplitude migration · Fixing missing events on Next.js

Frequently asked questions

Does this replace GA4's own tag or SDK entirely?+

It's meant to - the whole point is that GA4 receives its event stream through this destination instead of through its own separately-maintained tag or SDK call in your code, so running both at once will double-count events in GA4. Decide on one source for GA4 events and remove the other.

Will this get us GA4's free-tier reporting features exactly as if we'd tagged natively?+

Most standard GA4 reports work off the same underlying event data regardless of how it arrived, but any GA4 feature that depends on its own native tag behavior (certain auto-collected parameters, for instance) may not populate identically through a forwarded event - verify any specific GA4 report you depend on against current Google documentation before relying on it.

Other guides

Get a free, scored audit of your Amplitude instance

Send us read-only access and get a scored findings report within 48 hours: taxonomy health, duplicate events, governance gaps, and the three fixes with the highest data-trust payoff. No commitment.

Request the free audit