Conversion tracking
Conversion tracking is the wiring between what your product does and what an advertising platform can optimise toward. We define the actions, implement them client-side and server-side, verify each one fires once with the right value and arrives in the destination account, and document who owns it.
- GTM & server-side GTM
- GA4 key events
- Conversions API
- Consent Mode v2
GROW
Data, measurement & growth
The layer that keeps the other two honest. Event models, conversion tracking and attribution that make performance legible, and continuous optimisation of the product and the spend together rather than one at a time.
Also in this band
Analytics answers questions after the fact. Conversion tracking does something narrower and more consequential: it tells a bidding system, while it is spending, which of the clicks it bought turned into something the business wanted. That signal is what Smart Bidding, Advantage+ and app campaign optimisation are built on. If it is wrong, the platform is not confused — it is confidently buying more of whatever the broken signal rewards.
A conversion has three possible homes, and each of them covers a gap the other two leave open. Client-side tags fire in the browser or the app and are fast, visible and fragile. Server-side endpoints — the Conversions API, the Measurement Protocol, a server-side Tag Manager container — are more reliable and harder to inspect. Offline imports carry the outcomes that never touch a screen: a deal closed on a call, a refund, an order that shipped weeks later. The work is making the three agree without counting the same thing twice.
Nothing here is trusted because it was implemented. It is trusted because it was watched: the event observed firing once on a real device, the value checked against a real order, the row confirmed arriving in the destination account, the consent-denied case tested as deliberately as the granted one. Implementation is often the short part. Verification is where the time goes, and skipping it is how an account ends up bidding towards a number nobody in the room can explain.
Four ways the signal breaks
Each of these produces a conversion column that still moves, which is why they survive so long. All four are mechanical, and all four are fixable once somebody looks at the tag instead of the bid strategy.
- The thank-you page counts refreshes
- The conversion tag sits on the order confirmation page and fires on every load of it. A customer refreshes, bookmarks it, or hits back and forward; the payment gateway redirects through it twice on a retry. Each of those is another conversion in the column. The counting mode was never changed from every conversion to one per click, so the inflation compounds.
- The single-page app never re-fires
- The site is a React or Next.js application that changes route without a page load. The tag was configured on a DOM-ready trigger, so it counts the first screen a visitor sees and nothing afterwards. Checkout, sign-up and booking completions all happen on virtual pageviews the container never hears about. The account looks like it converts on the homepage only.
- Pixel and server both count the sale
- The Conversions API was added to recover events the browser was losing, and the pixel was left in place. Neither event carries the identifier that would let Meta recognise the two as a single purchase. Volume in the report inflates, cost per result looks better than it is, and the bidding system learns from a demand curve that does not exist.
- The consent banner blocks its own tag
- A cookie banner was installed to satisfy a legal review and configured to block scripts by category. The conversion tag sits in a category the banner denies by default, or the Consent Mode signal never reaches the container before the tag evaluates. Measurement collapses in a specific set of regions, and nobody separates that from a genuine drop in demand.
What the work covers
Six areas. The first two are settled before anything is implemented, because a well-built tag pointing at a badly defined action still produces the wrong number.
Conversion action definition and hierarchy
Before any tag is written, every conversion action is named, defined and ranked. What counts as a conversion, what is merely a signal of intent, what should be observed but never bid on. Primary and secondary are set deliberately, because that single toggle decides what the bidding system is actually chasing.
- A written definition per action: what it means, where it fires, who owns it
- Primary and secondary designation set per campaign goal, not left at the default
- Counting mode chosen per action: every conversion, or one per click
- Click-through and engaged-view windows set against the real sales cycle
- Micro-conversions kept secondary so they inform without steering the bid
- Duplicate legacy actions retired rather than left counting quietly in the background
Client-side tagging and Google Tag Manager
Containers are built with named triggers, versioned changes and a workspace nobody edits live. Tags fire on the state that actually confirms the outcome, not on a URL that a refresh can reproduce. Single-page applications get history-change or dataLayer triggers pushed by the application itself, so a route change is a real event.
- A dataLayer contract agreed with the developers and documented in the repository
- Google tag and container configuration, with version notes on every publish
- Transaction and order identifiers pushed so duplicates can be recognised later
- Triggers based on application state rather than a reachable confirmation URL
- Naming applied to tags, triggers and variables so a stranger can read the container
Server-side tagging and platform APIs
Where the browser cannot be trusted — ad blockers, browser restrictions, a payment redirect that drops the session — the event is sent from a system that already knows the truth. Server-side GTM, the Conversions API, the Measurement Protocol and the Google Ads API all carry the same identifiers so nothing is counted twice.
- A server-side Google Tag Manager container running on your own cloud project
- Meta Conversions API with a shared event ID and action source on every event
- GA4 Measurement Protocol for purchases, refunds and the state changes only your back office sees
- Webhook listeners on the payment provider, so the settled order is the trigger
- Retry and failure handling, because a dropped server event is invisible by nature
- Payload logging somewhere you can query it when a number is later disputed
Deduplication, value and currency
Two systems reporting the same sale is worse than one system missing it, because the error looks like growth. Every event carries an order or transaction identifier, and the deduplication key is tested by firing both paths on purpose. Values are real amounts in a stated currency, handled consistently for tax, shipping and discounts.
- Shared event ID across pixel and Conversions API, confirmed in the events manager
- Order ID passed to Google Ads so a repeated confirmation page is recognised
- Currency declared explicitly on every value, including multi-currency checkouts
- Refunds and cancellations sent as adjustments where the platform accepts them
- Lead values derived from your own pipeline rather than a placeholder figure
- Tax, shipping and discount treatment decided once and applied everywhere
App conversion events and Firebase
Apps track differently and break differently. Conversion events are logged through the Firebase SDK or a mobile measurement SDK, marked as conversions in the console, and connected to whichever ad accounts will bid on them. Purchase and subscription state is confirmed server-side against the store, not against the client's word.
- Firebase Analytics conversion events wired to the same names used on web
- Google Ads and Firebase linking, with imported events checked in both places
- App Store Server Notifications and Play real-time developer notifications for purchase state
- App Tracking Transparency handled where iOS attribution depends on it
- SKAdNetwork and AdAttributionKit conversion values chosen against real post-install milestones rather than defaults
- Deep link and deferred deep link paths tested so an install is not credited twice
Consent, enhanced conversions and lawful measurement
Consent Mode v2 is wired to reflect the banner genuinely running on your site rather than an idealised one, and both signal states are exercised instead of assumed. Enhanced conversions and hashed customer data are used only where you have a lawful basis and a disclosure that covers it. Where consent is denied, the tag stays denied and we say what that costs you.
- Consent Mode v2 signals wired ahead of tag evaluation rather than after it
- Banner categories mapped to the tags they gate, then tested granted and denied
- Enhanced conversions for web and for leads, where your privacy notice supports it
- Hashing performed before data leaves your systems, with the fields documented
- A record of which measurement is consent-dependent, so gaps stay explainable
The order the work happens in
Measurement goes wrong in a predictable sequence, so the work is sequenced to match it. Each stage below has to hold before the next is allowed to begin, because an error carried forward gets more expensive at every step it survives.
- 01
Audit every action that is counting today
We open each conversion action in each ad account and trace it back to the tag, import or SDK call that creates it. Counting mode, attribution window, primary or secondary status and value settings are all recorded. Anything nobody can explain is flagged before it is changed, so the audit stands on its own.
- 02
Write the conversion specification
The actions, their definitions, their values, their destinations and their owners are written down and reviewed with whoever will read the reporting. Disagreements about what a qualified lead is are cheap to settle in a document and expensive to settle after the tags are live. Nothing is implemented until this is agreed.
- 03
Implement across client, server and app
Tags, dataLayer pushes, server endpoints and SDK calls go in together, because a partial implementation produces the worst possible state: some conversions counted, some missing, and no way to tell which is which. Where the application has to emit an event, that change goes through your normal review and release process rather than around it.
- 04
Verify each path in a debug environment
Nothing is signed off from a screenshot. Each event is exercised on a real browser and a real handset, with consent first granted and then refused, on desktop, on mobile web and inside the in-app browsers that so much social traffic arrives through. Duplicates are triggered on purpose to prove the deduplication key holds, and the resulting row is located inside the destination account before a path is called finished.
- 05
Document the event map and name an owner
The work closes with a map of every conversion action: where it fires, what it carries, which account receives it, which campaigns bid on it, and one named person responsible for it. Tracking decays at the next release. A document with an owner attached is the only thing that reliably slows that down.
How one real sale becomes a signal an auction can use
Six stages, and five hand-offs between them. A hand-off is where a conversion picks up an error nobody notices until the reporting is challenged in a meeting, which is why every stage below carries an owner and a check instead of an assumption.
- 01
Define the action
Somebody has to say in plain words which interaction represents value and what it will be called: a submitted enquiry, a completed checkout, a subscription that has begun billing. That definition is written down before any code exists, because every number, argument and bid strategy downstream inherits it unchanged.
- 02
Implement the event
The event is emitted by whichever part of the system genuinely knows the outcome occurred, or pushed into the dataLayer for a container to act on. It fires on the confirmed result, never on a URL a visitor can reload, and it carries a transaction identifier from the first moment it exists.
- 03
Attach value
A conversion without a value can only be counted. With a real amount and a declared currency it can be bid on, compared and ranked. Where no revenue exists yet, a lead value is derived from your own pipeline rather than invented to look impressive.
- 04
Transmit to the destination
The event travels to wherever it has to be usable: a GA4 key event imported into Google Ads, a Conversions API call to Meta, a Firebase event linked to an app campaign, or an offline upload from your CRM. Identifiers travel with it.
- 05
Verify end to end
Somebody sits with a debugger and a real handset, completes the action, and confirms that one event arrives rather than two, carrying the amount the order actually charged. The duplicate path is fired deliberately to prove it is suppressed, and the row is found in the account that will bid on it. Until that has been observed, the implementation is a claim rather than a fact.
- 06
Feed the bidding system
Only then is the action marked primary and handed to a bid strategy. The auction now optimises towards something the business recognises, and when performance moves there is a defensible answer to the question of what the platform was actually buying.
Three places a conversion can be defined
These are not competing options so much as different fits, and the interesting failures happen where two of them describe the same sale. Deciding which one owns which outcome, on purpose and in writing, is most of the job.
Client-side
- Fires in the browser or the app, visible in a debugger within seconds
- Blocked by ad blockers, browser restrictions and denied consent categories
- Loses events when a payment redirect, a crash or a closed tab interrupts the session
- Quick to implement and just as quick to break with an unrelated release
- Right for engagement signals and anything the server never sees
Server-side
- Sent from a system that already knows the order is real
- Survives ad blockers, but adds infrastructure someone has to run and monitor
- Needs a shared event ID, or it double-counts against the client-side tag
- Fails silently by nature, so logging and retries are part of the build
- Right for purchases, refunds and anything money depends on
Offline & imported
- Uploaded from a CRM or back office days after the click that caused it
- Needs the click identifier captured at lead creation and kept until close
- Bounded by the platform's import window, so outcomes that land late are lost
- Carries the value that actually matters: the deal, not the enquiry
- Right for long sales cycles, phone-closed deals and qualified lead scoring
Verification before anything is trusted
None of this is clever. It is the difference between a number you can defend in a budget meeting and one you end up apologising for. An implementation is not finished until every line here has been observed, not assumed.
- The event fires once per real conversion, confirmed by deliberately trying to fire it twice
- A page refresh, a back-button return and a bookmarked confirmation URL produce no new conversion
- Value and currency arrive correct against a real order, including tax, shipping and discount handling
- Pixel and Conversions API events deduplicate on a shared event ID, checked in the events manager
- The event arrives in the destination ad account, not only in the analytics property
- It is attributed to the intended conversion action, not folded into a legacy one with a similar name
- Primary and secondary designations match what each campaign is supposed to be bidding towards
- Consent-denied behaviour is tested as deliberately as consent-granted behaviour
- Tested on mobile web and inside an in-app browser, on a real device rather than an emulator alone
- Every action appears in a written event map with its trigger, its value and its destination
- One named person owns each conversion action, so the next release has somebody to notice it break
Two numbers doing two different jobs
Expect a gap and stop treating it as a defect to be engineered away. An ad platform is not keeping your accounts; it is scoring its own auctions, which means it counts within windows it sets itself, fills in what a refused consent removed with an estimate, and takes credit for a journey it saw only the opening of. Your order table records money that settled and nothing else. Someone who taps an ad on a phone at lunch and pays from a laptop that evening is one customer to you and something far less certain to the platform. Grinding the two towards agreement costs weeks and finishes where it started. The workable discipline is narrower: give each recurring decision one number, record which system owns that number and why, then leave the definition alone long enough for a trend to mean anything at all.
Tools we work in
Names appear here to say where the work physically happens, and for no other reason. None of them implies partnership, certification, reseller status, endorsement or any other relationship, and each remains the trademark of whoever owns it.
- Tagging and containers
- Google Tag Manager
- Server-side Google Tag Manager
- Google tag (gtag.js)
- dataLayer
- Google Ads conversion tags
- Meta Pixel
- Consent Mode v2
- Destinations and APIs
- Google Ads
- Google Ads API
- Google Analytics 4
- Meta Conversions API
- GA4 Measurement Protocol
- Firebase Analytics
- Offline conversion import
- Enhanced conversions
- Verification and debugging
- GA4 DebugView
- Tag Assistant
- Meta Events Manager test events
- Chrome DevTools
- Charles Proxy
- Firebase DebugView
- Android Studio Logcat
- Infrastructure and records
- Google Cloud Run
- Cloud Logging
- BigQuery
- Node.js
- Git
- Google Sheets
What you are left with
- Every conversion action traced to a real business event and defined in writing
- Events verified firing once, at the right value, in the destination account
- Pixel and server events deduplicated on an identifier you can check yourself
- Consent-dependent measurement documented, so gaps are explained rather than argued over
- An event map with a named owner, so a break introduced by the next release has somebody positioned to catch it
What people ask before starting
01Who owns the containers, tags and conversion actions?
You do, without exception. The Google Tag Manager container, the server-side container and the cloud project it runs on, the analytics property and every conversion action inside your ad accounts are set up in your name from the first day. Every credential we hold was issued by you and can be switched off in a couple of clicks, with no conversation required first. Implementation code lands in your repository with its commit history intact. When the work stops, nothing has to be handed over, because nothing was ever kept anywhere but with you.
02Is any of this backed by a platform certification?
None whatsoever. MNF Infotech is an independent supplier: no badge, no tier, no certificate, no reseller agreement, and no mandate to represent Meta Platforms, Inc., Google LLC or anybody else whose products are named here. No platform endorses this work, and none of them has any say in the advice you get from us. Those names appear because the tags, containers and events physically live inside those products, and for no other reason. If a badge is written into your procurement rules, say so at the enquiry stage; we would rather lose the work now than argue about it once a contract exists.
03Can this be done in the tag manager without touching our code?
Partly, and the part that can is the part that matters least. Engagement events and simple page-based triggers live comfortably in a container. Purchases, single-page route changes, order identifiers and anything depending on application state need a dataLayer push or a server call, which means a code change through your normal review process. We will tell you which is which before we start.
04What makes one implementation cost more than another?
Four things, mostly. How many distinct conversion actions exist and how many destinations each has to reach, because verification happens per action per destination rather than once per project. Whether server-side tagging is genuinely required, since that brings infrastructure somebody has to build, run and watch. How much of what already exists survives the audit instead of being torn out and replaced. And whether an offline import means integrating with a CRM that was never designed to give its data up. Cloud and platform charges go straight from the vendor to you, never through us. We quote once the audit has shown which of those four apply.
05Which number should we report once this is done?
The one whose definition you can read out loud without hedging. A decision taken inside an ad platform is best made on that platform's own column, because that is the number its bidding reacts to. Anything describing revenue belongs to the system that takes the money. Both definitions go into the event map, along with the size of the gap between them and the reasons it exists, so the same question next quarter produces the same answer rather than a fresh argument.
06Do we actually need server-side tagging?
Not always, and it is worth resisting until the browser has demonstrably failed you. Server-side tagging earns its place when purchases are being lost to ad blockers or a payment redirect, when the truth about an order lives in a back office no browser ever sees, or when refunds have to reverse a conversion after the fact. Against that, it is infrastructure: something to build, monitor, secure and pay for every month. If your browser events are arriving reliably today, we will say so and leave the architecture alone.
07What will you not do?
We will not fire a conversion for an event that did not occur, no matter how much healthier the column would look afterwards. Personal data does not leave your systems for a platform without a lawful basis and a privacy notice that covers it. And we will not bypass a consent banner, disguise a request to slip past a browser restriction, or quietly leave a duplicate in place because removing it would drag the reported total down.
What this work usually connects to
Have your conversion tracking verified
Send us the site or app, the ad accounts and whichever number you no longer believe. We will trace what is currently counting, show you where it breaks, and tell you what it would take to fix it.
Directcontact@mnfinfotech.com