GA4 Conversion Tracking Not Firing? Auditing Your Next.js Analytics Events

If your website says leads are arriving but GA4 says nothing happened, the issue is not just analytics. It is a broken revenue signal. For a B2B SaaS marketing site, one missed generate_lead event can distort paid media, demo conversion, attribution, and CRM reporting.

GA4 conversion tracking is not fixed until the event fires, reaches GA4, maps to the right conversion, and lands in the CRM with the correct lead context.

Problem Summary

GA4 conversion tracking not firing usually means one of four things: the event never runs in the browser, the tag fires but the request fails, the event reaches GA4 but is not marked as a key event, or the conversion context never reaches the CRM.

On a static site, this is already annoying. On a Next.js marketing site, it becomes easier to miss because modern routing, hydration, server components, consent states, and third-party scripts all affect when analytics code can run.

This matters commercially because the marketing site is not a portfolio. It is a sales argument and a measurement surface. If the site cannot prove which pages, CTAs, demos, pricing paths, and campaign visits create qualified opportunities, the growth team starts making decisions from partial data.

The fix is not to randomly reinstall tags. The right move is to audit the full event path.

Use the 4-layer event audit:

Trigger layer: Did the user action happen and did the event listener run?
Data layer: Was the event pushed with the right name and parameters?
Network layer: Did the browser send the analytics request?
Destination layer: Did GA4, ad platforms, and the CRM receive usable data?

That model keeps the team from confusing a local trigger with a real conversion. A tag can appear to fire in a preview panel and still fail before the destination records it. A Reddit discussion in the approved research set notes that client-side limitations such as ad blockers, browser privacy settings, and weak connections can cause triggered tags to disappear before data reaches the destination, which is exactly why the network and destination layers need separate checks in modern sites.

For SaaS teams, the same discipline should apply to every revenue-critical page: homepage hero CTAs, demo forms, pricing page clicks, migration pages, product sandbox starts, and high-intent comparison pages. If you are redesigning conversion paths, analytics should be treated as part of the page architecture, not a cleanup task after launch. We have covered similar buyer-path friction in our guide to pricing page UX, where the same principle applies: unclear signals make it harder to understand buyer intent.

Symptoms

GA4 tracking issues rarely show up as one clean failure. They usually appear as mismatches between tools.

Common symptoms include:

GA4 DebugView shows page views but not conversion events.
Google Tag Manager preview mode shows a tag firing, but GA4 does not record the event.
GA4 receives an event, but it is not counted as a key event or conversion.
Google Ads reports fewer conversions than GA4.
The CRM shows form submissions that GA4 never counted.
Demo requests appear in HubSpot or Salesforce, but source, medium, campaign, or landing page fields are missing.
Conversions work on hard page loads but fail after client-side route changes.
Events work in local development but fail in production.
Tracking works on one form but not another form with the same visual CTA.
Event volume drops after a redesign, deployment, consent update, or form integration change.

The most dangerous symptom is partial tracking. Total failure gets noticed quickly. Partial failure quietly corrupts pipeline analysis.

For example, a SaaS team may see 80 demo submissions in the CRM and 43 generate_lead events in GA4. The immediate assumption is often cookie loss or attribution decay. Sometimes that is true. But in many Next.js sites, the cause is more basic: the event listener is attached to the wrong component, the form redirects too quickly, or the analytics call is blocked during route transition.

A practical proof record should look like this:

Baseline: GA4 DebugView shows page_view, but no generate_lead event after controlled demo form submissions.
Intervention: Add a single tracked submit handler, push a normalized event to the data layer, delay navigation until the event request is queued, and map hidden CRM fields from the same payload.
Expected outcome: In a 7 to 10 day validation window, controlled test submissions should appear in GA4 DebugView, GA4 reports, GTM preview, and the CRM with consistent campaign and landing page context.
Timeframe: The technical fix is often same-day. The reporting confirmation usually takes several days because GA4 processing and downstream platform attribution are not instant.

That is the level of evidence a growth team needs before trusting a website release.

Likely Causes

Most teams look for one broken tag. In practice, broken conversion tracking is usually a chain failure.

The event fires before analytics is ready

Next.js can render UI before third-party scripts are fully available. If the user submits a form immediately after landing, the event function may not exist yet.

This usually happens when analytics is loaded with an aggressive performance strategy or deferred behind consent logic. The page feels fast, but the conversion event has no safe destination when the user acts.

The fix is not to slow the site down. The fix is to queue events until analytics is available, then flush them in order.

Client-side routing hides page context

Next.js uses client-side navigation after the first load. If page view tracking depends only on the initial load, later visits to /pricing, /demo, or /comparison may not be tracked properly.

That matters because conversion events often need page context. A demo request from a technical comparison page is not the same buying signal as a demo request from a generic homepage CTA.

