GA4 is installed on your site. The green checkmark is there. The real-time view shows visitors. And yet, when someone asks how many conversions came from paid search last month, the honest answer is a number that exists in three different tools, disagrees with itself across all three, and cannot be defended in a room with a spreadsheet. The dashboard is not broken. The implementation is. And the gap between “GA4 is installed” and “GA4 conversion tracking is actually working” is where most businesses have been quietly operating for longer than they realize.
This is the step-by-step path from that gap to a tracking setup that produces numbers you can actually make decisions from.
Step 1 — Audit What GA4 Is Actually Receiving Right Now
Before fixing anything, establish what is genuinely broken versus what is working but misread. Open GA4 → Reports → Realtime and complete an actual conversion action on your site — a form submission, a thank-you page load, a purchase, whichever event you care about. Watch the realtime view. If nothing fires, the event is not being sent. If something fires but is not marked as a conversion, the event exists but has not been configured as a conversion. These are two different problems with two different fixes.
Then go to Admin → Events and check the event list. Cross-reference with Admin → Conversions. An event that appears in the event list but not in the conversions list is an event that GA4 knows about but is not counting as a conversion. An event missing from both lists is an event that is not being fired at all.
This distinction matters because it determines whether the next step is tagging (nothing is firing) or configuration (something is firing but not being counted correctly).
Step 2 — Set Up Conversion Events Correctly in GA4
GA4 measures conversions through events — specific actions that fire when a user completes a meaningful step. According to Google’s own GA4 documentation, the minimum required parameters for an e-commerce purchase event are value and currency. A purchase event without these fields fires as an event, registers in the event count, and shows up in zero revenue reports — which looks exactly like broken tracking when it is actually incomplete tracking.
For lead generation: the most reliable conversion event is a thank-you page view rather than a form submit, because the thank-you page only loads when the submission actually succeeded. A form submit event can fire even when the form returns a validation error, which inflates conversion counts without a corresponding lead existing anywhere in the CRM.
To mark an event as a conversion in GA4: Admin → Events → find the event → toggle “Mark as conversion”. If the event does not exist yet because it has never fired, create it under Admin → Events → Create event, then mark it as a conversion once it has been validated in realtime.
Step 3 — Implement Tags via Google Tag Manager
Hardcoding GA4 events directly into the site’s codebase works, but it creates a dependency on development resources every time a tracking requirement changes. Google Tag Manager sits between the site and the measurement tools, allowing conversion events to be added, modified, and debugged without a code deployment.
The correct setup for a GA4 conversion event in GTM:
- Create a GA4 Event Tag with the event name matching exactly what GA4 will be listening for.
- Set the trigger to the condition that signals a completed conversion — page path equals
/thank-you, or a custom event pushed to the dataLayer by the form on successful submission. - Use GTM’s Preview mode to verify the tag fires on the correct action and does not fire on unrelated interactions.
- Publish the container only after Preview confirms the tag behaves correctly. An unpublished GTM container is a tag that does not exist in production — this is the single most common cause of “it worked in Preview but not on the live site” reports.
One thing worth checking immediately: open your GTM container and look at every tag’s publication date. Tags that were last published more than six months ago and have never been audited since may be firing on page structures that no longer exist, or missing page structures that were added after the last publish.
Step 4 — Implement the GA4 Config Tag Correctly
Every GA4 Event Tag in GTM needs to reference a GA4 Configuration Tag that carries the Measurement ID. The Google Tag platform documentation is explicit on this: the configuration tag must fire before any event tags on every page. If the GA4 Configuration Tag fires on “All Pages” but an event tag fires on a trigger that can theoretically load before the configuration tag completes, the event has nowhere to attach and gets lost.
Verify this in GTM’s Preview mode by checking the tag firing order on a conversion page. The configuration tag should always appear before any event tags in the firing sequence.
Step 5 — Set Up Server-Side Tracking via Conversions API
Client-side tracking — a pixel in the browser — has been losing reliability for years. Ad blockers, browser privacy features, and intelligent tracking prevention quietly trim what a browser-based tag can see. For businesses where conversion accuracy directly affects budget decisions, the more durable layer is server-side tracking: sending the conversion event from your own server rather than relying on the visitor’s browser to report it.
For Google: this means sending events directly to the GA4 Measurement Protocol alongside the client-side tag. For Meta: the Conversions API runs parallel to the browser pixel. The principle is the same in both cases — two sources reporting the same event, with deduplication logic preventing double-counting.
Deduplication is non-negotiable when running both client-side and server-side tracking simultaneously. Both the browser tag and the server event must carry the same event_id — a unique identifier generated at the moment of conversion and passed to both layers. Without this, every conversion gets counted twice: once from the browser, once from the server, and the resulting inflated numbers look like strong performance right up until someone reconciles them against actual revenue. The full mechanics of why this happens are covered in Why Your Conversion Tracking Is Broken.
Step 6 — Configure Attribution Settings in GA4
GA4’s default attribution model is data-driven, which distributes conversion credit across touchpoints based on observed patterns rather than a fixed rule. This is more accurate than last-click for most businesses, but it requires a minimum volume — roughly 400 conversions and 4,000 ad clicks in 30 days — to function correctly. Below that threshold, GA4 falls back toward last-click without clearly announcing it has done so.
Check your attribution settings: Admin → Attribution Settings. Confirm the lookback window matches the realistic length of your sales cycle. A 30-day lookback on a business with a 90-day average consideration period will misattribute a significant share of conversions to direct or the last touch before close, while ignoring the touchpoints that actually started the relationship.
This is also where the discrepancy between GA4 numbers and Google Ads numbers typically lives — Google Ads applies its own attribution model with its own lookback window, and neither tool is wrong, they are simply answering different questions about the same conversion. Understanding which model each tool uses is a prerequisite for interpreting the gap between them, as detailed in What Is Marketing Attribution and Why It Matters.
Step 7 — Verify With Real Transactions and Monitor
The final step before declaring the implementation complete is end-to-end verification: complete an actual conversion on the live site, not in Preview mode, not on staging, and confirm the event appears in GA4’s realtime view within 30 seconds, shows the correct event parameters (value, currency, transaction ID where applicable), and is being counted as a conversion in the conversion report.
Then set a calendar reminder for 28 days from now. That is when the CrUX-based data and the GA4 comparison period will have enough data to show whether the fix held. Checking Search Console or comparing periods before that window produces artificially pessimistic comparisons.
What the Tutorials Conveniently Leave Out
- Hashed personal data sent to the Conversions API must be normalized before hashing or it matches nothing. Email addresses and phone numbers passed to Meta CAPI or Google’s enhanced conversions must be lowercased and stripped of whitespace before SHA-256 hashing. Hash “User@Email.com ” as-is and the resulting hash will never match the platform’s own hashed record of that user, and the event gets silently discounted with no error thrown anywhere visible.
- Google Signals data thresholding makes some conversion segments invisible. When Google Signals is enabled in GA4, segments with population sizes below a privacy threshold are withheld from reports entirely. A conversion segment that simply does not appear in a GA4 report is not necessarily a tracking failure — it may be a privacy feature doing exactly what it was designed to do. Check whether Signals is enabled before concluding that a segment’s data is missing due to a tag error.
- Consent Mode modeling affects reported conversion numbers even when tracking is technically correct. Under Google’s Consent Mode requirements for EEA and UK traffic, users who decline cookies have their conversions modeled rather than measured. The modeled numbers appear in reports alongside measured ones without clear labeling. An apparent drop in conversions in a region where a consent banner was recently added may be Consent Mode working correctly, not a tracking break.
- Cross-domain tracking breaks conversion attribution silently. If a conversion happens on a different domain from where the session started — a payment processor subdomain, a separate checkout domain, a third-party booking system — GA4 treats the return as a new session from Direct, breaking the attribution chain. GA4’s cross-domain configuration under Admin → Data Streams → Configure tag settings → Configure your domains must include every domain involved in a conversion path, not just the primary site domain.
- The community catches implementation issues faster than the documentation does. For edge cases, platform bugs, and unusual implementation scenarios, r/analytics surfaces real-world troubleshooting that the official documentation rarely covers. The pattern where GA4 stopped firing conversions after a specific Chrome update, or where a particular CMS plugin breaks the dataLayer push — these tend to appear there weeks before Google updates any support article.
- A fixed tracking setup still needs to connect to a working downstream funnel. Accurate conversion data is the measurement layer. If the funnel itself leaks leads at every stage, fixing GA4 just gives you more accurate visibility into a broken process rather than a better outcome. Why Funnels Leak Leads and Kill Conversions covers where those losses actually live and how to diagnose them by stage. Think with Google’s research consistently shows that measurement accuracy and conversion rate improvement need to be pursued together rather than sequentially.
Where This Fits
Fixing GA4 conversion tracking is not a one-afternoon task and it is not a permanent one either — it is an implementation that needs to be verified when the site changes, when campaigns change, when consent requirements change, and when new conversion actions are added. The businesses that get accurate conversion data over time are the ones that treat the measurement layer as infrastructure with the same maintenance cadence as everything else.
This is the kind of GA4 conversion tracking work OJC Labs implements for clients: events configured correctly, server-side deduplication in place, attribution set to reflect the actual sales cycle, and a verification process that confirms the implementation is working against real transactions rather than just Preview mode.
If your conversion numbers still do not reconcile across platforms after working through this guide, get in touch and we will find exactly where the break is.