Conversion tracking setup with one source of truth per action.

What this covers

This is the build, not the diagnosis. Conversion tracking for Google Ads and Meta, implemented across your tag manager, site and CRM, so every action you sell or capture is measured once, by one system.

One source of truth per conversion action. Each business action gets exactly one measurement path: a native Google Ads conversion tag, an imported GA4 key event, or an offline import. The choice is written down before anything is built. Where a duplicate is already live, retiring the losing path is inside this scope rather than a ticket you inherit.

Counting decided once, and recorded. Every conversion action and every GA4 key event leaves the build with its counting method set deliberately and the reason recorded in the register, and the Google Ads setting and the GA4 setting are decided together rather than one at a time. That happens on the scoping call, against how your business actually repeats: whether the same customer buying again is a second sale, and whether the same person submitting a form twice is a second lead.

Primary and secondary, assigned then locked. The build ships with one named primary action per campaign, the one whose count you want in that campaign’s Conversions column and steering its bidding, and everything upstream of it set secondary. Because a campaign can override the account default, the register records the goal each action sits in and any campaign that departs from it, rather than one flag per action. The register is the deliverable: it is what makes the next promotion a decision someone signs rather than a checkbox someone reasonable ticks.

Enhanced conversions, built from a named source. Web and leads are built against the same rule: the identifier is captured at the moment the customer supplies it, normalized to Google’s format, and hashed exactly once. That means naming a real source for every field on your site rather than scraping a confirmation page that no longer holds it, and stating in the spec what happens on the paths where a field is absent.

Offline conversion import. Built as one path: the click identifier captured on landing and persisted, written to the CRM record at submit, hashed contact details as the fallback for records that lose it, and the return leg that sends stage changes back with a conversion time and a value. The conversion window on the action is set as wide as the platform allows if your deals need it, before the first upload rather than after one fails. The platform caps that window, so where the sales cycle runs past the ceiling, closes that land outside it cannot be imported against the click. That is said during scoping, not discovered on the first upload.

Meta pixel and the Conversions API. Both paths are built and deduplicated on a shared event ID, and Events Manager is the sign-off rather than the configuration screen. Where the server path runs on your own infrastructure rather than a hosted relay, that is a server-side tagging build and is scoped there.

How it runs

Scope comes before price. A call establishes which actions matter, which systems hold the data, and which pieces need a developer on your side. The work is quoted fixed-price against that scope.

The spec is the first deliverable. Which system owns which action, where the click identifier is captured and where it is stored, the normalization and hashing rules for every user-provided field, the counting setting on each action, and what is deliberately not measured. A build with a written spec can be checked; a build without one can only be trusted.

Nothing is constructed in your live container. Tags are built and tested in a separate GTM workspace, across consent accepted, refused and left unanswered, on desktop and mobile with the connection throttled. Everything publishes as one named version referencing the spec, so the whole set reverts in a single action, and nothing publishes until you approve it.

Verification happens at the destination. A tag that fires is not a conversion that counted. Each action is checked against your own orders, leads or CRM records over the same window and timezone, and the difference the platforms are expected to have is stated up front rather than argued later.

What you get

A working implementation, with evidence per action. The request, the payload, and what the platform recorded, before and after, for every conversion action touched.

A conversion action register. One row each: source, counting setting, the goal it sits in and any campaign override, window, owner. This is what stops the next duplicate being created by someone acting reasonably.

The measurement spec as a maintained file, including normalization and hashing rules and the identifier scheme, so a developer can extend it without reopening the decisions.

A recorded walkthrough and a support window. What was built, where each piece lives, and questions answered after handover for a period agreed in the scope.

When this is the wrong fit

The brief is to find out why the numbers disagree. Diagnosis is separate work and it comes first. Scoping a build against a guess is how the wrong thing gets built well.

You want the reporting layer. Dashboards, attribution modeling and blended reporting sit on top of collection. This is collection.

Your CRM cannot store a field or return a list. Offline import needs both. Where neither is possible that part is scoped out rather than quietly promised.

You want tracking that ignores a consent choice, or someone to run the accounts. Neither happens here. Tags are built to respect the state the visitor left. The output is a signal your media buyer can rely on.

Most builds start with the Missing Conversions Audit, because it produces the input a scope is hardest to write without: which actions are miscounted, and by how much. It is $900 flat, and the fee is credited in full toward the implementation that follows. If you already know what needs building, say so on the call and the build is scoped directly.