The problem: three dashboards, three different answers
Google Ads says 412 purchases last month. Meta says 380. GA4 says 290, and the store’s order system says 305. Everyone in the meeting has a number, nobody knows which one to believe, and the budget decision gets made on instinct. That situation is so common that most marketing teams have stopped noticing it.
The causes are usually mundane: a purchase event that fires twice on page refresh, a conversion tag that was never updated after a checkout redesign, consent banners blocking tags for a large share of European visitors, ad blockers and browser tracking prevention eroding cookies, and attribution windows that differ by platform. None of it is exotic. All of it compounds until reported ROAS is a fiction and bidding algorithms are learning from corrupted signals.
What conversion tracking and analytics services involve
Analytics and conversion tracking is the infrastructure work of defining what a conversion is, capturing it reliably across browsers and consent states, sending it to each platform in the form that platform can use, and reconciling the whole thing against your source of truth. It sits beneath every other marketing service: paid search, paid social, affiliate and CRO are all only as good as the events they optimize on.
Done well, it is also mostly invisible. The output is not a wall of charts; it is confidence that when a campaign’s cost per acquisition changes, something real changed.
Who this is for
Businesses spending meaningfully on paid media, running lead generation with an offline sales step, or operating e-commerce stores where purchase data flows through multiple systems. It is also relevant to SaaS companies whose real conversions (activation, upgrade, retained) happen inside the product after signup, and to any organization migrating platforms, redesigning checkout, or facing consent requirements in the EU, UK or other regulated markets such as healthcare and finance.
What Axoria does
Event design: measure decisions, not clicks
Start from the questions
A GA4 property with two hundred auto-collected and hastily added events answers nothing. We start with the questions the business needs answered (which channels produce qualified leads, where do checkout users drop, which content leads to trials) and design events backward from them. Each event gets a name following GA4’s recommended schema where one exists, a fixed set of parameters, a defined trigger condition and a note on which platforms it is sent to.
Values that reflect worth
Conversions carry values so that bidding can weigh them. For e-commerce that means purchase value with tax and shipping handled consistently and, where possible, margin-adjusted values. For lead generation it means assigning relative values to lead, qualified lead and opportunity stages so a platform optimizing on value chases quality. For SaaS it means treating trial start, activation and paid conversion as distinct events with different weights, and sending the later ones back from the product database.
The data layer: the foundation your developers build once
Tags that scrape values from page elements break the moment a designer changes a class name. A data layer is a structured JavaScript object the site pushes on each page and interaction, containing everything tags need: page type, product IDs and prices, transaction totals, user login state, hashed email for enhanced conversions. We write the specification, review your developers’ implementation, and build the GTM container against it. On Shopify, WordPress with WooCommerce and most platforms there are established patterns; on custom stacks the spec is the main deliverable.
Server-side tagging and consent: what actually changes
Server-side tagging
A server container receives a single event stream from the browser and forwards it to GA4, Google Ads, Meta and others from your own subdomain. Benefits: first-party cookies with longer lifetimes under Safari and similar restrictions, fewer scripts in the page (which helps Core Web Vitals), and control over which fields each vendor receives. Costs: hosting, more moving parts and a real need for monitoring. It is worth it for most businesses with material ad spend, and not for small sites.
Consent Mode v2
Where consent laws apply, tags must respect user choices. Consent Mode passes the consent state to Google tags so that, when a user declines, no cookies are set and Google can model conversions from aggregate signals instead. We connect it to your CMP (Cookiebot, OneTrust, Usercentrics or another), test each consent state and the default before interaction, and make sure Meta and other vendors are governed by the same signals. We do not build workarounds that ignore a user’s refusal.
Enhanced conversions, CAPI and offline imports
Browser-only tracking now misses a large share of conversions, and ad platforms have added ways to recover them. Google’s enhanced conversions send hashed first-party data (email, phone) alongside the conversion so Google can match it to signed-in users. Meta’s Conversions API sends events server to server, deduplicated against the pixel by event ID so nothing is double counted. Both require careful handling of hashing, matching keys and consent.
For businesses where the real conversion happens offline, we set up offline conversion imports: click IDs are captured at form submission and stored in the CRM, and when a lead becomes an opportunity or a sale, that outcome is uploaded to Google Ads (and sent via CAPI to Meta) with the original click ID and timestamp. This is the mechanism that lets Google Ads campaigns optimize toward revenue instead of form fills, and it is the single most valuable piece of B2B tracking work.
Attribution models are lenses, not truth
GA4 defaults to data-driven attribution; ad platforms report on their own last-touch or engaged-view windows; a CRM might record only the first source. We explain what each model can and cannot see, set consistent lookback windows where you control them, and recommend which view to use for which decision. Where an absolute answer matters, we point to incrementality testing under our performance marketing service rather than pretending a model settles it.
Our process
Tracking audit
We inspect the current GA4 property, GTM container, ad platform tags and consent setup; compare reported conversions to source-of-truth records; and list every discrepancy with its cause and business impact.
Measurement plan and data layer spec
Events, parameters, values and destinations are defined with your stakeholders, and the data layer specification is handed to your developers with examples per page type.
Build in a staging workspace
GTM web and server containers, GA4 configuration, ad platform tags and consent integration are built and tested against the staging site or a GTM preview environment before anything goes live.
QA across states and devices
Every event is verified in GA4 DebugView, Tag Assistant and platform event managers, across consent states, browsers, logged-in and logged-out users, and edge cases such as refunds, refreshes and back-button navigation.
Go live and reconcile
After launch we compare each platform’s conversion count to the source of truth over a full week and document the expected variance, so future anomalies are recognizable.
Reporting and monitoring
Dashboards are built for each audience, tag monitoring is set up to alert on event volume drops, and the documentation is handed over so your team or any future agency can maintain the setup.
Tools we typically work with
Google Analytics 4, Google Tag Manager (web and server), Google Cloud Run or Stape for server container hosting, Google Ads and Microsoft Advertising conversion tools, Meta Events Manager and Conversions API, LinkedIn Campaign Manager, consent platforms including Cookiebot, OneTrust and Usercentrics, BigQuery for GA4 exports where data volume or retention warrants it, Looker Studio for reporting, and Microsoft Clarity or Hotjar alongside for behavioural context. For CRM connections: HubSpot, Salesforce and Zapier or Make for custom pipelines.
Reporting that gets used
Most dashboards die because they show everything to everyone. We build Looker Studio reports per audience: a leadership view with blended spend, conversions, CAC and revenue trend; a channel manager view with campaign-level detail and diagnostics; and, where relevant, a data quality view showing platform-versus-source-of-truth variance so drift is caught early. Sources are blended through connectors or BigQuery, with definitions documented on the report itself.
How results are measured
Tracking work is judged on accuracy and coverage. The core measure is the variance between platform-reported conversions and the source of truth after implementation, compared to before, with the remaining gap explained (consent refusals, cross-device, attribution window differences). We also track event match quality scores in Meta and Google, the share of conversions carrying enhanced data, consent rates by region, and tag error and volume alerts over time.
Downstream, better data typically improves campaign performance because bidding algorithms receive more and cleaner signals, but that effect belongs to the campaigns and we report it there, not as a tracking result.
What to expect and common challenges
Developer time is required
The data layer and some server-side pieces need engineering work. We write specs precise enough that a developer can implement them without guesswork, but the time still has to be scheduled.
Numbers may go down
Removing double counting and enforcing consent often reduces reported conversions. Real performance did not change; the reporting got honest. We prepare stakeholders before the switch.
Privacy rules constrain the design
We do not track users who declined consent, fingerprint devices or pass personal data unhashed to vendors. Where a legal question arises, we flag it for your counsel rather than guessing.