CRM vs measurement boundary

E-commerce · CRM. HubSpot, GA4 and the marketing data warehouse.

HubSpot in a store: GA4 vs CRM

Where GA4 measurement ends and HubSpot CRM work begins. How to avoid counting leads twice and comparing reports from two different sources.

GA4 Traffic, events and store purchases

Sessions, campaigns, ecommerce and last-click attribution in analytics reports.

HubSpot Contact, deal and CRM activity

Forms, email sequences, sales pipeline and HubSpot's own attribution model.

See what to agree upfront Join key for the warehouse

Updated: 2026-07-06

Starting point

Why the numbers disagree

In most stores HubSpot is the CRM: contacts, email, sequences, deals. GA4 measures on-site traffic, events and purchases. They are different tools and should stay that way. Problems start when someone compares both numbers as if they meant the same thing.

Marketing looks at campaigns and conversions in GA4. Sales closes deals in HubSpot. Leadership wants one revenue total at month end. Without a written boundary between systems, the question of who actually delivered the result appears very quickly.

A typical stack is a store (Shopify, WooCommerce, Magento), GA4 with GTM, HubSpot for forms and nurturing, sometimes ERP as the revenue source of truth. Each layer defines "order" or "customer" differently. This guide clarifies what each system reports and how to connect them in a warehouse if you need that at all.

Rules before you join data

Agree upfront

Before you connect systems, write down a few simple rules. Otherwise every team will maintain its own spreadsheet with "corrected" numbers.

  • GA4 reports traffic, events and purchase using analytics rules (session, last-click in reports).
  • HubSpot reports contacts, deals and email activity using its own attribution model.
  • The sales system (store, ERP) is the source of truth for revenue and order status.
  • A form lead is one moment in time: do not add it up as two conversions in two tools.
  • Cross-system comparisons use the same grain (order to order, not deal to session).

Purchase and deal answer different questions

Orders vs contacts

In GA4 and the store you work with orders: the purchase event, transaction_id, basket value, products. In HubSpot you work with contacts and deals: who filled a form, who entered an email sequence, where the sale stands.

That is not the same grain. "How many purchases in GA4" and "how many closed deals in HubSpot" answer different questions. Do not compare a BigQuery purchase export to a CRM report without deciding what you join and on which key.

In B2C most revenue goes through the store and GA4 ecommerce. HubSpot often handles newsletter signups, abandoned carts or landing page leads. In B2B a HubSpot deal may matter more than a single GA4 purchase because the order lands in ERP later. In both cases the boundary should be written down, not kept only in the analyst's head.

transaction_id as the default key

Join key

To link GA4 traffic with HubSpot data in a warehouse you need a shared key. transaction_id is the most reliable: the same ID in the GA4 purchase event and in the store or ERP order record.

Joining on email (GA4 user_id or form parameter to HubSpot contact_id) only works where you have a legal basis and consistent consent. Email often differs between systems (case, aliases, typos), so a "similar email" join in SQL quickly ruins data quality.

In practice keep a mapping table: transaction_id, ERP order_id, optionally HubSpot contact_id when the order came from a specific lead. Without it every Looker or Power BI report will guess relationships from scratch.

One moment, one metric

Count the lead once

Classic scenario: a user submits a contact form. GTM fires generate_lead in GA4 while the HubSpot integration creates a CRM contact. One moment, not two independent conversions to add into one KPI.

In your metric glossary split the definition of a lead and a purchase. A lead may matter for marketing, but leadership looks at store or ERP revenue. If your dashboard sums "GA4 leads" and "new HubSpot contacts", you count the same event twice.

For B2B forms decide whether generate_lead fires on every submit or only on first contact. HubSpot may update an existing record instead of creating a new one. GA4 will log another event unless you add logic. That gap often looks like a tagging bug but is really a definition mismatch.

CMP and consent like GA4

HubSpot tag and the cookie banner

HubSpot tracking in GTM follows the same rules as GA4: CMP first, then the tag. Without analytics_storage consent the tag often collects incomplete data or does not fire at all. Behaviour depends on the banner and on Consent Mode Basic vs Advanced.

In audits I see two common mistakes. First: the HubSpot tag fires before the user decides, because it sits in the page template outside GTM. Second: the tag is in GTM but has no consent trigger because "CRM is not analytics". In the EU treat it like any other tracking script and wire it to banner categories.

After go-live check GTM preview: HubSpot and GA4 tags should behave the same on reject and on accept. Otherwise you compare reports with different data coverage and conclude the CRM is "weak" when the issue is consent.

CRM models vs analytics

Attribution

HubSpot credits deals using its own rules (first/last touch in CRM, custom source fields). GA4 standard reports use session-based attribution and last-click by default (or another model if you pick one).

A gap of tens of percent between systems does not always mean a broken rollout. You may simply measure different things: session vs contact, purchase vs deal, different time to close.

If leadership asks "where customers came from", pick one reference report and align the rest to it. GA4's attribution simulator shows how the picture changes across models, but it will not replace HubSpot CRM rules.

Staging, mart and a shared view

Warehouse source

HubSpot contacts and deals usually land in the warehouse via API or a native integration (e.g. with Shopify). GA4 goes to BigQuery from the property export. Orders come from the store or ERP. Each source gets its own staging layer before you build a shared mart view.

Join on the agreed key, not on a "similar" email. Only then can BI show traffic, lead and order in one row or one funnel. Without that you keep three separate reports and copy numbers by hand.

Before building pipelines run the marketing warehouse checklist: metric owners, KPI glossary, cancellation rules. HubSpot and GA4 are only two nodes in a larger setup. The rest is covered in the marketing data hub.

What to remember

Summary

GA4 stays on traffic and purchase. HubSpot on contact and deal work. Revenue is confirmed in the store or ERP. Three layers, not three versions of the same number.

One KPI version for leadership comes from agreements and join keys, not a magic "sync everything" button. If you need that, start with the glossary and warehouse checklist, then add integrations one by one.

From boundary to rollout

Related resources

Marketing data hub Path from measurement to one KPI. Warehouse checklist Warehouse readiness before pipelines. GA4 taxonomy planner Event and parameter glossary for GA4. dataLayer generator dataLayer template for ecommerce. Consent hub Consent for GA4 and CRM tags. Attribution simulator Attribution models alongside HubSpot.

Implementation support

Need GA4, HubSpot and the warehouse aligned?

I help define the boundary between systems, pick join keys and build one KPI version for marketing and leadership.

Book a consultation Marketing data hub Web Analytics hub ← All tools