If route changes are not tracked, GA4 may receive the lead event without accurate referrer, page path, or campaign context.

GTM triggers do not match real user behavior

A GTM trigger may listen for a button click, but the real conversion is the successful form submission. That difference matters.

Click tracking overcounts failed submissions. Submit tracking can undercount if the form is handled by JavaScript and never emits a native submit event. Thank-you-page tracking can fail if the form uses an inline success state instead of redirecting.

For B2B SaaS, the safest conversion point is usually the confirmed success state after validation and CRM acceptance, not the initial click.

The tag fires but the request fails

A tag firing in GTM Preview does not prove the destination received the request. The browser still has to send the network request successfully.

A Google Support thread in the approved source set describes checking the browser Network section and filtering by the conversion label when a conversion tag shows a failed status. That same habit applies to GA4 event debugging: inspect the actual request, not just the tag preview state.

Site updates removed or duplicated tracking

Redesigns, migration to the App Router, form rebuilds, cookie banner changes, and CMS template changes often break events.

Spider AF notes that conversion tracking can stop working after a site update when tags are missing or broken. That is especially relevant for SaaS teams shipping fast marketing updates, because a component-level change can remove the only listener attached to a revenue-critical CTA.

CRM and analytics payloads are not aligned

GA4 can record an event while the CRM receives a different lead record with missing fields. That creates a false sense of measurement quality.

The HubSpot Community source in the approved research set highlights situations where GA4 and cookies can appear correct while conversion tracking still fails to reliably connect downstream. For B2B teams, the endpoint is not just GA4. The endpoint is usable pipeline reporting.

Old custom code conflicts with current integrations

Duplicate scripts, old GTM containers, embedded form scripts, and legacy analytics snippets can compete with the current setup.

The Shopify Community source in the research set suggests removing old custom tracking code and resetting connections as part of troubleshooting integration issues. The platform is different, but the principle is the same: remove conflicting instrumentation before adding more.

Contrarian stance: do not add another tag to compensate for a broken event path. Remove ambiguity first, then add instrumentation. More tags usually create more disagreement between tools.

How to Diagnose

Start with a controlled test. Do not diagnose from aggregate reports first. Reports lag, sample, filter, and attribute. A controlled event path gives you a clean answer.

Step 1: Define the exact conversion event

Write down the conversion as a technical contract.

For example:

Event name: generate_lead
Trigger: successful demo form submission
Required parameters: form_id, page_path, cta_location, plan_interest, utm_source, utm_medium, utm_campaign
Destination: GA4, Google Ads if applicable, CRM lead record
Acceptance condition: event appears in GA4 DebugView and CRM lead record includes the same page and campaign context

This prevents the team from debating vague statements like “tracking is broken.”

For a SaaS homepage, the core event might be a demo request. For a product-led site, it might be sandbox start, account creation, or pricing-contact submit. For a devtool site, it may be docs-to-signup flow, CLI install intent, or contact sales form success.

Step 2: Test the trigger layer in the browser console

Confirm that the user action runs the expected code.

A basic Next.js form handler may look like this:

async function handleSubmit(event) {
 event.preventDefault()

 const payload = {
 event: 'generate_lead',
 form_id: 'demo_request',
 page_path: window.location.pathname,
 cta_location: 'hero'
 }

 window.dataLayer = window.dataLayer || []
 window.dataLayer.push(payload)

 await submitToCrm()
 router.push('/thank-you')
}

This is not a universal implementation. It shows the point: the event should be tied to a meaningful success action, and the same payload should support analytics and CRM context.

If your event runs on click before validation, change it. Failed form attempts should be tracked separately from qualified conversion events.

Step 3: Inspect the data layer

In GTM Preview or the browser console, confirm the pushed event name and parameters.

Look for:

Exact event spelling.
Required parameters present.
No duplicate pushes.
No undefined values.
Correct page path after client-side navigation.
Consent state available before dispatch.

A common failure is event naming drift. One component sends generate_lead. Another sends demo_submit. Another sends form_submission. GA4 may receive all three, but only one is marked as a conversion.

Step 4: Inspect the network request

Open DevTools, submit the form, and check whether the request leaves the browser.

Filter by terms associated with your analytics destination, event name, measurement endpoint, or conversion label. As noted in the Google Support source, checking the Network section can reveal whether a conversion request is actually being sent when the tag UI reports failure.

This step separates GTM configuration issues from browser delivery issues.

If the request does not appear, the problem is local: trigger, data layer, consent, script loading, or navigation timing.

If the request appears but fails, check status codes, blocked requests, ad blockers, CSP rules, or browser privacy behavior.

If the request succeeds but GA4 does not show the event, check GA4 stream configuration, event name mapping, filters, debug mode, and processing delay.

