Marketing attribution software selection: buyer process

Decision framing before tool choice

Weak version: choose a familiar platform or a supplier labelled attribution, then expect one report to answer every marketing question. That is a poor starting point for marketing attribution software selection: it blurs platform credit, source reconciliation, aggregate modelling, experiments and causal proof, even though each produces a different kind of output.

Better version: name the buyer decision and required evidence before choosing a job class. Decide whether the work needs descriptive analytics, platform credit allocation, cross-system reconciliation, marketing mix modelling, or experiment and incrementality support. Treat these as separate requirements, not interchangeable labels. The job-class guide helps state the chosen requirement.

Candidate admission before comparison

Candidate evidence before testing

Better version: admit a candidate only when its legal entity, exact service and edition, UK or England availability evidence, evidence date and proposed terms are identifiable. Supplier pages state claims, not independent proof of accuracy or fitness. Use Vendor due diligence and evidence levels; check Companies House search guidance for identity, not solvency, quality or performance, and record the check date.

A shared brief before a supplier demonstration

Weak version: ask vendors to demonstrate a product against loosely stated goals, while leaving the population, geography, outcome or period open. Different candidates can then answer different questions and still appear comparable. Unclear event rules also hide how duplicates, refunds, late outcomes and missing matches affect the results.

Better version: define one buyer decision, eligible population, England geography rule, outcome, period, channels and evidence standard. Identify each input by system and identifier; specify how duplicates, missing matches, refunds and late events will be handled. Choose the job class only after these shared boundaries are written, so each response addresses the same task.

Data evidence instead of tidy-looking totals

Weak version: accept a clean-looking dashboard total without asking what the service supported, excluded or changed to produce it. Silent removal of invalid data can make a result look complete while weakening the buyer decision, especially if no one can reproduce the excluded-event count.

Better version: require the supported inputs and outputs, model version, identity treatment, missingness, buyer preparation and change history for the exact service. Request an unmatched-record export, field-level validation messages and a repeatable count of excluded events. Trace every reported total to the accepted fixture, then require an explanation for each excluded row.

Better version: keep unresolved service details visible rather than assuming they will be settled after selection. If sub-processors, overseas access, logs, export schema, deletion proof, accessibility evidence, support scope or the contractual service definition remain unknown, keep a candidate on hold.

Evidence gates before testing

Weak version: let a strong score in one category compensate for an unresolved privacy, PECR, security, accessibility, contract, intellectual property or exit issue. A weighted total can then look like approval even when an essential requirement is still blocked.

Better version: treat each requirement as a gate and assign every open item an owner, requested evidence and expiry date. Use the selection checklist to make requirements explicit. A candidate stays blocked until each gate is resolved; weights and thresholds must be approved for the buyer's procurement, not treated as fixed rules.

In the example, the accessibility and contract gate is HOLD and support and exit scores 55% against a 60% threshold. The candidate therefore fails despite a weighted result of 72.5%. A passing weighted figure cannot override a blocked gate or a shortfall against the support and exit requirement.

Buyer controls in the configured service

Weak version: rely on contractual labels or the supplier's public website to settle privacy and accessibility questions. That leaves the buyer's actual controller and processor decisions, tags, pixels and configured tasks unexamined, even though those are the conditions under which the service would be used.

Better version: map controller and processor roles from what each party actually decides, not from contract labels. The ICO guidance is marked under review following DUAA, so check its status again; assess tags and pixels against its storage and access guidance. Include data protection by design and relevant impact assessment guidance in the privacy review.

Better version: review authentication, least privilege, supplier access, logging and monitoring, incident help, backup and recovery. NCSC SaaS guidance treats customer configuration as an ongoing responsibility. Use the NCSC Cyber Assessment Framework principles and security review guidance, then test buyer-configured tasks and exports for accessibility. A GOV.UK accessibility introduction can inform that review.

A controlled test rather than a persuasive demo

Weak version: let candidates use different data or judge them by the explanation they give for their own outputs. This makes it difficult to tell whether a difference comes from the service, the input or the test conditions, and leaves exclusions hard to compare.

Better version: give each admitted candidate synthetic or specifically authorised data, the same event dictionary, fixture, expected outputs and exclusions. Compare observed results with the supplier's explanation, keeping those records distinct. The test should expose how the service handles difficult records, not merely confirm that a demonstration can be completed.

For an incrementality claim, require the counterfactual design to be declared before testing. The 2026 Magenta Book distinguishes impact evaluation from monitoring in its government context, but that distinction does not validate a commercial product or establish a supplier's performance.

Manual work as the commercial baseline

Weak version: treat a new dashboard as worthwhile because it is new, without documenting what the existing route already does. That makes it impossible to identify the process gap or judge whether the proposed service improves on staff work, controls, delays, exports and known errors.

Better version: compare the service with the current manual route and budget by four cost parts: licence or subscription, implementation, overage and exit. Record the manual process and the gap it is meant to address, without inventing a cost or defect rate. Keep that route in scope when assessing fit.

Better version: request comparable terms for each cost part. Licence may scale with events, rows or users; implementation covers one-off data and configuration; overage applies above contracted volume; exit covers export and deletion. Since public list prices are often unpublished, request the relevant volume band, a three-year total cost of ownership and a written exit price.

Approval that expires when its evidence changes

Weak version: record a final yes while service identity, legal terms, controlled results or a tested exit remain unresolved. If the edition, model or incorporated terms change during evaluation, carrying the old result forward would mean approving a service that was not the one assessed.

Better version: record accept, reject or HOLD for each gate with a named owner, evidence version and expiry. Put affected results on HOLD and invalidate them if the edition, model or terms change; rerun the relevant tests before relying on those results. Keep buyer-held artefacts, the decision and the evidence record together so work can continue if access ends unexpectedly.

The research closed on 6 September 2026 and consists only of desk research, with no product access and no supplier recommendation. Named UK procurement, privacy, PECR, security, accessibility, statistics, evaluation and commercial reviewers still need to assess the buyer's own facts before purchase.

A first pass that preserves the decision trail

Weak version: begin by collecting supplier names and demonstrations, then try to define success after seeing what each product offers. That reverses the evidence sequence and risks comparing candidates against different expectations or treating unanswered questions as minor scoring weaknesses.

Better version: start with the buyer decision, then move through the work in order. Name the decision owner and job class; fix the brief and input rules; admit only identifiable services; resolve gates; test one shared fixture; compare against the manual route; and record the evidence version and expiry before approval.