Founders of AI products often already have three places that look like “the truth”: a traffic tool, a billing tool, and a model / provider cost view. None of those alone answers the job this page is about: see customer payments and AI usage cost together, for the same people and the same period, without inventing links.
Why three separate tabs fail the job
| Tab | What it answers well | What it usually cannot answer |
|---|---|---|
| Traffic / product analytics | Who visited, which funnel converted | Whether those visitors paid enough to cover model cost |
| Billing / payments | Who paid, refunds, fees, MRR | How much attributable AI cost sat behind that cash |
| Provider / gateway cost dashboard | Tokens, model mix, estimated or billed spend | Which paying account (if any) that spend belongs to |
Putting screenshots of all three next to each other is not “one dashboard.” The missing piece is a join, not another chart.
What “one dashboard” must include
A single view that honestly tracks revenue and AI usage costs together needs at least:
- Observed revenue from the payment system (include refunds consistently; prefer real processor fees when available).
- Observed AI usage priced with the schedule effective at event time (not today’s price rewritten onto old calls).
- A stable account identity that appears in both the payment evidence and the model-usage evidence.
- An explicit unallocated bucket for usage or revenue that cannot be joined—shown, not averaged away.
- One shared time window and currency for every term in the calculation.
Without identity join + unallocated visibility, a “combined” dashboard is still three tabs with a prettier layout.
How to join Stripe revenue and OpenAI cost by customer
Use one opaque internal account ID on both verified payment records and server-observed usage. Aggregate each ledger by account, period and currency before joining. Two payments joined directly to two calls create four rows and duplicate the totals.
- For Grow or Die, start with the Stripe connection and server-side OpenAI integration. Browser visits alone do not create model usage or prove payer identity. GA4 is optional.
- For your own warehouse, follow the verified payer identity recipe, then run the six-row SQL fixture and query in a scratch database. This is a self-built verification method, not a production database migration or provider-invoice reconciliation feature.
- Check the intermediate payment and usage evidence before accepting the final contribution. Keep unknown prices, missing revenue and unmatched usage visible.
Download the synthetic inputs and SQL query into one directory, then run with SQLite 3.33 or later:
sqlite3 -json :memory: ".read account-ai-cost-fixture.sql" ".read account-ai-cost-reconciliation.sql"| Account | Net receipts | AI cost | Contribution |
|---|---|---|---|
| a | 15 | 5 | 10 |
| b | 10 | Unknown | Unknown |
Account a has $24 collected, less $1 tax, $3 fees and a $5 refund: $15 receipts minus $5 AI cost gives $10. Account b has an unpriced model call, so $10 receipts cannot establish its contribution. Compare all six rows with the expected output; retain the separate EUR row without adding it to USD.
If visits appear but usage or revenue does not, use the installation checklist to check collection, model pricing and payer identity separately.
The smallest honest combined number
When fees are available:
AI contribution (site or customer) = observed payment revenue − refunds − processor fees − attributable AI cost
Apply every term to the same population and period. If a payment is linked to account A but a model call has no account ID, keep that cost unallocated until the link is observed. Spreading unmatched cost across all customers invents a margin.
This is an operational contribution metric, not company net profit. Payroll, non-model infrastructure, support, and other opex stay out unless you add them and label them.
For the measurement rules behind the formula, see What is AI unit economics?. For why a token bill alone is not profit, see Token cost is not profit. For why observability / cost dashboards are a different category from profit analytics, see LLM observability vs AI profit analytics.
FAQ
Is connecting Google Analytics + Stripe + my LLM provider invoice enough?
Only if you also join payment customers to model-usage accounts for the same period, and keep unmatched rows visible. Exporting three CSVs into a spreadsheet can work; guessing the join cannot.
Can I allocate AI cost by traffic share?
Not if you want customer-level truth. Traffic share is not payment identity. Unlinked cost should stay unallocated.
Does “one dashboard” replace LLM observability?
No. Observability debugs model behavior (latency, errors, traces). Profit analytics debugs whether revenue covers attributable AI cost. Most teams eventually need both.
What should I refuse to conclude from a partial join?
Do not claim customer profitability, feature ROI, or “this session paid for itself” when identity coverage is incomplete. Site-wide contribution with an explicit unallocated line is safer than a fake per-customer margin.
Grow or Die is built for this JTBD: it joins visitors, customer payments, and server-side model cost so founders can see contribution after AI cost—with unallocated and coverage kept visible. It is not a full trace/eval suite. Plans start at $20/month per website after a 7-day trial; details on pricing.