Skip to content

Investigate unattributed revenue without guessing who the buyer was

Separate confirmed payments from attribution evidence with a case log, checkout metadata checks and clear outcomes for unresolved revenue.

GuideAnalytics

By

3 min read
Three investigation cards separate confirmed payment evidence, website scope and an unresolved visitor association; the unresolved state remains visibly labeled Unknown.

An unattributed payment is not automatically a broken payment integration. It can be a valid sale with insufficient evidence to connect it to a website visitor or acquisition source.

Treat the gap as an investigation record. The purpose is to identify a repairable collection problem while preserving uncertainty where the evidence genuinely ends. Guessing a source makes a chart look complete but weakens the decisions based on it.

Separate three questions

Ask these questions in order:

  1. Was a payment confirmed? Use the provider's authoritative record and supported event.
  2. Does it belong to this website? Check the configured integration, product scope and environment.
  3. Can it be associated with a visitor or acquisition source? Inspect supported attribution evidence.

Do not use the third question to rewrite the first. A confirmed payment remains revenue evidence even when no browser session exists. Likewise, a matching browser timestamp cannot establish that an unrelated payment belongs to the website.

Use a short case log

For a fictional payment, a useful investigation might look like this:

Field Example entry
Case Attribution review 017
Provider evidence Successful sandbox payment, stable payment ID retained privately
Website scope Product mapped to the intended staging website
Browser evidence No trusted visitor/session pair attached
Other evidence No earlier matched payment for the customer
Current classification Valid payment, unattributed
Next action Check metadata creation in the checkout handler

Keep actual payment and customer identifiers in an access-controlled record. A public issue or support screenshot usually needs only a synthetic reproduction and an internal case reference.

Inspect the handoff into checkout

The most useful debugging point is often the server handler that creates checkout. Check whether it receives the supported browser attribution pair, validates its shape and forwards the correct provider metadata fields. Also check that the fields survive any intermediary service.

Revfaro's attribution guide documents trusted visitor/session matching, return-page matching where supported and fallback evidence. It also describes why ambiguous payments remain unattributed. Read the provider-specific guide before applying a metadata field name from another integration.

A strict URL query allowlist can intentionally remove payment return identifiers. That is a reason to forward supported attribution metadata during checkout, not a reason to collect arbitrary query strings again.

Look for repeated patterns

Group cases by checkout path, provider, release version and acquisition route. If unattributed payments cluster around one newly introduced checkout endpoint, inspect that endpoint before changing the global attribution model.

If they cluster around users without a browser identifier, consider consent choices, blocked tracking and cross-device behavior. These are explanations to investigate, not excuses to declare every missing match unavoidable. Compare what the application was configured to collect with what it actually sent.

Keep renewals distinct from first purchases. A recurring payment may inherit an earlier customer's association; it should not automatically be interpreted as a new acquisition caused by that day's campaign.

Define an honest closeout

Use one of three outcomes: configuration repaired, expected measurement limit, or unresolved with next check. Include the evidence supporting the outcome and the date of the review. If a repair affects future checkouts only, say so; do not imply that historical source information has been recovered.

Avoid identity guesses based on a shared IP address, a nearby pageview or a buyer's name. Those clues can be shared by several people and do not replace a supported association. Preserve unknowns in the reporting discussion rather than distributing them across preferred channels.

For the broader purchase review, pricing currencies in SaaS comparisons helps prevent currency differences from being mistaken for attribution defects. For acquisition decisions, measuring directory submission ROI shows why evidence quality matters more than a fully colored chart.

More guide articles