What should lead teams require from marketing attribution software?
Marketing attribution software should explain which touchpoints receive credit for a meaningful action, under which model and scope. A lead-focused team also needs a separate first-party record showing the actual Lead, its Validation Outcome, the chosen Destination, and every Delivery attempt. Attribution answers what influenced the action. It does not, by itself, prove that an inquiry was contactable, safe to route, or successfully delivered.
The buying mistake is asking one attribution number to answer every operational question. Choose software that exposes its attribution assumptions and can be joined safely to the systems that own Lead and Delivery facts.
Which records should remain separate?
Use four records with explicit owners. The following table is Lucidity's analysis as of August 2, 2026. It is a system-boundary recommendation, not a claim that GA4 or another attribution product should replace operational Lead software.
| Record | Question it answers | Typical owner | What it does not prove |
|---|---|---|---|
| Touchpoint evidence | Which campaign, Source, medium, page, or interaction preceded the action? | Analytics or attribution platform | That the inquiry is a qualified Lead |
| Attribution credit | How much credit does the selected model assign to each eligible touchpoint? | Analytics or attribution platform | That another model would assign the same credit |
| Lead and Validation | Was a first-party inquiry received, and is it qualified, review, blocked, or error? | Lucidity or another Lead operations system | That a Destination accepted a Delivery |
| Destination and Delivery | Where was the Lead sent, which attempts occurred, and what was each outcome? | Lucidity or another Delivery system | That transport acceptance became revenue |
This separation is the same principle used in the Lead Source attribution guide: preserve observed evidence, identify inference, and name the source of truth for each fact. The Lead tracking software guide continues that record from Source and Intake through Validation, Destination, and Delivery.
Which attribution model is the software using?
Start by recording the model name, eligible channels, lookback window, and date the configuration changed. A report without those fields can look precise while hiding the rule that produced the result.
As of August 2, 2026, Google's official documentation lists three models in GA4 Attribution reports. The table below summarizes those documented models without recommending one as universally correct.
| GA4 model | Documented credit rule | Question before using it |
|---|---|---|
| Data-driven attribution | Uses property data and machine learning to distribute credit based on the estimated contribution of touchpoints. | Do stakeholders understand that the output can be fractional and revised? |
| Paid and organic last click | Assigns all credit to the last eligible non-direct channel before the key event. Direct receives credit when the path consists entirely of direct visits. | Does a last-touch decision match the report's stated business question? |
| Google paid channels last click | Assigns credit to the last eligible Google Ads channel, then falls back to paid and organic last click when no Google Ads click exists. | Is this report intentionally limited to Google paid-channel credit? |
Google documents the models, their direct-traffic handling, and configuration fields in its attribution overview. Treat the selected model as report metadata. Do not rename model output as an observed first-party Lead Source without preserving the underlying evidence and rule.
How does attribution scope change the answer?
Model and scope are separate choices. In GA4, user-scoped, session-scoped, and event-scoped traffic dimensions answer different questions. Comparing them without the prefix and scope can produce an apparent disagreement that is actually expected.
| Scope | Example dimension | Question | Operational boundary |
|---|---|---|---|
| User | First user source | Where did new users first come from? | It is not the Source evidence for every later Lead. |
| Session | Session source | Where did this session begin? | A person can return in another session before submitting. |
| Event | Source | Which touchpoints receive credit for the key event? | Credit is model output, not validation or Delivery evidence. |
Google's traffic-source scope documentation says user and session dimensions use paid and organic last click, while event-scoped dimensions use the selected reporting attribution model. That difference belongs in the report definition, not in a footnote added after the numbers fail to reconcile.
How should observed and modeled context be labeled?
Ask whether a metric can contain modeled key events, thresholding, consent-mode effects, or other estimation. Keep that answer beside the metric and its Data Freshness. Modeled data can be useful, but it should not be silently presented as an exact list of first-party Lead records.
Google's current modeled key events documentation says models estimate events that cannot be observed directly and that attributed channel data can be updated for up to 12 days after a conversion is recorded. A stable report therefore needs a named cutoff and a clear note when GA4 context can still change.
How should attribution connect to a first-party Lead?
Use explicit, non-personal correlation keys where the website, Intake, and Lead system can preserve them. Store the raw marketing evidence, the key used to match it, the match method, and the attribution rule. If the evidence is missing or ambiguous, record that outcome instead of silently guessing.
Keep contact data in the operational Lead system. Google states that Analytics data must not include information Google can recognize as personally identifiable, such as email addresses or personal mobile numbers, in its PII implementation guidance. Do not put names, email addresses, phone numbers, or form-field contents into GA4 event parameters, URLs, page titles, or UTM values.
The UTM attribution guide explains how to preserve landing-page campaign parameters as evidence without pretending they settle every later attribution question. The qualified Leads in GA4 guide separates browser events from the first-party qualification decision.
Marketing attribution software requirements matrix
Use the same questions for every candidate. This matrix is Lucidity's recommended evaluation method for lead-focused teams. It compares required evidence, not vendor popularity or an invented overall score.
| Requirement | Question to ask | Minimum evidence | Failure if absent |
|---|---|---|---|
| Model transparency | Which model assigned credit, and when did it change? | Model name, configuration history, eligible channels, lookback window | Credit appears objective when it depends on a hidden rule |
| Scope clarity | Is the value user-, session-, or event-scoped? | Dimension name, prefix, grain, and report context | Unlike acquisition questions are compared as if they match |
| Touchpoint evidence | Can an operator inspect the path behind aggregate credit? | Timestamped source, medium, campaign, landing page, and event evidence | Discrepancies cannot be explained or audited |
| Identity and matching | How is attribution evidence joined to a first-party Lead? | Non-personal key, match method, confidence or ambiguity outcome | Leads are guessed, duplicated, or assigned to the wrong journey |
| Data Freshness | Through what date is each source processed? | Per-source cutoff, generated time, revision note | Current and settled data are mixed |
| First-party Lead record | What proves an inquiry was actually received? | Lead ID, Intake, Business, received time, Source evidence | A browser event is counted as a Lead without an operational record |
| Validation Outcome | Was the Lead safe and contactable enough to route? | Validation Run, checks, outcome, reasons, evaluated time | Every submission is treated as equally usable |
| Destination decision | Which configured target should receive the qualified Lead? | Business and Location context, routing rule, Destination ID | Campaign credit is mistaken for operational ownership |
| Delivery evidence | Was each forwarding attempt accepted, retried, or failed? | Delivery ID, Destination, attempt time, terminal outcome | Routing is reported as successful handoff without a receipt |
| Audit and export | Can the team reproduce a report without exposing Lead payloads? | Versioned definitions, safe aggregates, access controls, export history | Results cannot be reviewed safely or reconciled later |
What should you ask in a software evaluation?
Can we see the rule?
Require the model, scope, eligible channels, lookback window, and change history beside every attribution output.
Can we preserve evidence?
Confirm that raw Source and campaign evidence can remain distinct from the later credit assigned by a model.
Can we join without PII?
Use non-personal correlation keys and keep names, emails, phone numbers, and form values out of analytics metadata.
Can we prove the handoff?
Require a first-party Lead, Validation Outcome, Destination decision, and Delivery receipt outside the attribution model.
How should a lead team implement the stack?
- Define the decision. State whether the report will guide budget, explain acquisition, reconcile Leads, or diagnose failed handoffs.
- Document model and scope. Record the attribution model, dimension scope, eligible channels, lookback window, timezone, and configuration date.
- Preserve first-party evidence. Store Source, campaign, landing page, and safe correlation keys with the Lead rather than overwriting them with one model label.
- Validate before routing. Use explicit checks and a Validation Outcome to decide whether automatic Delivery is appropriate.
- Resolve the Destination. Apply Business, Location, and routing rules independently from marketing credit.
- Record every Delivery. Keep each attempt and terminal outcome so a routed Lead is not automatically reported as delivered.
- Reconcile with freshness. Compare GA4 context and first-party Lead facts only with named cutoffs, definitions, and revision notes.
Where does Lucidity fit?
Lucidity is the first-party operational layer for website inquiries. It retains Lead facts, Validation Outcomes, routing decisions, Destinations, and Delivery attempts. GA4 remains traffic and attribution context. Lucidity does not turn an attribution model into proof that a Lead was contactable or that a Destination received it.
This boundary lets a lead team use attribution software for the job it does well while keeping an auditable record of the pre-CRM handoff. The result is not one magic source of truth. It is a chain of clearly owned evidence.
Connect attribution context to Delivery evidence
Use Lucidity to capture first-party website Leads, apply explicit Validation Outcomes, route qualified Leads, and inspect every Destination Delivery beside GA4 traffic context.
Request a Lucidity attribution workflow demo