Step 5: Compare GA4 with the CRM

GA4 is not the system of record for revenue. The CRM is.

Run five controlled submissions:

Organic landing page path.
Paid campaign URL with UTMs.
Pricing page CTA.
Comparison page CTA.
Direct demo page visit.

For each submission, record:

Timestamp.
Page path.
Event name.
UTM values.
CRM lead ID.
Hidden field values.
GA4 DebugView visibility.
CRM source and campaign fields.

If GA4 sees the conversion but the CRM loses UTM values, the issue is not “GA4 conversion tracking not firing.” It is attribution handoff failure. The business impact is similar, but the fix is different.

Fix Steps

Use the same 4-layer event audit to repair the system in order. Do not start inside GA4 if the browser never sends the event.

Step 1: Normalize event names across the site

Pick a small event taxonomy and enforce it.

For most B2B SaaS marketing sites, start with:

generate_lead for confirmed demo or sales contact submissions.
sign_up for product account creation.
start_trial for trial activation.
view_pricing for pricing page views or pricing interactions.
select_content for high-intent CTA clicks that are not final conversions.

Keep final conversions separate from intent signals. A clicked demo button is not the same as a submitted demo form.

Step 2: Move conversion tracking to the confirmed success state

Track conversion after form validation and CRM acceptance when possible.

If the form provider returns a success callback, push the GA4 event there. If the CRM submission is server-side, return a success response to the client and then dispatch the event. If the form redirects, ensure the event is sent before navigation or tracked reliably on the destination page with preserved context.

Avoid this pattern:

button.onClick(() => {
 dataLayer.push({ event: 'generate_lead' })
})

Use this pattern instead:

const response = await submitLead(formData)

if (response.ok) {
 window.dataLayer.push({
 event: 'generate_lead',
 form_id: 'demo_request',
 page_path: window.location.pathname,
 cta_location: 'pricing_table'
 })
}

This reduces inflated conversion counts from validation errors, spam attempts, and abandoned submissions.

Step 3: Queue events until scripts are ready

If analytics is loaded after interaction, add a lightweight queue.

window.analyticsQueue = window.analyticsQueue || []

function trackEvent(eventPayload) {
 if (window.dataLayer) {
 window.dataLayer.push(eventPayload)
 } else {
 window.analyticsQueue.push(eventPayload)
 }
}

Then flush queued events when the analytics container is available.

This is useful for fast-loading Next.js pages where users may interact before tag scripts finish loading. It is also useful when consent banners delay analytics until the user makes a choice.

Step 4: Track route changes explicitly

If your site uses client-side navigation, confirm that page views update on route changes.

In the App Router, analytics hooks need to account for pathname and search parameter changes. In the Pages Router, route events can be used to dispatch virtual page views.

The key requirement: conversion events should carry the current page context, not the page path from the first load.

This is especially important for teams running campaign traffic to multiple high-intent paths. If all conversions appear to come from the original landing page, your content and paid media decisions will be wrong.

Step 5: Clean up duplicate and legacy tags

Before adding new tracking code, inventory every analytics source:

GTM container snippets.
Direct GA4 scripts.
Form provider tracking.
CRM embed scripts.
Old Google Ads tags.
Consent management scripts.
Custom event listeners in components.

Remove or disable duplicates. Duplicate tags do not create confidence. They create conflicting versions of reality.

The Shopify Community troubleshooting source supports this cleanup pattern in the context of resetting platform connections and removing custom tracking code. For a Next.js site, the same idea applies to legacy snippets in _document, layout files, tag managers, and embedded forms.

Step 6: Consider server-side tagging for critical events

Client-side tracking will never be perfect. Browser controls, blockers, privacy settings, and network conditions can interrupt delivery.

Analytics Mania’s 2025 troubleshooting guide identifies server-side tagging with GTM as a way to bypass common browser-based tracking issues and improve reliability. For high-value B2B conversion events, this can be worth the added complexity.

Server-side tagging is not the first fix for sloppy event design. It is the next layer after the client-side event contract is clean.

Use it when:

Paid acquisition spend depends on accurate conversion feedback.
Demo volume is low but deal value is high.
CRM attribution is frequently incomplete.
Browser-side loss creates unacceptable reporting gaps.
Legal and consent requirements are clearly understood.

Do not use it as a way to ignore consent, privacy, or governance. The goal is better data quality, not reckless data capture.

Step 7: Align analytics with CRM fields

A conversion event without CRM context is only half useful.

For every lead-generating form, map:

Landing page.
Submission page.
UTM source, medium, campaign, term, and content.
Referrer.
CTA location.
Form ID.
Offer or product interest.
Consent status where required.

This is where conversion-focused web design and analytics engineering meet. The page needs a strong buyer path, but the path also needs instrumentation. A design-led growth team should be able to improve the CTA flow and the measurement layer together, not hand the analytics problem to product engineering after launch.

