Twenty questions to ask an attribution vendor, and the answers that should worry you

Attribution software is unusually easy to demonstrate and unusually hard to evaluate. The output is a chart of revenue by channel, every vendor can produce one, and a chart that is entirely fabricated looks exactly like a chart that is rigorously derived. There is no visible difference until somebody tries to trace a number, which almost never happens during a purchase.

In most software categories the demo shows you the product. In attribution the demo shows you a chart, and every product has one.

These are the questions that produce a difference. Some of them we would prefer buyers did not ask us either, which is the correct test for whether a question is worth including.

The four questions that matter most

Ask to see unmatched revenue as specific sales, ask which rule matched a specific row, ask what the tool does when it is unsure, and ask to run on your own data. Everything else is refinement.

1. Show me the revenue you could not attribute, on my data, as a list of individual sales with amounts.
2. Take any matched row and tell me which rule joined it and on what identifier.
3. What does the system do when a match is plausible but uncertain? Where does that revenue go?
4. Can we run this on a real export from our systems this week, rather than on a demo dataset?

The first question is the one that discriminates. A tool that reports a percentage but cannot produce the sales behind the remainder is not measuring; it is asserting. The answer takes seconds if the capability exists, and produces a noticeable change of subject if it does not.

The third question is the ethical one. There are only three honest answers — it goes to an unmatched bucket, it goes to a review queue, or it is counted at a stated confidence level. An answer along the lines of the algorithm handles it means revenue is being assigned by a rule nobody will show you.

Questions about matching

Matching is where accuracy is won or lost, and the details are rarely volunteered. Ask specifically about normalisation, thresholds, review, and reversibility.

• How are phone numbers normalised, and is the country setting per dataset or global?
• Are matches ever made on name similarity alone, and can that be disabled?
• Can a match be rejected by a human, and does rejecting it change the reported totals immediately?
• Are matching thresholds visible and adjustable by us, or fixed by you?
• Does the system ever match one sale to more than one source, and how is the revenue treated if so?

The reversibility question is more revealing than it looks. A system where a human can reject a match and see the totals change is a system built on the assumption that it will sometimes be wrong. One where matches are final has been built on a different assumption, and it is not a modest one.

The fuzzy name matching question is worth pressing. Name matching is legitimate for surfacing candidates for review and dangerous as a basis for automatically counting revenue, because two people can share a name. A vendor who does not distinguish those two uses has not thought about it carefully.

Questions about the unmatched bucket

How a vendor talks about unattributable revenue is the clearest signal of their philosophy. A tool that treats it as a defect to eliminate will eventually eliminate it by assumption.

Ask directly whether unmatched revenue is ever redistributed across channels, and listen for hedging. Proportional redistribution is a real practice, it inflates every channel by the same factor, and it is usually described in language like intelligent allocation or gap filling rather than by name.

Ask what a typical customer's unmatched share looks like. An honest answer is a range with a caveat about data completeness. An answer under five percent should prompt a follow-up about how, because it is not achievable on ordinary data without either exceptional intake discipline or a redistribution step.

For the avoidance of doubt about our own answer: CloseRev never redistributes. Unmatched revenue goes to a Direct / Unknown bucket, the bucket is always visible, and the individual sales inside it can be opened and read.

Questions about implementation cost

Ask what has to be true before the first real number appears. Tools requiring site tagging, tag manager changes or an integration project have a time to first answer measured in months rather than days.

This is the cost that gets understated most consistently in procurement, because it falls on people who are not in the buying meeting. A tracking implementation needs developer time, a testing cycle, and coordination with whoever owns the website, and those queues are usually the constraint rather than the work itself.

The follow-up question is what happens when the site changes. Tag-based implementations break silently during redesigns, and the failure is typically discovered weeks later when a channel's numbers look wrong. Ask how the vendor detects that and how you would find out.

Questions about data protection

You are handing over your customers' personal data. Ask where it is stored, whether workspaces are isolated, whether deletion is genuine, and what happens at termination — and get it in writing.

• In which jurisdictions is the data stored and processed, and can we constrain that?
• Is each customer's data isolated, and what technically prevents one customer's query reaching another's data?
• Is data encrypted at rest, and who holds the keys?
• When we delete something, is it deleted or flagged? Can you evidence a deletion after the fact?
• On termination, what is returned, in what format, and when is the remainder destroyed?
• Is our data used to train or improve anything sold to other customers?

The soft deletion question catches more vendors than any other on this list. Flagging a row as deleted is a common and reasonable engineering pattern, and it is not deletion in the sense a data subject request means. Vendors are often surprised to be asked and the answer tells you how much thought has gone into this area.

The last question has become materially more important recently. A clause permitting customer data to be used to improve the vendor's products is broad, common, and worth negotiating out or narrowing explicitly.

Questions about getting out

Ask what leaving looks like before you arrive. Export format, historical data, notice period and destruction commitments are all easy to agree during a sale and impossible to obtain afterwards.

