How to connect your CRM with Google Analytics 4

What the CRM knows that GA4 does not

GA4 records what a browser did on your site: sessions, sources, events, online purchases. It stops at the form submission or the checkout.

The CRM or ERP holds what happened afterwards:

• whether the lead was qualified, and by whom
• whether the deal closed, when, and for how much
• orders placed by phone or in a shop
• refunds, cancellations and repeat purchases
• customer attributes such as segment, plan or lifetime value

Marketing decisions need both halves. A campaign that brings many form fills and no closed deals looks good in GA4 and bad in the CRM, and only the combined view shows it.

First: store a GA4 identifier in the CRM

No route works without a key that exists on both sides.

To capture the Client ID, read it with gtag('get', 'G-XXXXXXXXXX', 'client_id', callback) when a form loads, write it into a hidden field, and save it on the lead or order record. The details are in the guide to the GA4 Client ID. The form tracking itself is covered in form tracking with GTM and GA4.

Do this before anything else. CRM records created before the field existed cannot be matched later.

Route 1. Import user data into GA4

GA4’s Data import accepts user data: attributes from your CRM, such as a loyalty rating or customer lifetime value, “which you can use to create segments and remarketing lists” (About Data Import, checked October 2026).

Two variants exist, by User ID and by Client ID. You upload a file with the identifier in one column and the attributes in the others. GA4 writes them to the matching users as user properties.

1. In GA4, register the attributes as user-scoped custom dimensions.
2. Export a file from the CRM: one row per customer, with the identifier and the attribute columns.
3. Open Admin, Data collection and modification, Data import, and create a data source of the type user data.
4. Upload the CSV, or set up SFTP for a scheduled upload, and map the columns.

What to know before you rely on it:

• It is joined at processing time. User data becomes part of the collected data and is included in the BigQuery export. It also means it cannot simply be deleted: Google notes that removing it requires a user or data deletion.
• It applies from the upload onwards. Events collected before the upload are not rewritten.
• Up to 10 user data import sources per property, 1 GB per source, 120 uploads per property per day.
• No personal data. Email addresses, names and phone numbers must not be uploaded as attributes.

Use this route when you want GA4 audiences built on CRM attributes, for example “customers on the annual plan”, to use in Google Ads.

Route 2. Send offline events to GA4

When the fact you want in GA4 is something that happened, such as a deal won or an order paid by invoice, send it as an event. There are two ways.

Event data import. A file of events with their timestamp and identifier, uploaded through Data import. Google describes it as importing “events not previously captured in real-time”, including from sources without an internet connection.

The Measurement Protocol. An HTTP request from your server to GA4 at the moment the CRM status changes. Google’s description: it lets you “record server-to-server and offline interactions” and one of its listed uses is to “tie online to offline behavior” (Measurement Protocol, checked October 2026). Each request carries the client_id you stored, and the event name and parameters you choose.

Two conditions from Google’s page: the Measurement Protocol supplements tagging and does not replace it, so the site still needs the Google tag; and the event has to reference a Client ID that the tag created. How the requests are built is covered in the guide to the GA4 Measurement Protocol.

Use this route when you want “deal won” as a key event in GA4, so that GA4’s attribution and Google Ads bidding can use it.

Where the GA4 routes stop

Both routes put a simplified copy of CRM data into a tool built for web sessions. That has consequences:

• GA4 keeps the event, not the record. A deal that changes stage, amount or owner four times is four events, and GA4 has no notion of the current state.
• Corrections are hard. A refunded order or a deal reopened and lost cannot be edited in GA4’s collected data.
• Retention is limited. Explorations work on event-level data kept for 2 months by default and 14 months at most on a standard property. Sales cycles and repeat purchase analysis often need longer.
• Matching is partial. Only records with a stored identifier arrive. Phone leads, imported lists and deals created by sales by hand are missing, and GA4 does not show you how many.
• Sampling and thresholds apply to the reports built on top, as described in data sampling in GA4.

For an analyst, the last two are the real problem. The number in the report is “CRM revenue by channel, for the part of the CRM that could be matched, as GA4 was able to store it”. Nobody reading the dashboard sees that qualifier.

Route 3. Join GA4 and CRM data in your warehouse

The third route goes the other way. GA4 exports its raw events to BigQuery through a native link, and each event carries user_pseudo_id, the Client ID, and user_id if you set one. The CRM data stays what it is, a table of leads, deals or orders, and the two are joined in SQL.

This query runs as written. The crm_deals part stands in for your CRM table, with three Client IDs taken from Google’s public GA4 sample:

WITH crm_deals AS (
  SELECT '88126277.5389735832' AS ga_client_id,
         'won' AS deal_status,
         1200 AS deal_amount
  UNION ALL
  SELECT '12545442.9053678590', 'lost', 0
  UNION ALL
  SELECT '2095299.8404862362', 'won', 450
),
ga_users AS (
  SELECT
    user_pseudo_id,
    ANY_VALUE(traffic_source.medium)
      AS first_medium,
    COUNT(DISTINCT (
      SELECT value.int_value
      FROM UNNEST(event_params)
      WHERE key = 'ga_session_id')) AS sessions
  FROM
    `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_*`
  WHERE _TABLE_SUFFIX BETWEEN '20210101' AND '20210131'
  GROUP BY user_pseudo_id
)
SELECT
  d.ga_client_id,
  d.deal_status,
  d.deal_amount,
  g.first_medium,
  g.sessions
FROM crm_deals AS d
LEFT JOIN ga_users AS g
  ON g.user_pseudo_id = d.ga_client_id

The placeholder mediums in two rows come from the sample, where Google obfuscated part of the data. On your own export they are your real sources.

What this route gives you that the first two do not:

• The CRM record stays whole. Current stage, amount and refunds come from the CRM table as it is today.
• Unmatched records are visible. The LEFT JOIN keeps deals with no GA4 match, so you can count them instead of losing them.
• No GA4 retention limit. The export is yours for as long as you keep it.
• Other tables join the same way: ad spend, product costs, subscriptions.

What it needs: the GA4 property linked to BigQuery, which is covered in connecting GA4 to BigQuery, the CRM data in the same warehouse, and someone who writes SQL.

Which route to choose

The routes do not exclude each other. Many teams send one offline key event to GA4 for bidding and do their reporting from the warehouse.

Make the join reusable

The join above is short. The work is in agreeing what it means: which deals count, what “first source” is, what happens to unmatched records. If that agreement lives in one analyst’s query, every new question starts with rewriting it.

OWOX Data Marts is built for that step. The analyst saves the SQL as a Data Mart on the warehouse, describes the fields and the rules, and publishes it. Reports on it are delivered to Google Sheets or Data Studio (the former Looker Studio) on a schedule, and business users build their own from the published fields without touching the SQL.

OWOX Data Marts is not a CRM connector and not a GA4 connector: it works on tables that are already in your warehouse, and the join stays the analyst’s. How raw GA4 export tables become reporting tables is described in GA4 export to BigQuery and data modeling.

ReportingEnrich Digital Marketing Reports with Sales DataMarch 7, 2024→GA4GA4 metrics and dimensions: the key ones explainedFebruary 15, 2024→Data IntegrationCRM and digital marketing data integration: a practical guideSeptember 30, 2026→

See all articles →