Revenue attribution
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
payment → customer → identity → visitor → first touch- Payment to customer. Every payment from a connector or the Payment API carries the provider's customer.
- 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:
- The customer's user id, matched to the user id your site sent with
identify. Connectors read it from the customer's metadata underpl_user_id,user_id,userIdoruid, or from the provider's own field (Polar's external id, Chargebee'scf_pl_user_id). The Payment API readscustomer.user_id. - The customer's email, matched to the
emailtrait sent withidentify, or to a user id that is that email (case-insensitive). - A ProductLense visitor id stored on the customer under
pl_visitor_idorvisitor_id(the Payment API'scustomer.visitor_id).
- The customer's user id, matched to the user id your site sent with
- 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.
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. |
| 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.