# How payments are attributed

ProductLense links each payment to the channel, source and campaign that first brought the paying customer, and stores that answer on the payment.

ProductLense attributes every payment to the first touch of the visitor who became the customer: the channel, source, medium, campaign, referrer domain and landing page of that visitor's first recorded event. The answer is resolved when the payment is written and stored on the payment, so revenue reports never re-run attribution.

## The chain

```text
payment → customer → identity → visitor → first touch
```

1. **Payment to customer.** Every payment from a connector or the [Payment API](/docs/revenue/payments-api) carries the provider's customer.
2. **Customer to identity.** ProductLense looks for visitors linked to the customer, in this order, and stops at the first source that finds a visitor with a first touch:
   1. The customer's user id, matched to the user id your site sent with [`identify`](/docs/track/identify-users). Connectors read it from the customer's metadata under `pl_user_id`, `user_id`, `userId` or `uid`, or from the provider's own field (Polar's external id, Chargebee's `cf_pl_user_id`). The Payment API reads `customer.user_id`.
   2. The customer's email, matched to the `email` trait sent with `identify`, or to a user id that is that email (case-insensitive).
   3. A ProductLense visitor id stored on the customer under `pl_visitor_id` or `visitor_id` (the Payment API's `customer.visitor_id`).
3. **Visitor to first touch.** Each visitor's first event is kept for the life of the site with its channel and UTM tags.

When one user has several visitors (a laptop and a phone, or visits on different days), the earliest first touch wins. When the visitors a source finds have no first touch, for example because they were recorded before the 90-day raw retention or blocked, ProductLense moves on to the next source instead of giving up.

> [!IMPORTANT]
> Set your own user id on the billing customer and pass the same id to `identify`, with the user's `email` in the traits: `window.productlense('identify', 'user_123', { email: 'ada@example.com' })`. The id is the strongest link; the email catches customers whose billing record has no id, as long as they pay with the email they signed up with. Each provider page shows where the id goes, for example [Stripe](/docs/revenue/stripe).

## Payments that arrive before the identify call

A customer can pay before your site identifies them, for example when the checkout webhook lands before the post-signup page loads. Such payments are stored without attribution. A job runs every day at 04:00 UTC, takes up to 500 unattributed payments from the last 90 days, and resolves them again. Once an identify call links the user, the next run fills in the channel.

## What is stored on the payment

| Column | Meaning |
|---|---|
| Channel | `paid`, `email`, `ai_assistant`, `social`, `organic_search`, `referral` or `direct`, as classified on the first visit. See [How ProductLense counts](/docs/get-started/how-productlense-counts). |
| Source, medium, campaign | `utm_source`, `utm_medium` and `utm_campaign` of the landing URL. Source and medium are stored in lower case. |
| Referrer domain | The first referrer's domain without `www.` |
| Landing path | The first page the visitor saw |
| Visitor id | The visitor whose first touch was used |
| Model | `first_touch` |

## Unattributed revenue

Revenue that cannot be linked to a visitor still counts toward totals, MRR and LTV. It appears in channel tables under an empty key. Common causes are customers who never visited the tracked site, sites installed after the customer's first visit, and customers whose provider record carries no user id and no matching email.

## Model

ProductLense uses first-touch attribution only. It answers "which channel brought the people who pay", which is what profit per channel and CAC need. There is no last-touch or multi-touch model.