Revenue attribution

Connect verified orders to the traffic and campaigns behind them.

Orders reach Seean in two ways: a native connector receives a payment provider’s signed webhooks, or your server sends verified orders and refunds to Seean’s order API. Each website reports in one currency that you choose. When an order names a visitor Seean knows, the attribution (touches, first and last source, landing page, time to buy) is derived on the server from that visitor’s tracked visits in the 90 days before the order. Fields your integration supplies are used only for visitors without tracked visits.

Connecting a payment provider

Open Settings → Integrations → Payment providers on your own website and select Enable under Creem, Mollie, Paddle, Polar, RevenueCat, Revolut, Shopify, Stripe, Superwall or Whop. The panel lists the setup steps, the website’s webhook URL for that provider (https://events.seean.io/api/connect/<provider>/<site ID>) and the events to enable; paste the provider’s signing secret and Seean verifies every delivery before storing it. For Stripe, Polar and Paddle, Quick connect creates the webhook from an API key you paste once instead; the key is not stored. After Save secret the field clears for security and the line below it reads Secret saved (ends in …) with the last four characters, so you can confirm the right secret is stored; paste a new value only to replace it. Paid orders and refunds then arrive automatically, and the status line shows the last event and any error. A failed connect or disconnect shows the server’s reason, including the seconds to wait when the request was rate-limited. The provider guides below give each provider’s steps, attribution snippet, refund and currency behavior and limits.

Stripe additionally offers a separate owner-only Optional Stripe payment reads section after connection. An initially unchecked consent control explicitly authorizes retention of a restricted read key for the exact initial Checkout invoice, payments and refunds—not renewals or a backfill. The key is never prefilled or returned; only the owner sees enabled status, test/live mode, account and suffix. Replace requires new consent. Remove read key leaves the webhook, orders and existing payment links intact. Quick/manual reconnect removes retained read access, while the quick-connect key remains used once and discarded. Demo/busy controls are disabled; successful actions and provider switches clear the typed read key. See the Stripe guide for permissions, successful-refund checks, signed-event/replay linkage and bounded explicit single-session recovery. This source delivery does not confirm production rollout or live historical recovery.

Delivery recovery

A native connector returns 503 when a refund arrives before its order (for up to one day after the refund was created; after that the refund is acknowledged and ignored), a Revolut order lookup fails, or ingestion is temporarily unavailable. Rate limits return 429. These responses leave delivery eligible for the provider’s retries; Seean does not keep a second webhook queue. After the original order is stored, replaying the refund with the same refund ID applies it once.

Check Settings → Integrations → Payment providers for the latest delivery time and recorded mapping or lookup error. Correct credentials or invalid payment data at their source. A later successful delivery clears the last error, so also check failed deliveries in the provider’s dashboard. Unsupported events and permanent payload/currency errors are acknowledged with 200; rejected orders are not stored.

Retry schedules and expiry are controlled by each provider. If delivery attempts expire, use its redelivery controls when available, or send the verified order/refund through the Order API with the original identifiers. Previously acknowledged failures are not automatically replayed by this change. Stripe’s optional reads can establish initial-payment links from newly delivered signed Checkout events or exact replays; enabling the key does not start historical recovery. Authenticated owners may separately request a single-session reconciliation dry run and then an explicit apply through a custom integration; there is no automatic or site-wide run. Unsupported multi-invoice/credit arrangements and missing references require review. Never create a new order ID merely to retry a payment.

Sending orders from your server

Open Settings → Integrations → Revenue, then expand Custom server integration (Order API) to choose the reporting currency and create an order API secret. Use your server or payment webhook handler to send verified orders to the displayed endpoint. Keep the secret on your server; do not include it in browser code. This is a custom integration, not an automatic connection to every checkout provider.

The tracker exposes window.seean.attribution() with the visitor ID, landing path, converting path and campaign. Pass those fields to your server with the order: the visitor ID is what links the order to the buyer’s visits. Without it the order is recorded as unattributed. Only forward payment events after verifying them with your provider.

Reporting currency

Each website has one reporting currency. Open the dropdown below Reporting currency in the Revenue integration card and choose an ISO 4217 code (USD by default); the selection saves automatically. Amounts are sent in that currency’s minor units: 2900 is USD 29.00, JPY has no minor unit so 2900 is JPY 2,900, and KWD uses three decimals so 2900 is KWD 2.900. An order in any other currency is rejected with HTTP 400 and the message Order currency EUR does not match the website's reporting currency USD (with the codes involved). Seean does not convert currencies.

Changing the reporting currency does not convert orders you already sent. Analyses count them as excluded, and the Revenue page shows a notice such as “3 orders use another currency and are excluded from the USD totals.” Only the orders in the current reporting currency form the totals.

Refunds

Refunds are a ledger per order. A refund can cover the full remaining amount or a partial amount, optionally carries your refundId so retries are deduplicated, and can carry its own timestamp. A refund that exceeds the remaining amount is rejected with HTTP 400; an order accepts at most 50 refunds. Once the refunded total reaches the order amount the order is marked refunded.

Refunds reduce net revenue in the period of the original order, not in the period of the refund date. A June order refunded in July lowers June’s net; July shows nothing for it. Review the range that contains the order.

Derived attribution

For an order with a known visitor, Seean reads that visitor’s visits in the 90 days before the order timestamp:

• Touches: the number of visits in that window.
• First source and Last source: the referrer or utm_source of the first and last visit; Direct when there is neither.
• Landing page: the entry page of the first visit.
• Time to buy: from the start of the first visit to the order.
• Campaign: the campaign your integration supplies; otherwise the utm_campaign of the most recent tagged visit.

If the visitor has no tracked visit in the window, the first source, last source, touches and time to buy your integration supplies are used, and the order counts as attributed only when it names a visitor and a landing path. Orders sent without a visitor ID are Unattributed. Orders recorded before derived attribution existed are backfilled once from their visitor’s tracked visits; a campaign your integration supplied is kept.

Attribution limits

Order ingestion accepts histories of up to 2,000 matching events within the 90-day window. It probes at most 2,001 rows to detect overflow, with a 1 MiB read budget. A complete saved journey can occupy up to 64 KiB. These limits apply to each order’s visitor history, not to a website’s total traffic. Seean saves every touch when the complete history fits; it no longer drops visits after the thirtieth.

If the history exceeds a limit, the order and refunds are still recorded exactly. The Revenue report shows an incomplete-history notice and an Incomplete history breakdown row instead of assigning credit from part of the journey. These orders do not contribute to attributed revenue or average time to buy; they remain in monetary totals and in the attribution-rate denominator. The report counts affected orders for its selected currency and period, including fully refunded ones. Changing the lookback does not recover history that could not be captured at ingestion.

Legacy shortened journeys are also marked incomplete until their full history can be recovered. Existing saved report results are preserved. Histories without tracked visits keep the integration-supplied attribution described above; they are distinct from a history that exceeded a limit. Automatic enrichment beyond these bounds is not currently available.

Ignore checkout and thank-you visits

A return from the payment provider often starts a new visit on your thank-you or checkout page, which would take last-touch credit. Under Settings → Exclusions → Revenue attribution only, admins and owners add up to 20 path rules with the traffic-exclusion syntax (/thanks exactly, or /checkout/* for a prefix). Visits that enter on a matching path are removed from the order’s touches before the lookback and model are applied; if no touch remains the order is Unattributed. Nothing is deleted: traffic, Overview pages and every other report keep those visits, and the converting page still shows the path your integration supplied. Rules apply to new calculations only - the Revenue and Overview reports start a new analysis when a rule changes, while results that were already saved, already computed scheduled reports and API results stay as they were; the next API request calculates with the new rules. Orders without a visit history (sent without a visitor ID, or older than derived attribution) cannot be filtered; the report counts them under the rules notice.

Revenue report

Open Revenue in the website sidebar. Its tables keep every value on one line; on narrow screens a table scrolls sideways inside its card and long purchase journeys are shortened with an ellipsis (hover for the full path). The toolbar has the date range plus the attribution controls:

• Attribution model: First touch credits the first visit in the lookback, Last touch the visit that led to the order, Linear splits the order evenly across its visits.
• Attribution lookback: 7, 14, 30 or 90 days before the order. A visit older than the lookback is not a touch. Complete saved visits are used for model credit, subject to the attribution limits below.
• Website default: the page opens with the website’s saved model and lookback (last touch, 30 days until one is saved). When your selection differs, admins and owners see Save as website default; the default is shared with the Overview’s revenue credit, the analytics API and MCP get_revenue, and with every teammate. A selection in the URL always wins for that view. Overview: net / gross chooses what the Overview KPI shows (see KPIs); the demo website cannot change these settings.

The top strip shows gross, refunds (with the refund count), net, attributed revenue, attribution rate and average time to buy. Attribution breakdown has five tabs: Landing pages, Converting pages, First source, Last source and Sources. Sources credits each source under the selected model, so with Linear an order appears once under each of its sources with a share of its net amount. Revenue by product lists orders, revenue, share and the attributed portion. Touches before purchase buckets orders by derived touch count. Purchase journeys groups paid orders by the entry page of each visit inside the lookback, oldest first (/ → /pricing → /checkout): consecutive repeats collapse, only the last six steps are kept behind an ellipsis, a path supplied by your integration replaces the derived journey, and orders without a visit history show their landing page. Journeys are visit entry pages, not every page viewed.

Orders lists the period’s orders newest first, twenty at a time with Load more, in the reporting currency only: time (hover for the exact moment in your display time zone), product with Refunded or Partially refunded −amount badges, first source, journey and amount under the selected model and lookback. Orders with an incomplete history show Incomplete history. Refunds lists every refund of those orders - refund time, order ID (or order time), product, refund ID and amount - also twenty at a time; a full refund recorded before refund ledgers existed appears once as legacy. Refunds always count in their order’s period, both here and in the totals. Viewers can read both lists; raw exports stay under Settings → Data.

Changing the model or lookback starts a new analysis for the same range; existing results and stored orders are not rewritten.

Compare periods

The comparison button next to the date range offers the same choices as Overview: Previous period, Previous week, Previous month, Previous quarter, Previous year, Custom range… and No comparison (see date ranges and filters). With a comparison active, each KPI in the top strip shows its percentage change against the comparison interval instead of its count: gross, refunds, net, attributed revenue, attribution rate and time to buy. A rise in refunds or time to buy is shown as a decline. Previous period is computed in the same analysis; other choices start one extra revenue analysis with the same model, lookback and reporting currency. Breakdown tables, products, touches, journeys, orders and refunds stay current-period views, and All time has no comparison.

Attribution handoff

Whether a connector or your server records the order, the link to the visit is the visitor ID. With a connector, attach seean_visitor_id (and optionally seean_landing_path, seean_converting_path, seean_campaign) from window.seean.attribution() to the provider’s checkout metadata, custom data, cart attributes or subscriber attributes as the provider guide shows; Seean reads those keys from the verified event. The public tracking token never authorizes order ingestion.

For a custom integration, capture window.seean?.attribution?.() when available during checkout creation and pass only the supported fields to your server. Store them with the checkout/order reference so the later verified payment event can use them. The helper can be absent before loading or return no attribution when collection is disabled. Accept an unattributed order in that case; do not invent visitor or campaign values.

After the tracker loads, await window.seean?.ready before reading attribution. This finishes after the initial collection attempt or its timeout; it does not guarantee that a visitor ID exists. Use this inside your asynchronous checkout handler and allow checkout to continue without attribution. Each provider example includes the wait.

The default visitor hash changes at midnight UTC and is scoped to one website. The 90-day lookback searches records carrying the captured identifier; it does not join that visitor’s different daily hashes. Preserve checkout-time attribution for delayed payment webhooks. A later return on a new UTC day has a new identity, so multi-day journeys are not reconstructed. Legacy orders and saved results keep their original identifiers and values.

Keep stable external order identifiers across retries. Forward recurring payments as the distinct paid orders they represent, and map each refund to the original external order ID with the provider’s refund ID. Your integration must account for the provider’s event ordering and duplicates. Convert provider amounts to the website’s reporting currency minor units only when the payment was actually charged in that currency; Seean rejects other currencies rather than converting them.

Verify your integration

Use your provider’s test facilities and a separate Seean test website where possible. Verify a paid order, an identical retry, a partial refund, a full refund and an order without attribution. Check the website’s Revenue report against the exact amounts and the derived attribution. A successful tracker request or a confirmation-page visit does not prove that the order was ingested.

Integration reference

Follow Order API and refunds for payloads, server-key handling, currency rules, refund rules and retry behavior. Provider availability summarizes which providers have a native connector.

Provider guides

Each guide covers the provider’s setup steps, the attribution snippet for its checkout, what is recorded, refunds, currency, verification and limits.

Tracked visitor history is captured once when a new order is accepted, through either the Order API or a supported provider connector. A temporary history lookup failure returns a retryable response; an accepted duplicate keeps the original attribution and exact amount. See Order API retries.

• Creem

  Connect Creem to Seean with the webhook secret, pass the visitor ID as checkout metadata and receive completed checkouts and refunds.

• Mollie

  Connect Mollie to Seean through signed next-generation webhooks, pass the visitor ID as payment metadata and receive paid payments and refunds.

• Paddle

  Connect Paddle to Seean with the notification secret key, pass the visitor ID as checkout custom data and receive completed transactions and approved refunds.

• Polar

  Connect Polar to Seean with the webhook secret, pass the visitor ID as checkout metadata and receive paid orders, renewals and refunds.

• RevenueCat

  Connect RevenueCat to Seean with the webhook authorization value, pass the visitor ID as Web Billing metadata or a subscriber attribute and receive purchases, renewals and refunds.

• Revolut

  Connect the Revolut Merchant API to Seean with the webhook signing secret and Merchant API secret key, pass the visitor ID as order metadata and receive completed orders.

• Shopify

  Connect a Shopify store to Seean with the webhook signing secret, write the visitor ID as a cart attribute and receive paid orders and refunds.

• Stripe

  Connect Stripe Checkout to Seean with the webhook signing secret, pass the visitor ID as session metadata and receive paid orders and refunds.

• Superwall

  Connect Superwall to Seean with the webhook signing secret, set the visitor ID as a user attribute and receive purchases and renewals.

• Whop

  Connect Whop to Seean with the webhook signing secret, pass the visitor ID as checkout metadata and receive successful payments and refunds.

Something unclear? Contact support.