Web analytics

Revenue attribution for Stripe, Polar and your API

Connect payments to website traffic sources with Yaap. Attribute Stripe, Polar or server API revenue, account for refunds and report currencies separately.

Last updated September 16, 2026

Find the traffic that leads to payments

Revenue attribution connects payment records to the website activity that preceded them. It helps you compare sources and campaigns by the revenue linked to them, alongside visits and conversions. High traffic and high revenue do not always come from the same places.

Yaap can receive payments from Stripe webhooks, Polar webhooks or a server payment API. When a payment carries a valid analytics visitor identifier, Yaap can connect it to recorded activity. Payments without a usable identifier stay unattributed; Yaap does not infer an identity from a customer email.

Use revenue reports with conversion goals and funnels to follow acquisition, completed actions and payments in the same analytics workspace.

Connect the payment workflow you already use

Open Revenue → Payment settings for a website. For Stripe or Polar, configure the appropriate webhook endpoint and signing secret. Keep test and live integrations separate so sample purchases do not affect production reporting.

Your checkout integration passes the visitor identifier to your server only when your tracking configuration permits identifiers. The server attaches the required analytics metadata to the payment provider record. Adding a webhook secret alone does not add that metadata to an existing checkout flow.

If you use another payment workflow, send records through the server payment API. Keep its credential on the server and use a stable payment ID for retries. Choose one ingestion path for each sale; sending the same sale through both a webhook and the API creates separate records.

The integration overview links to the full payment contract, provider metadata examples and signature-verification requirements.

Keep refunds, currencies and environments visible

Revenue reports account for refunds and separate currencies. Compare USD with USD and JPY with JPY instead of summing unlike amounts into a misleading total. Test payments belong in test reports, even when the integration uses the same website.

A browser event called purchase can be useful for a conversion goal, but it does not create a verified payment record. Payment amounts must come from your server or payment provider, not a browser-provided value.

Validate the integration with a test payment, a refund and a payment without a visitor identifier. Confirm that the first is attributed when matching activity exists, the refund changes the totals and the last remains unattributed. These checks reveal missing metadata before you rely on source-level results.

Understand what attribution can tell you

Attribution depends on the activity you collect, retained history and payment metadata. Anonymous collection, unavailable storage, a paused tracker or missing checkout metadata can leave a payment unattributed. That is a reporting limitation to investigate, not a reason to invent a match.

A source credited with revenue shows an observed relationship. It does not prove that the source caused an incremental sale. Read the report with that distinction in mind when deciding where to spend time or budget.

Review collection controls, connect your payment workflow and compare the first reports with provider records. Revenue attribution is available with hosted Yaap and self-hosted installations.

Try Yaap with your own website

Start a 14-day hosted trial with no credit card, or follow the documentation to run Yaap in your own Cloudflare account.

Start your free trial