11 min read
How to evaluate Stripe acquisition revenue
A practical audit for connecting acquisition context to customers, payments, renewals and refunds.
· Grometrics Team
A Stripe revenue report is useful only when you can inspect the path behind a number. Pick one customer, trace the acquisition context into checkout, reconcile every included money event, and state what remains unmatched. That exercise tests the data more reliably than comparing dashboard totals alone.
This article gives you a repeatable audit with example figures. For named vendors and buying criteria, use the Stripe analytics tools comparison. If you need to implement GA4 purchase and refund delivery, use the Stripe to GA4 setup guide.
The result you want: For every included payment, you should be able to explain the customer, revenue type, amount, currency, acquisition source, matching evidence and any limitation. If one of those fields is missing, label the result incomplete instead of guessing.
Define the decision before opening a dashboard
Start with one decision. Examples include whether to increase an email budget, whether paid search customers survive the first renewal, or whether a landing page produces refund prone buyers. The decision determines which customers, payments and dates belong in the review.
- Choose one reporting period and one business timezone.
- Choose whether revenue means gross collected, revenue after refunds, new revenue only, or another clearly named measure.
- Choose whether the unit is payments, subscriptions, or newly acquired paying customers.
- Choose one attribution view, such as first source or the source attached to the converting session.
- Record taxes, fees, disputes and currency conversion separately unless the report explicitly includes them.
Do not mix units: Two payments from one customer are two transactions, not two acquired customers. A renewal can increase customer value, but it must not reduce customer acquisition cost by increasing the new customer count.
Build one auditable source to payment row
Begin with a successful Stripe payment and work backward. The useful record is not just an amount beside a channel. It is a chain of identifiers and timestamps that another person can inspect.
| Field | Example | Why it matters |
|---|---|---|
| Acquisition | email / launch_october | Names the captured source and campaign rather than inferring them later |
| Entry | /pricing at 09:12 UTC | Shows where and when the attributed visit began |
| Identity | visitor v_123 to customer cus_456 | Proves that the browser journey and Stripe customer were joined |
| Payment | pi_789 at 09:26 UTC | Provides the unique money record and successful payment time |
| Revenue type | New purchase | Keeps acquisition separate from renewals and adjustments |
| Value | USD 50 | Keeps amount and currency together |
| Confidence | Matched before checkout | States why the source assignment is credible |
- Open the Stripe payment and note its payment, customer, amount, currency, status and creation time.
- Open the matching customer or transaction in your analytics report.
- Confirm the customer identity was connected before or during checkout, not guessed from a later visit.
- Inspect the original referrer, landing page and campaign values.
- Record the match reason and keep an explicit unmatched state when the evidence is absent.
Work through a purchase, renewal and refund
Illustrative example: a visitor arrives through an email campaign on 2 September, signs up and pays USD 50. The same Stripe customer renews for USD 50 on 2 October. A USD 20 partial refund is issued on 5 October. All three events fall inside the selected reporting period. These are example figures, not customer results.
| Event | Amount | Customer count | Audit check |
|---|---|---|---|
| Initial purchase | USD 50 | 1 new customer | Payment and customer match the captured email campaign |
| Renewal | USD 50 | 0 new customers | A separate successful payment belongs to the same Stripe customer |
| Partial refund | USD minus 20 | 0 new customers | The adjustment references the original payment and is counted once |
If the email campaign spent USD 30, new customer acquisition cost is USD 30 divided by one new paying customer, which equals USD 30. Revenue after refunds divided by spend is 80 divided by 30, or 2.67. Call that a revenue to spend ratio unless your organisation has explicitly defined it as ROAS. Neither number proves that the campaign caused the purchase or that it was profitable.
Reconcile the numbers before comparing channels
Run reconciliation with the same payment statuses, date basis, timezone and currency rules on both sides. A difference is a prompt to inspect definitions, not permission to force the totals to match.
| Measure | Calculation | Required definition |
|---|---|---|
| Gross collected | Included successful payments | Payment status and payment date |
| Revenue after refunds | Gross collected minus included refunds | Refund date or original payment date |
| Attribution coverage | Matched eligible payments divided by eligible payments | What makes a payment eligible and matched |
| Customer acquisition cost | Acquisition spend divided by new paying customers | Spend scope and first paid conversion |
| Revenue to spend ratio | Attributed revenue divided by acquisition spend | Gross, new, or refund adjusted revenue |
- Compare counts before totals. A count difference is usually easier to diagnose than an amount difference.
- List the missing payment identifiers instead of comparing only aggregate revenue.
- Separate zero revenue from missing data. They are not the same result.
- Keep unmatched payments in the denominator when reporting attribution coverage.
- Reconcile each currency separately unless you have a documented conversion method.
Example coverage statement: The report matched 92 of 100 eligible Stripe payments, so payment attribution coverage is 92 percent for this period. Eight payments remain unattributed and their revenue is not assigned to a source.
Diagnose the common mismatches
| Symptom | Inspect first | Do not assume |
|---|---|---|
| Payment exists in Stripe but not the report | Connection scope, payment status, event delivery, date range and currency | The customer never paid |
| Payment is present but the source is missing | Tracking start time, consent, cross domain handoff and identity at checkout | Direct traffic created the customer |
| Renewal appears as a new customer | Customer identifier and revenue type classification | Every charge is an acquisition |
| Refund is larger than expected | Partial refund identifiers and whether cumulative totals were sent repeatedly | Stripe duplicated the refund |
| GA4 revenue differs from Stripe | Purchase delivery, refund delivery, tax, shipping, timezone and event deduplication | One platform is universally wrong |
| Channel ratio looks unusually high | Spend coverage, unmatched payments, customer count and reporting window | The channel produced incremental profit |
A payment import cannot reconstruct acquisition context that was never captured. If tracking began after the visit or the checkout identity was not preserved, leave the source unmatched. A later direct session is not evidence that direct traffic acquired the customer.
Test a Stripe analytics tool with five records
Do not evaluate a tool from its demo dashboard. Use a controlled test workspace or known internal records, then inspect five cases that expose different parts of the data model. Avoid real charges made only for testing unless your payment process explicitly supports them.
| Test record | A passing result |
|---|---|
| Normal purchase | One successful payment is connected to the expected customer and captured source |
| Delayed payment | The payment appears after confirmation without inventing a new visit or duplicate sale |
| Renewal | A new payment increases customer value without increasing acquired customer count |
| Partial refund | Only the refunded amount reduces the chosen revenue measure and the adjustment appears once |
| Historical unmatched payment | The payment remains visible with an honest unmatched source state |
- Can you open the payment behind an aggregate number?
- Can you explain why a source was assigned?
- Can you separate new purchases, renewals and refunds?
- Can you export the identifiers needed for reconciliation?
- Can you see unmatched payments without silently dropping them?
- Can you apply one date, currency and customer definition across the report?
Buying rule: Choose the smallest reporting setup that answers your recurring decision with inspectable evidence. Keep Stripe for payment operations. Keep GA4 when its traffic and advertising reports are useful. Add another tool only when it closes a named reporting gap.
Turn the audit into a weekly review
- Set the date range and confirm the timezone and currency scope.
- Review new purchases, renewals, refunds and unmatched payments separately.
- Check attribution coverage before ranking sources or campaigns.
- Open at least one payment behind the largest movement.
- Compare new paying customers and refund adjusted revenue with spend.
- Record one decision, one uncertainty and the next check.
In Grometrics, use Revenue to separate money events, Attribution to inspect source relationships, and Campaigns to compare attributed revenue with recorded spend. Use the Stripe revenue setup guide when the collection path needs correction before analysis.
Repeat the worked audit across several customers before changing a budget. When the source match, spend coverage or reporting window is incomplete, record the result as inconclusive. Honest uncertainty is more useful than precise looking attribution built on missing evidence.
CONNECT YOUR PAYMENTS
Grometrics works with Stripe, RevenueCat, Gumroad, Shopify, and more. Setup takes about 5 minutes.
Connect payments →See the full comparison:
Best Stripe analytics toolsRELATED POSTS