A form can submit successfully, a lead can reach the CRM and the user can still arrive at a thank-you page while GA4 records no conversion. That sounds contradictory only if “business success” and “analytics success” are treated as the same event. They are not. A redirect creates a boundary between the action that matters to the business and the page that analytics eventually sees. If measurement is attached to the wrong side of that boundary, the lead can be real while the conversion signal is missing.

The short answer

When a GA4 conversion disappears after a redirect, first identify the exact success state. Then verify whether the GA4 event fires before navigation, whether the browser has time to send it, whether the destination page is actually being measured, and whether the event being marked as a key event is the event that represents success.

Do not begin by replacing GA4 or adding another analytics platform. A different tool cannot repair a broken measurement boundary by itself.

A common flow that creates the problem

Consider this journey: Landing page → form submit → OTP verification → lead accepted → redirect → thank-you page.

There are several technically different moments inside what a marketer may call “one conversion”. If the real business outcome is “verified lead accepted” but analytics waits for a thank-you-page view, measurement now depends on the redirect and destination page working perfectly.

  • The form was submitted
  • OTP verification succeeded
  • The backend accepted the lead
  • The CRM received the record
  • The browser started navigating
  • The thank-you page loaded
  • GA4 received an event

Step 1 — define the actual conversion

Ask one question before opening GTM Preview: What event proves that the desired action succeeded?

For an OTP-gated lead form, the first click on Submit is usually too early. A user may submit invalid information or fail verification. The thank-you page can be too late if the business has already accepted the lead before the redirect.

The strongest measurement point is normally the reliable success signal closest to the actual business outcome. That may be a successful API response, verified OTP callback, application success state or another deterministic signal exposed by the implementation.

Step 2 — separate lead capture from page navigation

A lead reaching the CRM proves that one part of the workflow succeeded. It does not prove that a GA4 event fired. Likewise, a thank-you page loading proves navigation succeeded. It does not prove the lead was accepted.

Debug the chain as separate states. This separation prevents a common debugging mistake: changing analytics when the actual issue is application flow, or changing application flow when the tag simply never fired.

  • Did the application report success?
  • Did the analytics trigger observe that success?
  • Did the GA4 event fire?
  • Did navigation interrupt the request?
  • Did GA4 receive/process the event?
  • Did the CRM receive the lead?

Step 3 — inspect the event before the redirect

Use GTM Preview/Tag Assistant and the browser developer tools to inspect the moment immediately before navigation.

Do not use “the tag exists in GTM” as proof. The relevant question is whether it fired on the successful journey.

  • Which dataLayer event occurs
  • Whether the GA4 event tag fires on that event
  • Whether consent allows measurement
  • Whether the measurement ID is correct
  • Whether a JavaScript error interrupts the flow
  • Whether navigation happens immediately after the trigger
  • Whether the request is sent before the document unloads

Step 4 — verify the destination page independently

If the strategy intentionally uses a thank-you page as the conversion signal, verify that page on its own.

A destination-page conversion can be perfectly valid when the page represents a unique, reliable success state. The problem is assuming that it does.

  • GA4/GTM is present on the destination
  • The page is not outside the measured domain unexpectedly
  • Consent state remains valid
  • The page does not redirect again before measurement
  • The page_view or dedicated success event is visible in debugging
  • Cross-domain behaviour is configured when the journey crosses domains

Step 5 — do not fire a conversion on every thank-you page view

A thank-you URL can sometimes be opened directly, refreshed or revisited. If every page view becomes a conversion, reporting may overcount.

Where practical, tie the event to a success state or carry enough state into the destination to distinguish a genuine completed journey from an arbitrary page load. The implementation depends on the application, but the measurement principle is stable: count the business event, not merely a convenient URL.

What if another analytics tool records it?

That is useful diagnostic evidence, but it does not automatically mean GA4 is the problem.

Different tools can initialise at different times, listen to different events and persist data differently. If PostHog, another product analytics tool or server logs record the journey while GA4 does not, compare the measurement points rather than declaring one platform “working” and the other “broken.”

A redirect problem remains a redirect problem even if the tracking product changes.

Client-side versus server-side evidence

Client-side analytics tells you what the browser observed. Backend/CRM evidence can tell you whether the business transaction was accepted. For important lead journeys, comparing both is valuable.

A useful evidence chain is: Browser success signal → GA4 event → backend acceptance → CRM record. The systems do not need to contain identical data, but they should be reconcilable enough to identify where loss occurs.

A practical debugging checklist

  • Define the business success state
  • Reproduce one clean test journey
  • Inspect the application success event
  • Confirm the GTM trigger
  • Confirm the GA4 event tag
  • Check the network request before navigation
  • Verify the destination page separately
  • Check GA4 DebugView/realtime evidence as appropriate
  • Confirm the CRM/backend result
  • Test failure paths so they do not count as success
  • Test refresh/direct thank-you-page access
  • Document the final measurement rule

What this teaches about analytics architecture

Conversion tracking is not just tag configuration. It is part of the product journey.

When measurement is planned after development, analytics teams are forced to infer success from whatever URL, click or DOM state happens to exist. When success states are designed to be measurable, the implementation becomes more reliable and easier to debug.

This is why Fusion Works treats analytics, websites and automation as connected systems rather than separate tasks.

QUESTIONS

Questions

Why does my lead reach the CRM but not GA4?

Because CRM capture and GA4 collection are separate events. The backend may accept the lead even if the browser never fires or completes the analytics request.

Should a thank-you page be the GA4 conversion?

Only when the page reliably represents a completed action and cannot easily create false repeats. A deterministic application success event is often closer to the real outcome.

Will switching from GA4 to another analytics tool fix redirect tracking?

Not automatically. If the underlying success state or redirect timing is wrong, changing tools can move the symptom without fixing the measurement design.

Should the conversion fire before or after the redirect?

Fire it at the most reliable point that represents genuine success. In many application flows that is before navigation, after the application confirms success.