Profit per channel is the net revenue attributed to an acquisition channel, after processor fees and refunds, minus what you spent on that channel in the same period. This post explains every step ProductLense takes to compute it, and where its limits are. The short reference version is in the methodology docs.
\nEvery visitor’s first event stores where they came from: the channel, utm_source, utm_medium, utm_campaign, the referrer domain, the landing page and the time. Channels are classified on arrival: click ids or paid mediums (cpc, ppc, paid, paidsocial, display) are paid, utm_medium=email is email, and the referrer decides between AI assistant, social, organic search, referral and direct.
Because ProductLense is cookieless, an anonymous visitor is one browser on one day. That sounds limiting, but for revenue it rarely matters, because of step 2.
\nWhen someone signs up or logs in, your code calls:
\nwindow.productlense('identify', 'user_123', { email: 'a@b.com' });From that moment, the visitor is linked to user_123. Every later visit, on any day, joins the same person, and the first touch stays the one recorded before signup.
Payments arrive from your billing provider by webhook, by a 12-month backfill when you connect, by a nightly reconcile, or through the payments API. Each one is resolved when it is written:
\npl_user_id), matched to an identify call;The chain is payment → customer → identity → visitor → first touch, and the resolved channel, source, campaign and landing page are stored on the payment row. Resolving at write time means every revenue report is a plain query over one table. Payments that cannot be matched yet are retried nightly, so an identify call that arrives after the payment still credits the right channel.
Gross charges overstate what you keep. For every payment ProductLense stores the amount, the currency, and the fee the provider reports:
\ncharge: net = amount − fee\nrefund or chargeback: net = −(amount + fee)Refunds subtract the fee too, because most processors keep the original fee when you refund. For merchants of record, the fee is what they keep, including the tax they remit: Paddle’s fee is grand total minus earnings, so net revenue equals your payout. Every amount is converted to USD at the European Central Bank reference rate for its day and also kept in its original currency.
\nAd spend comes from manual entries or a CSV with date, channel, source, medium, campaign, amount, currency. It joins to revenue on channel, source, medium and campaign, the same keys the first touch carries from your UTM tags.
profit(channel, period) = Σ net revenue of payments attributed to channel and paid in period\n − Σ ad spend for channel in periodThen three ratios:
\nCAC = ad spend / new customers\nROAS = attributed net revenue / ad spend\npayback = CAC / average net revenue per new customer in their first 30 daysAn example month for one channel, Google Ads, with round numbers:
\n| Item | Amount |
|---|---|
| Gross revenue from customers whose first touch was Google Ads | $1,200 |
| Processor fees on those payments | $40 |
| Refunds | $100 |
| Net revenue | $1,060 |
| Google Ads spend | $500 |
| Profit | $560 |
| New customers | 10 |
| CAC | $50 |
| ROAS | 2.12× |
If those ten customers paid $53 net on average in their first 30 days, payback is $50 / $53 ≈ 0.9 months: the channel earns back what each customer cost within the first month.
\nThe same table for a channel with $2,000 of spend and the same revenue would show a loss of $940, with a minus sign and a down arrow next to it. That is the row you want to see before next month’s budget, not after.
\nFor small SaaS companies, the expensive question is which channel to put more money or time into, and that is a question about where customers start. Closing channels such as email and retargeting only work on people another channel already brought. First touch is also the model that is easiest to check by hand, which matters when the number decides a budget.
\nProfit per channel is on the Growth and Scale plans. The methodology page has every formula.
\n", "date_published": "2026-10-11T00:00:00Z" }, { "id": "https://productlense.app/blog/introducing-productlense", "url": "https://productlense.app/blog/introducing-productlense", "title": "Introducing ProductLense: see which channels make you money", "summary": "ProductLense is cookieless analytics that joins your traffic to your billing provider and shows revenue and profit per channel. Here is what it does and costs.", "content_html": "ProductLense is product analytics that shows which users pay you and which channels make a profit. Today it is available at app.productlense.app, free up to 10k events a month.
\nIf you run a small SaaS, your numbers live in two places. Google Analytics or PostHog shows visits and clicks by source. Stripe or Paddle shows money by customer. Nothing joins the two unless you build a pipeline: export payments, match customers to users, match users to visits, and keep it all in sync as refunds and renewals arrive.
\nSo the question that decides where you spend your next month of effort, which channel brings customers who pay and keep paying, usually gets answered by gut feel or by ad platform dashboards that each claim the same sale.
\nProductLense answers it directly.
\nCookieless analytics. A script of about 1 KB records pageviews, custom events, outbound links and downloads, with no cookies and nothing stored on the visitor’s device. Visitors are counted with a hash of the site, IP address and user agent that uses a salt that changes every day, and the IP is never stored. Most sites run it without a consent banner.
\nRevenue attribution. When a visitor signs up, your code calls identify with your user id. ProductLense connects to your billing provider (Stripe, Paddle, Lemon Squeezy, Polar, Dodo Payments, Razorpay, Chargebee, Shopify, Gumroad or Creem) or takes payments through an API, and follows each payment back through the customer and the user id to the visitor’s first touch: source, medium, campaign, referrer and landing page. Renewals and refunds land on the same channel automatically.
Profit per channel. Enter ad spend or import it as CSV, and ProductLense subtracts it, along with processor fees and refunds, from attributed revenue. Each channel, source and campaign gets profit, CAC, ROAS and payback in months. This is the number we built ProductLense for. A channel that brings a lot of revenue can still lose money once spend and refunds are counted, and a quiet newsletter can be the most profitable thing you do.
\nRevenue retention by channel. Net revenue retention cohorts, month 0 to 12, split by acquisition channel. Which channels bring customers who stay and expand, and which bring customers who cancel after a month.
\nAsk. Type a question such as “which campaign made the most profit last month” and get a real table from ProductLense’s own stats engine, with a three-sentence summary whose every number is checked against the table before it is shown. The AI turns your question into a validated query; it never queries your data and never sees raw events or personal data.
\n| Plan | Events a month | USD | INR |
|---|---|---|---|
| Free | 10k | $0 | ₹0 |
| Starter | 100k | $19 | ₹999 |
| Growth | 1M | $49 | ₹2,499 |
| Scale | 10M | $149 | ₹6,999 |
Free includes one billing connection, so revenue by channel works from day one. Starter adds funnels, visitor journeys, three sites and 12 months of history. Growth adds every billing connection, profit, cohorts and CSV import across ten sites. Scale removes the site limit and adds API keys for server-side events and payments, and priority support. Annual billing is ten times the monthly price. Team members are unlimited on every plan. INR prices apply to accounts registered in India and include UPI. See pricing for the full matrix.
\nProductLense never sells data and never sends raw events, emails or user ids to an AI model; Ask and the daily insight see aggregates only. “Export data” in site settings downloads a zip of a site’s daily aggregates, payments and ad spend, and deleting a site or account purges its analytics data within minutes, always within 7 days; backup copies expire within 30 days.
\nProductLense v1 deliberately leaves out session replay, feature flags, A/B tests, surveys, mobile SDKs and data warehouse export. If you need those, PostHog and Mixpanel do them well, and ProductLense can run alongside them with the same user id. We would rather do one job completely: what visitors do, which ones pay, and which channels make a profit.
\nProductLense runs on servers in Germany: a Go API, ClickHouse for events and Postgres for accounts and payments. Raw events are kept for 90 days and hourly aggregates for the life of the site. Billing credentials are encrypted at rest.
\nProductLense is built in India and operated by RedAnalytica, the same business behind Reelsmith.video. Questions, bugs and feature requests go to support@productlense.app.
\nidentify after signup and connect your billing provider.Cookieless analytics is enough for most SaaS products because the moment that matters for revenue, signup, is also the moment you can identify the person with your own user id. Cookies mainly help you recognise anonymous visitors across days, and for a SaaS that gap is small, measurable, and cheaper than a consent banner.
\nAn analytics cookie stores a random id in the visitor’s browser. On every later visit, the tool reads it back and knows it is the same browser. That buys three things:
\nIt costs you a consent banner in the EU and UK, and with it every visitor who clicks “reject” or ignores the banner. It also costs a script that privacy-focused browsers and blockers treat with suspicion.
\nProductLense counts a visitor with a hash:
\nvisitor_id = sha256(site_id | ip | user_agent | daily_salt), first 16 hex charactersThe salt is derived from a server secret and the date, and changes every 24 hours. The IP address is used for the hash and a country lookup and then discarded. Nothing is written to the browser: no cookie, no local storage.
\nThe same browser on the same day produces the same id, so sessions, bounce rate, same-day journeys and first touch for same-day signups all work. The same browser tomorrow produces a different id that cannot be linked back, because yesterday’s salt is gone.
\nBeing plain about the trade:
\nThree reasons.
\nSignup is the identity moment. A SaaS gets a user id at signup. From then on, identify links every visit and every payment to that user, across days and devices, without cookies. The part of the journey that decides revenue attribution, from signup to first payment to renewals and refunds, is fully joined.
Most signups happen early. For self-serve SaaS, a large share of signups happen in the visitor’s first session or first day, and that is fully covered. You can check this for your own product: ProductLense’s visitor journeys show how many signups had earlier visits on the same day.
\nComplete counts beat long memory. With a banner, the visitors who decline are simply missing, and they are not a random sample. A cookieless tool counts everyone, every day. For comparing channels, complete counts with a one-day memory are usually more accurate than a long memory over a filtered sample.
\ndefer, so it does not slow down pages.identify.Under GDPR, an IP address is personal data even if you only hold it for milliseconds, and a hashed id can still count as pseudonymous data. Cookieless analytics reduces what is processed and stored, but it is still processing. That is why ProductLense acts as a processor under a DPA, lists its subprocessors on request, keeps data in Germany, and documents every field in the privacy docs. The same applies under India’s DPDP Act, where your company is the data fiduciary and ProductLense is your processor.
\nidentify at signup and login, with the same user id you store on your billing provider’s customers as pl_user_id.For a typical SaaS, it does not. Read how ProductLense attributes revenue or install the script and check with your own traffic.
\n", "date_published": "2026-10-11T00:00:00Z" }, { "id": "https://productlense.app/changelog#2026-10-11-first-public-release", "url": "https://productlense.app/changelog#2026-10-11-first-public-release", "title": "Changelog 0.1.0: First public release", "summary": "ProductLense 0.1.0: cookieless tracking, ten billing connectors plus a payments API, profit per channel, cohorts by channel, Ask and the daily insight.", "content_html": "The first public version of ProductLense, at app.productlense.app.
\na.js, budget 1,200 bytes gzipped): pageviews including SPA route changes, custom events with props, identify, outbound link clicks and file downloads. No cookies, no local storage.POST /api/v1/payments for any other source, and server-side events at POST /api/v1/events.identify calls.