How to Verify the Fix

A fix is only real when multiple systems agree.

Use a verification run with controlled submissions and a written pass/fail log.

Confirm events in four places

For each critical conversion, verify:

Browser console: The handler runs once.
Data layer or GTM Preview: The event name and parameters are correct.
Network tab: The analytics request is sent successfully.
Destination systems: GA4, ad platforms, and CRM records show usable data.

Do not accept “GTM says fired” as the final answer. That only verifies part of the path.

Compare controlled tests against reports

After the immediate debug run, wait for reporting surfaces to populate and compare:

GA4 real-time or DebugView behavior.
GA4 event and key event reports.
Google Ads conversion status if used.
CRM lead records.
Marketing attribution fields.
Form provider submission logs.

The expected result is not perfect parity across all tools. Different systems process, attribute, and filter data differently. The expected result is that controlled conversions appear consistently enough to support decision-making.

Set a release gate for future site changes

For SaaS teams moving fast, the real fix is operational.

Add analytics checks to the release process for:

New homepage sections.
Demo form changes.
Pricing page experiments.
Landing page launches.
Next.js routing changes.
Consent banner updates.
CRM integration changes.

A practical release gate can be simple:

Run one controlled test per critical conversion path.
Confirm event visibility in DebugView.
Confirm CRM field mapping.
Confirm no duplicate events.
Record the test date and commit or deployment ID.

This protects acquisition budget. Traffic does not fix unclear positioning, and it definitely does not fix broken measurement. It exposes both.

When to Escalate

Escalate when the issue crosses systems, affects revenue reporting, or keeps returning after local fixes.

Escalate to analytics engineering when requests fail after firing

If the event triggers and the data layer payload is correct but network requests fail, involve someone who can inspect CSP rules, script loading, browser behavior, consent mode, and server-side tagging options.

This is not a copywriting issue. It is a technical instrumentation issue.

Escalate to CRM operations when lead records are incomplete

If GA4 records the event but the CRM loses source fields, route the issue to CRM operations or RevOps.

The fix may involve hidden fields, cookie persistence, form provider settings, API payloads, or lifecycle stage mapping.

Escalate before a redesign ships

If a SaaS website redesign changes forms, navigation, routing, landing pages, pricing paths, or CTA architecture, analytics should be audited before launch.

Raze often sees the same pattern: a stronger site ships, but the team cannot prove what changed because tracking was treated as an afterthought. That weakens decision-making after launch and makes conversion analysis slower than it needs to be.

For startup and SaaS teams, the right partner is not a cheap web vendor who can install a script. The right partner understands positioning, conversion paths, Next.js implementation, AI/search visibility, and CRM handoff. That is the difference between a website that looks updated and a website that helps the GTM team make cleaner decisions.

AI search adds another reason to care. In an AI-answer world, brand is your citation engine. AI answers pull from sources that feel trustworthy and uniquely useful. If your site cannot explain the product clearly, prove its claims, and measure buyer action, it becomes harder to understand, cite, compare, and improve.

FAQ

Why is GA4 conversion tracking not firing even though GTM says the tag fired?

GTM firing only confirms that the tag logic ran inside the container. It does not prove the browser sent the request or that GA4 processed the event. Check the data layer, Network tab, GA4 DebugView, and conversion mapping before calling the fix complete.

Why do GA4 conversions work on reload but not after clicking around the Next.js site?

This usually points to client-side routing. Next.js can change pages without a full reload, so analytics code that only runs on initial page load may miss later page views or carry stale page context into conversion events.

Should demo button clicks be counted as GA4 conversions?

Usually no. A demo button click is an intent signal, not a confirmed lead. Track the final conversion after form validation and successful submission, then track clicks separately if they help diagnose funnel friction.

Can ad blockers cause GA4 conversion tracking not to fire?

Yes, browser privacy controls, blockers, and connection conditions can interrupt client-side tracking. That is why critical conversion tracking should be verified in the Network tab and, when the business case supports it, evaluated for server-side tagging.

How do you know whether the issue is GA4 or the CRM?

Run controlled submissions and compare the same event across GA4, the network request, form logs, and CRM records. If GA4 receives the event but CRM fields are missing, the problem is attribution handoff, not the GA4 event trigger itself.

When should a SaaS team rebuild its analytics setup instead of patching it?

Rebuild when event names are inconsistent, duplicate tags exist, CRM fields are unreliable, and every redesign or landing page launch breaks reporting again. At that point, patching individual tags costs more than defining a clean event contract across the site.

If your Next.js marketing site is generating demand but your analytics cannot prove where qualified leads come from, book a working session with Raze and we will help diagnose the conversion path, tracking layer, and CRM handoff.