Why Three Departments Got Three Different 'Net Revenue' Numbers—and How a Semantic Layer Fixes It for Local SEO

The Same Data, Three Answers

Ask a simple question—'What was last month's net revenue for the East region?'—and you might get three different numbers from three different departments. Finance says it's confirmed revenue. Operations counts what customers actually paid after refunds. Sales points to signed contracts.

None of them are wrong. They're just answering different questions using the same label: 'revenue.'

For local SEO, the same chaos shows up in reporting. One dashboard says your Google Business Profile impressions doubled. Another says clicks stayed flat. A third shows calls didn't move. All three can be true if each tool measures a different thing—impressions might include map views, clicks might exclude direction requests, and calls might only count those that lasted over 30 seconds.

Data Isn't the Same as Business Definition

Look at a raw order record: order_id 10086, amount 999, status 3, created_at 2026-07-12. The database knows the technical rules—this is a numeric field, that one is a timestamp. But it doesn't know whether 'amount' means the signed contract value, the user's actual payment, or the net after refunds.

Even when a field is literally named 'revenue,' the business meaning is still ambiguous. Is it gross or net of tax? Does it include shipping? What if the order was partially refunded?

In local SEO, the equivalent is a metric like 'views' in Google Business Profile. Google counts a view when a user opens your profile, but it also counts views when they see your profile in a map search without clicking. That's a different action than 'search views' or 'post views.' The field name is the same, but the business definition varies.

The Real Problem: Rules Are Scattered

BI tools let anyone pull data and build reports. That's great for speed, but it means every analyst rewrites the same logic in their own way. One person filters by payment date; another uses order date. One includes refunds; another doesn't.

The issue isn't too many reports. It's that business rules aren't managed in one place. Reports and AI just amplify the inconsistency.

For a local business, this shows up when you compare your Google Business Profile stats with your website analytics. The profile might count a 'click-to-call' as any tap, while your phone system counts only calls that connected. Suddenly, your phone call count for the week is either 15 or 47, depending on who you ask.

You Can't Automate What You Haven't Defined

A semantic layer won't decide whether 800K, 1M, or 1.2M is the 'right' revenue. Those numbers serve different purposes. Sales cares about contracts, ops cares about payments, finance cares about recognized revenue.

What you need is to give each concept a clear name, define when to use it, specify the calculation rules and data sources, and assign an owner who reviews and updates the definition. Then record version changes.

For local SEO, that means writing down what 'impressions' means for your team. Does it include map views? Do you count a view if the profile is shown but the user never scrolls to it? Make a decision, write it down, and stick to it.

Turning Definitions into Executable Rules

Databases speak technical language—payments.pay_amount, payment_status. Business people speak business language—'successful payment,' 'East region,' 'last natural month.' A semantic layer sits between them, translating business definitions into structures the database can query.

Take 'platform net payment amount.' In a semantic model, you'd break it into metrics, dimensions, and relationships. The metric might be 'net payment,' defined as successful payments minus successful refunds in the same period. The dimension could be 'region,' mapped to a field like 'customer_region.'

For local SEO, this could mean defining 'local visibility' as a composite metric: your Google Business Profile impressions plus your website organic sessions from your service area, minus any sessions that bounced in under 10 seconds. You'd map each part to its data source—GBP API, Google Analytics, call tracking—and set the time range to your business's timezone.

From Question to Query

When someone asks, 'What was last month's East region net revenue?' the system shouldn't guess. It should ask: 'Do you mean contract value, platform net payment, or confirmed revenue?' Then it runs the query against the right definitions.

The result isn't just a number. It comes with context: metric name, region, time range, timezone, data refresh time, and the user's permission scope. That way, anyone can trace exactly what was calculated and why.

In local SEO, that context might look like: 'Impressions for your 5 locations, last full month, excluding map views, data refreshed 2 hours ago, filtered to your manager-level access.'

Why This Matters for Local SEO

Local SEO is full of ambiguous metrics. 'Rankings' can mean map pack, organic, or local finder. 'Visibility' might include impressions, clicks, or calls. 'Engagement' could be reviews, posts, or Q&A.

If you don't define these terms, you'll keep arguing over numbers instead of acting on them. A semantic layer—or even just a documented business glossary—forces everyone to agree on what they're measuring. Then your reports, dashboards, and AI tools can all use the same definitions.

You don't need a big enterprise system. A shared spreadsheet with definitions, owners, and calculation rules is a start. The goal is to make your business definitions reusable, so you're not reinterpreting the same data every week.

When your team asks, 'Did our local SEO improve last month?' you'll be able to answer with one number, one definition, and one source of truth—not three.