Why you cannot measure cost per acquisition by location

An attribution gap is the difference between the conversions a system records and the conversions it can attribute to a source. A conversion event that fires without the location parameter needed to assign it is the clearest example.

Nothing is lost or double-counted. Corporate can see aggregate spend and aggregate conversions, and the totals are correct. What cannot be produced is a defensible cost per acquisition for any individual site.

That is a specific failure with a specific consequence: you cannot defend a budget decision at the location level, because you have no location-level number to defend it with.

It also has a specific shape in the reports, which is worth recognising because people misread it. You will see healthy totals and a location dimension that is either absent or largely unset. Nobody raises it, because the number at the top of the page is fine.

Usually because nobody required it. A measurement plan that starts from events rather than from decisions produces events that carry whatever parameters the implementer thought of.

The second cause is cloning. A new location is onboarded by copying the last one, and the cloned conversion action still points at the original site's thank-you page. It reports conversions cheerfully and attributes them to the wrong location, sometimes for months.

The third is third-party handoffs. The visitor moves to a booking platform or payment processor, the session breaks, and whatever location context existed does not survive the trip. This one has a defined fix rather than a workaround: the destination domains have to be configured on the data stream so the identifier is carried across in the link parameter.

The fourth is quieter and catches good implementations. The parameter is on the event and nobody ever registered it, so it exists in collection and not in reporting. Google's own guidance treats these as two separate steps, with data appearing 24 to 48 hours after both the parameter has been sent and the custom dimension has been created. Sending is usually a developer's task and registering is usually an analyst's, and the handover is where it dies.

Only the first is a design problem. The other three are verification problems: the work was done and never checked against real traffic.

The franchisee row is the one that creates political problems rather than only analytical ones. A franchisee paying into a corporate marketing spend and receiving a consolidated number has no way to verify they are getting value, and reasonably assumes they are not.

The last row matters if you use an agency. Without per-location data, no claim about performance can be falsified, which is not a position any operator should accept.

There is a compounding cost the table understates. Every month the gap stays open is a month of history you will not have when someone finally asks how a location has trended. The fix is forward-only, so the cost of delay is not the delay itself, it is the missing baseline afterwards.

The same shape of problem appears when the segments are languages rather than places. One blended cost per acquisition across French and English hides which of the two is carrying the other, and the remedy is identical: the segment has to exist in the data before any budget argument about it can be settled. Running two languages through a single account is where this comes up most often in Ottawa.

The instinct, when location is missing, is to create a separate conversion action for each site. It looks like the direct solution: one action per location, each with its own count, no parameter required.

It is a trap in two different systems at once. In Analytics, a standard property allows 30 key events, 50 event-scoped custom dimensions and 25 user-scoped custom dimensions. One key event per location spends the entire allowance on a single question, and a group with more than thirty sites cannot even finish the job.

In Google Ads it is worse, because it fragments the data bidding runs on. Conversion actions are what the bid strategy optimises against, and splitting one well-populated action into thirty thin ones gives the algorithm thirty sparse signals instead of one strong one. You have bought a report and paid for it in performance.

One conversion action, carrying a location parameter, registered once as a custom dimension. That is a single slot, a single bidding signal, and a dimension you can segment every report by. The version that scales is the boring one.

Start with the measurement plan, not the tags. Name the decisions the business makes monthly, then the events and parameters those decisions require. If location is not a required parameter on every conversion event, per-location reporting is impossible later without reimplementation.

Pass a stable identifier rather than a display name. A store called "Kanata" that becomes "Ottawa West" at rebrand splits into two series that nobody can join afterwards, and no report will tell you it happened. Use the same identifier the business uses in its own systems, so a marketing number and a finance number can be reconciled without a lookup table somebody maintains by hand.

Then trace the highest-value conversion path end to end in a real session with debug tooling open: user action, data layer, trigger, tag fire, platform receipt. Duplicate firing and broken linkage are visible in minutes this way and invisible in reports for months.

Then verify again after a week of live traffic. The failures that matter are conditional: the mobile variant of the form, the returning visitor, the booking flow that only redirects for one service type. Those are the failures that survive launch QA, and they are the reason a second pass exists.

A franchise IV therapy operator with more than fifteen clinics across two states had exactly this gap. Tracing it to the event layer in GA4 and correcting the conversion configuration so location resolved on every conversion restored per-clinic attribution across every site, and made automated per-location quarterly reporting possible.

If the events are wrong, this is a GA4 and Tag Manager implementation problem: event architecture, parameters, and verification per conversion path.

If the events are right and the systems still disagree, it is a conversion attribution audit: quantify each gap, separate structural variance from defects, and declare which source is authoritative for which decision. Some of the gap between platforms is designed in rather than broken, which is worth understanding before you go looking for a bug.

If you need to join location data across ad platforms, call tracking and a booking system to answer the question at all, it is a marketing data warehouse. Cross-platform questions cannot be answered without a place the data sits together.

Do this before optimisation work, not after. Per-location cost per acquisition is not comparable until it is fixed, and optimising against incomparable numbers is measuring a bent ruler more carefully.

Open last month's report and try to produce cost per acquisition for your best and worst site. If the location dimension is missing or mostly unset, you have the gap, and the rest of this is a plan rather than an investigation.

Then count your conversion actions. If there is one per location, the fix above is also a consolidation, and it should be sequenced deliberately because merging conversion actions resets what bidding has learned.

Then check the newest location. Onboarding is where the pattern reproduces itself, and the most recently added site is the one most likely to be pointing at an older site's confirmation page. If the newest one is correct, the runbook is working. If it is not, fixing the historical sites without fixing the runbook buys you a year.