Which question does revenue attribution really answer?
Revenue attribution is not intended to prove that marketing was always successful. It is intended to show what a reliable relationship there is between a campaign and a business result. To do this, events such as published posts, first-party clicks, orders and sales are connected via stable identifiers.
Attribution is particularly difficult when multiple channels are involved, cookies are missing, or a customer returns directly later. An honest system therefore deliberately leaves part of the sales unattributed. This gap is more valuable than a seemingly complete but fabricated mapping.
Cleanly separate confirmed, derived and unattributed
Confirmed means that there is direct, workspace-specific evidence. An example is an order with a verified post or click ID that points to an actual published post from the same campaign. Derived means that the relationship is plausible and supported by first-party signals, but does not have the same probative value. Unattributed includes all results without sufficient connection.
These levels may not be merged into a single number in reports. A decision maker must be able to see which sales are certain, probable or cannot be assigned. Otherwise there will be an accuracy that the database cannot provide.
- confirmed: direct verified evidence
- derived: plausible derivation with its own signal basis
- unattributed: insufficient connection
- rejected: presented claim was rejected due to missing or third-party evidence
Why a suitable UTM string is not yet proof
UTM parameters are easy to copy or set later. A URL with the name of a campaign does not prove that the click actually came from your own published post. For a derived assignment, there should also be a first-party click with a suitable campaign and post identifier.
Workspace isolation is equally important. A post from another workspace, an unknown content identifier or an external campaign may not serve as evidence. Even data that looks correct will be discarded if the chain of ownership and provenance is incorrect.
Orders and sales can only count once
Commerce providers can deliver the same event multiple times: webhook retry, manual sync, or delayed status change. Deduplication is therefore based on a stable provider order ID and the store context, not on amount and time. Two orders for the same amount are possible; counting the same external order twice is an error.
The model needs additional states for refunds, cancellations and partial payments. Only the relevant paid net value in the correct currency should be included in the campaign evaluation. Changes must update the same order instead of creating a new sales record.
A decision-making attribution report
A good report will show posts published, clicks, leads, confirmed orders, derived orders, unattributable orders, and revenue per campaign. Rejection reasons such as “post not found”, “UTM without first-party click” or “foreign workspace” are visibly included.
The next marketing decision does not automatically follow the highest sales value. Consider margin, sample size, channel effort, and data quality. A campaign with a smaller but fully confirmed result can be a better learning basis than a large derived number with weak evidence.
FAQ
Does every turnover have to be attributed to a campaign?
No. An unassignable proportion is normal. It is crucial to show it separately and not to distribute it artificially through assumptions.
Is a UTM campaign ID enough for confirmed revenue?
No. A UTM can be a signal, but should be supported by workspace's own first-party evidence such as a known click or a stable post ID.
How do you prevent sales from being counted twice?
Orders are deduplicated using a stable external order ID in the store and workspace context. Repeated deliveries update the same record.
