Tracking and attribution for dispensaries

Here is the sentence that should change how you read every dispensary report you have ever been sent.

Calls: The number of times a customer clicked on the call button on your Business Profile.

Google Business Profile Help, read September 8, 2026

A call, in the number your agency shows you, is a button press. Not a connected call. Not a conversation. Not a customer. Every other metric in that report works the same way, and once you know the definitions, most dispensary reporting reads differently.

What Google actually counts

Straight from Google's Business Profile performance documentation, quoted rather than summarized, because the wording is the point.

• Calls are clicks on the call button. Google adds that you must "add your phone number to track this metric".
• Directions are people who asked. Google says it changed how it counts them "to account for: Multiple taps. Direction request cancellation. Spam", so the number is filtered and still stops at the request.
• Views count unique people, not impressions: "A person can only be counted once a day. We don't count multiple visits on the same day." Someone who checks you on a phone and a laptop "can be counted a limited number of times".
• Menu clicks are counted "per user, per day", covering menu photos, menu links and structured menu data. A customer who checks your menu four times before driving over counts once.
• Website clicks are clicks on the website link. That one is what it sounds like.
• Searches, the terms people used, are "updated at the start of each month" and "might take up to 5 days to show up".

Two more that shape everything above. Performance data "is available only for verified Business Profiles", so an unverified or suspended profile reports nothing at all. And the data "includes views, searches, and actions from both organic search results and Google Ads", which for a dispensary is mostly academic since the ads are prohibited, but it does mean the metric is not an organic metric by definition.

None of this is Google being evasive. It is Google being precise, and the precision is available to anyone who reads the help page. Almost nobody selling dispensary reporting does.

Three systems, three different views

A dispensary has three sources of truth and they do not agree, for reasons that are structural rather than fixable.

The Business Profile sees the map surface: how people found the profile and what they tapped. This is where a Map Pack ranking actually cashes out, and it is invisible to your website analytics because most of those actions never touch your site. Someone who searches, taps directions and drives over is a complete customer journey with zero website sessions.

Search Console sees your website in Google's results: impressions, clicks, average position by query and page. It is the only first-party view of what Google is willing to show you for, and the keyword research spoke covers what it does and does not name.

Your analytics and point of sale see behavior on your property and the money. This is the only one that contains revenue, and it is the one most local reporting leaves out.

The mistake is trying to make these reconcile. Profile views count a person once a day; analytics counts sessions; the point of sale counts transactions. Track each against its own history and stop trying to make the columns tie.

Where the chain breaks, specifically

Two breaks, and both are worth naming because vendors routinely paper over them.

The direction request to the door. Nobody outside Google can tell you who arrived. There is no dispensary-grade store-visit measurement we can point at, and any conversion rate you are quoted between direction requests and visits is an assumption wearing a number. The honest workaround is a proxy you control: ask at the counter, or watch whether direction requests and same-day transactions move together over months. Correlation across a long enough window is not attribution, and it is better than a made-up rate.

The call button to the sale. Google counts the tap. Whether anyone answered, how long the call lasted and whether it ended in an order are all outside the metric. Call tracking on your own line closes that gap, with one caution carried from the multi-location spoke: Google requires a profile's phone number to be "the single, authoritative phone number ... verifiable by the business owner", and whether a tracking number satisfies that is not addressed anywhere in Google's documentation. We flag it as an open question rather than recommending around it.

There is a third, softer break specific to this industry: if your menu lives inside a third-party widget, the behavior inside it belongs to that platform's reporting. What each menu provider counts, and how, is something we cannot verify without account access, so this page tells you what to ask them rather than characterizing their numbers.

Tying the offline part back, and its documented limit

Google names the mechanism. Among the uses of the GA4 Measurement Protocol it lists "Tie online to offline behavior" and "Send events that happen outside standard user-interaction, like offline conversions".

Then it names the limit, which is the part that matters:

Advertising identifiers ... are automatically joined with Measurement Protocol events using client_id or app_instance_id.

Google Analytics, Measurement Protocol for GA4

The join key is the visitor's own identifier. A system that never met the visitor, a nightly job reading your point of sale, a booking calendar, a call log, has no client_id to send. So the event arrives with no source attached and lands as direct traffic. That is not a misconfiguration, it is the documented behavior, and it has three practical consequences.

• Keep server-recovered conversions as their own event. Merging an unattributable count into your main conversion silently poisons every channel report you run afterwards.
• Do not build the whole stack server-side. Google's own words: "While it's possible to send events to Google Analytics solely with the Measurement Protocol, only partial reporting may be available. The purpose of the Measurement Protocol is to augment existing events."
• Watch for derived events. Google states that "Rules for generating or renaming events aren't triggered by events sent with the Measurement Protocol." If your conversion is created by a tag-manager rule from a raw event, sending that raw event server-side means the conversion never fires.

One more small trap in the same documentation: if device information is not sent, it "defaults to desktop for Web streams", which quietly skews a device report nobody thinks to question.

A worked example: booking a call

Take the case that breaks most local setups, because it shows every rule on this page at once.

A form submission is easy: the page fires a browser event on success, the visitor's identifier is present, and the conversion can be derived from that event in the tag manager. A booked call is not. Google publishes no event API for its appointment scheduling, so completion cannot be observed in the browser at all. The only way to count it is server-side, reading the calendar feed on a schedule and sending the result in.

Which lands you exactly where the client_id rule above says you will land: that scheduled job never met the visitor, so the event arrives with no source attached and is attributed to direct. The correct response is not to fight it. It is to keep the booking count as its own event, never merged into the form-conversion count, so one honest number is not quietly poisoning the other.

That is the shape of nearly every offline-to-online problem in a dispensary. The outcome you care about happens somewhere the browser cannot see, the bridge back is server-side, and the bridge loses the source. Design the report around that instead of pretending the join is clean, and set out which parts of the chain are instrumented and which are inference before anyone signs off on the numbers.

What to report instead of rankings

Rankings are an input. Google states there is "no way to request or pay for a better local ranking", and separately that third-party tools "don't have access to Google's internal ranking data" and that none is "approved by Google Search". A report made only of positions is describing an input, measured by an instrument nobody validates, against an outcome it never looked at.

Report these four instead, every month, in this order.

1. Profile actions. Calls, direction requests, website clicks and menu clicks, downloaded from the profile rather than retyped. Google supports exporting these to a spreadsheet, and multi-location operators can export several profiles at once. If your columns come back full of asterisks, downloads are not enabled on those profiles yet.
2. Position across the trade area. Sampled from where customers actually are, since distance is measured from the searcher. Label it as your measurement, not Google's.
3. Revenue from the point of sale, split by new and returning. This is the column that makes the rest of the report an argument rather than a slide.
4. Search Console by query family, with families defined before you look at the data so it cannot flatter you afterwards.

The working checklist

1. Verify the profile or nothing else on this list produces data.
2. Add the phone number to the profile, which Google notes is required for the calls metric to exist.
3. Export profile performance monthly rather than screenshotting it, and enable downloads if you manage several locations.
4. Stop calling button taps "calls" in your own reporting, and rename the row.
5. Decide the call-tracking question deliberately, knowing Google's authoritative-number rule and that the interaction is undocumented.
6. Keep server-recovered conversions as separate events from browser conversions.
7. Check whether any conversion is derived by a rule before sending its raw event server-side.
8. Send device information with server events so the report does not default everything to desktop.
9. Define query families in advance and report core separately from anything you no longer sell.
10. Put revenue in the report. If it is not there, the report is not finished.

Frequently asked questions