The specific thing to secure is the right to export your matched history in an open format, not just your original uploads. The matched data represents work, and a vendor who will return only what you supplied is holding the output of that work hostage in a quiet way.

Ask also about pricing change notice. Attribution tools become embedded in reporting routines quickly, which creates the conditions for uncomfortable renewal conversations. A notice period agreed at the start costs nothing and is unobtainable later.

Questions to ask their customers, not them

Reference calls are more useful when the questions are operational rather than evaluative. Ask what broke, what the match rate turned out to be, and whether the finance team accepted the numbers.

The finance question is the one that predicts satisfaction most reliably. A tool whose numbers were accepted by the reference customer's finance function has passed a test no vendor can stage, and one whose numbers are still disputed internally is telling you what your own second year will look like.

Ask also what the reference would do differently. The answer is almost always about data preparation rather than about the tool, and it will tell you where your own project will spend its time.

The proof of value, structured properly

Run a paid or unpaid pilot on one real export, with a written definition of what success means, agreed before the data is loaded. Without a stated threshold, a pilot becomes a demonstration and always succeeds.

State in advance what would make you decline. A match rate below a certain figure that cannot be explained by your own data completeness. An inability to trace ten sampled sales end to end. Numbers that do not reconcile to your finance total. Writing those down before seeing anything is what turns a pilot into a test.

Use your own data, over a period you already understand well, and include the awkward parts — a month with an unusual deal, a channel you suspect is underperforming, the file with the messy phone numbers. A pilot on clean, convenient data proves nothing about the ninety percent of the year that is neither.

Questions about who owns the number internally

Before evaluating any vendor, decide who inside your business will own the output, run the monthly process and answer for the figures. Attribution tools fail more often for want of an owner than for want of features.

The failure is consistent and easy to predict. A tool is bought by marketing, the export depends on sales operations, the definitions depend on finance, and no individual is accountable for the monthly cycle. The first two months run because the purchase is fresh, the third slips, and by the sixth the login is used occasionally to answer specific questions rather than to produce a regular report.

The owner does not need to be senior and does need to be named, with the monthly cycle in their objectives. Half a day a month is a realistic estimate for a mid-market business once the process is established, and the absence of that half day is what kills more attribution programmes than any product limitation.

It is fair to ask a vendor how their existing customers staff this. A vendor who has thought about adoption will describe the cycle and the role; one who has not will describe the software, which tells you they have not been present for the second year of many deployments.

Pricing questions that matter later

Ask what the price is driven by, what happens when that metric grows, and what a bad month costs. Attribution pricing is frequently tied to volumes that grow with the business, which is fine when understood and unpleasant when discovered.

Common bases are records processed, revenue analysed, users, workspaces and connected sources. Each behaves differently as you grow. Pricing on records processed punishes exactly the behaviour that improves accuracy, since widening the source export is the main lever for reducing unattributed revenue, and a buyer who has not noticed that will find themselves choosing between a better number and a smaller invoice.

Ask specifically what happens in an unusual month — a large historical backfill, a migration, a one-off analysis reaching back three years. Backfills are exactly what you want to do early, and a pricing model that penalises them will quietly discourage the most valuable thing a new customer can do.

Finally, ask for the renewal uplift policy in writing. It is a normal commercial question, the answer is easy to give at the point of sale, and it is a materially different conversation eleven months later.

How to score the answers

Weight the answers by how hard they would be to fake. A specific, checkable claim about matching or deletion is worth more than any amount of general assurance about accuracy or partnership.

In practice three answers carry most of the weight: whether they showed you the unmatched sales on your own data, whether they could explain a specific match, and whether they named their own limitations without prompting. A vendor scoring well on those three is very unlikely to be badly wrong elsewhere; a vendor failing them is unlikely to be saved by a strong feature list.

Be sceptical of answers that arrive as categories rather than facts. Enterprise-grade security, bank-level encryption and AI-powered matching are not answers to any question on this list, and their appearance in place of a specific response is itself information.

And write the answers down. A procurement process that runs over six weeks will not remember which vendor said what about deletion, and the differences that matter are usually in the detail of a sentence rather than in the overall impression.

The questions we would rather you did not ask us

A vendor's willingness to name their own limitations is the most reliable signal available, and it costs nothing to test: ask what their product is bad at and what kind of customer should not buy it.

Every honest product has an answer. Ours is that CloseRev does not do incrementality testing, does not model multi-touch journeys, cannot help if your source data was never captured, and is a poor fit for businesses whose sales are almost entirely anonymous at the point of purchase. Any of those may disqualify us for a given buyer.

A vendor who cannot produce a comparable list is either not thinking clearly about their own product or has decided not to tell you. Both are reasons for caution, and the question takes ten seconds.

Ask every vendor what their product is bad at. The ones who answer immediately and specifically are the ones whose other answers you can rely on.