SaaS discount code attribution measures what happens after a prospect receives and redeems an offer. It connects the code and its distribution context to a real customer, confirmed payments, later renewals, refunds, and retention. The result is not merely a redemption leaderboard. It is an economic view of whether a promotion acquired incremental customers at an acceptable cost.
A code is useful evidence, but it is not a complete acquisition source. The same public code may appear in an email, a creator video, a deal directory, and a private message. Existing customers may find it. A visitor can arrive through one campaign and enter a code associated with another. Treating the code as the sole source erases that journey and encourages every distributor to claim the same revenue.
A reliable system therefore preserves two dimensions: how the customer arrived and which commercial offer changed the price. This guide explains the records, calculations, cohort comparisons, and controls needed to evaluate SaaS discounts without confusing gross list value with money actually earned.
Separate acquisition, offer, and payment facts
Start with three event families that answer different questions. Acquisition events describe the visitor's source, referrer, landing page, UTM values, and touch sequence. Offer events describe which coupon or promotion code was eligible, entered, applied, removed, or rejected. Payment events describe the provider-confirmed subtotal, discount, tax, amount due, amount paid, currency, status, and refund.
Do not collapse these facts into one campaign column. A customer might arrive from a paid search ad, redeem a partner code, and pay through Stripe. Paid search is acquisition evidence, the partner code is offer evidence, and Stripe is the payment authority. Reporting can compare or combine them, but the raw records should remain distinct.
This separation also prevents a common accounting error. List price is not collected revenue. If a plan lists for $100 and a valid offer removes $20, the initial gross contract value may be $100, the discount is $20, and the amount before tax is $80. The report must label each amount instead of calling all three “revenue.” Stripe's Invoice object documentation distinguishes subtotal, total discount amounts, total, amount due, and amount paid. Use provider fields rather than reconstructing money from a pricing page.
For acquisition data, adopt a stable SaaS UTM naming convention. For offer data, use immutable internal IDs alongside the human-readable code. Display text can be reused or mistyped, while a promotion code ID identifies the actual configuration that was redeemed.
Model coupons and promotion codes correctly
Payment systems often distinguish discount rules from customer-facing codes. In Stripe, a coupon defines discount logic such as percentage or fixed amount, eligible products, duration, and redemption limits. A promotion code wraps a coupon with a code customers can enter and can add restrictions. Multiple promotion codes can point to one coupon.
That relationship affects analysis. Grouping only by coupon answers whether the underlying offer worked, but it combines every distribution channel using that offer. Grouping by promotion code can distinguish CREATOR_A from NEWSLETTER_A, even when both provide the same percentage. Preserve coupon ID, promotion code ID, entered code where appropriate, discount object ID, and the version of your internal campaign mapping.
Stripe's current Checkout discounts documentation says Checkout can accept a coupon or promotion code and can expose a customer-entered promotion code field. It also documents controls including eligible products, first-time transaction restrictions, minimum amounts, expiration, and maximum redemptions. These are eligibility controls, not proof that a campaign caused a sale.
Keep a campaign registry outside the payment object. A useful row contains offer owner, intended audience, distribution partner, planned channel, launch and end dates, coupon and code IDs, discount terms, commission rule, and campaign status. Never infer the original campaign later from code text alone. If a code leaks from a private newsletter into a coupon directory, the registry preserves intent while observed acquisition data reveals what actually occurred.
For subscription offers, duration belongs in the model. Stripe's subscription discount guide explains that a discount can apply once, for a number of months, or indefinitely, and that the invoice that consumed a once-only coupon retains the discount evidence even after the subscription no longer shows it. Snapshot the applied discount on each invoice rather than relying on today's subscription object to explain historical billing.
Carry both identities through checkout
Discount attribution needs a durable join from browser journey to customer and payment. Capture an opaque analytics session ID before redirecting to hosted checkout, attach it using the payment provider's supported reference or metadata path, and preserve the provider customer, checkout, subscription, invoice, and payment identifiers returned later. Do not send sensitive browsing data or raw personal information as metadata.
The Talivia Stripe Checkout guide shows how to pass the current Talivia session in a server-created Checkout Session and how the return visit provides an additional match. The payment webhook remains the authority for money. A success page is only a browser event: it may be refreshed, skipped, or shown before an asynchronous payment settles.
Record offer events with their own timestamps. Useful states include offered, code submitted, accepted, removed, checkout expired, payment succeeded, payment failed, and refunded. This reveals where the promotion changed behavior. A high number of rejected submissions may indicate confusing terms or code leakage. Many accepted codes followed by expired checkouts may indicate that the discount did not resolve the underlying purchase objection.
Talivia can connect source and session evidence to confirmed payment events through its revenue attribution workflow. Keep the promotion code as a separate commercial dimension in your warehouse or campaign ledger, joined through the same checkout, customer, subscription, and invoice identities. This lets you ask both “Which journey produced this payment?” and “Which offer changed its price?” without forcing one answer to replace the other.
Test identity failure paths deliberately. Cover missing session metadata, a return on another device, a logged-in customer using a new browser, duplicate webhooks, an expired Checkout Session, and a code added after a sales-assisted conversation. Unmatched payments must remain visible as unattributed rather than being assigned to the discount's intended channel.
Calculate net revenue instead of credited list value
A useful promotion report starts from confirmed money and maintains a bridge from list value to retained value. At invoice or payment level, preserve the undiscounted eligible subtotal, discount amount, tax, amount due, amount paid, currency, refund amount, dispute amount, and provider fee if your decision requires contribution economics.
Use explicit metrics:
- Redeemed checkout: an accepted discount attached to checkout. This is intent, not revenue.
- Discounted customer: a distinct customer with a confirmed eligible payment using the offer.
- Collected revenue: provider-confirmed amount paid, excluding tax when your policy requires it.
- Discount cost: eligible subtotal minus discounted subtotal under a documented rule.
- Retained revenue: collected revenue minus refunds and disputes linked to the payment.
- Contribution after promotion: retained revenue minus variable service cost, partner commission, and other included acquisition costs.
Do not treat the discount as cash marketing spend without qualification. Unused capacity has different economics from a hard fulfillment cost, and some buyers would not have purchased at list price. “Revenue forgone” is a scenario, not an observed bank transaction. Show the discount amount, but keep the assumptions used for incremental cost and margin separate.
Partner commission requires another ledger. If a creator earns a percentage of collected revenue, define whether the base is before or after discount, tax, refunds, disputes, and payment fees. Store each commission accrual and reversal against the payment. Never calculate lifetime commission by multiplying a current subscription price by a redemption count.
When a payment is refunded, link the reversal to its original payment and original offer cohort. The SaaS refund revenue attribution guide explains why cash-date and cohort-date views serve different purposes. Finance may need the refund on the date cash reversed, while acquisition analysis needs it deducted from the campaign that produced the customer.
Compare conversion with an eligible control
A promotion can have many redemptions and still create little incremental value. Customers who were already ready to buy may simply pay less. To estimate lift, compare against a credible group that could have received the offer under similar conditions.
The cleanest design is a randomized holdout when commercial and legal constraints allow it. Define eligibility before exposure, randomly assign the offer, keep pricing presentation otherwise consistent, and measure both assignment and actual redemption. Analyze by assignment first so that highly motivated redeemers do not make the offer appear stronger merely because they selected themselves.
When randomization is not possible, use a cautious matched comparison. Align plan, geography, device, acquisition source, landing page, signup period, customer segment, and observation age. Publish the remaining limitations. A newsletter audience receiving a code cannot be compared directly with all organic visitors if the groups differ in intent and familiarity.
Report at least eligible visitors, checkout starts, successful first payments, net initial revenue, average discount, refund rate, and contribution per eligible visitor. Redemption rate alone omits the people who saw the offer and did nothing. Conversion among redeemers is also mechanically selected because redemption happens near payment.
Avoid running overlapping public codes without a precedence rule. If a visitor sees one offer and redeems another, preserve both exposure and redemption. Decide in advance whether campaign credit follows randomized assignment, redeemed code, acquisition model, or separate columns. Changing that rule after results arrive makes the winning campaign a reporting choice rather than an observed result.
Follow subscription cohorts beyond the first invoice
An introductory offer can improve first-payment conversion while attracting customers who cancel when full price begins. Evaluate discounted and comparable full-price customers at equal subscription age, not merely during the launch month. Recent cohorts have had fewer renewal and churn opportunities.
Build cohort rows using the first successful paid invoice, offer ID, acquisition source, plan, billing interval, and customer segment. Then show initial collected revenue, renewal opportunities, successful renewals, cumulative retained revenue, expansion, contraction, refunds, effective churn, and contribution. Mark immature periods as incomplete rather than zero.
Discount expiry is an important boundary. For a three-month promotion, inspect the first full-price invoice separately from the discounted periods. A payment failure at that point is not automatically price rejection, and a cancellation request does not prove the discount caused the original purchase. Review invoice history, product usage, support context, and cancellation timing before forming a hypothesis.
Use the same definitions as your broader subscription revenue attribution model. First payment, renewal, expansion, refund, and churn are different events. The SaaS churn attribution framework also explains why effective endings, scheduled cancellations, involuntary churn, and contraction should not be combined into one count.
Compare revenue at equal age. A code with lower initial revenue can still be worthwhile if it produces enough incremental retained customers. Conversely, impressive signup volume can destroy contribution if discounts, partner payments, refunds, and support costs remain high after renewal. The decision should follow mature net economics, not the loudest launch metric.
Detect leakage, stacking, and attribution conflicts
Public offers spread beyond their planned audience. Monitor acquisition source against intended distribution. A partner code redeemed mostly by branded search or direct returning customers may be leaking, or customers may be searching for a code at checkout. That does not automatically imply fraud, but it changes the incremental value and commission discussion.
Set review rules for unusually high redemptions from one customer, card, account, or network; repeated first-time offers; disposable accounts; self-referrals; rapid refund behavior; and geographic use outside the campaign. Apply privacy and proportionality principles. These signals should trigger review, not automatic accusations.
Offer stacking also needs an explicit policy. Discounts can coexist with credits, trials, negotiated pricing, or legacy plans. Record each adjustment separately and define which combinations are allowed. If provider behavior changes, version the logic. A single “discounted” boolean cannot explain why amount due fell to zero.
Reconcile daily at several levels. Accepted checkouts should match provider discount objects. Paid discounted invoices should match campaign records. The sum of visible line amounts, discounts, tax, and adjustments should explain the provider total. Refunds should connect to original payments. Every payment should have an attribution status, including explicitly unattributed.
Use test mode to exercise percentage and fixed discounts, once and repeating durations, rejected and expired codes, duplicate webhook delivery, asynchronous payment, failed renewal, partial refund, full refund, code leakage, and multiple currencies. The Stripe subscription and invoice guide provides the Talivia-side event and identity path for recurring billing tests.
Turn offer evidence into a budget decision
A decision-ready report keeps acquisition source, redeemed offer, and payment outcome visible together. For each campaign, show the eligibility rule and observation cutoff, then compare incremental conversion, collected and retained revenue, discount value, commissions, refunds, mature renewal behavior, and contribution. Include sample size and unmatched-payment coverage so apparent precision does not hide incomplete joins.
Pause or narrow an offer when it mostly subsidizes customers who were likely to buy, leaks far outside the intended audience, attracts poor-fit cohorts, or cannot be reconciled. Expand it when a credible comparison shows additional retained customers and contribution after the full cost of the offer. Sometimes the best result is not a larger discount but better targeting, shorter duration, product restrictions, or a clearer landing promise.
Begin with one controlled promotion. Assign distinct code IDs by distributor, preserve the acquisition journey, pass a safe session identifier through checkout, and reconcile a test payment through its first renewal or refund. Only then automate campaign reporting.
If source and payment evidence are still separated, create a Talivia account and validate one test journey from campaign landing page to confirmed payment. Keep discount records alongside that attribution chain, measure actual collected and retained revenue, and let mature cohort economics decide whether the offer deserves more budget.
