Google Analytics is a category-defining tool. It is not the wrong tool. It is the tool that answers "how many?" — and B2B teams keep asking it "who?" instead. That is a category error, not a product complaint. This piece is about what each question is for, and what happens when you stop overloading one tool with the job of both.
The questions aggregate analytics is built to answer
Aggregate analytics — Google Analytics, Plausible, Fathom, Matomo, any of them — is optimised for questions phrased as counts. How many sessions did the pricing page get? What is the bounce rate on the pillar article we published on Monday? Which channels are growing month over month? Which country tab has the highest engagement? These are the questions marketing teams need answered every week, and this is the category of tool that answers them well.
The reason aggregate analytics answers those questions well is precisely the reason it cannot answer "who?" — it is designed to strip personally identifying detail out of the pipeline before it hits your dashboard. Sessions are counted, cohorts are grouped, geographies are rolled up. The person behind the session is deliberately erased. That erasure is the product working correctly.
The questions only company-level identification can answer
B2B sales does not ask "how many?" It asks "who?". Which companies looked at pricing this week? Which target-account visitors came back a second time? Which enterprise came through a comparison page and read the security page? These questions are not obtainable from counts — they need the entity behind the session resolved to a company, and they need it done in a way that is legally defensible for the EU.
Company-level identification does exactly one thing that aggregate analytics deliberately does not do: it resolves the IP address the session originated from to an organisation, using verified B2B data with a documented lawful basis. It does not identify the individual — no cookies, no fingerprinting, no personal profile — only the organisation. That is a very narrow product, and that narrowness is what makes it defensible.
The question table you can put in front of your team
| Question | Aggregate analytics | Company-level identification |
|---|---|---|
| How many sessions did the pricing page get? | Yes — native metric | No — not its job |
| Which companies looked at pricing? | No — anonymised by design | Yes — its primary job |
| What is the bounce rate on the pillar article? | Yes — native metric | No |
| Which target accounts read the security page? | No | Yes — filter identified list by page |
| Which country produces the most sessions? | Yes | Partial — country available per company |
| Which SDR should call ACME Corp today? | No | Yes — company + pages + recency |
| Which channels are growing month over month? | Yes — native report | No |
| Did the campaign account for last week’s pipeline? | Partial — first-touch attribution | Yes — identified companies with UTMs and outcomes |
A useful test if you are unsure which side a question lives on: does the answer help you decide which company to call, or does it help you decide which channel to invest in? Call-decision questions belong on the right column; channel-decision questions belong on the left.
How to set them up as complements, not competitors
The teams that get this right run both tools without either one trying to be the other. Aggregate analytics owns the weekly and monthly rhythms — the "how is our traffic trending?" review. Company-level identification owns the daily and hourly rhythms — the "who deserves a human today?" review. Both dashboards live in the same folder. Neither pretends to replace the other.
Practically: leave your existing aggregate setup untouched. Add a small company-identification script — the delta is one loader and a few kilobytes. Push the identified companies into wherever sales already looks (CRM, Slack channel, shared doc). Now marketing keeps their weekly channel report; sales gets a daily named list. Nothing about your analytics stack has to change; you simply extend it with a data source it was never designed to produce.
Consent surfaces are different
Aggregate analytics that uses cookies typically triggers a consent banner in the EU. Company-level identification without cookies — no client-side identifiers, no cross-site tracking — does not trigger the same banner requirement because it does not rely on storing information in the visitor’s terminal equipment. Two products, two different surface areas, two different consent conversations.
Three anti-patterns to avoid
- Trying to reverse-engineer identified companies from aggregate analytics by filtering by "ISP" — you will get a list of network operators, not businesses.
- Turning off aggregate analytics because "we have identification now" — you will lose your channel and campaign reports, which identification was never designed to produce.
- Sending identified-company data into an aggregate analytics tool as a custom dimension — you will muddy your aggregate reports and probably violate the analytics tool’s TOS.
The mental model that keeps this simple
Aggregate analytics is your traffic thermometer. Company-level identification is your visitor list. A thermometer tells you the room is warmer than yesterday; the list tells you who came in. Both facts are useful; neither replaces the other. Once teams accept that framing, most of the "should we switch?" debate disappears — the answer is "both, for different questions."
If you are shortlisting tools that answer the "who?" question, our Leadfeeder alternative overview walks through what a GDPR-first, company-only setup looks like in practice.
Published by
lead.box Team
More articles
See lead.box on your own traffic
Start free — no card, no sales call required. Or book a 20-minute walk-through if you want the guided tour.