“We can see traffic, but not what users do in the product.”
GA4 can tell you who arrived and where they came from. It cannot tell you what happened after they signed up. Here is why the two halves of the journey stay disconnected and what it takes to join them.
A composite of engagements I have run, not a specific client. The numbers are illustrative, but the shape of the problem is one I see repeatedly.
The acquisition report looks healthy
A B2B SaaS business gets around 900 trial signups a quarter. GA4 reports the channel mix cleanly: paid search, organic, a partner referral, and some direct. Cost per signup is trending down. On the acquisition side, marketing is doing its job and can prove it.
The question nobody can answer
The management asks a reasonable question: which channel brings the users who actually stick around? GA4 knows everything up to the signup button and nothing after it. The product database knows what people did after signup, but has no idea where they came from. Neither system can answer alone, and nothing joins them.
The spreadsheet becomes permanent
Monthly, a CSV is exported from both systems and merged by email address. The process takes two days, fails whenever a personal sign-up address differs from a work billing address, and yields data that lacks internal credibility.
Two systems capture data in their own silos
The data sits in two places that have no way to agree that a visitor and a user are the same person.
The join between the two halves is the whole problem.
Two tools, two identities
GA4 keys everything on a browser cookie. The product keys everything to an account ID created at signup. It doesn’t reveal the anonymous visitor’s identity across the signup boundary, so the journey is disjointed at the exact moment product use begins.
Nobody designed the product events
Engineers added product events as features shipped, naming them for whatever made sense that afternoon: btn_click_3, newOnboardStep, feature_used_v2. There is no naming convention and no property schema, so you cannot build a funnel out of them even though the events exist.
GA4 is the wrong tool for what happens inside a product
GA4 is built around sessions, pageviews, and campaigns. Product questions are about cohorts, retention curves, and feature adoption over weeks. You can force some of it into GA4, and the result is always a worse version of what a product analytics tool does natively.
The properties that matter are missing
Plan tier, company size, signup source, and role are not attached to the events, so even where the events fire correctly, you cannot segment them into anything a decision depends on.
The fix, with an example.
Assume a hypothetical SaaS business selling shift-scheduling software to hospitality operators such as restaurants, bars, and small hotel groups. Around 900 free trials a quarter, arriving through paid search, a partner program with two point-of-sale vendors, and organic content. Plans range from £49 to £240 per month, depending on the number of venues, with a 14-day trial and no card required. Amplitude had been installed for two years.
- 01 Which acquisition channel produces operators still scheduling at day 30?
- 02 What key actions does a trial signup that eventually converts take during the first week?
- 03 Where in the setup do trials stall?
- 04 How to identify high-churn customers after three months of product use?
newSchedule, schedule_create, and Create Schedule (v2) were all still firing for the same action, depending on which part of the app was used to fire the event. Any funnel built on one of them undercounted the scheduling event by two-thirds.schedule_created, shift_published, staff_invited, payroll_synced — with the three legacy names mapped onto schedule_created so the history survives, then retired.trial_started and subscription_created fired client-side after the payment interface redirect. A tenth of them never arrived because of closed tabs, blockers, and patchy connections in restaurant back offices. Subscription numbers were faulty and never quite matched the payment data, and the trust in the data is lost.shift_published fired with nothing attached to it. You could see that shifts were being published; you could not see by which plan tier, at what venue size, or from which acquisition channel. Questions were unanswerable even though the event they needed had been around for a while.signup_source, plan_tier, venue_count, user_role, days_since_signup.- ◆A versioned tracking plan and event taxonomy document
- ◆The taxonomy implemented in Amplitude or Mixpanel
- ◆Identity resolution across anonymous and known users
- ◆Funnel, retention, and cohort reports built and working
- ◆The team trained on the schema they now own
One customer, one story.
GA4 and product analytics are not rivals.
GA4 answers acquisition questions well and integrates with Google Ads and Search Console in ways that are hard to give up. Amplitude and Mixpanel answer product questions that GA4 handles poorly. The mistake is not running both — it is running both without a shared taxonomy, so the two never agree, and the team learns to trust neither.
It depends more on your team than on your product. Mixpanel tends to suit teams that want to self-serve quickly with less setup; Amplitude tends to suit teams that will invest in governance and want deeper cohort and behavioral analysis. I will give you a recommendation with reasons rather than a preference, and the taxonomy work is identical either way.
No, and you should not. They answer different questions. GA4 keeps the acquisition side and its Google integrations; the product tool takes the behavioral side. The shared taxonomy keeps them from contradicting each other.
Less than teams expect for the taxonomy work and more than they expect for identity stitching. The alias step usually needs a developer for a short, focused task. I write the specification so that time is spent implementing rather than deciding.
Usually a mapping exercise rather than a rebuild. We map existing events onto the new taxonomy where they are salvageable and deprecate them where they are not, so you keep history without carrying the naming chaos forward.
Typically four to eight weeks. The tracking plan takes one to two weeks, implementation two to four, depending on how much is server-side, and validation the rest. Identity stitching is the piece most likely to extend the timeline.
Both tools price on tracked events or monthly users, and a badly designed taxonomy is genuinely expensive because it fires events nobody reads. Designing the plan first is the primary cost-control measure, which is another reason it comes before implementation.
Sound like your setup?
That is usually where we start. Thirty minutes, no obligation — and you leave knowing whether this is your problem or something else entirely.
Book a free 30-minute call