How Coruve attributes revenue

When money arrives from your connected Stripe or Shopify account, Coruve tries to match the payer to a browser it has seen. If it can, it looks at that browser’s visits and credits the payment to one of them — and which one it picks is the whole question, because the answer changes what your channels look like.

There is no single right answer. So Coruve does not pick one. It shows both answers, in the same table, in adjacent columns, always.

Credit is assigned per payment, not per customer. A customer who pays twice after arriving two different ways produces two credits, which is why the worked example above splits $40 into $10 and $30 under last touch.

Revenue is reported by the UTC day it arrived, because exchange rates are published per day and a finer window would convert an evening payment at a rate published before it. So “the visit before the payment” means a visit that started on or before the end of the day the payment arrived. A visit later than that never takes credit, and a visit on the day of the payment itself does — which is usually the visit that converted.

A payment knows a customer. A pageview knows a browser. They are the same person only when something linked them — and the one mechanism that links them is your site calling identify() with the same user id your payment processor knows. Payments that were never linked cannot be credited to any channel.

So every attributed figure in Coruve is shown next to its coverage: the share of your revenue in the range that the rows cover at all. Not the share of customers — the share of money, because one large unlinked customer can make those two numbers differ by half.

Revenue Coruve cannot credit to a visit gets its own rows in the same table, with its own payment counts and amounts. It is never distributed across the channels Coruve can see, and it is never quietly left out of a table whose percentages would then not add up.

Both models divide up the same pot, so the two columns have the same total. The difference is where the money lands. Coruve reports that as one number: the share of attributed revenue that sits on a different row under first touch than under last touch.

A business with one marketing channel reads 0%, honestly. A business that buys ads to close people who found it through search can read 40% or more — and that number is the reason the two columns exist.

When someone is sent to Stripe Checkout, PayPal or Shopify’s checkout and comes back to finish, the browser reports the payment page as the referrer. Usually that changes nothing — the round trip stays inside the same visit, and the channel that originally brought them is the one that gets credit. But if checkout takes longer than half an hour, or they come back in a different browser window, it starts a new visit whose referrer is the payment page.

A visit that arrives from one of these is a return from checkout, not an arrival. Coruve still counts the visit; it does not let it take credit for the payment. Those payments are reported as Visited only from a payment page when the payment page is the only place Coruve ever saw that visitor arrive from — which usually means the Coruve snippet is missing from the pages before checkout.

Coruve looks back 90 days before the start of the range you are viewing. A visit older than that is not treated as a first touch; the payment is reported as Linked, but no visit on record instead of being credited to the oldest visit that happens to survive.

This is a limit chosen for query cost, and it is stated rather than hidden because a limit chosen for cost is exactly the kind a product applies quietly and then reports the truncated answer as the whole answer. It mainly affects first touch; the visit before a payment is rarely three months old. Your plan’s data retention also applies — Coruve cannot look back further than it kept the visits.

How much of that window you can actually reach depends on identify(). First touch reaches back over one day's visits — the visitor identifier resets daily, so a payment is matched to the single day your site identified this customer on, and a customer identified on more than one day is left unattributed rather than credited to one of them. A visitor your site never identifies has no link at all, so their visits are not reachable from a payment in the first place.

When your site calls identify(), Coruve stores a one-way hash of the user id you passed alongside the visitor identifier that browser had that day. That link is what lets a payment find the visits that led to it.

The visitor identifier is a daily hash of the browser’s signature and the network address, not of the device, so two of your users on one network and one browser build can still share it for a day. When several of your users identify from one browser identifier on one day, we cannot tell which visits were whose, so that day's visits are left unattributed rather than credited to one of them. It is uncommon, and it is written down here because it is the one case where a payment cannot be traced back to the visits that led to it.

• Bots and crawlers. Traffic Coruve classified as a crawler is not a visit anywhere in the product, and it cannot be a touch.
• Visits your exclusion rules hide. If you exclude your own traffic, or a hostname, or a path, those visits do not take credit either. Turning a rule off restores them, because the events were kept — the rule is applied when the report is read, not when the data is stored.
• Visits by people who never paid. Obvious, but worth stating: the attribution table counts the visits of payers, so its visit counts are smaller than your traffic report’s and are not meant to match them.

Coruve does not offer data-driven attribution. A model that assigns credit by fitting a machine-learning model to your own history cannot be checked by you, changes its answer when the history changes, and is sold as objectivity. Two models you can count by hand are worth more than one you cannot audit.

Coruve does not claim a channel caused a payment. Both models describe which visit came before the money, which is a fact about order. Only an experiment can measure cause.

Coruve does not fill in the gaps. Payments it cannot tie to a visit are shown as their own rows, with their own counts — never spread across the channels it can see, and never dropped from the table.

Coruve does not report a single attributed number. Every attributed figure appears twice, once per model, beside the share of your revenue the rows cover at all.