Key takeaways
- Name the event before you scale spend. An ontology beats twenty tags nobody uses.
- One source of truth, consent-aware collection, and deduplication — or your dashboard is a story.
- Offline outcomes belong in the architecture. A form submit is not a sale.
The dashboard shows forty conversions. Sales closed three. Finance asks which channel worked. Nobody can answer because “conversion” meant four different things.
Conversion tracking architecture is the work you do before another campaign launches: an event ontology, a source of truth, consent rules, deduplication, and an offline outcome you can tie back to the click. If you cannot name the event, do not scale the spend. A pixel that fires on every page view is not strategy. It is noise with a logo.
How to build a high-conversion sales funnel in 2027 named the stages. How to sell more from your website named the leak when the page stalls. This page is the measurement layer that keeps both honest.
A conversion is a decision, not a firehose
Teams install tags because the platform wizard told them to. Then marketing optimises for form submits while sales optimises for qualified proposals while finance counts cash. Each team has a chart. None of them describe the same object.
Start with definitions. A conversion event is an observable action that changes a decision: pause an ad group, rewrite a page, call a lead, send a proposal, or recognise revenue. If the number moving does not change what someone does next week, it is not a conversion event. It is decoration.
| Label | Often means | Should mean |
|---|---|---|
| Conversion | Any tagged click | One primary action per funnel stage |
| Lead | Form submit | Reply you can work |
| Qualified lead | MQL in CRM | Fit + intent + timing you defend |
| Customer | Stripe charge | Cash for the scoped offer |
Google’s tagging guidance for Google Analytics and Google Ads conversion tracking assume you know which events are primary and which are diagnostic. The platforms will count what you tell them to count. They will not choose your business definition.
Name the event ontology
An event ontology is the list of events the business actually uses, with one owner each.
Macro events change budget or roadmap: qualified lead, proposal sent, contract signed, purchase, renewal.
Micro events diagnose friction: form start, form error, offer-section view, click-to-call, chat open, checkout step.
Forbidden events are duplicates of macro events under cuter names, or events that fire twice because two tools listen to the same DOM node.
Document each event in one table:
| Event name | Trigger | Owner | Primary? | Feeds which decision |
|---|---|---|---|---|
| `form_complete` | Successful submit on `/quote` | Marketing | Yes | Pause/scale ad groups |
| `call_click` | Tap-to-call on mobile hero | Marketing | No | Diagnose mobile layout |
| `qualified_lead` | CRM stage set by human | Sales | Yes | Channel mix review |
Cap primary events per funnel. A practical service funnel might track landing view, offer view, form start, form complete, qualified response, proposal, and close. More than that without owners is how dashboards go stale.
Wednesday: export your last thirty days of “conversions.” List what actually fired. Delete or demote any event that did not change a decision.
Pick one source of truth per question
Analytics breaks when every tool claims to be canonical.
- Traffic and on-site behaviour: one web analytics property with a documented data layer.
- Paid media outcomes: ad platform conversions aligned to the same primary events, with deduplication rules written down.
- CRM truth: qualified stages and revenue live in the system sales uses, not in a spreadsheet beside it.
Consent belongs in the architecture, not as a footer afterthought. The ICO guidance on consent and cookies and platform consent modes determine which events may fire before acceptance. Essential measurement — error logging, security, completion of a purchase the user requested — differs from optional analytics and advertising tags. Collect less, document why, and do not compare pre-consent traffic to post-consent traffic without labelling the break.
Deduplication rules must be explicit: one primary conversion per session for ads, server-side backup where platforms allow it, and CRM imports that do not double-count offline wins already attributed online.
Wire offline outcomes back
A form submit is not a sale. Architecture is incomplete until offline stages import cleanly.
Define the offline outcome: qualified call, proposal, contract, payment, churn. Map each to a CRM stage or finance record. Import on a schedule sales will maintain — daily is enough for most service businesses. Match on a stable ID: email, phone, or opportunity key — not “same first name.”
Google Ads supports offline conversion imports when you can pass click identifiers or hashed customer data under current policies. Use them when paid search is material spend. Without offline feedback, algorithms optimise for forms, not revenue.
QA before spend scales
Run a release checklist every time tracking changes:
1. Event fires once per intended action in staging and production. 2. Primary events appear in analytics, ads, and CRM with the same name or mapped alias. 3. Consent denied suppresses optional tags; essential paths still work. 4. Mobile and desktop both complete the path. 5. A test lead flows to the inbox and CRM with source preserved. 6. Offline import test row appears in reporting within the promised window.
Digital marketing owns the media map. Web development owns the data layer and tag implementation. Splitting those without a shared ontology is how teams argue with charts.
When reporting is broken, start with paid ads analytics. When the page completes but sales does not recognise the lead, that is conversion repair. The estimator at get started scopes the architecture before the next campaign buys fiction.
