# AttribIQ complete context
> First-party product facts and the complete public guide corpus for AttribIQ, an EU-hosted SaaS revenue attribution platform.
Canonical site: https://attribiq.com/
Compact index: https://attribiq.com/llms.txt
AttribIQ connects observed acquisition context with matched payment outcomes. Its documented scope includes browser tracking, UTMs, referrers, landing pages, signup and checkout context, Stripe webhooks, a generic Payment API, Google Search Console data, funnels, subscriptions, renewals, refunds, churn, and revenue reports.
Interpretation notes:
- An identifiable referrer hostname or explicit campaign signal can be journey evidence; missing traffic and modeled visibility do not receive revenue credit.
- Treat first-touch, last-touch, and session-touch as distinct reporting models.
- Do not describe attribution as proof of causality.
- Do not infer undocumented product features.
- EU hosting and privacy-minimizing defaults are product characteristics, not legal advice or a guarantee of compliance.
- Follow each document's canonical URL when citing or linking for people.
---
# Understand the AttribIQ overview dashboard
> Read visitors, pageviews, sessions, engagement, acquisition, content, audience, and optional revenue from the AttribIQ overview.
Canonical page: [https://attribiq.com/guides/overview-dashboard](https://attribiq.com/guides/overview-dashboard)
Category: Web Analytics
Last updated: 2026-10-02
Topics: web analytics, dashboard, visitors, pageviews, sessions
## Summary
Start with the traffic trend, then use the acquisition, content, and audience summaries to decide which detailed report to open. Revenue is an additional outcome when a payment source is connected.
## What this guide covers
- Read the headline traffic metrics
- Switch the trend between visitors and pageviews
- Use acquisition, content, and audience summaries
- Separate web analytics from optional revenue data
The Overview is the starting point for checking what happened on a site during a selected period.
It combines traffic, engagement, acquisition, content, and audience summaries. When payment data is connected, it can also place revenue and paid conversions beside those web analytics metrics.
## Start with the date range
Select the same date range and reporting timezone whenever you compare periods or tools. A day boundary in one timezone can move sessions and events into a different date in another.
For a quick check, use a preset such as 24 hours, 7 days, 30 days, or 90 days. Use a custom range for a launch, campaign, or release window.
## Read the headline metrics
The core web analytics cards include:
- Visitors: distinct visitors represented in the selected period.
- Pageviews: tracked page-view events.
- Sessions: grouped activity within the session rules used by the tracker.
- Bounce rate: the share of sessions that did not continue into additional measured activity.
- Average session duration: average measured time across sessions.
Read [visitors, pageviews, and sessions](https://attribiq.com/guides/visitors-pageviews-sessions) before comparing them as if they were interchangeable.
## Use the trend before the rankings
Switch the main chart between visitors and pageviews to see whether the change is broad traffic growth or deeper browsing by a similar audience.
A total can hide a short spike or a slow decline. The trend helps you locate the date worth investigating in Acquisition, Pages, or Campaigns.
## Choose the next report
Use the overview summaries as routes into deeper questions:
- Acquisition for sources, countries, and devices.
- Pages for content and landing-page performance.
- Campaigns for tagged traffic and optional attributed revenue.
- Realtime for current sessions and incoming events.
- Goals and Funnels for conversion.
- Revenue for matched payment outcomes.
## Treat revenue as additional context
Revenue cards depend on Stripe or Payment API events. Empty revenue does not make the traffic reports incomplete; it means payment data is not connected or no accepted revenue events exist in the selected range.
If payments are connected, compare the traffic trend and revenue trend separately. More visitors do not automatically mean more paid conversions.
## A weekly review in practice
Suppose a weekly report shows 1,200 sessions, up from 1,000 in an equally long period. The 20% increase is a starting point for investigation, not proof that the site improved.
| Check | Example observation | Next action |
| --- | --- | --- |
| Traffic trend | Most of the increase happened on Tuesday | Check what launched or changed that day |
| Acquisition | A newsletter supplied the extra visits | Open the campaign and its destination pages |
| Content | Most visitors started on one new guide | Review that page’s goal and funnel |
| Conversion | Signup rate fell despite more sessions | Inspect the steps before signup and the campaign audience |
| Audience | Mobile makes up most of the new traffic | Test the destination and signup flow on a phone |
These numbers are illustrative. Use your own report values and a consistent goal denominator. A change in traffic mix can move a site's overall conversion rate even when individual pages behave the same way.
## Build a report around a decision
Start with one question: which campaign to repeat, which page to improve, or which funnel step to investigate. Link that question to a traffic report and a measurable action.
For a content site, compare [pages and landing pages](https://attribiq.com/guides/content-and-landing-pages) with newsletter signups. For a lead-generation site, measure form completion as a [goal](https://attribiq.com/guides/create-goals). For a SaaS product, first review signup conversion, then add [Stripe attribution](https://attribiq.com/guides/stripe-revenue-attribution) if you need paid outcomes.
## Next steps
Open the [live sample dashboard](https://attribiq.com/demo-dashboard), then learn how to read [traffic sources and referrers](https://attribiq.com/guides/traffic-sources-referrers).
## Frequently asked questions
### Do I need Stripe to use the overview?
No. Visitors, pageviews, sessions, engagement, acquisition, content, and audience reports work without a payment integration.
### Why can two analytics tools show different totals?
Tracking coverage, bot filtering, session rules, timezone, blocked requests, and privacy settings can all change the totals. Align those rules before comparing.
---
# Visitors, pageviews, and sessions
> Understand what visitors, pageviews, and sessions count in AttribIQ and why the three metrics answer different questions.
Canonical page: [https://attribiq.com/guides/visitors-pageviews-sessions](https://attribiq.com/guides/visitors-pageviews-sessions)
Category: Web Analytics
Last updated: 2026-09-08
Topics: visitors, pageviews, sessions, web analytics
## Summary
Visitors estimate audience size, pageviews count viewed pages, and sessions group related activity. Compare all three over the same period instead of treating one as a complete measure of growth.
## What this guide covers
- Distinguish visitors, sessions, and pageviews
- Use views per session
- Compare periods consistently
- Understand the cookieless limitation
Visitors, sessions, and pageviews describe different levels of website activity.
## Visitors
Visitors are distinct visitor identifiers observed during the selected period. They are useful for estimating audience size, but they are not verified people.
AttribIQ's cookieless default stores identifiers in tab-scoped session storage. A separate tab can receive a different identifier, and the same person on another browser or device is not automatically joined.
## Sessions
A session groups related activity. Sessions answer questions such as:
- How many browsing periods occurred?
- Which source or campaign started a session?
- How many pages did a typical session include?
- Which events happened in the same journey?
One visitor can have more than one session.
## Pageviews
A pageview records a tracked page load or client-side route view. Pageviews help compare content demand and browsing depth.
For a single-page app, verify that route changes create pageviews and that the integration does not also send a duplicate manual event.
## Views per session
Views per session is:
```txt
pageviews / sessions
```
Use it as a simple browsing-depth indicator. A high value is not universally better: documentation, pricing, and support pages can have very different expected journeys.
## Compare like with like
When comparing AttribIQ with another analytics product, align:
- Date range and timezone.
- Included hostnames and blocked paths.
- Bot and internal-traffic filtering.
- Single-page-app routing behavior.
- Consent and storage mode.
Small differences are expected when tools use different identity and session rules.
## Next steps
Use the [overview dashboard guide](https://attribiq.com/guides/overview-dashboard) for the full report and [realtime analytics](https://attribiq.com/guides/realtime-analytics) to verify incoming traffic.
## Frequently asked questions
### Can one visitor create multiple sessions?
Yes. A visitor can return in another session, and the default tab-scoped storage can also create separate identifiers across tabs.
### Does a page reload create a pageview?
It can. Verify the tracker behavior on your site and check that single-page-app route changes and full reloads are not being recorded twice.
---
# Understand traffic sources and referrers
> Read sources, referrers, campaigns, and direct traffic without assigning more certainty than the browser supplied.
Canonical page: [https://attribiq.com/guides/traffic-sources-referrers](https://attribiq.com/guides/traffic-sources-referrers)
Category: Web Analytics
Last updated: 2026-10-02
Topics: sources, referrers, direct traffic, campaigns, utm
## Summary
A referrer is the page or hostname supplied by the browser, a source is the normalized acquisition label, and a campaign comes from explicit tags. Missing evidence should remain direct or unknown.
## What this guide covers
- Distinguish source from referrer
- Understand direct traffic
- Use UTM campaign fields
- Avoid overclaiming attribution
Acquisition reports explain how a recorded visit reached the site using the evidence available in the request.
## Referrer
The referrer is the page or hostname supplied by the browser. It may identify a search engine, partner, publication, social network, or another page on your own site.
Referrers can be missing because of browser policy, application behavior, copied links, redirects, or privacy controls.
## Source
Source is a normalized label used to group related traffic. For example, multiple Google referrer URLs can appear under a common source label.
Use the raw referrer when you need the supplied hostname and the source when you need a cleaner comparison.
## Campaigns
UTM parameters provide explicit campaign context:
- `utm_source`
- `utm_medium`
- `utm_campaign`
- `utm_content`
- `utm_term`
Use a consistent naming policy. `newsletter`, `Newsletter`, and `email-newsletter` create separate values unless normalized before publishing.
The [UTM builder](https://attribiq.com/tools/utm-builder) can create a tagged URL, and the [UTM checker](https://attribiq.com/tools/utm-checker) can review it before launch.
## Direct and unknown traffic
Direct does not always mean someone typed the address. It means the recorded visit did not include a usable source signal.
Do not silently convert missing evidence into a confident acquisition claim. Keep the recorded traffic state visible and apply attribution models separately when revenue is connected.
## A practical review
For a campaign window:
1. Check total visitors and sessions.
2. Compare source and campaign rows.
3. Open the landing pages receiving that traffic.
4. Review goal or funnel conversion.
5. Add revenue only if payment events are connected.
## Compare traffic quality before revenue
A source with more sessions is not automatically a better source. Compare a meaningful goal as well as visits.
For example, suppose a newsletter brings 200 measured sessions and 12 sessions complete a signup goal. A partner link brings 500 sessions and 10 complete the same goal. The illustrative signup rates are 6% and 2%, respectively. The partner supplied more reach; the newsletter supplied more signups from fewer sessions.
Keep the same time window and goal definition. Inspect the [landing pages](https://attribiq.com/guides/content-and-landing-pages) and [device mix](https://attribiq.com/guides/country-and-device-reports) before deciding whether the difference comes from the source, audience or destination.
This review works without Stripe. When payment events are available, [UTM revenue attribution](https://attribiq.com/guides/utm-revenue-attribution) adds purchases and refunds to the comparison.
## Next steps
Read [UTM revenue attribution](https://attribiq.com/guides/utm-revenue-attribution) for payment-aware campaigns or [content and landing pages](https://attribiq.com/guides/content-and-landing-pages) for the next step in the visit.
## Frequently asked questions
### Why is traffic marked direct?
The request may not include a usable referrer or campaign value. Bookmarks, copied links, privacy controls, applications, and redirects can all remove that evidence.
### Should I replace direct traffic with the previous known campaign?
Only if that is an explicit attribution rule you intend to use. Keep the recorded session evidence separate from any later model that assigns credit.
---
# Measure content and landing-page performance
> Use page and landing-page reports to understand what people read, where journeys begin, and which pages contribute to conversion.
Canonical page: [https://attribiq.com/guides/content-and-landing-pages](https://attribiq.com/guides/content-and-landing-pages)
Category: Web Analytics
Last updated: 2026-10-02
Topics: pages, landing pages, content analytics, conversion
## Summary
All-pages reports show demand across the site; landing-page reports focus on where sessions begin. Add goals, funnels, or revenue to evaluate outcomes instead of ranking content by traffic alone.
## What this guide covers
- Distinguish pages from landing pages
- Compare traffic and outcomes
- Investigate content changes
- Avoid causal claims
Page reports explain what content received measured activity. Landing-page reports focus on where a session or journey began.
## All pages
Use the all-pages view to find:
- Frequently viewed content.
- Pages that changed after a launch or release.
- Paths that may be missing tracking.
- Content worth connecting to a goal or funnel.
Compare both pageviews and visitors. Repeated use of one page can create many pageviews without a similar increase in audience.
## Landing pages
A landing page is the first tracked page in the recorded session or journey.
Landing-page reporting is useful for campaign destinations, SEO content, product launches, and pricing paths. It does not prove that the first page caused the later outcome.
## Add conversion context
Traffic alone cannot tell you whether a page helped the visitor complete an important action.
Use:
- A path goal for a confirmation or success page.
- A custom-event goal for an in-page action.
- A funnel for an ordered sequence.
- Revenue attribution for matched payment outcomes.
Keep the denominator visible. A page with fewer conversions can still have a stronger conversion rate if it received much less traffic.
## Investigate changes
When a page rises or falls:
1. Confirm the date range and tracking coverage.
2. Compare the source and campaign mix.
3. Check whether the URL or route changed.
4. Review related goals and funnel steps.
5. Separate traffic changes from payment changes.
## Compare pages with a worked example
Imagine two guides measured over the same 28 days. Each newsletter signup is counted once per measured session, and the denominator is sessions that began on that guide.
| Landing page | Landing sessions | Sessions with a signup | Signup rate |
| --- | --- | --- | --- |
| Broad introduction | 1,000 | 20 | 2% |
| Specific implementation guide | 200 | 12 | 6% |
The introduction brings more signups in total. The implementation guide converts a larger share of its smaller audience. Both can be useful; the next action depends on whether you need more reach or a better path from interest to signup. These are illustrative figures, not AttribIQ customer results.
Use a [goal](https://attribiq.com/guides/create-goals) or [funnel](https://attribiq.com/guides/build-and-read-funnels) with the same period and definitions to investigate the relationship. Do not divide every goal completion across the whole site by one page's pageviews and label that the page's conversion rate.
## Turn the report into an editorial decision
- **Traffic grows and conversion holds:** improve internal links to the next useful guide or action.
- **Traffic grows but conversion falls:** compare source and device mix, then check whether the page answers the visitor's question.
- **Traffic falls suddenly:** verify the URL, tracker coverage and campaign activity before rewriting the content.
- **Search impressions grow without visits:** inspect query, page and position in [Search Console](https://attribiq.com/guides/what-is-google-search-console). A website tracker measures visits after arrival; it cannot report unclicked search impressions.
For campaign work, pair this report with [sources and referrers](https://attribiq.com/guides/traffic-sources-referrers). Revenue can be added later when a payment integration is in place.
## Next steps
Create a [path or custom-event goal](https://attribiq.com/guides/create-goals), then read [landing-page revenue attribution](https://attribiq.com/guides/landing-page-revenue-attribution) when payment data is connected.
## Frequently asked questions
### Is the most visited page the best page?
Not necessarily. High traffic can come from broad intent. Compare the page with goals, funnels, and revenue when those outcomes are available.
### What is a landing page?
It is the first tracked page in a session or journey, according to the tracker and reporting rules.
---
# Install AttribIQ
> Install the AttribIQ tracker, verify visitors and pageviews, and start measuring traffic, content and conversions. Add Stripe attribution when needed.
Canonical page: [https://attribiq.com/guides/install-attribiq](https://attribiq.com/guides/install-attribiq)
Category: Implementation Guides
Last updated: 2026-10-02
Topics: install, tracker, stripe, payment api, cli
## Summary
Add your project’s tracker and verify pageviews in Realtime. You can use traffic, acquisition, content, audience, goals and funnels without connecting a payment provider. Stripe or the Payment API adds revenue to those reports when you need it.
## What this guide covers
- Install and verify the web tracker
- Read visitors, sources and pages
- Define a conversion goal and funnel
- Add payment attribution when needed
Start by collecting web analytics. Add a payment integration when you want to connect visits to revenue.
The tracker records visits, sessions, sources, referrers, UTM campaigns, pages, and goals. The payment integration connects those sessions to purchases, subscriptions, renewals, refunds, and churn.
## Add the web tracker
Place the tracker on pages where visitors arrive, evaluate the product, sign up, or start checkout.
```html
```
Use the project-specific script URL from your AttribIQ project settings. The install key in the URL maps browser events to your project.
If you want the browser to load the tracker from your own domain, use a [first-party tracker proxy](https://attribiq.com/guides/first-party-tracker-proxy) and proxy both the script path and the event endpoint.
## Content Security Policy
If your site uses Content-Security-Policy, merge the AttribIQ edge origin into the page's existing directives.
```http
script-src 'self' https://edge.attribiq.com;
connect-src 'self' https://edge.attribiq.com;
```
The direct tracker loads JavaScript from `https://edge.attribiq.com` and sends events back to `https://edge.attribiq.com`. It does not require `unsafe-inline`, `unsafe-eval`, or an AttribIQ `img-src` origin.
AttribIQ cannot override a customer's CSP from the edge domain. The browser evaluates the page owner's policy before fetching the tracker script.
For nonce-based policies, add the page's nonce to the external script tag and keep the same nonce in the CSP header:
```html
```
With a first-party proxy, the browser-facing CSP usually only needs your own origin for the tracker paths, because the server-side proxy forwards requests to AttribIQ.
## Verify your first pageview
Open a page with the tracker installed and then open **Realtime** in the same AttribIQ project. Confirm the page path appears. Navigate to another tracked page and check the next event.
If nothing arrives, check that the project script loaded, your Content Security Policy allows its requests and the page is using the correct project snippet. Avoid adding the tracker twice through both a site template and a tag manager.
## Start using web analytics
You now have a useful website analytics setup without payment events:
| Question | Report | Guide |
| --- | --- | --- |
| How much activity does the site receive? | Overview | [Visitors, pageviews and sessions](https://attribiq.com/guides/visitors-pageviews-sessions) |
| Where do visitors come from? | Acquisition and Campaigns | [Sources and referrers](https://attribiq.com/guides/traffic-sources-referrers) |
| Which content do they visit? | Pages | [Content and landing pages](https://attribiq.com/guides/content-and-landing-pages) |
| Which audiences reach the site? | Countries and devices | [Audience reports](https://attribiq.com/guides/country-and-device-reports) |
| Do visitors take the next step? | Goals and Funnels | [Create goals](https://attribiq.com/guides/create-goals) |
Allow collected events to reach the reports and keep the date range and reporting timezone aligned. Visitors are measured identifiers, not a count of known people. The default tracker keeps those identifiers within a browser tab; see [tracker behavior](https://attribiq.com/guides/web-tracker) when comparing tools.
## Define a conversion
Choose one action that matters to the site: a signup confirmation, a completed form or a request for a demo. A path goal works when the action has a dedicated destination page. Use a custom-event goal when the action happens within a page.
Then use a [funnel](https://attribiq.com/guides/build-and-read-funnels) to compare the measured steps leading to that goal. Start with one journey you can test yourself before adding more.
## Add payment attribution when you need it
To measure revenue by source or campaign, carry the visitor and session IDs from the browser through your backend into the payment record. A successful payment must be matched to that earlier context; installing the tracker alone does not provide that link.
- **Stripe:** follow [Stripe revenue attribution](https://attribiq.com/guides/stripe-revenue-attribution), [pass attribution to Checkout](https://attribiq.com/guides/pass-attribution-to-stripe-checkout), then [connect the webhook receiver](https://attribiq.com/guides/connect-stripe-to-attribiq).
- **Other billing systems:** normalize payment events on your backend and use the [Payment API](https://attribiq.com/guides/generic-payment-api-revenue-tracking).
This is a separate setup step. Traffic, content, audience, goal and funnel reporting remain useful without it.
## Query reports from the CLI
Use the CLI when you want revenue reports in scripts, release checks, or automation.
```sh
attribiq revenue --project proj_123 --from 30d --group-by campaign --json
attribiq overview --project proj_123 --from 90d --json
attribiq funnels inspect signup-to-paid --project proj_123 --json
```
Read [CLI reports](https://attribiq.com/guides/cli-reports) for the first commands to support.
## Next steps
Read the [overview dashboard](https://attribiq.com/guides/overview-dashboard), review your [traffic sources](https://attribiq.com/guides/traffic-sources-referrers), and choose one [conversion goal](https://attribiq.com/guides/create-goals). Explore the [live demo](https://attribiq.com/demo-dashboard) to see the reports before connecting your own data.
## Frequently asked questions
### What is the fastest install path?
Add the project script, open a tracked page, confirm it appears in Realtime, then review Overview and Pages. Payment setup is optional.
### Do I need Stripe?
No. The web analytics reports, goals and funnels work without Stripe. For revenue reporting, connect Stripe or send normalized events through the Payment API.
### Should the tracker run on the marketing site or app?
Install it wherever attribution-relevant sessions happen: marketing pages, pricing pages, guides, signup pages, and app pages that can lead to checkout.
### Can I install the tracker without revenue events?
Yes. The tracker provides the analytics base layer. Revenue reports become useful once Stripe webhooks or Payment API events are connected.
---
# Use realtime web analytics
> Verify incoming pageviews and events, inspect active sessions, and use realtime reports without treating a short window as a trend.
Canonical page: [https://attribiq.com/guides/realtime-analytics](https://attribiq.com/guides/realtime-analytics)
Category: Web Analytics
Last updated: 2026-09-08
Topics: realtime analytics, active visitors, events, sessions
## Summary
Use Realtime to verify installation and inspect current activity. Use longer date ranges for performance decisions because a five-minute window is volatile.
## What this guide covers
- Verify a tracker installation
- Read active visitor and event data
- Inspect a live session
- Know when not to use realtime
Realtime shows recent visitors, live sessions, and incoming events.
It is best for verifying collection and observing a launch as it happens. It is not a substitute for a stable date-range report.
## Verify installation
After installing the tracker:
1. Open a tracked page.
2. Navigate to another tracked route.
3. Open Realtime for the same project.
4. Confirm the pageview and session appear.
5. Trigger a custom event if your implementation sends one.
If the visit does not appear, check the browser network request, project install key, allowed hostnames, and blocked paths.
## Read the snapshot
The Realtime report includes:
- Active visitors in the recent window.
- Pageviews and events.
- Top pages and sources.
- Live visitor or session rows.
- Recent event details.
- Approximate country-level map context when available.
Select a session or event to inspect the recorded context. Do not treat it as verified personal identity.
## Use longer reports for decisions
A realtime window is small and volatile. One campaign click or internal test can change its rankings.
Use Overview, Acquisition, Pages, and Campaigns for period comparisons. Use Realtime to answer “is data arriving?” and “what is happening now?”
## Next steps
Read [Install AttribIQ](https://attribiq.com/guides/install-attribiq) for setup or return to the [overview dashboard](https://attribiq.com/guides/overview-dashboard) for period reporting.
## Frequently asked questions
### How often does the realtime report refresh?
The current dashboard refreshes its live snapshot every 15 seconds and also provides a manual refresh action.
### Why is my test visit missing?
Check the project, hostname allowlist, blocked paths, script loading, browser requests, and whether bot or internal-traffic rules exclude the visit.
---
# Create path and custom-event goals
> Define important website actions as path or custom-event goals before building funnels or connecting revenue.
Canonical page: [https://attribiq.com/guides/create-goals](https://attribiq.com/guides/create-goals)
Category: Goals & Funnels
Last updated: 2026-09-08
Topics: goals, custom events, path goals, conversion
## Summary
Use a path goal when reaching a URL is the outcome. Use a custom-event goal when the action happens without a unique page. Name goals around the user action.
## What this guide covers
- Choose path or event matching
- Name goals clearly
- Verify goal activity
- Use goals in funnels
A goal marks an action that matters to the site.
Examples include viewing a signup-complete page, submitting a form, starting checkout, downloading a resource, or activating a product feature.
## Path goals
Use a path goal when the outcome has a unique tracked URL, such as:
```txt
/signup/success
```
Path goals are simple to verify because the matching pageview appears in the page and session history.
Avoid broad matches that also include unrelated pages.
## Custom-event goals
Use a custom-event goal when the action occurs without a unique page. Your site sends a named event, and the goal matches that event name.
Examples:
- `signup_started`
- `demo_requested`
- `checkout_opened`
- `report_exported`
Use stable names and document when the event fires. Do not include raw personal data in event names or properties.
## Name the outcome
Name goals around what the visitor completed, not the implementation detail.
Prefer “Signup completed” over “Button click 4.” A clear name remains understandable in a funnel and when the UI changes.
## Verify the goal
After creating a goal:
1. Complete the action once.
2. Check the incoming pageview or custom event in Realtime.
3. Confirm the goal count in the selected period.
4. Check that retries or repeated route handling do not double count it.
## Next steps
Combine goals and tracked steps in [a funnel](https://attribiq.com/guides/build-and-read-funnels), or learn [what conversion rate means](https://attribiq.com/guides/what-is-conversion-rate).
## Frequently asked questions
### Should a button click be a path goal?
Use a path goal only if the click reliably leads to a unique tracked URL. Otherwise send a custom event and use an event goal.
### Does a goal require revenue?
No. Goals measure website actions independently. Revenue adds payment outcomes when connected.
---
# First-party tracker proxy for analytics
> Proxy the AttribIQ tracker and event endpoint through your own domain using CDN, framework, or reverse-proxy examples.
Canonical page: [https://attribiq.com/guides/first-party-tracker-proxy](https://attribiq.com/guides/first-party-tracker-proxy)
Category: Implementation Guides
Last updated: 2026-06-06
Topics: proxy, tracker, first party, cdn, nginx, vercel, cloudflare, netlify, nextjs
## Summary
A first-party proxy serves the tracker script and event endpoint from your own domain while forwarding requests to AttribIQ. It is available on Growth and higher plans. Proxy both paths, keep the browser snippet pointed at local paths, and preserve forwarded IP headers only through trusted proxy infrastructure.
## What this guide covers
- Choose local proxy paths
- Proxy the tracker script and event endpoint
- Install the proxied script tag
- Verify pageviews in Realtime
A first-party tracker proxy keeps the browser-facing AttribIQ paths on your own domain.
This setup is available on Growth and higher plans. Direct install remains available on every plan.
Open project settings, choose **First-party proxy**, and select your deployment platform. The dashboard generator fills in the install key and AttribIQ upstream URLs for the current project.
The direct install uses the AttribIQ edge domain:
```html
```
The proxied install uses local paths on your site:
```html
```
Your proxy then forwards those local paths to the project-specific AttribIQ upstream URLs.
## Content Security Policy
With a first-party proxy, the browser loads the script and sends events through your own site paths. For strict CSP deployments, the browser-facing AttribIQ requirement is normally covered by your existing first-party directives:
```http
script-src 'self';
connect-src 'self';
```
The proxy server still forwards to `https://edge.attribiq.com`, but that upstream request is not controlled by the browser's CSP.
## Generated values
Use the exact upstream URLs from project settings.
| Value | Example |
| --- | --- |
| Local script path | `/_aiq/s.js` |
| Local event path | `/_aiq/e` |
| Upstream script URL | `https://edge.attribiq.com/i/a7K4mN2qR8tP.js` |
| Upstream event URL | `https://edge.attribiq.com/i/a7K4mN2qR8tP/x` |
You can choose different local paths, but keep them stable after publishing. If you change them, update the script tag and the rewrites together.
## Vercel
Add rewrites in `vercel.json`.
```json
{
"rewrites": [
{
"source": "/_aiq/s.js",
"destination": "https://edge.attribiq.com/i/a7K4mN2qR8tP.js"
},
{
"source": "/_aiq/e",
"destination": "https://edge.attribiq.com/i/a7K4mN2qR8tP/x"
}
]
}
```
Vercel also supports reverse proxy rewrites to external destinations in `vercel.json`.
## Next.js
Use `rewrites()` in `next.config.js`.
```js
/** @type {import('next').NextConfig} */
const nextConfig = {
async rewrites() {
return [
{
source: "/_aiq/s.js",
destination: "https://edge.attribiq.com/i/a7K4mN2qR8tP.js"
},
{
source: "/_aiq/e",
destination: "https://edge.attribiq.com/i/a7K4mN2qR8tP/x"
}
]
}
}
module.exports = nextConfig
```
## Netlify
Add redirects in `_redirects`.
```text
/_aiq/s.js https://edge.attribiq.com/i/a7K4mN2qR8tP.js 200
/_aiq/e https://edge.attribiq.com/i/a7K4mN2qR8tP/x 200
```
## Cloudflare Worker
Create a Worker route for the two local paths. Use this for Cloudflare Workers or Cloudflare Pages projects that can route selected paths through a Worker.
```js
const upstream = {
"/_aiq/s.js": "https://edge.attribiq.com/i/a7K4mN2qR8tP.js",
"/_aiq/e": "https://edge.attribiq.com/i/a7K4mN2qR8tP/x"
}
export default {
async fetch(request) {
const url = new URL(request.url)
const target = upstream[url.pathname]
if (!target) return fetch(request)
const headers = new Headers(request.headers)
headers.delete("Cookie")
headers.set("Host", "edge.attribiq.com")
headers.set("X-Forwarded-For", request.headers.get("CF-Connecting-IP") || "")
const init = {
method: request.method,
headers,
redirect: "manual"
}
if (request.method !== "GET" && request.method !== "HEAD") {
init.body = request.body
}
return fetch(target, init)
}
}
```
## Express or Node
If your app server can handle proxy routes, keep the script and event paths explicit.
```js
import express from "express"
const app = express()
app.use("/_aiq/s.js", async (_req, res) => {
const upstream = await fetch("https://edge.attribiq.com/i/a7K4mN2qR8tP.js")
res.type("application/javascript")
res.send(await upstream.text())
})
app.use("/_aiq/e", express.text({ type: "*/*" }), async (req, res) => {
const upstream = await fetch("https://edge.attribiq.com/i/a7K4mN2qR8tP/x", {
method: req.method,
headers: {
"Content-Type": req.get("Content-Type") || "text/plain;charset=UTF-8",
"X-Forwarded-For": req.ip
},
body: req.body
})
res.status(upstream.status).send(await upstream.text())
})
```
## Nginx
Forward both paths and strip cookies.
```nginx
location = /_aiq/s.js {
proxy_set_header Host edge.attribiq.com;
proxy_set_header Cookie "";
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass https://edge.attribiq.com/i/a7K4mN2qR8tP.js;
}
location = /_aiq/e {
proxy_set_header Host edge.attribiq.com;
proxy_set_header Cookie "";
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass https://edge.attribiq.com/i/a7K4mN2qR8tP/x;
}
```
## Caddy
Use explicit handlers for the script and event paths.
```caddyfile
handle /_aiq/s.js {
rewrite * /i/a7K4mN2qR8tP.js
reverse_proxy https://edge.attribiq.com {
header_up Host edge.attribiq.com
header_up Cookie ""
}
}
handle /_aiq/e {
rewrite * /i/a7K4mN2qR8tP/x
reverse_proxy https://edge.attribiq.com {
header_up Host edge.attribiq.com
header_up Cookie ""
}
}
```
## Apache httpd
Enable `mod_proxy` and `mod_proxy_http`, then add explicit proxy rules to the virtual host.
```apache
ProxyPreserveHost Off
ProxyPass "/_aiq/s.js" "https://edge.attribiq.com/i/a7K4mN2qR8tP.js"
ProxyPassReverse "/_aiq/s.js" "https://edge.attribiq.com/i/a7K4mN2qR8tP.js"
ProxyPass "/_aiq/e" "https://edge.attribiq.com/i/a7K4mN2qR8tP/x"
ProxyPassReverse "/_aiq/e" "https://edge.attribiq.com/i/a7K4mN2qR8tP/x"
```
## Kubernetes ingress
Prefer a small internal proxy service, then route the local paths to that service with your ingress controller. This avoids relying on brittle per-path external-origin annotations.
```yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: attribiq-proxy
spec:
rules:
- host: www.example.com
http:
paths:
- path: /_aiq/s.js
pathType: Exact
backend:
service:
name: attribiq-proxy
port:
number: 8080
- path: /_aiq/e
pathType: Exact
backend:
service:
name: attribiq-proxy
port:
number: 8080
```
The internal proxy service should forward `/_aiq/s.js` to the upstream script URL and `/_aiq/e` to the upstream event URL.
## CloudFront
Use two cache behaviors for `/_aiq/s.js` and `/_aiq/e` with `edge.attribiq.com` as the custom origin. Configure the behavior for `/_aiq/e` to allow `POST` and avoid forwarding viewer cookies. Use an edge function only if you need to rewrite the request URI before the origin request.
## Forwarded IP headers
Preserve `X-Forwarded-For` through proxy infrastructure that you control. AttribIQ should only honor forwarded IP headers from trusted proxy networks. For a self-hosted collector, configure:
```env
TRUSTED_PROXY_CIDRS=127.0.0.1/32,10.0.0.0/8,172.16.0.0/12
TRUSTED_PROXY_DEPTH=1
```
Do not trust arbitrary browser-sent forwarding headers on a public collector.
## Platform references
- [Vercel rewrites](https://vercel.com/docs/rewrites)
- [Next.js rewrites](https://nextjs.org/docs/app/api-reference/config/next-config-js/rewrites)
- [Netlify rewrites and proxies](https://docs.netlify.com/routing/redirects/rewrites-proxies/)
- [Cloudflare Workers fetch](https://developers.cloudflare.com/workers/runtime-apis/fetch/)
- [Nginx reverse proxy](https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy)
- [Caddy reverse_proxy](https://caddyserver.com/docs/caddyfile/directives/reverse_proxy)
- [Apache mod_proxy](https://httpd.apache.org/docs/2.4/mod/mod_proxy.html)
- [CloudFront origin modification](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/helper-functions-origin-modification.html)
## Verify
After deploying:
1. Load `https://your-site.example/_aiq/s.js` and confirm it returns JavaScript.
2. Load a tracked page with the proxied script tag.
3. Open Realtime in AttribIQ and confirm the pageview appears.
4. Check that the project install key shows recent usage in settings.
Read [web tracker reference](https://attribiq.com/guides/web-tracker) for tracker fields and [Install AttribIQ](https://attribiq.com/guides/install-attribiq) for the checkout attribution flow.
## Frequently asked questions
### Is a first-party proxy required?
No. The direct project script is the default install. A proxy is useful when you want the browser to load the tracker from your own domain.
### Which paths should I use?
Use short, opaque paths such as /_aiq/s.js and /_aiq/e. Avoid obvious names such as analytics, tracking, stats, or pixel.
### Do I need to proxy both paths?
Yes. The script path loads the tracker. The event path receives pageviews, goals, and custom events.
### Should I forward cookies?
No. Strip or avoid forwarding cookies to AttribIQ unless you have a specific reason.
---
# Build and read a funnel
> Combine path and event steps into a funnel, measure conversion and drop-off, and investigate where visitors leave.
Canonical page: [https://attribiq.com/guides/build-and-read-funnels](https://attribiq.com/guides/build-and-read-funnels)
Category: Goals & Funnels
Last updated: 2026-09-08
Topics: funnels, goals, conversion, drop-off
## Summary
A funnel is an ordered sequence of path or event steps. Start with a small number of meaningful steps, then inspect the largest drop without assuming the step caused it.
## What this guide covers
- Choose useful funnel steps
- Interpret conversion and drop-off
- Inspect a funnel step
- Connect payment outcomes when available
A funnel measures how visitors progress through an ordered sequence of tracked paths or events.
## Choose the question first
Examples:
- Landing page → signup started → signup completed.
- Pricing page → checkout opened → payment completed.
- Documentation page → account created → first project created.
Choose steps that represent meaningful changes in intent. Avoid adding every click.
## Use path and event steps
A step can match a page path or a custom event.
Use a path when reaching a unique URL is sufficient. Use an event when the action happens in place or needs a precise trigger.
## Read the report
For each step, review:
- Visitors who reached the step.
- Conversion from the first step.
- Drop-off from the previous step.
- The largest absolute loss.
The largest drop is a prioritization signal, not proof of a cause.
## Inspect the step
When a step loses visitors:
1. Confirm the event or path is instrumented on every relevant route.
2. Compare device and source mix.
3. Check whether visitors can skip the step.
4. Review the date range around releases or campaign changes.
5. Test the experience directly.
## Add revenue when useful
A funnel works without a payment integration. When Stripe or Payment API events are connected, payment outcomes can add revenue context to the same journey.
Keep funnel completion and realized revenue separate. A completed checkout-start event is not the same as an accepted payment event.
## Next steps
Read [signup-to-paid funnel tracking](https://attribiq.com/guides/signup-to-paid-funnel) for a SaaS example or [connect Stripe](https://attribiq.com/guides/connect-stripe-to-attribiq) for payment events.
## Frequently asked questions
### How many steps should a funnel have?
Use the smallest sequence that represents the decision you need to understand. Extra implementation steps can make the report noisy.
### Does drop-off prove a page is broken?
No. Visitors can leave because of intent, timing, eligibility, technical problems, or tracking gaps. Use the step as a place to investigate.
---
# Read country and device reports responsibly
> Use country and device breakdowns to investigate traffic and conversion while accounting for small samples and derived context.
Canonical page: [https://attribiq.com/guides/country-and-device-reports](https://attribiq.com/guides/country-and-device-reports)
Category: Web Analytics
Last updated: 2026-09-08
Topics: countries, devices, audience, privacy
## Summary
Country and device rows are useful for broad patterns, quality checks, and experience testing. They are derived dimensions, not verified facts about a person.
## What this guide covers
- Use country reports
- Use device reports
- Avoid small-sample conclusions
- Connect findings to testing
Audience breakdowns add context to traffic, content, goal, funnel, and revenue reports.
Use them for broad patterns and quality checks, not for identifying people.
## Country reports
Country-level context can help with:
- Finding unexpected traffic spikes.
- Reviewing regional campaign reach.
- Prioritizing language or localization research.
- Checking whether a launch reached its intended market.
Country is not a verified residence. VPNs, relays, proxies, corporate networks, and mobile routing can change the derived location.
## Device reports
Device categories help compare desktop, mobile, tablet, and other recorded device types.
Use device data to locate experiences worth testing. For example, a large mobile audience with weak funnel progression is a reason to inspect the mobile flow, not automatic proof that the device caused the difference.
## Watch sample size
A segment with two conversions from ten visitors has a 20% conversion rate, but it is not more reliable than a segment with hundreds of visits.
Read the visitor count beside any rate and compare a sufficiently long period.
## Connect the breakdown to action
When a row looks unusual:
1. Confirm the traffic volume.
2. Compare its sources and landing pages.
3. Review relevant goals and funnel steps.
4. Test the site on the device class or from the region where practical.
5. Check whether tracking coverage differs.
## Next steps
Use [traffic sources and referrers](https://attribiq.com/guides/traffic-sources-referrers) to understand acquisition mix or [build a funnel](https://attribiq.com/guides/build-and-read-funnels) to compare progression.
## Frequently asked questions
### Is country the visitor's home country?
No. It is country-level context derived for the recorded request and can be affected by VPNs, relays, proxies, and network routing.
### Should I optimize for the highest-converting device immediately?
Check traffic volume, source mix, and the actual experience first. Small samples can create unstable rates.
---
# What is revenue attribution?
> Revenue attribution connects visits, UTMs, campaigns, landing pages, sessions, and payment events to paid accounts.
Canonical page: [https://attribiq.com/guides/what-is-revenue-attribution](https://attribiq.com/guides/what-is-revenue-attribution)
Category: Revenue Attribution
Last updated: 2026-05-20
Topics: revenue attribution, saas analytics, campaign reporting
## Summary
Revenue attribution answers a money question: where did paid accounts come from? Instead of stopping at pageviews or signups, it connects the visit and campaign history to purchases, subscriptions, renewals, refunds, and churn.
## What this guide covers
- Understand the difference between traffic analytics and revenue attribution
- Learn why payment events need visitor and session identifiers
- Compare first-touch, last-touch, and session-touch models
- Know which attribution reports are useful for SaaS builders
Revenue attribution is the practice of connecting revenue events back to the visits and marketing context that happened before the payment.
For a SaaS product, the revenue event might be a new subscription, renewal, upgrade, refund, cancellation, or churn event. The earlier context might be the first landing page, the session source, a UTM campaign, a pricing page view, or a signup event.
The useful question is not "how many people visited the site?" It is "which sources produced customers who paid?"
## Why normal analytics stops too early
Traffic analytics can tell you that 2,000 visitors came from search, 600 came from a newsletter, and 200 clicked a paid campaign. That is useful, but it can be misleading when the conversion you care about is paid revenue.
A campaign with low visit volume can produce high-value customers. A page with many visits can produce no revenue. A channel can create signups that never become paid accounts.
Revenue attribution fixes the reporting gap by joining two datasets:
1. Analytics events from the browser, such as pageviews, sessions, referrers, UTMs, and goals.
2. Payment events from Stripe or another payment system, such as purchases, subscription starts, renewals, refunds, and churn.
The bridge is an identifier. AttribIQ uses visitor and session identifiers from the tracker, then carries those identifiers into checkout metadata or the generic Payment API.
## The core attribution models
First-touch attribution gives credit to the earliest known source for a visitor. This is useful when you want to know which acquisition channels introduced customers to the product.
Last-touch attribution gives credit to the latest known source before payment. This is useful when you want to know which campaign or page closed the conversion.
Session-touch attribution gives credit to the active session where the revenue event happened. This is useful for short buying journeys, trial upgrades, and checkout behavior.
None of these models is always right. The practical move is to show them side by side and explain what each one means.
## Reports that matter
The most useful early reports are:
- Revenue by source.
- Revenue by UTM campaign.
- Revenue by landing page.
- Revenue by referrer.
- Revenue by first page and checkout path.
- Revenue by signup-to-paid funnel step.
- Refunds and churn by source.
These reports help answer operational questions. Which content should you write more of? Which campaign should you pause? Which landing page brings customers who renew? Which source creates refunds?
## What to avoid
Avoid treating attribution as perfect truth. Browser privacy features, cross-device journeys, private sharing, consent choices, payment processor redirects, and long sales cycles can all hide parts of the path.
Good attribution software should make the model visible. If a report credits direct traffic, you should know whether direct really was the first known source or whether it appeared after a known campaign. If a renewal is attributed to an original campaign, the report should make that rule clear.
## How AttribIQ approaches it
AttribIQ starts with simple EU-hosted analytics. It then connects payment events through Stripe webhooks or the generic Payment API. The product keeps first-touch, last-touch, and session-touch attribution separate so builders can read revenue without pretending the model is more precise than it is.
Start with [Install AttribIQ](https://attribiq.com/guides/install-attribiq), then read [how Stripe revenue attribution works](https://attribiq.com/guides/stripe-revenue-attribution) when you are ready to connect payments.
## Frequently asked questions
### Is revenue attribution the same as web analytics?
No. Web analytics measures visits, pages, referrers, events, and goals. Revenue attribution connects those signals to payment events so you can report money by source, campaign, landing page, and path.
### Can attribution prove exactly why someone bought?
No. Attribution is a useful reporting model, not perfect causality. It helps you compare sources consistently, but it cannot know every offline influence or private browser journey.
### Which attribution model should a small SaaS start with?
Start with first-touch, last-touch, and session-touch. They are simple enough to explain and good enough to spot useful acquisition patterns before moving into complex multi-touch models.
### Does Stripe provide revenue attribution by itself?
Stripe records payments and subscriptions. It does not know the visitor source, landing page, or UTM campaign unless you pass that context into Stripe metadata or connect it through an attribution system.
---
# What is conversion rate?
> Conversion rate is the percentage of visitors, sessions, leads, or users who complete a desired action such as signup, checkout, or payment.
Canonical page: [https://attribiq.com/guides/what-is-conversion-rate](https://attribiq.com/guides/what-is-conversion-rate)
Category: Analytics Fundamentals
Last updated: 2026-06-25
Topics: conversion rate, saas metrics, funnels, analytics
## Summary
Conversion rate is completed actions divided by the eligible audience. For SaaS teams, it is most useful when each funnel step is defined clearly and connected to revenue quality.
## What this guide covers
- Define conversion rate
- Calculate common SaaS conversion rates
- Avoid misleading conversion rate comparisons
- Connect conversion rate to revenue
Conversion rate is the percentage of people or sessions that complete a desired action.
The action can be a signup, demo request, trial start, checkout, purchase, upgrade, or renewal. The denominator should match the question you are asking.
```txt
conversion rate = conversions / eligible audience * 100
```
If 1,000 visitors land on a page and 50 sign up, the visitor-to-signup conversion rate is 5%.
## Common SaaS conversion rates
SaaS teams often track:
- Visitor-to-signup conversion rate.
- Signup-to-activation conversion rate.
- Trial-to-paid conversion rate.
- Signup-to-paid conversion rate.
- Checkout-started-to-paid conversion rate.
- Paid-to-renewed conversion rate.
Each one answers a different question. Do not collapse every funnel problem into one headline number.
## Why conversion rate can mislead
Conversion rate can improve while revenue gets worse.
For example, a campaign can attract many low-intent users who sign up because the offer is broad, but few of them pay. Another campaign can bring fewer visitors, lower signup conversion, and much higher revenue.
That is why SaaS teams should read conversion rate with:
- Revenue per visitor.
- Paid conversion rate.
- Average revenue per account.
- Refund rate.
- Churn rate.
- Source and campaign.
## Segment before comparing
A single site-wide conversion rate is rarely enough. Segment conversion by source, campaign, landing page, device, country, and returning vs new visitors.
Organic search visitors reading a learning article may convert differently from paid search visitors landing on a pricing page. That does not mean one page is broken. It may mean the intent is different.
## Conversion rate and revenue attribution
Revenue attribution makes conversion rate more useful because it shows what happened after the conversion.
Instead of only asking which landing page created signups, you can ask which landing page created paid accounts, renewals, and retained revenue.
That helps avoid optimizing for the wrong step.
## Next steps
Read [signup-to-paid funnel tracking](https://attribiq.com/guides/signup-to-paid-funnel) to connect conversion steps across the SaaS funnel. Use [landing page revenue attribution](https://attribiq.com/guides/landing-page-revenue-attribution) when you want to compare pages by revenue instead of visits.
## Frequently asked questions
### How do you calculate conversion rate?
Divide the number of conversions by the eligible audience, then multiply by 100. For example, 50 signups from 1,000 visitors is a 5% visitor-to-signup conversion rate.
### What is a good conversion rate?
It depends on traffic source, product category, price, intent, and funnel step. Compare conversion rates within the same funnel and segment before comparing against broad benchmarks.
### Is signup conversion rate enough?
No. A source can create many signups and little revenue. SaaS teams should also measure trial-to-paid, signup-to-paid, and revenue per visitor.
### Should conversion rate use users or sessions?
Use the denominator that matches the question. Landing page conversion often uses sessions or visitors; product activation often uses users; paid conversion often uses trials or signups.
---
# What is marketing attribution?
> Marketing attribution explains which channels, campaigns, ads, pages, and touchpoints influenced a signup, purchase, or subscription.
Canonical page: [https://attribiq.com/guides/what-is-marketing-attribution](https://attribiq.com/guides/what-is-marketing-attribution)
Category: Revenue Attribution
Last updated: 2026-06-25
Topics: marketing attribution, attribution models, campaign reporting, saas analytics
## Summary
Marketing attribution is the practice of assigning credit for a conversion to the marketing touchpoints that happened before it. For SaaS teams, attribution becomes more useful when it connects those touchpoints to revenue, not only signups.
## What this guide covers
- Understand what marketing attribution means
- Compare marketing attribution with revenue attribution
- Know the common attribution models
- Avoid common attribution mistakes
Marketing attribution is the practice of deciding which marketing touchpoints get credit for a conversion.
The touchpoint might be a Google search, newsletter click, paid ad, partner referral, product launch, social post, or blog visit. The conversion might be a signup, demo request, trial start, checkout, or paid subscription.
The point is to answer a practical question: where did this customer come from?
## Why attribution matters
Without attribution, most teams optimize for the easiest numbers to count. They rank pages by traffic, campaigns by clicks, and channels by signups.
That can hide the real outcome. A campaign can bring many visitors and few customers. A quiet partner referral can produce fewer signups but better accounts. A landing page can look small in traffic reports and still produce high-value subscriptions.
Marketing attribution gives you a rule for connecting the earlier touchpoints to the later result.
## Common attribution models
The common models are:
- First-touch attribution, which credits the first known source.
- Last-touch attribution, which credits the last known source before conversion.
- Session-touch attribution, which credits the session where the conversion happened.
- Linear attribution, which splits credit evenly across known touchpoints.
- Position-based attribution, which gives more credit to first and last touches.
Small SaaS teams should usually start with first-touch, last-touch, and session-touch. They are easier to explain and easier to audit.
## Marketing attribution vs revenue attribution
Marketing attribution often stops at form fills, leads, trials, or signups. Revenue attribution goes further.
For SaaS, the useful question is not only which campaign created a signup. It is whether that signup became a paying customer, renewed, refunded, upgraded, or churned.
That requires joining two paths:
1. The marketing path: source, campaign, landing page, referrer, and signup.
2. The payment path: checkout, subscription, invoice, renewal, refund, and churn.
The bridge is usually an attribution identifier passed into checkout or stored with the customer record.
## What attribution cannot prove
Attribution cannot prove why a person bought. It can only apply a consistent reporting rule to the data you have.
Some visits are private. Some referrers are missing. People move across devices. Paid clicks and organic searches can both influence the same account. Direct traffic can appear after a campaign introduced the customer.
Good attribution reports show these limits instead of hiding them. They should make direct traffic, unattributed revenue, and missing checkout metadata visible.
## How to start
Start with a small set of revenue reports:
- Revenue by source.
- Revenue by UTM campaign.
- Revenue by landing page.
- First-touch vs last-touch revenue.
- Unattributed revenue.
Then add more detail only when a real decision requires it.
Read [what revenue attribution means](https://attribiq.com/guides/what-is-revenue-attribution) for the payment-aware version, then compare [first-touch vs last-touch attribution](https://attribiq.com/guides/first-touch-vs-last-touch-attribution).
## Frequently asked questions
### Is marketing attribution the same as revenue attribution?
Not exactly. Marketing attribution can stop at leads, signups, trials, or purchases. Revenue attribution specifically connects marketing touchpoints to payment events, renewals, refunds, and churn.
### What is the simplest attribution model?
First-touch and last-touch attribution are usually the simplest models. First-touch credits the first known source, while last-touch credits the last known source before conversion.
### Can marketing attribution be perfect?
No. Browser privacy features, private sharing, missing referrers, long sales cycles, and cross-device behavior all create gaps. Attribution is a consistent reporting model, not perfect proof.
### What should a SaaS team attribute?
Start with paid conversions and revenue by source, campaign, landing page, and signup path. Signups are useful, but revenue tells you whether the channel creates customers.
---
# What is a webhook?
> A webhook is an HTTP callback one system sends to another when an event happens, such as a payment, signup, invoice, refund, or subscription change.
Canonical page: [https://attribiq.com/guides/what-is-a-webhook](https://attribiq.com/guides/what-is-a-webhook)
Category: Analytics Fundamentals
Last updated: 2026-06-25
Topics: webhook, api, payment events, automation, saas
## Summary
A webhook is an event notification sent from one system to another over HTTP. In SaaS analytics, webhooks are often how payment providers send reliable revenue, subscription, refund, and churn events to your backend.
## What this guide covers
- Understand what webhooks are
- Compare webhooks with polling
- Know common SaaS webhook use cases
- Use webhooks safely for revenue events
A webhook is an HTTP callback sent by one system to another when an event happens.
Instead of your app repeatedly asking "did anything change?", the other system sends a request when there is something to report.
For example, a payment provider can send a webhook when a customer pays an invoice, starts a subscription, receives a refund, or cancels.
## Webhook example
A webhook flow looks like this:
```txt
event happens -> provider sends HTTP request -> your backend processes the event
```
The request usually contains event data in JSON. Your backend verifies the request, records the event, and returns a successful response.
## Webhooks vs polling
Polling means your app asks another API for updates on a schedule.
Webhooks are event-driven. They are usually better when you need to react quickly to changes, such as payments, signups, failed invoices, support events, or deployment notifications.
Polling can still be useful for reconciliation, but webhooks are usually the primary path for payment lifecycle events.
## Common webhook use cases
SaaS teams use webhooks for:
- Payment completed.
- Invoice paid.
- Subscription updated.
- Subscription cancelled.
- Refund created.
- Trial started.
- User invited.
- Form submitted.
- Lead created.
- Deployment finished.
For revenue analytics, payment webhooks are especially important because they provide a backend source of truth.
## Webhook safety basics
Webhook endpoints should:
- Verify signatures from the provider.
- Process events idempotently.
- Store the provider event ID.
- Return success only after safe processing.
- Retry internal work when downstream systems fail.
- Avoid trusting browser-only payment events as revenue.
Idempotency matters because providers can retry the same webhook. Your system should not create duplicate revenue if the same event arrives twice.
## Webhooks and attribution
Webhooks tell you that a payment happened. They do not automatically tell you which campaign, page, or source created the customer.
For attribution, your checkout flow needs to pass a visitor or session identifier into the payment system before the webhook arrives. Then the webhook processor can connect payment data back to analytics context.
Read [what a Stripe webhook is](https://attribiq.com/guides/what-is-a-stripe-webhook) for a payment-specific example, then use [Stripe webhook revenue events](https://attribiq.com/guides/stripe-webhook-revenue-events) when you are ready to map events into reports.
## Frequently asked questions
### What is a webhook in simple terms?
A webhook is an automated message one app sends to another app when something happens.
### How is a webhook different from an API request?
An API request is usually made when your app asks for data. A webhook is sent when another system notifies your app that an event happened.
### Are webhooks reliable?
Good webhook providers retry failed deliveries, but your endpoint still needs signature verification, idempotency, and error handling.
### Why do payment providers use webhooks?
Payment state changes after checkout. Webhooks let your backend receive completed payments, renewals, refunds, cancellations, and failed payment events without relying on the browser.
---
# AI referral attribution methodology
> How an identifiable AI referrer or campaign signal can connect a known visit to a matched payment, and what missing signals cannot establish.
Canonical page: [https://attribiq.com/guides/ai-referral-attribution-methodology](https://attribiq.com/guides/ai-referral-attribution-methodology)
Category: Revenue Attribution
Last updated: 2026-09-02
Topics: AI referral attribution, AI referral traffic, referrer evidence, attribution limits
## Summary
AttribIQ classifies reviewed AI-provider referrers and, when enabled, trusted campaign sources. Revenue is reported only when the resulting visit connects to a payment through a known visitor or session ID. Missing traffic, prompt mentions, citations and visibility estimates do not receive revenue credit.
## What this guide covers
- Understand what counts as an observed AI referral
- Distinguish AI-sourced revenue from an earlier AI touch
- Understand why AI visibility is not revenue evidence
- Recognize the limits of missing and dark referral traffic
AI referral attribution connects a visit with an identifiable referrer or campaign signal to a later matched payment. It answers a narrow question: did a visible referral reach the site and remain connected through checkout?
The method starts with evidence from the visit. It does not start with prompt monitoring, a visibility score, or a guess about which answer influenced a purchase.
## What counts as an observed AI referral
An observed AI referral requires a signal attached to a real visit. AttribIQ currently classifies:
- a browser referrer hostname that matches the versioned registry of reviewed AI-provider domains; or
- an explicit campaign source that matches a reviewed provider rule when trusted campaign classification is enabled.
AttribIQ's web tracker records referrer, source, UTM, landing-page, visitor, and session context. The classifier maps reviewed domains to providers and records the matched rule and classifier version. Referral hosts outside the registry remain available in the retained traffic data but are not automatically counted as AI traffic.
Provider referrer behavior can change, and some assistants do not send a stable referrer. A platform name alone is not sufficient evidence.
## How visits connect to payment revenue
The browser journey and payment system are separate until an identifier connects them.
1. The tracker records the observed visit and creates visitor and session identifiers.
2. The site passes those identifiers into checkout or its billing record.
3. Stripe webhooks or the generic Payment API send the payment event to AttribIQ.
4. AttribIQ joins the payment to the known journey and applies the selected attribution model.
5. Refund and churn events adjust the revenue reports according to the existing payment-event rules.
Read the [browser attribution API](https://attribiq.com/guides/browser-attribution-api) for the client-side context and the [Payment API reference](https://attribiq.com/guides/payment-api-reference) for server-side revenue events.
## AI-sourced revenue and earlier AI touches
AI-sourced revenue means the selected attribution touch for a payment carries verified AI-source evidence under the active attribution model. A first-touch model and a last-touch model can select different sources for the same journey, so the model must remain visible.
An earlier AI touch means the same known journey includes an observed AI visit, but another source is selected for the payment. AttribIQ reports those mutually exclusive events as assisted AI revenue, separately from direct AI revenue, so one payment is not counted in both totals.
This distinction prevents double counting. One payment should not silently appear as both fully AI-sourced and fully sourced to another channel.
## Observed traffic versus modeled visibility
AI visibility products can monitor prompts, brand mentions, citations, or estimated share of voice. Those records describe model outputs, not site visitors.
AttribIQ does not give revenue credit to a mention, citation, or visibility estimate. Those records can be useful research, but only a separate observed visit matched through supported journey identifiers becomes revenue evidence here.
This is also why AttribIQ is not a general-purpose product analytics suite or a prompt-monitoring index. Its documented role is connecting acquisition context and customer journeys to payment outcomes.
## Unknown and dark AI traffic
Not every AI-influenced visit is observable. Referral information may disappear when someone:
- opens a link in a private or embedded browser;
- copies a URL from an answer into another browser;
- moves from one device to another;
- uses an assistant that does not send a referrer;
- follows a redirect that strips campaign context; or
- declines or blocks the local tracking needed for the journey.
This traffic can appear direct or unknown. AttribIQ does not classify it as AI traffic without another explicit, supported signal. “Dark AI” is therefore a limitation to document, not a number to manufacture.
## Important reporting limitations
- Attribution is a consistent reporting model, not proof that a source caused a purchase.
- Ordinary `google.com` referrals remain search traffic unless a distinct supported signal identifies an AI feature.
- Referrer hosts and campaign markers should be reviewed when providers change their link behavior.
- Cross-device and privacy-restricted journeys may remain unmatched.
- Unlike currencies should not be summed unless the report has a supported conversion method.
- EU hosting and privacy-minimizing product choices are not legal guarantees.
For the product scope, see [AI referral revenue attribution](https://attribiq.com/ai-revenue-attribution). For the broader model, read [What is revenue attribution?](https://attribiq.com/guides/what-is-revenue-attribution).
## Frequently asked questions
### Can AttribIQ measure revenue from AI referral traffic?
It can connect revenue when a visit matches a reviewed provider referrer or trusted campaign rule and the later payment carries the AttribIQ visitor or session identifier. Missing referral evidence cannot be reconstructed reliably.
### Does an AI mention or citation receive revenue credit?
No. A mention, citation, or modeled visibility record is not a visitor journey. It must remain separate unless a real observed visit can be matched through supported evidence.
### Is ordinary Google traffic classified as AI traffic?
No. An ordinary google.com referral is search traffic unless a separate, supported signal identifies an AI search experience. AttribIQ does not infer that distinction from a normal Google referral.
### Can AttribIQ identify all dark AI traffic?
No. Some assistants, apps, privacy tools, copied links, and cross-device journeys omit referral evidence. That traffic may appear direct or unknown and should not be relabeled without a supported signal.
---
# How to track Stripe revenue by source and campaign
> Connect Stripe Checkout, subscriptions, invoices, refunds, and webhooks to source, campaign, landing page, and session reports.
Canonical page: [https://attribiq.com/guides/stripe-revenue-attribution](https://attribiq.com/guides/stripe-revenue-attribution)
Category: Stripe & Payments
Last updated: 2026-10-02
Topics: stripe, revenue attribution, subscriptions, metadata
## Summary
Stripe knows the payment, customer, subscription, invoice, and refund. To attribute that revenue, your app must also pass the visitor and session context that existed before checkout. The safest pattern is to copy AttribIQ identifiers into Checkout Session metadata and subscription metadata, then process Stripe webhooks idempotently.
## What this guide covers
- Understand which Stripe objects matter for attribution
- Know why metadata is copied onto checkout and subscription objects
- Map Stripe webhook events into normalized revenue events
- Avoid common attribution mistakes around renewals and refunds
Stripe revenue attribution connects Stripe's payment lifecycle to the visits and campaigns that happened before the customer paid.
Stripe is the source for the money event. AttribIQ is the source for the browser and campaign context. The integration works when your app carries AttribIQ identifiers into Stripe metadata before checkout starts.
Start with a working [web analytics installation](https://attribiq.com/guides/install-attribiq). Confirm that a visit appears in Realtime and that its [traffic source](https://attribiq.com/guides/traffic-sources-referrers) and [landing page](https://attribiq.com/guides/content-and-landing-pages) are correct. These reports are useful before you connect payments; they also give you the acquisition context to validate against later.
If you are evaluating the product, see [Stripe revenue attribution software](https://attribiq.com/stripe-revenue-attribution). If you need purchases inside Google Analytics, use the separate [Stripe and GA4 integration tutorial](https://attribiq.com/guides/stripe-google-analytics-integration).
Stripe documents Checkout Sessions, metadata, and subscription webhooks in its official docs: [Checkout Sessions](https://docs.stripe.com/api/checkout/sessions), [metadata](https://docs.stripe.com/metadata), and [subscription webhooks](https://docs.stripe.com/billing/subscriptions/webhooks).
## The objects that matter
For a subscription SaaS product, these Stripe objects usually matter:
- Checkout Session for the initial checkout attempt.
- Customer for the paying account in Stripe.
- Subscription for recurring billing state.
- Invoice for renewals and failed payments.
- Charge or PaymentIntent for payment settlement and refunds.
The key mistake is only thinking about the first payment. If you want revenue by campaign, you also need to decide how renewals, upgrades, downgrades, refunds, cancellations, and churn should inherit or change attribution.
## The metadata bridge
The browser tracker knows the AttribIQ project, visitor, and session. Before checkout, your frontend sends that attribution object to your backend.
```js
const attribution = window.attribiq?.getAttribution?.() ?? null
await fetch("/api/create-checkout-session", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({ price_id: "price_123", attribution })
})
```
The backend copies that context into Stripe. This example shows the attribution fields inside an existing authenticated Checkout handler. Resolve the allowed price and the project ID on your server; validate the visitor and session IDs before using them. The browser must not decide which account or project receives revenue.
```js
const metadata = attribution?.visitor_id && attribution?.session_id
? {
attribiq_project_id: projectId,
attribiq_visitor_id: attribution.visitor_id,
attribiq_session_id: attribution.session_id
}
: {}
const session = await stripe.checkout.sessions.create({
mode: "subscription",
line_items: [{ price: priceId, quantity: 1 }],
success_url: "https://example.com/billing/success?session_id={CHECKOUT_SESSION_ID}",
cancel_url: "https://example.com/pricing",
client_reference_id: attribution?.visitor_id || undefined,
metadata,
subscription_data: { metadata }
})
```
Copying metadata to both places matters. The Checkout Session helps with the first conversion. Subscription metadata helps with future invoice and subscription events.
Attribution is optional context, so a blocked tracker or unavailable browser identifier must not stop a customer from paying. Omit missing fields and keep that payment unattributed. Do not manufacture visitor IDs, put email addresses into metadata as analytics identifiers, or assume that identifiers survive a new device or every later visit. Respect the collection and consent settings used on your site.
## Choose the ingestion path
There are two Stripe ingestion paths.
For most teams, Stripe should send selected webhook events directly to AttribIQ's native receiver. AttribIQ verifies the Stripe signature when the endpoint secret is configured, ignores duplicate Stripe event IDs, extracts the AttribIQ metadata, writes the revenue event, and runs attribution.
Use a customer-owned relay only when your backend needs to normalize custom billing semantics before AttribIQ receives the event. In that path, your webhook handler should:
1. Verify the Stripe webhook signature.
2. Store the Stripe event ID and reject duplicate deliveries.
3. Extract AttribIQ metadata from the event object.
4. Normalize the event into purchase, subscription_started, renewal, upgrade, downgrade, refund, cancellation, or churn.
5. Use Stripe object IDs for idempotency.
6. Send the normalized revenue event to `POST /v1/revenue`.
Do not rely on redirect success pages as the source of truth. They are useful for UI, but webhooks are the reliable payment lifecycle feed.
## Attribution rules for renewals
Most SaaS teams attribute renewals back to the original acquisition source unless they have a reason to model expansion separately. That makes reports like "MRR by campaign" stable and understandable.
Refunds should subtract from the attributed source that received the original credit. Churn should be visible by source too. A campaign that creates many initial purchases but high refunds may be worse than a quieter channel with stronger retention.
## Worked example: campaign to renewal and refund
The following is an illustrative EUR subscription journey, not a customer result. Use one attribution model and one reporting currency when comparing the rows.
| Step | Evidence to retain | Expected reporting outcome |
| --- | --- | --- |
| A visitor lands on `/pricing?utm_source=newsletter&utm_medium=email&utm_campaign=autumn` | Source, campaign, landing page, visitor and session IDs | A newsletter visit in web analytics, with no revenue yet |
| The visitor signs up and starts Checkout | Signup event plus the same IDs on Checkout and subscription metadata | A goal conversion and a checkout handoff |
| Stripe confirms the first €49 invoice | Paid invoice ID, amount, currency and attribution metadata | One €49 revenue event assigned to the known journey |
| Stripe delivers that webhook again | The same Stripe event ID | No second revenue event |
| A later €49 renewal is paid | A new invoice ID and the subscription's acquisition identifiers | Another €49, using the configured attribution model |
| €10 of that renewal is refunded | Refund ID and a link to the original payment | A €10 reduction against the credited journey |
The payment amounts in this example total €88 after the refund. That is a payment reporting example, not an MRR calculation or accounting definition of net revenue. A failed renewal adds no paid revenue. An unmatched payment still belongs in payment totals, with its missing attribution visible.
Read [UTM revenue attribution](https://attribiq.com/guides/utm-revenue-attribution) for campaign naming and [first-touch, last-touch and session-touch attribution](https://attribiq.com/guides/first-touch-vs-last-touch-attribution) before interpreting the channel totals.
## Validate the complete journey
Use a separate test project and Stripe test mode before connecting production payments. Keep your endpoint secret on the server and verify signatures against the unmodified request body, as described in [Stripe's webhook documentation](https://docs.stripe.com/webhooks).
1. Open a tagged campaign URL and verify its source, campaign and landing page in AttribIQ.
2. Complete a test checkout. Inspect its Checkout Session and subscription for the expected metadata keys.
3. Inspect the paid invoice webhook and confirm one payment record with the correct currency and amount. Check both the source report and unmatched revenue.
4. Resend the same event from Stripe. The recorded payment total must remain unchanged.
5. Exercise a renewal and a refund. Verify their object IDs and how they change the original journey's revenue.
6. Repeat with attribution unavailable. Payment ingestion should still work, with the payment shown as unmatched.
If you receive both Checkout and invoice events, choose one payment record for each billing transaction. An invoice and its Checkout Session can describe the same first charge; different webhook event IDs alone do not prove that two payments occurred.
## Diagnose missing attribution
| Symptom | First check |
| --- | --- |
| Payment is present but source is empty | Compare the metadata IDs with the actual tracked visitor and session |
| First payment matches but renewals do not | Confirm subscription metadata and inspect the renewal invoice payload |
| Revenue appears twice | Check both webhook redelivery handling and Checkout-versus-invoice overlap |
| Campaign differs from your expectation | Check the selected attribution model, UTM spelling and the observed journey |
| Stripe total differs from the report | Align dates, timezone, currencies, refund treatment and supported event types |
Do not repair missing evidence by guessing a source. Use the [unattributed revenue calculator](https://attribiq.com/tools/unattributed-revenue-calculator) to understand the size of the gap, then fix the checkout handoff for future payments.
## Next steps
Start with [passing attribution into Stripe Checkout](https://attribiq.com/guides/pass-attribution-to-stripe-checkout), then [connect Stripe to AttribIQ](https://attribiq.com/guides/connect-stripe-to-attribiq). If you do not use Stripe or need a custom relay, use the [generic Payment API guide](https://attribiq.com/guides/generic-payment-api-revenue-tracking).
## Frequently asked questions
### Which Stripe events should I start with?
For the native AttribIQ receiver, start with invoice.paid, charge.refunded, and customer.subscription.deleted. Add checkout.session.completed and customer.subscription.updated only after you confirm those events match your billing model.
### Should metadata live only on the Checkout Session?
No. Checkout metadata is useful for the first purchase, but subscription renewals and lifecycle changes need metadata on the subscription too.
### Can I use client_reference_id for attribution?
You can use it as a reconciliation pointer, but you should still copy explicit attribution identifiers into metadata so webhook processing is clear and extensible.
### What if some Stripe events arrive without attribution metadata?
Store and process them as unattributed revenue rather than dropping them. Missing attribution is a data quality issue, not a reason to lose revenue records.
---
# What is a Stripe webhook?
> A Stripe webhook is an HTTP notification Stripe sends to your backend when payments, subscriptions, invoices, refunds, and customer events happen.
Canonical page: [https://attribiq.com/guides/what-is-a-stripe-webhook](https://attribiq.com/guides/what-is-a-stripe-webhook)
Category: Stripe & Payments
Last updated: 2026-06-25
Topics: stripe webhook, webhooks, stripe, payment events, subscriptions
## Summary
A Stripe webhook is a server-to-server event notification. For revenue attribution, webhooks are the reliable way to receive payment, subscription, renewal, refund, and churn events after checkout.
## What this guide covers
- Understand what Stripe webhooks do
- Know which webhook events matter for SaaS revenue
- Learn why webhooks are safer than success pages
- Connect webhook events to attribution metadata
A Stripe webhook is an HTTP request Stripe sends to your backend when something happens in Stripe.
For example, Stripe can send a webhook when a Checkout Session completes, an invoice is paid, a subscription changes, or a charge is refunded.
Webhooks let your backend react to payments without relying on the customer's browser.
## Why webhooks matter
A checkout success page is not a reliable source of truth. The customer can close the tab, lose connection, block scripts, or never return from the payment page.
Stripe webhooks are server-to-server notifications. They are designed for backend workflows such as:
- Marking an account as paid.
- Recording a subscription start.
- Processing renewals.
- Recording refunds.
- Updating subscription status.
- Syncing revenue into analytics.
For attribution, the webhook is where payment data becomes reportable revenue.
## Common Stripe webhook events
SaaS teams usually start with:
- `checkout.session.completed` for completed Checkout Sessions.
- `invoice.paid` for subscription invoices and renewals.
- `customer.subscription.updated` for plan changes and status changes.
- `customer.subscription.deleted` for cancellations.
- `charge.refunded` for refunds.
You do not need to process every Stripe event on day one. Start with the events that change revenue or subscription state.
## Webhooks and attribution metadata
Stripe knows the payment object, customer, invoice, subscription, amount, currency, and status. It does not automatically know the visitor source, campaign, landing page, or session that led to checkout.
That bridge has to be created before checkout. Your app should read the attribution context from the browser, send it to your backend, and copy stable identifiers into Stripe metadata.
When the webhook arrives, your backend can extract that metadata and connect the payment event to the earlier visit.
## Security basics
Webhook endpoints should verify Stripe signatures. They should also process events idempotently because webhook delivery can be retried.
Idempotency means that if the same Stripe event arrives twice, your system records it once.
Do not trust arbitrary client-side payment messages as revenue. Treat Stripe webhooks as the authoritative payment lifecycle feed.
## Next steps
Read [Stripe webhook revenue events](https://attribiq.com/guides/stripe-webhook-revenue-events) for the implementation workflow. If you are using Checkout, start with [how to pass attribution to Stripe Checkout](https://attribiq.com/guides/pass-attribution-to-stripe-checkout).
## Frequently asked questions
### Is a Stripe webhook required for revenue attribution?
For reliable Stripe revenue attribution, yes. Checkout success pages can be missed, but webhooks are designed to notify your backend when payment lifecycle events happen.
### Which Stripe webhook event should I start with?
For simple Checkout flows, start with checkout.session.completed. For subscriptions, also process invoice.paid, customer.subscription.updated, customer.subscription.deleted, and charge.refunded.
### Can a webhook be delivered more than once?
Yes. Webhook processors should be idempotent so a retried event does not create duplicate revenue.
### Where does attribution metadata come from?
Your app should copy attribution identifiers into Checkout Session metadata and subscription metadata before Stripe sends webhook events.
---
# What is checkout attribution?
> Checkout attribution connects the visit, campaign, landing page, and session before checkout to the payment event that happens after checkout.
Canonical page: [https://attribiq.com/guides/what-is-checkout-attribution](https://attribiq.com/guides/what-is-checkout-attribution)
Category: Stripe & Payments
Last updated: 2026-06-25
Topics: checkout attribution, stripe checkout, revenue attribution, payment metadata
## Summary
Checkout attribution is the bridge between marketing analytics and payment data. It passes stable visitor or session identifiers into checkout so completed payments can be connected back to source, campaign, and landing page.
## What this guide covers
- Understand the checkout attribution bridge
- Know what data should be passed before checkout
- Avoid relying only on success pages
- Connect checkout attribution to revenue reports
Checkout attribution is the handoff between analytics and payment processing.
Before checkout starts, your site may know the visitor's source, UTM campaign, landing page, referrer, and session. After checkout completes, your payment provider knows the payment, customer, subscription, invoice, and amount.
Checkout attribution connects those two worlds.
## The checkout attribution problem
Most payment systems do not know where a customer came from. Stripe, Paddle, Lemon Squeezy, Shopify, or a custom billing system can record the transaction, but they do not automatically know the marketing journey before checkout.
That creates a reporting gap:
```txt
Campaign visit -> signup -> checkout
payment event -> revenue
```
If no identifier crosses the checkout boundary, revenue becomes unattributed.
## The attribution bridge
The bridge is usually a small set of stable identifiers:
- Project ID.
- Visitor ID.
- Session ID.
- Checkout ID or internal customer ID.
Extra fields such as landing page, referrer, UTM source, UTM campaign, and checkout page can help with debugging. The stable identifiers matter most because they let the payment event join back to the analytics session.
## How checkout attribution works
A practical checkout attribution flow looks like this:
1. The tracker stores visitor, session, landing page, referrer, and UTM context.
2. The user clicks a checkout or upgrade button.
3. The browser sends attribution context to your backend.
4. Your backend validates the context.
5. Your backend creates the checkout session and stores attribution identifiers in metadata.
6. The payment provider sends a webhook when payment succeeds.
7. The webhook processor records revenue with the attribution identifiers.
The success page can be useful for UI, but webhooks should be the reporting source of truth.
## Common mistakes
Avoid these mistakes:
- Creating checkout sessions directly from the browser.
- Only storing attribution on the success page.
- Forgetting subscription metadata for renewals.
- Letting payment processor redirects become acquisition referrers.
- Dropping revenue events that have missing attribution.
Missing attribution should be visible in reports. It is a data quality issue, not a reason to lose revenue totals.
## Next steps
Use [how to pass attribution to Stripe Checkout](https://attribiq.com/guides/pass-attribution-to-stripe-checkout) for a concrete implementation. For custom billing, read [Generic Payment API revenue tracking](https://attribiq.com/guides/generic-payment-api-revenue-tracking).
## Frequently asked questions
### Why does checkout need attribution metadata?
The payment provider knows that a payment happened, but not which visit, campaign, or landing page created the customer unless your app passes attribution identifiers into checkout.
### Should attribution be sent from the browser directly to Stripe?
No. Send browser attribution context to your backend, validate it, then create the checkout session server-side.
### What is the minimum useful checkout attribution data?
A visitor ID and session ID are the minimum useful bridge. Landing page, referrer, and UTM fields help with debugging and reporting.
### Does checkout attribution work for subscriptions?
Yes, but subscription metadata matters. Copy attribution identifiers onto the subscription so renewals can inherit acquisition context.
---
# How to connect Stripe Checkout to Google Analytics 4
> Connect Stripe Checkout to GA4 using client IDs, verified payment webhooks and Measurement Protocol. Handle purchases, renewals, refunds and duplicates.
Canonical page: [https://attribiq.com/guides/stripe-google-analytics-integration](https://attribiq.com/guides/stripe-google-analytics-integration)
Category: Stripe & Payments
Last updated: 2026-10-02
Topics: stripe, google analytics, ga4, checkout, measurement protocol
## Summary
Use your existing Google tag to collect the browser journey, save its GA4 client ID with the checkout record, and send purchase events from verified Stripe payment webhooks through Measurement Protocol. A success-page redirect alone does not confirm payment. Give each paid invoice or order one transaction ID, and send refunds against that same ID.
## What this guide covers
- Carry browser analytics context into a server-side checkout record
- Choose payment events without counting the first subscription charge twice
- Build and validate a GA4 purchase payload
- Understand why a renewal does not automatically inherit an old GA4 session
A Stripe and Google Analytics integration needs two connected records: the visit that led to checkout and the payment Stripe confirmed. This tutorial covers **Stripe-hosted Checkout and a GA4 web data stream**. It assumes your site already has a working Google tag and your backend creates Checkout Sessions.
The architecture is: website visit → server checkout record → Stripe Checkout → verified webhook → durable analytics queue → GA4. It supplements your existing website measurement. Google describes [Measurement Protocol as a companion to browser tagging](https://developers.google.com/analytics/devguides/collection/protocol/ga4), so a server-only implementation cannot reconstruct an unobserved browser journey.
## 1. Prepare your GA4 web stream
Find the web stream's measurement ID, such as `G-EXAMPLE123`, and create a Measurement Protocol API secret in the stream settings. The measurement ID is public. Keep the API secret on your server, outside frontend bundles, source control and request logs.
Confirm that your own landing, pricing, success and cancel pages are measured. Review unwanted referrals for `checkout.stripe.com` so the hosted payment page does not become a misleading referral source. Stripe's [Checkout analytics guide](https://docs.stripe.com/payments/checkout/analyze-conversion-funnel) explains this configuration.
Use the same consent decisions for browser collection and server-side analytics. A backend event must not bypass a visitor's choice. Do not put names, email addresses, addresses or other personal details into GA4 event parameters.
## 2. Capture the browser IDs before redirecting
After analytics collection is permitted and the Google tag is initialized, read its `client_id` and `session_id` through the tag API. The following helper times out so an unavailable or blocked tag cannot delay checkout indefinitely.
```js
async function readGa4Context(measurementId) {
if (typeof window.gtag !== "function") return null
const read = (field) => new Promise((resolve) => {
const timeout = setTimeout(() => resolve(null), 500)
window.gtag("get", measurementId, field, (value) => {
clearTimeout(timeout)
resolve(value ?? null)
})
})
const [clientId, sessionId] = await Promise.all([
read("client_id"),
read("session_id")
])
return clientId ? { clientId, sessionId } : null
}
```
Call this helper only from the branch of your checkout flow where analytics collection is permitted. Send its result with your checkout request. On the server, validate it and associate it with your own order or subscription record. Treat these IDs as analytics context, never as authentication or proof of payment.
Store the Checkout Session ID against that record. Keep the client ID, captured session context and collection permission available when subsequent payment events arrive. If context is unavailable, let checkout proceed; do not invent an identifier or manufacture attribution. The [Google tag `get` reference](https://developers.google.com/tag-platform/gtagjs/reference#get) documents the supported fields.
## 3. Select one payment event per transaction
Verify the Stripe signature against the raw request body before processing a webhook. Persist the event and queue analytics delivery, then acknowledge it promptly. Stripe can retry delivery and events may arrive out of order; follow its [webhook handling guidance](https://docs.stripe.com/webhooks).
| Billing situation | Integration rule |
| --- | --- |
| One-time Checkout payment | Process a completed Checkout Session only when its payment status confirms payment; also handle delayed payment success |
| Subscription first charge | Use the paid invoice as the transaction; do not also count its Checkout Session as a second purchase |
| Subscription renewal | Give the newly paid invoice its own transaction ID |
| Trial or zero-value invoice | Apply an explicit policy; do not report it as money collected |
| Refund | Wait for a successful refund and reference the original purchase transaction ID |
Consult Stripe's [Checkout fulfillment guide](https://docs.stripe.com/checkout/fulfillment) and [subscription webhook guide](https://docs.stripe.com/billing/subscriptions/webhooks) for the relevant event types. If your billing system can mark invoices paid outside Stripe or use customer balances, distinguish those cases from newly collected cash before mapping them to analytics revenue.
Use two duplicate checks in persistent storage: the Stripe event ID for redeliveries, and the business transaction ID for two different events describing one payment. For refunds, deduplicate each refund ID separately. A customer or subscription ID alone is not a transaction ID because it can have many payments.
## 4. Send a purchase from your backend
Here is an illustrative payload for one €49 subscription payment, with no tax or shipping. Replace every example ID with the stored context and the actual billing record. Send it with a server-side HTTP POST to Google's [Measurement Protocol endpoint](https://developers.google.com/analytics/devguides/collection/protocol/ga4/sending-events).
```text
POST https://www.google-analytics.com/mp/collect?measurement_id=G-EXAMPLE123&api_secret=SERVER_SECRET
Content-Type: application/json
```
```json
{
"client_id": "123456789.1234567890",
"events": [{
"name": "purchase",
"params": {
"transaction_id": "in_example_paid_invoice",
"currency": "EUR",
"value": 49,
"items": [{
"item_id": "price_example_monthly",
"item_name": "Monthly subscription",
"price": 49,
"quantity": 1
}]
}
}]
}
```
Calculate `value` from the item amounts after discounts, excluding tax and shipping. Convert Stripe amounts using the currency's unit rules; dividing by 100 is wrong for zero-decimal currencies. Retain currencies separately, and do not treat one unit of EUR and one unit of USD as interchangeable revenue. Google's [ecommerce documentation](https://developers.google.com/analytics/devguides/collection/ga4/ecommerce) defines purchase, item and refund parameters; Stripe documents [currency units and exceptions](https://docs.stripe.com/currencies).
When delivery is delayed, preserve the actual event time with `timestamp_micros`, subject to Google's supported backdating window. Do not replace old payment timestamps with the current time to make an old import look like new revenue. Keep a durable record of queued, attempted and completed sends, with a deliberate retry policy.
## 5. Handle session attribution and renewals
For a purchase associated with an observed active session, include the captured `session_id` in event parameters when Google's session-attribution requirements are met. Google currently requires delivery within 24 hours of session start and an event timestamp inside that session. If you send `engagement_time_msec`, it must represent measured engagement; do not insert an arbitrary value to make Realtime display the event. See the [Measurement Protocol use cases](https://developers.google.com/analytics/devguides/collection/protocol/ga4/use-cases).
The example payload omits session parameters because it does not assume a current browser session. Do not reuse a months-old session ID for an automatic renewal or change the payment time to fit the original visit. A recorded purchase and correctly attributed acquisition revenue are separate outcomes to validate.
For recurring revenue by original acquisition campaign, retain that campaign and your chosen attribution model in your billing or attribution records. The [Stripe revenue attribution guide](https://attribiq.com/guides/stripe-revenue-attribution) explains how AttribIQ carries known visitor and session identifiers into subscription reporting.
## 6. Report refunds without creating a second purchase
Send a `refund` event with the original `transaction_id`, currency, and a **positive** refunded value. Include the affected items and quantities when item-level refund reporting is required. A €10 partial refund uses `value: 10`, not `-10`, and must not reuse the full €49 purchase amount. Your backend must distinguish successive partial refunds and failed or pending refunds. Check the actual outcome in [Stripe's refund lifecycle](https://docs.stripe.com/refunds).
## 7. Validate before using the revenue report
First send the payload to `/debug/mp/collect` with the same query parameters and inspect `validationMessages`. That endpoint checks structure; it does not add events to reports or verify that your API secret is valid. A successful HTTP response from `/mp/collect` alone also does not prove an event was valid. Follow Google's [event validation instructions](https://developers.google.com/analytics/devguides/collection/protocol/ga4/validating-events).
Use a separate GA4 test property and Stripe test mode to check the full path:
1. Complete a tagged checkout and verify its client ID and stored transaction mapping.
2. Confirm the correct purchase amount, currency and item details in GA4 after processing.
3. Reload the success page and resend the webhook. Neither action should add a purchase.
4. Test a delayed payment, a renewal and a partial refund.
5. Test with analytics unavailable or declined. Checkout must still work, and your server must honor the collection decision.
6. Reconcile against your billing records with the same date range, timezone, tax treatment and currency. Investigate reporting differences before using GA4 totals for decisions.
## Choose the reporting workflow you need
Keep GA4 when its reports, Google Ads connections or BigQuery workflows are useful to your team. If you want a simpler website reporting workflow, compare the [web analytics features](https://attribiq.com/web-analytics) and the [Google Analytics alternative](https://attribiq.com/comparisons/google-analytics-alternative).
AttribIQ can start with [traffic sources](https://attribiq.com/guides/traffic-sources-referrers), [landing pages](https://attribiq.com/guides/content-and-landing-pages), [goals](https://attribiq.com/guides/create-goals) and funnels. Connecting Stripe is an additional step for matching those journeys to payments; it is not required to use web analytics.
## Frequently asked questions
### Does Stripe Checkout automatically send purchases to GA4?
Your integration must send the relevant GA4 ecommerce events. For Stripe-hosted Checkout, collect the journey on your own site and connect verified payments to that context on your backend.
### Can I track purchases only on the success page?
A customer can pay without returning to your site, and a success page can be reloaded. Use verified payment events as the source for completed purchases.
### Will GA4 assign every renewal to the original campaign?
Do not assume that it will. GA4 session attribution has timing and session-ID requirements. Keep the original acquisition context in your billing or attribution system when you need recurring revenue by acquisition source.
### Do I need AttribIQ to connect Stripe and GA4?
No. This integration uses your application, Stripe and Google's Measurement Protocol. AttribIQ is an optional separate product for web analytics and payment attribution.
---
# Web Tracker Reference
> Install the AttribIQ tracker and record sessions, pageviews, referrers, UTMs, goals, events, and checkout context.
Canonical page: [https://attribiq.com/guides/web-tracker](https://attribiq.com/guides/web-tracker)
Category: API Reference
Last updated: 2026-09-04
Topics: tracker, javascript, pageviews, events, goals
## Summary
The web tracker is the analytics base layer. It captures pageviews, sessions, referrers, UTMs, and local attribution identifiers that can later be passed into checkout.
## What this guide covers
- Install the browser tracker
- Understand the required script attributes
- Know where the tracker should run
- Connect tracker identifiers to revenue events
The AttribIQ web tracker records the visit context that revenue attribution needs later.
Use it on the pages that influence acquisition and checkout. That normally includes the marketing site, pricing page, guides, signup flow, and relevant app pages.
## Script tag
```html
```
The tracker install key maps events to the project. The script sends browser events to the matching edge endpoint.
For first-party loading from your own domain, read [first-party tracker proxy](https://attribiq.com/guides/first-party-tracker-proxy).
## CSP requirements
AttribIQ uses one browser-facing origin for direct installs: `https://edge.attribiq.com`.
Add it to the page owner's CSP where scripts and fetch/XHR requests are allowed:
```http
script-src 'self' https://edge.attribiq.com;
connect-src 'self' https://edge.attribiq.com;
```
The current tracker does not load dynamic third-party scripts, use `eval`, execute inline code, or send events with image beacons. If your CSP uses nonces and `strict-dynamic`, the page template must add the matching nonce to the AttribIQ script tag.
## Captured context
The tracker captures:
- Page path and hostname.
- Referrer.
- Source and UTM campaign fields.
- Visitor ID.
- Session ID.
- Device, browser, country, and other aggregate dimensions when available.
- Custom events and goals when your app sends them.
Avoid putting raw personal data into page paths, query strings, or custom event metadata.
## Browser attribution object
Before checkout starts, your app can read the local attribution object:
```js
const attribution = window.attribiq.getAttribution()
```
That object is the bridge between browser sessions and payment events. Read the [browser attribution API](https://attribiq.com/guides/browser-attribution-api) for the expected fields.
## Single-page apps
For React, Vue, Svelte, or other client-routed apps, pageviews should be sent when the route changes. If you use AttribIQ's default script, verify route changes in the dashboard after installing.
## Next steps
Start with [Install AttribIQ](https://attribiq.com/guides/install-attribiq). Then connect checkout using [Stripe metadata](https://attribiq.com/guides/pass-attribution-to-stripe-checkout) or the [Payment API reference](https://attribiq.com/guides/payment-api-reference).
## Frequently asked questions
### Where should I install the tracker?
Install it on marketing pages, pricing pages, signup pages, and app pages that can influence checkout.
### What is the required field?
Use the project-specific script URL from project settings. The install key in the URL maps events to the right project.
### Does the tracker create payment events?
No. The tracker captures attribution context. Payment events come from Stripe webhooks or the Payment API.
### Can I use the tracker in a single-page app?
Yes. The tracker should record route changes as pageviews when the app navigation changes.
---
# Browser Attribution API Reference
> Read visitor, session, landing-page, referrer, and UTM context in the browser before signup or checkout begins.
Canonical page: [https://attribiq.com/guides/browser-attribution-api](https://attribiq.com/guides/browser-attribution-api)
Category: API Reference
Last updated: 2026-09-04
Topics: browser api, attribution object, checkout, javascript
## Summary
The browser attribution API exposes the current AttribIQ project, visitor, session, landing page, referrer, and UTM context. Send this object to your backend when checkout starts.
## What this guide covers
- Read attribution from window.attribiq
- Understand the fields in the attribution object
- Send attribution safely to your backend
- Avoid trusting browser-provided data for billing decisions
The browser attribution API exposes the visit context that should travel into checkout.
Use it when a visitor clicks upgrade, starts checkout, creates a paid account, or begins any flow that can produce revenue.
## Read the object
```js
const attribution = window.attribiq.getAttribution()
```
Expected shape:
```json
{
"project_id": "proj_123",
"visitor_id": "v_abc",
"session_id": "s_def",
"landing_page": "/pricing",
"referrer": "https://google.com",
"utm_source": "google",
"utm_campaign": "brand-search"
}
```
## Required fields
The minimum useful fields are:
- `project_id`
- `visitor_id`
- `session_id`
Landing page, referrer, and UTM values are useful for debugging, but the stable identifiers are what let AttribIQ join payment events to analytics sessions.
## Send attribution to your backend
```js
await fetch("/api/create-checkout-session", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({
price_id: "price_123",
attribution
})
})
```
Your backend should validate the shape, ignore unknown fields, and decide which values to put into Stripe metadata or your own pending checkout record.
## Security boundaries
Do not use browser attribution to decide:
- Payment amount.
- Plan entitlement.
- Billing currency.
- User account ownership.
- Discount eligibility.
The browser attribution object is for reporting. Billing decisions belong on the server.
## Next steps
Use [pass attribution to Stripe Checkout](https://attribiq.com/guides/pass-attribution-to-stripe-checkout) for a full Stripe flow, or [Payment API reference](https://attribiq.com/guides/payment-api-reference) for custom billing.
## Frequently asked questions
### Can the browser attribution object be trusted?
Treat it as client-provided attribution context, not as billing authority. Validate shape and project ownership server-side.
### Which fields are required for revenue attribution?
project_id, visitor_id, and session_id are the minimum useful fields.
### Should I send the entire object to Stripe?
No. Send the object to your backend, then copy the stable identifiers into Stripe metadata.
### Can I store the object with my own checkout session?
Yes. Storing it with your own pending checkout record can make webhook reconciliation easier.
---
# Revenue Payment API Reference
> Send custom purchases, renewals, refunds, and subscription events with idempotency and optional journey identifiers.
Canonical page: [https://attribiq.com/guides/payment-api-reference](https://attribiq.com/guides/payment-api-reference)
Category: API Reference
Last updated: 2026-09-04
Topics: payment api, revenue api, idempotency, custom billing
## Summary
The Payment API accepts normalized revenue events from custom billing systems and unsupported providers. Send stable transaction IDs, event type, amount, currency, timestamp, and AttribIQ visitor or session identifiers.
## What this guide covers
- Send a revenue event to /v1/revenue
- Use idempotency keys safely
- Choose supported event types
- Connect custom payments to attribution identifiers
The Payment API is for sending revenue events from custom billing systems and payment providers that are not connected natively yet.
Stripe users should usually prefer the Stripe webhook integration. Use this API when you already have normalized payment events in your own backend.
## Endpoint
```http
POST /v1/revenue
Authorization: Bearer sk_project_...
Idempotency-Key: txn_123
Content-Type: application/json
```
## Request body
```json
{
"provider": "custom",
"transaction_id": "txn_123",
"event_type": "purchase",
"amount": 2900,
"currency": "EUR",
"occurred_at": "2026-05-20T10:30:00Z",
"visitor_id": "v_abc",
"session_id": "s_def",
"customer_id_hash": "hash_123",
"metadata": {
"plan": "builder",
"product": "monthly_subscription"
}
}
```
## Fields
| Field | Required | Notes |
| --- | --- | --- |
| `provider` | Yes | Use `custom` or your provider key. |
| `transaction_id` | Yes | Stable provider or billing event ID. |
| `event_type` | Yes | One of the supported normalized event types. |
| `amount` | Yes | Integer in minor currency units. |
| `currency` | Yes | ISO currency code such as `EUR` or `USD`. |
| `occurred_at` | Recommended | ISO timestamp. Defaults to receive time if omitted. |
| `visitor_id` | Optional | AttribIQ visitor ID from the browser attribution object. |
| `session_id` | Optional | AttribIQ session ID from the browser attribution object. |
| `customer_id_hash` | Optional | Stable one-way customer identifier. |
| `metadata` | Optional | Small debugging context such as plan or product. |
## Event types
Supported event types:
- `purchase`
- `subscription_started`
- `renewal`
- `upgrade`
- `downgrade`
- `refund`
- `cancellation`
- `churn`
Use stable event names. Reporting becomes harder when integrations invent provider-specific names for the same business event.
## Idempotency
Retries are normal. Send the same `Idempotency-Key` for the same logical payment event and keep `provider + transaction_id` stable.
Do not generate a fresh random transaction ID on each retry. That creates duplicate revenue.
## Next steps
Read [generic Payment API revenue tracking](https://attribiq.com/guides/generic-payment-api-revenue-tracking) for implementation guidance, or [browser attribution API](https://attribiq.com/guides/browser-attribution-api) to pass visitor context into custom checkout.
## Frequently asked questions
### Should amount be in cents?
Send amount in minor currency units. For EUR and USD, 2900 means 29.00.
### What should the idempotency key be?
Use the same stable transaction, invoice, or billing event ID every time you retry the same event.
### Can I send events without visitor_id?
Yes. They will be recorded as unattributed revenue if no attribution identifiers are present.
### What content type should I use?
Use application/json with a project API key in the Authorization header.
---
# CLI Reporting Reference
> Run AttribIQ overview, revenue, campaign, goal, and funnel reports from scripts, release checks, and internal tools.
Canonical page: [https://attribiq.com/guides/cli-reports](https://attribiq.com/guides/cli-reports)
Category: API Reference
Last updated: 2026-09-04
Topics: cli, reports, revenue, funnels, automation
## Summary
The CLI is for revenue questions in scripts, agents, and release workflows. Start with overview, revenue by campaign, and signup-to-paid funnel inspection.
## What this guide covers
- Run revenue reports from the command line
- Group revenue by campaign, source, or landing page
- Inspect funnels in JSON
- Use CLI output in automation
The AttribIQ CLI is for teams that want revenue reports outside the dashboard.
It is useful in release checks, weekly reporting scripts, internal agents, and operational workflows where JSON output is easier to consume than a browser dashboard.
## Overview report
```sh
attribiq overview --project proj_123 --from 90d --json
```
The overview report should return visitors, pageviews, events, goals, conversions, revenue, and paid conversion rate for the selected date range.
## Revenue by campaign
```sh
attribiq revenue --project proj_123 --from 30d --group-by campaign --json
```
Useful groupings include:
- `source`
- `campaign`
- `landing_page`
- `referrer`
- `country`
- `device`
- `goal`
Use campaign reports when deciding which launch, newsletter, ad, or partner effort deserves more work.
## Funnel inspection
```sh
attribiq funnels inspect signup-to-paid --project proj_123 --json
```
Funnel output should include step counts, conversion rates, drop-offs, and attributed revenue when payment events are connected.
## Automation pattern
Use CLI reports for questions like:
- Did revenue by campaign drop after a release?
- Which landing page created the most MRR this week?
- Did a launch email create paid conversion?
- Which funnel step lost the most revenue?
The CLI should not replace the dashboard. It should make the same revenue model available to scripts.
## Next steps
Install the tracker with [Install AttribIQ](https://attribiq.com/guides/install-attribiq), then connect payments through [Stripe revenue attribution](https://attribiq.com/guides/stripe-revenue-attribution) or the [Payment API reference](https://attribiq.com/guides/payment-api-reference).
## Frequently asked questions
### Is the CLI required?
No. The dashboard is the primary interface. The CLI is useful for developers who want reports in scripts and automation.
### Should CLI output be JSON?
Use JSON for automation and table output for humans. The examples here prefer JSON because it is easier to pipe into tools.
### What project identifier should I use?
Use the project public ID from AttribIQ project settings.
### Can the CLI query funnels?
Yes. Funnel inspection should return conversion rates, step counts, and attributed revenue when configured.
---
# How to pass attribution to Stripe Checkout
> Capture AttribIQ visitor context in the browser, send it to your backend, and copy it into Stripe Checkout metadata.
Canonical page: [https://attribiq.com/guides/pass-attribution-to-stripe-checkout](https://attribiq.com/guides/pass-attribution-to-stripe-checkout)
Category: Implementation Guides
Last updated: 2026-06-25
Topics: stripe checkout, metadata, implementation, javascript
## Summary
The checkout server should not guess attribution. Capture the browser attribution object before the user starts checkout, send it to your backend, validate it, and copy the stable identifiers into Stripe metadata.
## What this guide covers
- Read attribution from the AttribIQ browser API
- Send visitor and session identifiers to your checkout endpoint
- Copy attribution safely into Stripe Checkout Session metadata
- Understand what to validate before creating checkout
Stripe Checkout attribution starts before the user leaves your app for checkout.
The important rule is simple: the browser knows the visit context, but the server creates the Stripe Checkout Session. Your frontend should read attribution from AttribIQ and pass it to your backend. Your backend should validate it and write it into Stripe metadata.
## Install the tracker
Install AttribIQ on your marketing site and app pages where the checkout can begin.
```html
```
When a visitor lands on the site, the tracker records source, referrer, UTM values, visitor ID, session ID, and landing page context.
## Capture attribution before checkout
When the user clicks the upgrade or checkout button, read the attribution object and send it to your backend.
```js
async function startCheckout(priceId) {
const attribution = window.attribiq?.getAttribution?.()
const response = await fetch("/api/create-checkout-session", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({ price_id: priceId, attribution })
})
const { url } = await response.json()
window.location.href = url
}
```
This is a transport step. The browser is not deciding the plan, the price, or the payment amount.
## Validate on the backend
On the server, validate the input before calling Stripe:
- The requested price ID is allowed for the authenticated user or public checkout.
- The attribution object has the expected shape.
- The project ID belongs to the AttribIQ project you expect for this site.
- String lengths are bounded.
- Unknown fields are ignored or stored only as debug metadata.
Do not allow the browser to decide revenue amount, currency, plan entitlements, or account ownership.
## Create the Checkout Session
Use Stripe's server-side Checkout Sessions API. Stripe supports metadata on Checkout Sessions and documents `client_reference_id` as a reconciliation field.
```js
const attribution = req.body.attribution || {}
const session = await stripe.checkout.sessions.create({
mode: "subscription",
line_items: [{ price: priceId, quantity: 1 }],
success_url: "https://example.com/billing/success?session_id={CHECKOUT_SESSION_ID}",
cancel_url: "https://example.com/pricing",
client_reference_id: attribution.visitor_id,
metadata: {
attribiq_project_id: attribution.project_id,
attribiq_visitor_id: attribution.visitor_id,
attribiq_session_id: attribution.session_id,
attribiq_landing_page: attribution.landing_page,
attribiq_utm_source: attribution.utm_source,
attribiq_utm_campaign: attribution.utm_campaign
},
subscription_data: {
metadata: {
attribiq_project_id: attribution.project_id,
attribiq_visitor_id: attribution.visitor_id,
attribiq_session_id: attribution.session_id
}
}
})
```
Keep metadata small and predictable. Store the identifiers that let AttribIQ join payment events to visits. Use the dashboard for reporting rather than trying to put every marketing field into Stripe.
## Test the path
Run a checkout from a URL with UTMs:
```txt
https://example.com/pricing?utm_source=newsletter&utm_campaign=launch
```
After checkout completes, inspect the Checkout Session and Subscription metadata in Stripe. Then confirm the AttribIQ dashboard shows the revenue under the campaign and landing page you used.
If the first payment is attributed but renewals are not, subscription metadata is usually missing.
## Next steps
After Checkout metadata is working, [connect Stripe to AttribIQ](https://attribiq.com/guides/connect-stripe-to-attribiq). For the broader model, read [Stripe revenue attribution for SaaS](https://attribiq.com/guides/stripe-revenue-attribution).
## Frequently asked questions
### Can I create the Stripe Checkout Session directly from the browser?
No. Create Checkout Sessions on your server. The browser can send attribution context to your server, but your Stripe secret key must stay server-side.
### Should I trust all attribution fields from the browser?
Treat browser data as client-provided context. Validate project IDs, accepted hostnames, and expected shapes before storing or forwarding it.
### What fields are required?
The minimum useful fields are project_id, visitor_id, and session_id. Landing page, referrer, and UTM fields improve debugging and reporting.
### Where should I put subscription metadata?
For subscription checkouts, put the same attribution identifiers into subscription_data.metadata so renewals and subscription lifecycle events keep the attribution bridge.
---
# Connect Stripe to AttribIQ
> Configure Stripe to send payment events to AttribIQ after your app has copied visitor and session identifiers into Stripe metadata.
Canonical page: [https://attribiq.com/guides/connect-stripe-to-attribiq](https://attribiq.com/guides/connect-stripe-to-attribiq)
Category: Stripe & Payments
Last updated: 2026-06-25
Topics: stripe, webhooks, revenue attribution, setup
## Summary
Use the native Stripe webhook path when Stripe can send events directly to AttribIQ. Use the Payment API relay path when your backend needs to normalize custom billing events before delivery.
## What this guide covers
- Choose direct Stripe webhooks or a Payment API relay
- Configure the AttribIQ webhook endpoint in Stripe
- Select a safe first event set
- Test revenue attribution end to end
Stripe should send revenue events to AttribIQ after your checkout flow carries AttribIQ metadata into Stripe.
The integration has two valid paths:
| Path | Use it when |
| --- | --- |
| Native Stripe webhook | Stripe can send events directly to AttribIQ and you do not need custom billing semantics. |
| Payment API relay | Your backend already normalizes Stripe events, needs custom retries or backfills, or needs to map custom usage billing before AttribIQ receives it. |
Most teams should start with native Stripe webhooks. The relay path is an escape hatch, not a requirement.
## Before you connect Stripe
Install the tracker and pass attribution into Checkout first.
Your backend should create Stripe Checkout and include these metadata fields:
```js
const session = await stripe.checkout.sessions.create({
mode: "subscription",
line_items: [{ price: priceId, quantity: 1 }],
success_url: "https://example.com/billing/success?session_id={CHECKOUT_SESSION_ID}",
cancel_url: "https://example.com/pricing",
client_reference_id: attribution.visitor_id,
metadata: {
attribiq_project_id: attribution.project_id,
attribiq_visitor_id: attribution.visitor_id,
attribiq_session_id: attribution.session_id
},
subscription_data: {
metadata: {
attribiq_project_id: attribution.project_id,
attribiq_visitor_id: attribution.visitor_id,
attribiq_session_id: attribution.session_id
}
}
})
```
Subscription metadata is important. Checkout metadata covers the initial checkout event, while subscription metadata keeps renewals and subscription lifecycle events connected to the original attribution identifiers.
## Configure native Stripe webhooks
In Stripe, create a webhook endpoint for AttribIQ:
```txt
https://api.attribiq.com/v1/integrations/stripe/webhook
```
Use the API hostname for your AttribIQ deployment if you are not using the hosted service.
Start with this conservative event set:
- `invoice.paid`
- `charge.refunded`
- `customer.subscription.deleted`
This set captures paid invoices, refunds, and cancellations while avoiding ambiguous checkout setup sessions and broad subscription update events.
Add these events only after you confirm that their semantics match your billing model:
- `checkout.session.completed`
- `customer.subscription.created`
- `customer.subscription.updated`
`checkout.session.completed` is useful for one-time purchases and subscription starts, but setup-mode sessions should not become purchases. `customer.subscription.updated` can represent upgrades, downgrades, status changes, or metadata-only changes, so it needs careful handling before it should affect revenue reports.
## Configure the signing secret
Stripe signs each webhook endpoint with its own signing secret. AttribIQ verifies Stripe signatures when the endpoint secret is configured for the receiver.
After creating the endpoint in Stripe:
1. Open the webhook endpoint in Stripe.
2. Reveal the endpoint signing secret.
3. Configure that secret in AttribIQ for the Stripe revenue webhook receiver.
If your AttribIQ workspace does not yet expose self-serve Stripe signing-secret settings, use one of these paths:
- Ask support or your deployment operator to configure the native Stripe webhook secret.
- Use the Payment API relay path from your own backend until project-level Stripe settings are available.
Do not reuse your AttribIQ billing webhook secret or a different Stripe endpoint secret. Stripe endpoint secrets are specific to each webhook endpoint.
## Test in Stripe test mode
Use test mode before sending live events.
1. Visit your site with UTM parameters.
2. Start checkout from a tracked page.
3. Inspect the Stripe Checkout Session metadata.
4. For subscriptions, inspect the Stripe Subscription metadata.
5. Send or replay the selected test events from Stripe.
6. Confirm the AttribIQ revenue report shows revenue.
7. Confirm duplicate Stripe deliveries return as duplicates and do not double-count revenue.
8. Confirm missing visitor or session IDs appear as unattributed revenue instead of fabricated attribution.
If revenue is missing but Stripe metadata is present, check webhook delivery logs and signing-secret configuration first.
If the initial payment is attributed but renewals are not, subscription metadata is usually missing.
## Use a Payment API relay instead
Use a relay if your backend should remain the payment-event source of truth.
The relay receives Stripe events, applies your billing rules, and posts normalized events to AttribIQ:
```http
POST /v1/revenue
Authorization: Bearer sk_project_...
Idempotency-Key: in_123
Content-Type: application/json
```
```json
{
"provider": "stripe",
"transaction_id": "in_123",
"event_type": "renewal",
"amount": 2900,
"currency": "EUR",
"occurred_at": "2026-06-25T10:30:00Z",
"visitor_id": "v_abc",
"session_id": "s_def",
"metadata": {
"stripe_invoice_id": "in_123",
"plan": "builder"
}
}
```
Use stable Stripe object IDs or durable billing-event IDs for `transaction_id` and `Idempotency-Key`. Do not generate a fresh random ID on retry.
## Next steps
Read [how to pass attribution to Stripe Checkout](https://attribiq.com/guides/pass-attribution-to-stripe-checkout) for the metadata bridge. Use the [Payment API reference](https://attribiq.com/guides/payment-api-reference) if your backend will send normalized revenue events instead of direct Stripe webhooks.
## Frequently asked questions
### Do I need to build my own Stripe webhook relay?
No, not by default. Use Stripe's direct webhook delivery to AttribIQ unless you need custom billing normalization, custom retries, or backfills from your own system.
### What must happen before Stripe sends events?
Your app must copy attribiq_project_id, attribiq_visitor_id, and attribiq_session_id into Stripe metadata before checkout starts.
### What if my AttribIQ workspace does not show a Stripe signing-secret field?
Ask support to configure native Stripe delivery for your project, or use the Payment API relay path until self-serve Stripe settings are available.
### Can I use the Payment API with Stripe instead?
Yes. If your backend already receives Stripe webhooks and normalizes billing events, send those normalized events to POST /v1/revenue with a project API key.
---
# Stripe webhook revenue events
> Send Stripe webhook events to AttribIQ and understand how Stripe objects become attributed revenue events.
Canonical page: [https://attribiq.com/guides/stripe-webhook-revenue-events](https://attribiq.com/guides/stripe-webhook-revenue-events)
Category: Stripe & Payments
Last updated: 2026-06-25
Topics: stripe webhooks, revenue events, subscriptions, idempotency
## Summary
Webhooks are the reliable feed for Stripe revenue attribution. Stripe can send events directly to AttribIQ, or your backend can normalize events and post them through the Payment API.
## What this guide covers
- Choose the first Stripe events to send
- Understand idempotency and duplicate webhook delivery
- Understand AttribIQ's native Stripe event mapping
- Handle missing metadata without losing revenue
Stripe webhooks turn payment activity into a reliable revenue event stream.
Checkout redirects are useful for user experience, but revenue analytics should be driven by webhook events. Stripe sends events when checkout completes, invoices are paid, subscriptions change, and refunds occur. AttribIQ turns supported Stripe events into a smaller revenue event vocabulary that reports can understand.
## Native receiver endpoint
For direct Stripe delivery, configure a Stripe webhook endpoint:
```txt
https://api.attribiq.com/v1/integrations/stripe/webhook
```
Use the API hostname for your deployment if you are not using the hosted AttribIQ service.
The Stripe object must include `attribiq_project_id` metadata so AttribIQ can route the revenue event to the right project. `attribiq_visitor_id` and `attribiq_session_id` are the strongest attribution links.
If your workspace does not yet expose self-serve Stripe signing-secret settings, ask support or your deployment operator to configure the endpoint secret, or use a customer-owned relay that sends normalized events to the Payment API.
## Start with a small event set
For the current native AttribIQ receiver, start conservatively:
- `invoice.paid`
- `customer.subscription.deleted`
- `charge.refunded`
This set covers paid invoices, cancellations, and refunds while avoiding setup-mode checkout sessions and broad subscription updates.
Add these events only after you confirm that their semantics match your billing model:
- `checkout.session.completed`
- `customer.subscription.created`
- `customer.subscription.updated`
`checkout.session.completed` is useful for checkout completions, but setup-mode Checkout Sessions should not become purchases. `customer.subscription.updated` can mean upgrade, downgrade, status change, metadata change, or another non-revenue update.
If your backend needs exact control over those distinctions, use a Payment API relay instead of sending those raw Stripe events directly to AttribIQ.
## Signature and idempotency
Stripe signs each webhook event with the endpoint secret. AttribIQ verifies signatures when that secret is configured for the receiver.
Stripe may retry events. AttribIQ stores processed Stripe event IDs and ignores duplicates so repeated deliveries do not duplicate purchases, renewals, or refunds.
## Normalize into revenue events
AttribIQ's native Stripe receiver maps supported Stripe events into normalized revenue event types:
| Stripe signal | AttribIQ event type |
| --- | --- |
| Completed checkout for a new subscription | `subscription_started` |
| Completed checkout for a one-time payment | `purchase` |
| Paid recurring invoice | `renewal` |
| Plan amount increases | `upgrade` |
| Plan amount decreases | `downgrade` |
| Refunded charge | `refund` |
| Subscription cancelled or deleted | `cancellation` or `churn` |
The mapping should be explicit in code. Do not let every Stripe event become a new analytics event type. Reporting works better when event names are stable.
Current implementation note: broad Stripe events can be ambiguous. For example, `customer.subscription.updated` is not always an upgrade, and `checkout.session.completed` can represent setup-mode flows. Use the conservative event set first unless you have verified the mapping for your billing flow.
## Extract attribution metadata
For the first checkout, attribution usually comes from `checkout.session.metadata`. For renewals and subscription lifecycle events, metadata should come from the Subscription. That is why [passing attribution to Stripe Checkout](https://attribiq.com/guides/pass-attribution-to-stripe-checkout) copies the same identifiers into `subscription_data.metadata`.
The minimum fields are:
- `attribiq_project_id`
- `attribiq_visitor_id`
- `attribiq_session_id`
If those fields are missing, the revenue event can still be valid. Mark it as unattributed and keep it in totals.
## Handle refunds and churn carefully
Refunds should subtract money from the source that received the original credit. Churn should be tied back to the subscription or customer history so teams can see whether a channel creates poor-fit customers.
This does not mean every source with churn is bad. It means the dashboard should show revenue quality, not just first purchase volume.
## Operational checks
Before going live:
- Send test webhooks from Stripe.
- Confirm duplicate events do not double-count revenue.
- Confirm metadata appears on subscriptions.
- Confirm missing metadata becomes unattributed revenue.
- Confirm refunds reduce net revenue.
Once this is stable, read [connect Stripe to AttribIQ](https://attribiq.com/guides/connect-stripe-to-attribiq) for the full setup checklist and [UTM revenue attribution](https://attribiq.com/guides/utm-revenue-attribution) to understand how campaign reporting uses normalized events.
## Frequently asked questions
### Why not rely on the checkout success page?
A success page can be blocked, closed, or refreshed. Stripe webhooks are designed for asynchronous payment lifecycle processing.
### What should be the idempotency key?
Use stable Stripe object IDs and event IDs. Store processed event IDs so duplicate deliveries do not create duplicate revenue.
### Should failed invoices count as churn?
Not immediately. Failed invoices are payment risk. Churn should be recorded when the subscription is cancelled, deleted, or moves into a churn state you define.
### What happens when attribution metadata is missing?
Record the revenue as unattributed and surface it as a data quality issue. Dropping valid revenue would make totals wrong.
---
# UTM revenue attribution
> Use UTM source, medium, campaign, content, and term fields to report revenue instead of only visits or signups.
Canonical page: [https://attribiq.com/guides/utm-revenue-attribution](https://attribiq.com/guides/utm-revenue-attribution)
Category: Campaigns & UTMs
Last updated: 2026-10-02
Topics: utm, campaigns, revenue attribution, mrr
## Summary
UTMs become more useful when they are connected to revenue. Instead of asking which campaign created traffic, report which campaign created paid accounts, MRR, renewals, refunds, and churn.
## What this guide covers
- Understand which UTM fields matter for revenue reports
- Create a simple naming convention for campaigns
- Avoid losing campaign credit to direct traffic
- Read campaign revenue without overreacting to noisy data
UTM revenue attribution reports money by campaign fields.
Most teams already use UTMs to measure traffic. The gap is usually further down the funnel: did the campaign create paid accounts, and did those accounts renew, refund, or churn?
## The UTM fields that matter
The standard fields are:
- `utm_source`: the platform or origin, such as newsletter, google, linkedin, partner, or producthunt.
- `utm_medium`: the broad channel, such as email, cpc, social, referral, or affiliate.
- `utm_campaign`: the named initiative, such as launch-week, black-friday, or q2-webinar.
- `utm_content`: the variant, creative, placement, or link.
- `utm_term`: the keyword or targeting term.
For early revenue reporting, source and campaign matter most. Medium helps group channels. Content and term are useful once paid ads or experiments become important.
## Use a simple naming convention
Use lowercase names, hyphens, and stable campaign terms:
```txt
utm_source=newsletter
utm_medium=email
utm_campaign=launch-week
utm_content=pricing-link
```
Avoid mixing `Newsletter`, `email-newsletter`, and `mail` for the same source. Analytics becomes hard to read when naming is inconsistent.
Before publishing a link, check the failure states that most often split reports:
- Mixed case, such as `LinkedIn` and `linkedin`.
- A campaign renamed halfway through a launch.
- Spaces or punctuation that differ between tools.
- UTMs added to internal links, which replace useful acquisition context.
- A redirect that drops query parameters before the landing page loads.
- `utm_source` present but `utm_campaign` missing, leaving the initiative unclear.
## Connect UTMs to checkout
When a visitor arrives with UTMs, AttribIQ stores the campaign context with the session and visitor. Before checkout, your app passes the AttribIQ visitor and session identifiers into Stripe metadata or the generic Payment API.
The payment event can then be joined back to the original campaign context.
```txt
campaign visit -> signup -> checkout -> Stripe webhook -> attributed revenue
```
The critical step is the checkout bridge. If the payment system never receives attribution identifiers, Stripe can tell you that someone paid, but not which campaign created that customer.
## Do not let direct overwrite campaigns
A common attribution error is giving all credit to direct traffic because the customer returned later by typing the URL or using a bookmark.
For revenue reports, direct should usually not overwrite a known campaign source by default. If the first visit came from a newsletter and the payment happened two days later in a direct session, first-touch attribution should still credit the newsletter. Session-touch attribution can show that the checkout session was direct.
Both views are useful. They answer different questions.
## How to read UTM revenue
Do not rank campaigns only by total revenue. Also look at:
- Paid conversion rate.
- Average revenue per paying customer.
- Refund rate.
- Renewal rate.
- Trial-to-paid conversion.
- Revenue per visit.
A small campaign with high revenue per visit may deserve more attention. A big campaign with high refunds may need better targeting.
For a complete example from tagged visit to paid invoice, renewal and refund, follow the [Stripe revenue attribution setup and validation guide](https://attribiq.com/guides/stripe-revenue-attribution). If you are still measuring traffic, start with [sources and referrers](https://attribiq.com/guides/traffic-sources-referrers) before adding payment data.
## Next steps
Use [landing page revenue attribution](https://attribiq.com/guides/landing-page-revenue-attribution) to see which pages convert campaign traffic. Read [direct traffic revenue attribution](https://attribiq.com/guides/direct-traffic-revenue-attribution) if direct is taking too much credit.
## Frequently asked questions
### Which UTM field is most important?
utm_source and utm_campaign are usually the most important fields. Source identifies the channel or platform, while campaign identifies the specific launch, newsletter, ad group, or experiment.
### Should every link have UTMs?
Use UTMs for intentional campaign links such as newsletters, sponsorships, ads, affiliates, and partner posts. Do not add UTMs to internal navigation because that can overwrite useful session context.
### Can UTMs track revenue across subscriptions?
Yes, if the campaign context is connected to the customer or subscription through attribution identifiers before checkout.
### Why does direct traffic get revenue from a campaign visitor?
Direct traffic can appear when someone returns later without campaign parameters. A good attribution model can preserve the earlier known campaign instead of overwriting it with direct.
---
# What are UTM parameters?
> UTM parameters are campaign tags added to URLs so analytics tools can identify the source, medium, campaign, content, and term behind a visit.
Canonical page: [https://attribiq.com/guides/what-are-utm-parameters](https://attribiq.com/guides/what-are-utm-parameters)
Category: Campaigns & UTMs
Last updated: 2026-06-25
Topics: utm parameters, utm source, utm campaign, campaign tracking
## Summary
UTM parameters are URL tags for campaign tracking. They help analytics tools group visits by source, medium, campaign, content, and term. They become much more useful when they are connected to signups, checkout, and revenue.
## What this guide covers
- Learn what UTM parameters are
- Know what each UTM field means
- Create cleaner campaign URLs
- Avoid common UTM mistakes
UTM parameters are campaign tags added to the end of a URL.
They tell an analytics tool where a visit came from and which campaign should receive credit. A tagged URL might look like this:
```txt
https://example.com/pricing?utm_source=newsletter&utm_medium=email&utm_campaign=launch-week
```
When someone clicks the link, the analytics tool can store the campaign fields with the visit.
## The five UTM fields
The standard fields are:
- `utm_source`: the platform or sender, such as google, newsletter, linkedin, partner, or producthunt.
- `utm_medium`: the channel type, such as cpc, email, social, referral, or affiliate.
- `utm_campaign`: the named campaign, such as launch-week, q3-webinar, or black-friday.
- `utm_content`: the creative, placement, button, or link variant.
- `utm_term`: the keyword, audience, or targeting term.
For most SaaS teams, `utm_source` and `utm_campaign` carry the most useful early signal.
## Why UTMs matter
Referrer data is often incomplete. Email clients, private browsers, messaging apps, redirects, and privacy settings can all remove useful source information.
UTMs give you explicit campaign data. They are especially useful for:
- Newsletters.
- Sponsorships.
- Partner links.
- Paid search campaigns.
- Paid social campaigns.
- Affiliate links.
- Product launches.
- Webinars and events.
## Good UTM naming
Use lowercase, hyphens, and stable names:
```txt
utm_source=newsletter
utm_medium=email
utm_campaign=launch-week
utm_content=pricing-cta
```
Avoid changing names for the same channel. `newsletter`, `email-list`, and `mail` may all mean the same thing to your team, but they become separate rows in a report.
## Common UTM mistakes
The most common mistakes are:
- Tagging internal links.
- Using inconsistent capitalization.
- Mixing source and medium.
- Creating campaign names that are too vague.
- Forgetting to connect UTMs to checkout.
Internal links are especially risky. If a visitor arrives from Google and then clicks an internal link tagged with `utm_source=homepage`, the original acquisition source can be overwritten.
## UTMs and revenue
UTMs are not enough for revenue reporting by themselves. Stripe or another payment provider will not automatically know which campaign created the customer.
To report revenue by UTM campaign, your analytics system needs to store campaign context with the visitor or session, then pass an attribution bridge into checkout.
Read [UTM revenue attribution](https://attribiq.com/guides/utm-revenue-attribution) for the payment-aware workflow, and [direct traffic revenue attribution](https://attribiq.com/guides/direct-traffic-revenue-attribution) if direct traffic is taking credit from campaigns.
## Frequently asked questions
### What does UTM stand for?
UTM comes from Urchin Tracking Module, a naming convention that became standard in web analytics for tagging campaign URLs.
### Which UTM parameters are required?
No field is technically required by the browser, but utm_source and utm_campaign are the most useful minimum fields for campaign reporting.
### Should I use UTMs on internal links?
Usually no. Internal UTMs can overwrite the original acquisition source and make revenue attribution harder to read.
### Can UTMs track revenue?
UTMs do not track revenue by themselves. They need to be stored with the visit and connected to checkout or payment events.
---
# Landing page revenue attribution
> Measure which first pages and pricing paths create paid accounts, not just visits or signups.
Canonical page: [https://attribiq.com/guides/landing-page-revenue-attribution](https://attribiq.com/guides/landing-page-revenue-attribution)
Category: Revenue Attribution
Last updated: 2026-09-02
Topics: landing pages, revenue attribution, conversion rate, saas
## Summary
Landing page attribution shows which entry pages create revenue. It is more useful than pageview ranking because it connects the first page, later signup, checkout, renewal, refund, and churn behavior.
## What this guide covers
- Separate page traffic from page revenue
- Choose the landing page fields to store
- Compare first page and checkout path reports
- Use revenue per visit to prioritize content and campaigns
Landing page revenue attribution tells you which entry pages eventually created money.
Most analytics dashboards can show top pages. That report is not enough for SaaS growth work. A blog post can get fewer visits than the homepage but create better customers. A high-traffic reference page can produce many visits and little revenue. A pricing page can close revenue but may not be the first page that introduced the customer.
## The landing page field
The landing page is the first page recorded in a session or visitor journey, depending on the attribution model.
Common fields are:
- First landing page for the visitor.
- Landing page for the current session.
- Page before signup.
- Page before checkout.
- First pricing page viewed.
AttribIQ keeps these concepts separate so you can ask more precise questions. "Which page introduced paid accounts?" is not the same as "which page was viewed before checkout?"
## Why revenue per visit matters
Pageviews can reward broad content that attracts unqualified traffic. Revenue per visit adds quality.
```txt
Revenue per visit = attributed revenue / landing page visits
```
This metric helps prioritize pages. A low-traffic article that creates paid accounts may deserve internal links, better distribution, or a stronger call to action. A high-traffic page with no paid conversion may need clearer positioning or a different audience.
## Handle paths carefully
Normalize URLs before reporting:
- Remove query strings except campaign fields that belong in UTM reports.
- Treat trailing slashes consistently.
- Group dynamic app paths when needed.
- Exclude checkout redirects, login pages, and billing success pages from acquisition reports.
Without normalization, the same page can appear as several rows and hide the pattern.
## Read landing page reports with context
Landing page revenue attribution is strongest when paired with source and campaign:
| Report | Question |
| --- | --- |
| Revenue by first landing page | Which entry pages introduce paid accounts? |
| Revenue by session landing page | Which current sessions close revenue? |
| Revenue by page before signup | Which pages move visitors into accounts? |
| Revenue by page before checkout | Which paths create paid conversion? |
Do not force one page to explain the whole journey. Use the report to find candidates for improvement.
## Worked decision example
Use one date range, currency and attribution model before comparing pages:
| First landing page | Visits | Matched net revenue | Revenue per visit |
| --- | ---: | ---: | ---: |
| `/guides/payment-api-reference` | 400 | €2,000 | €5.00 |
| `/pricing` | 1,600 | €3,200 | €2.00 |
Pricing produces more matched revenue in total, but the API guide produces more revenue per visit. A reasonable next test is to add a clearer product path from the guide without assuming that the page caused the payments. Check match rate and source mix before changing the content plan.
## Practical improvements
When a landing page creates visits but no revenue:
- Align the headline with the traffic source.
- Add a clearer product path.
- Link to pricing, implementation guides, or API reference pages at the right moment.
- Add a comparison page for bottom-funnel visitors.
- Reduce irrelevant traffic sources.
When a page creates high-value customers, invest in distribution and internal links.
## Next steps
Read [UTM revenue attribution](https://attribiq.com/guides/utm-revenue-attribution) to connect page performance to campaigns. Use [signup-to-paid funnel tracking](https://attribiq.com/guides/signup-to-paid-funnel) to see where visitors drop after the landing page.
## Frequently asked questions
### Is the landing page always the page that caused a purchase?
No. It is the first known page in the journey. It is a useful attribution lens, but it should be read alongside source, campaign, and checkout session reports.
### Should blog posts get credit for revenue?
They should get credit when they are the first known landing page for a visitor who later pays. This helps identify content that introduces good customers.
### How is this different from top pages?
Top pages rank traffic volume. Landing page revenue attribution ranks pages by the money connected to visitors who started there.
### What if a user lands on the app login page?
You can exclude login, billing, and internal app paths from landing page reports so acquisition pages are easier to evaluate.
---
# What is Google Search Console?
> Google Search Console reports queries, pages, clicks, impressions, CTR and average position for a verified site in Google Search.
Canonical page: [https://attribiq.com/guides/what-is-google-search-console](https://attribiq.com/guides/what-is-google-search-console)
Category: Campaigns & UTMs
Last updated: 2026-09-02
Topics: google search console, seo, organic search, search analytics
## Summary
Google Search Console shows organic search performance for a verified website. It reports queries, pages, clicks, impressions, CTR, and average position. Revenue teams should connect that data to landing page and payment outcomes.
## What this guide covers
- Understand what Google Search Console reports
- Know the difference between clicks and impressions
- Use Search Console data without over-reading it
- Connect organic search data to revenue
Google Search Console is a free Google tool for understanding how a verified website appears in organic Google Search.
It can show which queries, pages, countries, devices, and search appearances led to impressions and clicks.
Search Console is one of the most useful SEO tools because it reports data from Google Search itself, not only from your website analytics.
## What Search Console reports
The most common Search Console metrics are:
- Impressions.
- Clicks.
- Click-through rate.
- Average position.
- Query.
- Page.
- Country.
- Device.
For content teams, the query and page reports are especially useful. They show which searches are discovering which pages.
## Clicks, impressions, CTR, and position
An impression means a result from your site appeared in search results.
A click means someone clicked through to your site.
Click-through rate is clicks divided by impressions.
Average position is the average ranking position for the selected query, page, or filter. It is useful directionally, but it can vary by country, device, personalization, and result type.
## Search Console vs analytics
Search Console tells you what happened in Google Search before the visit.
Website analytics tells you what happened after the visit.
For example, Search Console can show that a guide received 10,000 impressions and 300 clicks. Analytics can show whether those visitors read more pages, signed up, started checkout, or became customers.
## The revenue reporting gap
Search Console does not know your revenue. It does not know which organic visitors later paid, renewed, refunded, or churned.
To estimate organic search revenue, you need to connect:
1. Search Console query and page data.
2. Organic landing page sessions.
3. Signup or checkout attribution.
4. Payment events.
That is where revenue attribution becomes useful for SEO. It helps you prioritize content by business outcome, not only clicks.
## Next steps
Read [Google Search Console revenue reports](https://attribiq.com/guides/search-data-revenue-reports) for the AttribIQ workflow. Use [landing page revenue attribution](https://attribiq.com/guides/landing-page-revenue-attribution) to compare organic pages by paid outcomes.
## Frequently asked questions
### Is Google Search Console the same as Google Analytics?
No. Search Console focuses on organic Google Search visibility and clicks. Google Analytics focuses on site and app behavior after visitors arrive.
### What is an impression in Google Search Console?
An impression usually means a URL from your site appeared in Google Search results for a query.
### Can Search Console show revenue by query?
Not by itself. Search Console reports search performance. Revenue by query requires joining organic landing pages and search data to payment outcomes.
### Why does Search Console data lag?
Search Console data is not real time. Recent rows can be delayed or adjusted, so teams should avoid treating same-day search data as final.
---
# Search Console Revenue Reports
> Import Google Search Console data and estimate organic revenue by query and landing page while keeping estimates distinct from payment attribution.
Canonical page: [https://attribiq.com/guides/search-data-revenue-reports](https://attribiq.com/guides/search-data-revenue-reports)
Category: Campaigns & UTMs
Last updated: 2026-09-04
Topics: search data, seo, organic search, csv import, revenue attribution, paid plans
## Summary
Search performance rows explain which queries and pages bring organic traffic. AttribIQ connects that search data to revenue reports by matching organic landing pages with attributed payment events. CSV import is the default path; Google Search Console OAuth is optional and disabled unless explicitly configured.
## What this guide covers
- Understand what search data imports store
- Know how AttribIQ estimates organic search revenue
- Import CSV rows or post normalized search performance rows
- Keep Google endpoints out of the default analytics path
Search tools can show clicks, impressions, click-through rate, and average position. They do not know which organic visits became paying customers. AttribIQ adds the revenue side by joining imported search rows with revenue already attributed inside your project.
Use this report when you want to answer questions like:
- Which organic landing pages created paid accounts?
- Which search queries are associated with revenue, not only clicks?
- Which SEO pages attract traffic but fail to create payments?
- Which content topics should get more product or conversion work?
## Import Paths
AttribIQ treats search performance as imported data, not as a required Google dependency.
The supported paths are:
- CSV import from Search Console exports or another search reporting tool.
- Generic Search Performance API rows posted by your backend or scripts.
- Optional Google Search Console OAuth, disabled by default.
- Future adapters such as Bing Webmaster Tools using the same row shape.
## Row Shape
Each imported row can include:
- date
- landing page
- query
- country
- device
- clicks
- impressions
- click-through rate
- average position
CSV headers can use common names such as `date`, `query`, `page`, `clicks`, `impressions`, `ctr`, and `position`.
The generic API accepts the same normalized row shape at `/v1/projects/{project}/search-data/imports`.
## How Revenue Is Matched
Search data does not expose a user-level payment identifier that can be joined directly to Stripe or another billing system. AttribIQ therefore treats search data as an organic search context layer.
The revenue report compares:
- imported organic landing pages
- organic source and referrer data from the AttribIQ tracker
- attributed revenue rows from Stripe webhooks or the Payment API
- the selected attribution model and reporting range
That makes query-level revenue an estimate, not a payment processor ledger. Use it to prioritize SEO work, not to replace payment reconciliation.
## Google-Free Default
AttribIQ does not need GA4, Google tags, or Google browser endpoints for search revenue reporting.
CSV and generic API imports keep the data flow under your control. The optional Google Search Console adapter is only available when `GOOGLE_SEARCH_CONSOLE_ENABLED=true` and the OAuth credentials are configured on the API server.
## What To Check After Importing
Start with landing pages before queries. Landing pages are easier to reason about because they map directly to AttribIQ sessions and payment attribution.
Look for:
- pages with high clicks and low revenue
- pages with low clicks and high paid conversion
- branded queries that mostly land on pricing or comparison pages
- non-branded queries that start trial or checkout paths
- pages where direct or unattributed revenue suggests a broken handoff
## Limits To Keep In Mind
Imported search data inherits the limits of its source. Search Console exports can have privacy thresholds and reporting delays. Other tools may aggregate rows differently.
For that reason, AttribIQ keeps search data separate from the payment event source of truth. Stripe webhooks and Payment API events remain the revenue record. Search imports help explain the organic search path that led to that revenue.
## Next Steps
If organic search is a key channel, read [landing page revenue attribution](https://attribiq.com/guides/landing-page-revenue-attribution) and [UTM revenue attribution](https://attribiq.com/guides/utm-revenue-attribution) next. If revenue is not appearing against organic pages, check [direct traffic revenue attribution](https://attribiq.com/guides/direct-traffic-revenue-attribution) for common handoff gaps.
## Frequently asked questions
### Does AttribIQ require Google Search Console?
No. Search data reporting works from CSV imports or normalized Search Performance API rows. Google Search Console OAuth is an optional adapter that must be explicitly enabled.
### Is search data import available on the free plan?
No. Search data revenue reports are available on paid AttribIQ plans.
### Does AttribIQ add Google scripts to my website?
No. Search data imports are backend imports. CSV and generic API imports do not call Google endpoints, and the optional Google adapter does not add browser-side Google tags.
---
# First-touch vs last-touch attribution
> Compare first-touch, last-touch, and session-touch attribution models for SaaS revenue reporting.
Canonical page: [https://attribiq.com/guides/first-touch-vs-last-touch-attribution](https://attribiq.com/guides/first-touch-vs-last-touch-attribution)
Category: Revenue Attribution
Last updated: 2026-05-20
Topics: first touch, last touch, attribution models, saas analytics
## Summary
First-touch shows what introduced paid accounts. Last-touch shows what happened closest to conversion. Session-touch shows the context of the payment session. Use all three at first because each answers a different business question.
## What this guide covers
- Know what each simple attribution model means
- Choose the right model for acquisition, conversion, and checkout questions
- Avoid treating one model as universal truth
- Explain revenue attribution reports to non-analytics teammates
Attribution models are rules for assigning revenue credit.
For most SaaS builders, the first useful set is first-touch, last-touch, and session-touch. They are easy to explain, quick to implement, and good enough to reveal whether acquisition and conversion work are pointing in the right direction.
## First-touch attribution
First-touch gives credit to the earliest known source or landing page for a visitor.
Use it to answer:
- Which channels introduce customers who eventually pay?
- Which blog posts or landing pages start good journeys?
- Which campaigns create long-term customer value?
First-touch is useful for content, SEO, referrals, partnerships, and community traffic where the first visit may happen well before checkout.
## Last-touch attribution
Last-touch gives credit to the latest known source before conversion.
Use it to answer:
- What pushed the customer over the line?
- Which campaigns or pages close the sale?
- Which retargeting, launch, or pricing paths create paid conversion?
Last-touch can over-credit direct traffic, branded search, or checkout-adjacent pages if you read it without context.
## Session-touch attribution
Session-touch gives credit to the active session where the revenue event happened.
Use it to answer:
- What was happening when the customer paid?
- Did the payment happen after a direct return, a campaign click, or an API reference visit?
- Which pages appeared in the checkout session?
Session-touch is practical for debugging the payment journey. It is not always the best acquisition model.
## A simple example
A visitor finds your blog from search on Monday. On Wednesday they read a comparison page from a newsletter link. On Friday they type your domain, visit pricing, and subscribe.
| Model | Credit |
| --- | --- |
| First-touch | Search and the original blog landing page |
| Last-touch | Direct or the latest known non-direct source, depending on your rule |
| Session-touch | Friday's checkout session |
All three can be true. The mistake is asking one report to answer every question.
## How to use the models
Start every revenue review with the question:
- Acquisition question: use first-touch.
- Conversion question: use last-touch.
- Checkout debugging question: use session-touch.
- Retention quality question: compare renewal, refund, and churn by original source.
This keeps the conversation clear. It also prevents teams from changing attribution rules every time a favored channel looks weaker than expected.
## Next steps
Read [direct traffic revenue attribution](https://attribiq.com/guides/direct-traffic-revenue-attribution) to understand why direct often appears in last-touch reports. Then connect payments with [Stripe revenue attribution](https://attribiq.com/guides/stripe-revenue-attribution).
## Frequently asked questions
### Which model is most accurate?
No single model is universally most accurate. Each model is a rule for assigning credit. The useful choice depends on the question you are asking.
### Should direct traffic get last-touch credit?
Sometimes, but direct should not always erase a known campaign. Many teams keep direct as session-touch context while preserving known campaign credit for first-touch reports.
### When should I use multi-touch attribution?
Use simple models first. Consider multi-touch only when you have enough volume, multiple paid channels, and a real decision that simple models cannot support.
### Can these models handle renewals?
Yes. A renewal can inherit original first-touch and last-touch acquisition context, while also showing the current renewal event separately.
---
# Direct traffic revenue attribution
> Handle direct traffic in SaaS revenue reports without overwriting useful UTM, referrer, and campaign attribution.
Canonical page: [https://attribiq.com/guides/direct-traffic-revenue-attribution](https://attribiq.com/guides/direct-traffic-revenue-attribution)
Category: Campaigns & UTMs
Last updated: 2026-09-02
Topics: direct traffic, attribution, utm, campaign reporting
## Summary
Direct traffic often means the browser did not send a useful source, not that there was no source. Preserve earlier known campaign context, report direct session-touch separately, and exclude payment processor redirects from acquisition credit.
## What this guide covers
- Understand what direct traffic can mean
- Prevent direct sessions from overwriting known campaigns
- Handle Stripe and payment redirects correctly
- Read direct revenue without hiding acquisition sources
Direct traffic is one of the most misunderstood rows in analytics.
Direct usually means the browser did not provide a useful referrer or campaign parameter. It does not always mean the person typed your URL from memory. It can come from bookmarks, email apps, messaging apps, documents, private browsing, privacy tools, redirects, and missing UTMs.
## Why direct takes too much credit
Revenue often happens after a return visit. A customer might first arrive from a newsletter, think for a day, then come back directly and pay.
If your attribution system overwrites the source with every new session, the newsletter loses credit and direct gets the revenue. That makes campaign performance look worse than it is.
The fix is to keep multiple views:
- First-touch source: the earliest known source.
- Last known non-direct source: the latest meaningful source before conversion.
- Session-touch source: the source of the payment session.
Direct can appear in the session-touch view without erasing useful acquisition history.
For example, suppose one matched payment has this recorded path:
| Time | Recorded evidence |
| --- | --- |
| Monday | `utm_source=newsletter`, landing page `/guides/payment-api-reference` |
| Wednesday | Direct session, pricing page, checkout |
| Payment | Visitor and session IDs present in billing metadata |
The first-touch report selects the newsletter. The payment-session report shows direct. Neither view proves what caused the purchase; together they explain the evidence AttribIQ received.
## Exclude payment processor redirects
Payment systems can create misleading referrers. A checkout redirect from `checkout.stripe.com` is not a marketing source. It is checkout infrastructure.
Exclude payment processor domains from acquisition credit:
- `checkout.stripe.com`
- Customer portal domains.
- Hosted billing pages.
- Payment confirmation redirects.
Keep those domains in debug logs if useful, but do not let them become source rows in revenue reports.
## Use direct as a signal
Direct is not bad. High direct revenue can mean strong brand demand, repeat visits, word of mouth, or private sharing.
But if direct dominates all revenue, investigate:
- Are campaign links missing UTMs?
- Are email links tagged consistently?
- Are internal links incorrectly tagged with UTMs?
- Is checkout metadata missing?
- Are app and marketing domains configured as allowed hosts?
- Are payment redirects excluded?
## Attribution rule example
A simple rule works well for early SaaS:
```txt
If a session source is direct and the visitor has a known prior campaign, keep the prior campaign for first-touch and last-known-non-direct reports. Still show direct for the payment session.
```
This makes reports honest. It does not hide that checkout happened in a direct session, but it also does not discard the campaign that introduced the customer.
## Next steps
Read [first-touch vs last-touch attribution](https://attribiq.com/guides/first-touch-vs-last-touch-attribution) to decide which model answers each question. Use [UTM revenue attribution](https://attribiq.com/guides/utm-revenue-attribution) to reduce preventable direct traffic.
## Frequently asked questions
### Does direct traffic mean the user typed the URL?
Sometimes. It can also mean bookmarks, private apps, missing referrer headers, email clients, messaging apps, privacy tools, or broken campaign tagging.
### Should direct ever receive revenue credit?
Yes. It is useful as session-touch context and can be true first-touch for known brand traffic. It should not automatically erase a previous known campaign.
### Should checkout.stripe.com be a referrer?
Payment processor domains should usually be excluded from acquisition referrer reports. They are part of checkout infrastructure, not a marketing source.
### How do I reduce unattributed direct traffic?
Use consistent UTMs for campaigns, avoid tagging internal links, preserve first-touch context, and pass visitor identifiers into checkout.
---
# Generic Payment API revenue tracking
> Send normalized revenue events to AttribIQ when you use a custom checkout or a payment provider that is not connected natively yet.
Canonical page: [https://attribiq.com/guides/generic-payment-api-revenue-tracking](https://attribiq.com/guides/generic-payment-api-revenue-tracking)
Category: Stripe & Payments
Last updated: 2026-05-20
Topics: payment api, revenue events, custom checkout, idempotency
## Summary
The generic Payment API is for teams that do not use Stripe or need custom revenue ingestion. Send stable transaction IDs, event types, amounts, currency, timestamps, and AttribIQ visitor or session identifiers so revenue can be attributed.
## What this guide covers
- Understand when to use the generic Payment API
- Send idempotent revenue events
- Choose supported event types for purchases, renewals, refunds, and churn
- Connect custom payments to AttribIQ visitor and session data
The generic Payment API lets any backend send revenue events into AttribIQ.
Use it when you do not use Stripe, when your payment provider is not supported yet, or when your billing system already normalizes payment activity internally.
## Event shape
The event should describe what happened, when it happened, how much money changed, and which AttribIQ visitor or session should receive attribution context.
```http
POST /v1/revenue
Authorization: Bearer sk_project_...
Idempotency-Key: txn_123
Content-Type: application/json
```
```json
{
"provider": "custom",
"transaction_id": "txn_123",
"event_type": "purchase",
"amount": 2900,
"currency": "EUR",
"occurred_at": "2026-05-20T10:30:00Z",
"visitor_id": "v_abc",
"session_id": "s_def",
"customer_id_hash": "hash_123",
"metadata": {
"plan": "builder",
"product": "monthly_subscription"
}
}
```
Amounts should be sent in minor units. For EUR and USD, `2900` means 29.00.
## Supported event types
Start with a small vocabulary:
- `purchase`
- `subscription_started`
- `renewal`
- `upgrade`
- `downgrade`
- `refund`
- `cancellation`
- `churn`
Keep event names stable. If every integration invents new names, the dashboard becomes hard to compare.
## Idempotency
Payment systems retry. Your backend may retry too. AttribIQ should receive a stable transaction ID and an idempotency key so duplicate submissions do not create duplicate revenue.
Good transaction IDs are provider object IDs, invoice IDs, charge IDs, or your own durable billing event IDs.
Avoid generated random IDs for every retry. They defeat idempotency.
## Attribution identifiers
The browser tracker exposes an attribution object. Your app should pass it to your backend when a checkout, upgrade, or purchase begins.
At minimum, send:
- `visitor_id`
- `session_id`
- `customer_id_hash` when an authenticated customer exists
The customer hash should be a stable one-way identifier, not raw email. That keeps reporting useful without turning analytics into a customer database.
## Processing rules
A robust receiver should:
1. Validate the project API key.
2. Validate the event type, amount, currency, and timestamp.
3. Enforce idempotency with provider plus transaction ID.
4. Store accepted events for debugging.
5. Write normalized revenue events into analytics storage.
6. Join the event to prior visitor and session data.
If attribution fields are missing, accept the revenue as unattributed. Totals must stay correct even when attribution is incomplete.
## Next steps
Read [what revenue attribution is](https://attribiq.com/guides/what-is-revenue-attribution) for the model, or use [Stripe revenue attribution](https://attribiq.com/guides/stripe-revenue-attribution) if Stripe is your payment provider.
## Frequently asked questions
### When should I use the generic Payment API?
Use it when your payment provider is not connected natively, when you run custom billing, or when you want to send normalized revenue events from your own backend.
### What is the most important field?
transaction_id is critical for idempotency. It lets AttribIQ reject duplicates when the same payment event is retried.
### Can I send negative amounts for refunds?
Prefer a refund event type with the refunded amount as a positive integer in minor units. The reporting layer can subtract it consistently.
### Do I need both visitor_id and session_id?
Send both when you have them. Visitor ID helps connect long journeys. Session ID helps connect the payment to the active checkout session.
---
# GDPR-friendly revenue analytics
> Design revenue analytics with data minimization, clear purpose, EU hosting, and careful handling of identifiers.
Canonical page: [https://attribiq.com/guides/gdpr-friendly-revenue-analytics](https://attribiq.com/guides/gdpr-friendly-revenue-analytics)
Category: Privacy & EU Analytics
Last updated: 2026-05-20
Topics: gdpr, privacy, eu analytics, data minimization
## Summary
GDPR-friendly revenue analytics starts with minimization. Collect the few analytics and payment identifiers needed to answer revenue questions, avoid raw personal data where possible, document the purpose, and make sure your legal basis and cookie choices match your setup.
## What this guide covers
- Separate legal compliance from product design choices
- Understand why data minimization matters for analytics
- Use hashed or pseudonymous identifiers where possible
- Know when to involve legal review
GDPR-friendly revenue analytics is not a single switch. It is a set of product and operational choices that reduce unnecessary data collection while preserving useful reporting.
The official GDPR text on EUR-Lex defines principles such as lawfulness, fairness, transparency, purpose limitation, data minimization, accuracy, storage limitation, integrity, and confidentiality. Use official sources such as [Regulation (EU) 2016/679](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX%3A32016R0679) and your legal counsel for compliance decisions.
## Start with the reporting purpose
Define the business questions before collecting data:
- Which source created paid accounts?
- Which campaign created MRR?
- Which landing page created refunds or churn?
- Which signup funnel step loses paid conversion?
Those questions do not require raw email addresses, full names, or invasive behavioral profiles. They usually require page, source, campaign, session, visitor, and normalized payment event data.
## Minimize identifiers
A practical revenue analytics setup can use:
- Project ID.
- Visitor ID.
- Session ID.
- Hashed customer ID after login or checkout.
- Payment transaction ID.
- Payment event type, amount, currency, and timestamp.
Avoid putting raw emails, names, billing addresses, or free-form customer notes into analytics metadata. If you need customer support or billing records, keep them in the system designed for that purpose.
## Be honest about pseudonymous data
Pseudonymous identifiers are useful because they reduce direct identifiability, but they may still be personal data under GDPR depending on context. Treat them carefully:
- Keep identifiers scoped to the project.
- Use retention limits.
- Avoid cross-site sharing unless the user has explicitly designed for it.
- Restrict access to raw event exports.
- Document what identifiers mean.
## Cookie choices matter
Cookieless analytics can reduce storage on the user's device and can lower the amount of data collected. Optional first-party collection can preserve identifiers across reloads and later visits but changes the privacy posture.
Do not describe a setup as "no consent needed" without legal review. Cookie and tracking rules depend on jurisdiction, implementation details, and purpose.
## Revenue data needs extra care
Payment events can reveal commercially sensitive behavior even when they do not include raw personal data. Protect them with:
- Project-scoped API keys.
- Idempotency checks.
- Access controls.
- Audit logs for sensitive exports.
- Retention settings.
- Clear processor terms.
## AttribIQ posture
AttribIQ is designed as EU-hosted web and revenue analytics for SaaS teams. The product starts cookieless by default, supports optional first-party collection, and focuses on traffic, conversion, and revenue questions with a limited event set.
Use [cookieless analytics with revenue attribution](https://attribiq.com/guides/cookieless-analytics-with-revenue-attribution) for implementation tradeoffs, then read [Install AttribIQ](https://attribiq.com/guides/install-attribiq) for tracker and Payment API setup.
## Frequently asked questions
### Is this legal advice?
No. This guide explains product and implementation patterns. Your legal basis, notices, consent flows, and data processing terms should be reviewed for your company and jurisdictions.
### Does cookieless analytics automatically avoid GDPR?
No. GDPR can still apply when personal data or pseudonymous identifiers are processed. Cookieless design can reduce risk and data volume, but it is not a legal exemption by itself.
### Can revenue analytics use customer IDs?
Use stable hashes or internal pseudonymous IDs instead of raw emails where possible. Store only what the report needs.
### Why does EU hosting matter?
EU hosting can simplify data residency posture for EU companies, but it does not replace GDPR obligations such as purpose limitation, transparency, retention controls, and processor terms.
---
# What is a first-party cookie?
> A first-party cookie is set by the website a visitor is using and can help remember sessions, preferences, login state, and analytics identifiers.
Canonical page: [https://attribiq.com/guides/what-is-a-first-party-cookie](https://attribiq.com/guides/what-is-a-first-party-cookie)
Category: Privacy & EU Analytics
Last updated: 2026-06-25
Topics: first-party cookie, cookies, privacy, analytics, gdpr
## Summary
A first-party cookie is set by the site the visitor is on. It can support sessions, preferences, and analytics continuity, but privacy and consent requirements still depend on what the cookie does and which laws apply.
## What this guide covers
- Define first-party cookies
- Compare first-party and third-party cookies
- Understand analytics use cases
- Avoid overclaiming privacy compliance
A first-party cookie is a cookie set by the website the visitor is using.
If someone visits `example.com`, a cookie set by `example.com` is first-party in that context. First-party cookies can remember login state, preferences, carts, session information, and analytics identifiers.
## First-party vs third-party cookies
The difference is the domain relationship.
A first-party cookie is set by the site in the browser address bar. A third-party cookie is set by another domain embedded on the page, such as an advertising, tracking, or embedded service domain.
Browsers increasingly restrict third-party cookies because they can track people across unrelated sites. First-party cookies are generally more reliable, but they are not automatically free from privacy rules.
## Why analytics uses first-party cookies
Analytics tools use identifiers to understand whether pageviews belong to the same session or returning visitor.
A first-party analytics cookie can help answer:
- Is this a new or returning visitor?
- Did the visitor come back after a campaign click?
- Which landing page started the journey?
- Did the same visitor later sign up or start checkout?
Without a stable identifier, analytics can still count pageviews and sessions, but longer journeys are harder to connect.
## First-party cookies and revenue attribution
Revenue attribution often needs continuity between the first visit and the payment event.
For short journeys, a session identifier may be enough. For longer trial-to-paid journeys, a first-party visitor identifier can improve attribution accuracy because the payment may happen days or weeks after the first visit.
That does not mean every team should use the strongest possible identifier. The right setup depends on privacy requirements, consent choices, product value, and reporting needs.
## Privacy considerations
Do not assume that first-party means compliant.
The privacy question depends on:
- What the cookie stores.
- Whether the data can relate to a person.
- Whether the cookie is strictly necessary.
- Whether analytics consent is required.
- What your privacy notice says.
- Which jurisdictions apply.
Use data minimization. Store only what the report needs, avoid raw personal data where possible, and document the purpose clearly.
## Next steps
Read [cookieless analytics with revenue attribution](https://attribiq.com/guides/cookieless-analytics-with-revenue-attribution) to compare privacy-minimizing tracking options. For implementation choices, see [first-party tracker proxy for analytics](https://attribiq.com/guides/first-party-tracker-proxy).
## Frequently asked questions
### Is a first-party cookie always allowed?
No. Whether a cookie is allowed without consent depends on its purpose, jurisdiction, and local rules. Strictly necessary cookies are treated differently from analytics or advertising cookies.
### How is a first-party cookie different from a third-party cookie?
A first-party cookie is set by the site the visitor is using. A third-party cookie is set by another domain embedded on the page.
### Can analytics use first-party cookies?
Yes. First-party cookies can improve visitor and session continuity, but teams still need to review privacy notices, legal basis, and consent requirements.
### Does cookieless analytics avoid all privacy obligations?
No. Cookieless analytics can reduce data collection, but privacy law can still apply when personal or pseudonymous data is processed.
---
# Cookieless analytics with revenue attribution
> Compare cookieless analytics with first-party attribution when Stripe or Payment API revenue needs to be tied to visits.
Canonical page: [https://attribiq.com/guides/cookieless-analytics-with-revenue-attribution](https://attribiq.com/guides/cookieless-analytics-with-revenue-attribution)
Category: Privacy & EU Analytics
Last updated: 2026-09-02
Topics: cookieless analytics, revenue attribution, privacy, first-party collection
## What this guide covers
- Understand the limits of cookieless visitor continuity
- Choose when first-party collection is worth it
- Avoid promising perfect attribution
- Keep revenue reporting useful when attribution is partial
Cookieless analytics reduces the amount of state stored in a visitor's browser. In AttribIQ's default cookieless mode, visitor and session identifiers use tab-scoped session storage. They survive reloads and SPA navigation in the same tab, but are not written to cookies or persistent local storage and do not provide durable cross-tab or returning-visitor identity. If session storage is unavailable, the tracker falls back to page memory.
Revenue attribution adds a harder requirement: connecting a later payment back to an earlier visit. That connection can be easy in the same session and harder across days, devices, browsers, or private contexts.
## What cookieless can do well
Cookieless analytics is good for:
- Pageviews.
- Referrers.
- Sources.
- UTM campaigns.
- Country-level location and devices at an aggregate level.
- Same-session goals.
- Same-session checkout attribution.
If a visitor lands on a campaign page and pays in the same session, cookieless attribution can still be useful.
## Where cookieless gets weaker
Cookieless attribution is weaker when:
- The user returns days later.
- The user closes the tab or starts a separate browser session.
- The user switches browser or device.
- The signup happens in an app subdomain.
- Checkout happens after a long trial.
- Privacy tools remove or change signals.
- The payment event lacks visitor and session identifiers.
These are not product bugs. They are tradeoffs. A privacy-minimizing setup collects less continuity data, so some attribution becomes less complete.
## Optional first-party collection
First-party collection can keep a stable, project-scoped visitor identifier in local storage until the configured attribution window has elapsed without activity. Sessions still rotate after 30 minutes of inactivity. This preserves continuity across later visits and gives first-touch and last-touch reports more evidence to work with.
Use it when:
- You sell subscriptions.
- Trial-to-paid journeys last more than one session.
- Paid campaigns need revenue reporting.
- You can update consent, notices, and internal documentation appropriately.
Do not turn it on just because more data sounds better. The mode should match your business need and privacy posture.
## Country-level GeoIP
AttribIQ uses trusted proxy country headers when available and can use a locally provisioned MaxMind-compatible country MMDB for direct collector traffic. Raw IP addresses are not stored in analytics event rows. Country is the default location granularity; region and city-level enrichment should be treated as a stricter privacy choice and reviewed separately.
## Keep unattributed revenue visible
The dashboard should never hide revenue just because attribution is missing. It should show:
- Total revenue.
- Attributed revenue.
- Unattributed revenue.
- Revenue by first-touch source.
- Revenue by session-touch source.
This keeps financial totals honest while making attribution quality visible.
## Payment bridge still matters
Cookieless or not, payment attribution still needs a bridge. When checkout starts, pass the AttribIQ attribution object to your backend and include visitor or session identifiers in Stripe metadata or the Payment API.
Without that bridge, the payment system can report money but cannot connect it to the earlier analytics path.
## Next steps
Read [pass attribution to Stripe Checkout](https://attribiq.com/guides/pass-attribution-to-stripe-checkout) for the checkout bridge. Read [GDPR-friendly revenue analytics](https://attribiq.com/guides/gdpr-friendly-revenue-analytics) for privacy design considerations.
## Frequently asked questions
### Can cookieless analytics attribute revenue?
Yes, but with limitations. It can attribute revenue when the payment happens in a context that can be connected to a session or visitor. Long return journeys may be less complete without a stable first-party identifier.
### Is first-party collection required?
No. It is optional. Use it when the business value of stronger attribution justifies the additional privacy and consent review.
### What should dashboards show when attribution is incomplete?
They should show unattributed revenue explicitly so totals stay correct and data quality gaps are visible.
### Does cookieless mean anonymous?
Not necessarily. A cookieless setup can still process data that relates to a person or device in some contexts. Treat privacy claims carefully.
---
# Signup-to-paid funnel tracking
> Track the path from visit to paid account, find where customers drop out, and see how later refunds or churn change the result.
Canonical page: [https://attribiq.com/guides/signup-to-paid-funnel](https://attribiq.com/guides/signup-to-paid-funnel)
Category: Goals & Funnels
Last updated: 2026-09-02
Topics: funnels, signup, trial, paid conversion, saas metrics
## Summary
A signup-to-paid funnel should not stop at account creation. Track the steps from visit to signup to trial to checkout to payment, then connect renewals, refunds, and churn so the funnel reflects revenue quality.
## What this guide covers
- Define a practical SaaS signup-to-paid funnel
- Choose events that are stable enough for reporting
- Segment funnel conversion by source, campaign, and landing page
- Avoid optimizing signups that do not become revenue
A signup-to-paid funnel shows where visitors become customers and where money leaks out.
The common mistake is stopping the funnel at signup. Signups matter, but SaaS revenue comes from paid conversion, renewals, expansion, and retention. A source that creates many free accounts but no paid customers is not performing the same as a source that creates fewer signups and more MRR.
## A practical funnel
Start with a short funnel:
1. Landing page visit.
2. Signup started.
3. Account created.
4. Activation event completed.
5. Checkout started.
6. Subscription started or purchase completed.
7. First renewal.
You can add trial started, invite sent, project created, or integration connected when those actions predict paid conversion.
## Keep the unit explicit
A visitor, user, account, subscription and payment are not interchangeable:
- A visitor is the browser journey recorded before identity is known.
- A user is a person who signs in; one account may contain several users.
- An account is the SaaS customer entity making the buying decision.
- A subscription is the recurring billing agreement for an account.
- A payment is one purchase, invoice or refund event.
Choose the denominator beside each metric. “20% paid conversion” is ambiguous unless the report says whether it means visitors-to-paying-accounts, signups-to-subscriptions or trial-accounts-to-first-payment.
## Choose stable events
Good funnel events are durable. They should survive UI redesigns and product copy changes.
Prefer:
- `signup_started`
- `account_created`
- `project_created`
- `trial_started`
- `checkout_started`
- `subscription_started`
- `renewal`
Avoid events that describe small button clicks unless they are truly meaningful. Too many steps make the funnel noisy.
## Segment by acquisition context
The funnel becomes more useful when segmented by:
- Source.
- Campaign.
- Landing page.
- Referrer.
- Device.
- Country.
- First-touch vs last-touch model.
This shows whether the problem is acquisition quality or product conversion. If one campaign gets many signups but few paid accounts, the campaign might be overpromising. If every source drops at checkout, the checkout path may be the issue.
## Include revenue quality
Paid conversion rate is not enough. Add:
- MRR by source.
- Revenue per signup.
- Refund rate.
- Renewal rate.
- Churn by source.
This prevents the team from optimizing for cheap signups that do not retain.
## Use the funnel for decisions
The best funnel review ends with a concrete action:
- Rewrite a landing page.
- Improve onboarding before trial.
- Fix checkout friction.
- Stop a campaign that produces refunds.
- Double down on a source with high renewal quality.
The report should help decide where to spend engineering, content, and marketing time.
## Next steps
Read [landing page revenue attribution](https://attribiq.com/guides/landing-page-revenue-attribution) to connect the first funnel step to pages. Read [Stripe webhook revenue events](https://attribiq.com/guides/stripe-webhook-revenue-events) to make the paid and renewal steps reliable.
## Frequently asked questions
### What is the first funnel step?
For acquisition analysis, start with a landing page visit or qualified session. For product analysis, start with signup. Keep those views separate.
### Should every product action be a funnel step?
No. Choose steps that represent real commitment, such as signup, activation, trial started, checkout started, and paid.
### How do I account for trials?
Track trial_started and paid conversion separately. A source that creates many trials but few paid accounts needs different treatment than a source that creates fewer but better trials.
### Should churn be part of the funnel?
Churn is after conversion, but it should be connected to the same acquisition source so you can see revenue quality.
---
# What is MRR?
> Monthly recurring revenue, or MRR, is the normalized recurring subscription revenue a SaaS business expects in a month.
Canonical page: [https://attribiq.com/guides/what-is-mrr](https://attribiq.com/guides/what-is-mrr)
Category: Goals & Funnels
Last updated: 2026-06-25
Topics: mrr, monthly recurring revenue, saas metrics, subscriptions
## Summary
MRR is normalized monthly subscription revenue. It helps SaaS teams compare recurring revenue across plans, upgrades, downgrades, renewals, and churn. It becomes more useful when connected to acquisition source and campaign.
## What this guide covers
- Define monthly recurring revenue
- Understand expansion, contraction, and churned MRR
- Avoid common MRR calculation mistakes
- Connect MRR to attribution reports
MRR stands for monthly recurring revenue.
It is the normalized recurring subscription revenue a SaaS business expects in a month. If a customer pays EUR 120 per year, the normalized MRR is EUR 10 per month.
MRR helps teams understand the recurring part of the business without waiting for every invoice schedule to line up.
## Types of MRR
Common MRR components are:
- New MRR from new customers.
- Expansion MRR from upgrades or added seats.
- Contraction MRR from downgrades or removed seats.
- Churned MRR from cancelled subscriptions.
- Reactivation MRR from returning customers.
Net MRR movement is the combination of those changes over a period.
## MRR vs revenue collected
MRR is not the same as cash collected.
Cash collected depends on invoices, billing intervals, payment timing, refunds, taxes, and failed payments. MRR is a normalized subscription metric.
For example, an annual subscription can collect EUR 1,200 today and add EUR 100 in MRR. The cash and MRR are both useful, but they answer different questions.
## Common MRR mistakes
Avoid these mistakes:
- Counting one-time setup fees as MRR.
- Ignoring downgrades and contraction.
- Treating failed payments as immediate churn without a policy.
- Mixing tax-inclusive and tax-exclusive amounts.
- Reporting MRR without source or cohort context.
MRR should be calculated consistently, or trends become hard to trust.
## Why MRR needs attribution
MRR by source is more useful than signups by source.
A campaign can create many free accounts and little recurring revenue. Another source can create fewer customers with higher expansion and lower churn.
Attribution lets you compare sources by:
- New MRR.
- Expansion MRR.
- Churned MRR.
- Net MRR.
- Revenue per visitor.
- Payback quality.
## Next steps
Use [signup-to-paid funnel tracking](https://attribiq.com/guides/signup-to-paid-funnel) to connect visitors to paid subscriptions. Read [Stripe revenue attribution for SaaS](https://attribiq.com/guides/stripe-revenue-attribution) when subscription events need to flow from Stripe into revenue reports.
## Frequently asked questions
### What does MRR stand for?
MRR stands for monthly recurring revenue.
### Is MRR the same as cash collected?
No. MRR normalizes recurring subscription value into a monthly number. Cash collection depends on billing schedules, invoices, taxes, refunds, and payment timing.
### Should one-time setup fees count as MRR?
Usually no. MRR should represent recurring subscription revenue, not one-time fees.
### Why attribute MRR by source?
MRR by source shows which channels create recurring subscription value, not only signups or one-time payments.
---
# What is churn?
> Churn measures lost customers or recurring revenue when subscriptions cancel, fail to renew, downgrade, or stop paying.
Canonical page: [https://attribiq.com/guides/what-is-churn](https://attribiq.com/guides/what-is-churn)
Category: Goals & Funnels
Last updated: 2026-06-25
Topics: churn, revenue churn, customer churn, saas metrics
## Summary
Churn measures lost customers or recurring revenue. SaaS teams should separate customer churn from revenue churn and connect churn back to acquisition source so growth is measured by quality, not only volume.
## What this guide covers
- Define customer churn and revenue churn
- Understand why churn needs source context
- Avoid common churn reporting mistakes
- Connect churn to revenue attribution
Churn measures customers or recurring revenue that is lost.
For SaaS teams, churn usually appears when a subscription is cancelled, fails to renew, downgrades, or stops paying. Churn is one of the most important quality checks for growth because it tells you whether customers stay.
## Customer churn vs revenue churn
Customer churn measures lost accounts.
```txt
customer churn = lost customers / starting customers
```
Revenue churn measures lost recurring revenue.
```txt
revenue churn = lost recurring revenue / starting recurring revenue
```
These can tell different stories. Losing one large account can create low customer churn and high revenue churn. Losing several small accounts can create high customer churn and low revenue churn.
## Gross churn vs net churn
Gross revenue churn counts lost recurring revenue from cancellations and downgrades.
Net revenue churn subtracts expansion from retained customers. If existing customers upgrade enough to offset lost revenue, net revenue churn can be negative.
Negative net revenue churn is usually a strong SaaS signal, but it should not hide acquisition quality. A channel that creates customers who churn quickly may still be expensive even if the whole business expands.
## Why churn needs attribution
Most acquisition reports stop at signup or first payment. That can make weak channels look strong.
Churn attribution connects lost revenue back to the original source, campaign, landing page, or signup path. It helps answer:
- Which channels create customers who stay?
- Which campaigns create refunds or cancellations?
- Which landing pages attract low-fit accounts?
- Which sources expand after signup?
This matters because revenue quality is not visible in traffic reports.
## Common churn reporting mistakes
Avoid these mistakes:
- Mixing customer churn and revenue churn.
- Treating failed payment retries as immediate churn without a policy.
- Ignoring downgrades.
- Looking only at first-month churn.
- Reporting churn without source, plan, or cohort.
Churn should be connected to the same acquisition data used for signup and revenue reports.
## Next steps
Read [signup-to-paid funnel tracking](https://attribiq.com/guides/signup-to-paid-funnel) to keep churn connected to the funnel. Use [Stripe webhook revenue events](https://attribiq.com/guides/stripe-webhook-revenue-events) to normalize cancellations, refunds, renewals, and subscription changes.
## Frequently asked questions
### What is customer churn?
Customer churn is the percentage of customers lost during a period.
### What is revenue churn?
Revenue churn is the recurring revenue lost from cancellations, downgrades, or non-renewals during a period.
### Can churn be negative?
Net revenue churn can be negative when expansion revenue from retained customers is larger than lost revenue from churn and contraction.
### Why attribute churn by source?
A channel can produce many paid customers who churn quickly. Churn by source helps identify acquisition quality, not only acquisition volume.
---
# What is customer acquisition cost?
> Customer acquisition cost, or CAC, is the sales and marketing cost required to acquire a new customer over a defined period.
Canonical page: [https://attribiq.com/guides/what-is-customer-acquisition-cost](https://attribiq.com/guides/what-is-customer-acquisition-cost)
Category: Goals & Funnels
Last updated: 2026-06-25
Topics: customer acquisition cost, cac, saas metrics, marketing spend
## Summary
Customer acquisition cost is sales and marketing spend divided by new customers acquired. It is most useful when segmented by source, campaign, payback period, and customer quality.
## What this guide covers
- Define customer acquisition cost
- Calculate basic CAC
- Understand blended and paid CAC
- Connect CAC to revenue attribution
Customer acquisition cost, or CAC, is the cost required to acquire a new customer.
The simple formula is:
```txt
CAC = sales and marketing spend / new customers acquired
```
If a SaaS company spends EUR 10,000 on acquisition in a month and gets 100 new customers, the simple CAC is EUR 100.
## What to include in CAC
CAC can include:
- Paid ads.
- Sponsorships.
- Affiliate payouts.
- Content production.
- Marketing tools.
- Sales salaries.
- Marketing salaries.
- Agency costs.
- Events and webinars.
The exact formula depends on the decision you are making. A board-level blended CAC calculation may include more costs than a campaign-level paid CAC calculation.
## Blended CAC vs paid CAC
Blended CAC uses total acquisition spend and all new customers. It is useful for understanding the whole growth engine.
Paid CAC focuses on paid spend and customers attributed to paid channels. It is useful for campaign decisions.
Both can be valid. The problem is mixing them without labeling the report.
## CAC needs payback context
A low CAC is not automatically good. If customers churn quickly or pay very little, the channel may still be weak.
CAC should be read with:
- Monthly recurring revenue.
- Gross margin.
- Payback period.
- Refund rate.
- Churn rate.
- Expansion revenue.
- Source and campaign.
The goal is not just cheap customers. The goal is profitable customers who stay.
## CAC and revenue attribution
Attribution connects acquisition cost to customer outcomes.
Instead of only asking how much a campaign spent, you can ask:
- How many paid customers came from it?
- How much new MRR did it create?
- How quickly did CAC pay back?
- How much revenue refunded?
- How many customers churned?
This is why campaign reports need payment events, not only clicks and signups.
## Next steps
Read [UTM revenue attribution](https://attribiq.com/guides/utm-revenue-attribution) to connect campaign tags to revenue. Use [signup-to-paid funnel tracking](https://attribiq.com/guides/signup-to-paid-funnel) to keep acquisition cost tied to paid conversion.
## Frequently asked questions
### How do you calculate CAC?
A simple CAC formula is sales and marketing spend divided by new customers acquired in the same period.
### What is blended CAC?
Blended CAC uses total acquisition spend and all new customers, including organic and unpaid channels.
### What is paid CAC?
Paid CAC isolates paid acquisition spend and the customers attributed to those paid channels.
### Why connect CAC to attribution?
Attribution helps compare CAC by source and campaign, then connect that cost to revenue, refunds, renewals, and churn.
---
# What is LTV:CAC?
> LTV:CAC compares customer lifetime value with customer acquisition cost to estimate whether a SaaS acquisition channel creates enough value to justify its cost.
Canonical page: [https://attribiq.com/guides/what-is-ltv-cac](https://attribiq.com/guides/what-is-ltv-cac)
Category: Goals & Funnels
Last updated: 2026-06-25
Topics: ltv cac, customer lifetime value, cac, saas metrics
## Summary
LTV:CAC compares customer lifetime value with acquisition cost. It is useful for judging channel quality, but it depends heavily on retention, margin, attribution, and how you calculate lifetime value.
## What this guide covers
- Define LTV:CAC
- Understand why the ratio matters
- Avoid common LTV:CAC mistakes
- Segment LTV:CAC by acquisition source
LTV:CAC compares customer lifetime value with customer acquisition cost.
It is usually written as a ratio:
```txt
LTV:CAC = customer lifetime value / customer acquisition cost
```
If a customer is worth EUR 900 over their lifetime and costs EUR 300 to acquire, the LTV:CAC ratio is 3:1.
## Why LTV:CAC matters
The ratio helps answer whether acquisition is economically healthy.
If a channel costs more to acquire customers than those customers are likely to return, growth can become expensive even when signups increase. If a channel creates customers with strong retention and expansion, it may deserve more investment even if upfront CAC is higher.
## Lifetime value assumptions
Lifetime value depends on assumptions such as:
- Average revenue per account.
- Gross margin.
- Customer lifetime.
- Churn rate.
- Expansion revenue.
- Contraction revenue.
- Refunds.
Because these assumptions can be uncertain, LTV:CAC should be treated as a decision metric, not a precise truth.
## Why blended LTV:CAC can hide problems
A blended ratio across the whole business can look healthy while one campaign is weak.
For example, organic search may create customers with long retention while a paid social campaign creates customers who churn quickly. A blended number can hide the difference.
Segment LTV:CAC by:
- Source.
- Campaign.
- Landing page.
- Plan.
- Country.
- Customer type.
- Cohort.
## LTV:CAC and attribution
Attribution helps connect the ratio to the source that created the customer.
To calculate source-level LTV:CAC, you need:
1. Acquisition cost by source or campaign.
2. Customers attributed to that source.
3. Revenue and retention for those customers.
4. Refund, churn, and expansion events.
This is why LTV:CAC depends on reliable checkout and payment attribution.
## Next steps
Read [what customer acquisition cost is](https://attribiq.com/guides/what-is-customer-acquisition-cost) first if you need the CAC side of the ratio. Use [MRR attribution](https://attribiq.com/guides/what-is-mrr) and [churn attribution](https://attribiq.com/guides/what-is-churn) to understand customer quality after acquisition.
## Frequently asked questions
### What does LTV:CAC mean?
LTV:CAC is the ratio between customer lifetime value and customer acquisition cost.
### What is a good LTV:CAC ratio?
Benchmarks vary. Many SaaS teams treat 3:1 as a useful reference point, but the right target depends on margin, payback period, growth stage, and retention.
### Why can LTV:CAC be misleading?
The ratio depends on assumptions about lifetime value, churn, gross margin, and attribution. Small changes in those assumptions can change the result.
### Should LTV:CAC be segmented?
Yes. Segment by source, campaign, plan, customer type, and cohort. A blended ratio can hide weak channels and strong niches.
---
# Google Analytics alternative for Stripe revenue attribution
> Compare GA4 ecommerce reporting with AttribIQ’s checkout-to-payment workflow, Stripe events, model choice and visible unmatched revenue.
Canonical page: [https://attribiq.com/guides/ga4-alternative-for-stripe-revenue](https://attribiq.com/guides/ga4-alternative-for-stripe-revenue)
Category: Comparisons
Last updated: 2026-10-02
Topics: google analytics, ga4, stripe, payment api, revenue attribution, saas analytics
## Summary
GA4 is still useful when you need Google Ads depth, BigQuery exports, ecommerce reporting, or a broad web and app analytics standard. It is less direct when a SaaS team wants one report that connects traffic source, checkout metadata, Stripe webhooks or Payment API events, renewals, refunds, and churn. AttribIQ is the narrower choice: simple analytics first, then revenue attribution built around normalized payment events.
## What this guide covers
- Decide when GA4 is still the right analytics layer
- Understand why payment revenue attribution needs more than pageviews
- Compare GA4 ecommerce tracking with a payment-event workflow
- Plan a low-risk migration where GA4 and AttribIQ run side by side
- Know which internal guides to use for implementation
Most Google Analytics alternative pages make the same argument: GA4 is complex, privacy is harder than it used to be, cookie banners reduce data quality, and lightweight analytics tools are easier to read.
That argument is true for many teams, but it is not specific enough for a SaaS company. A SaaS team does not only need to know which pages got visits. It needs to compare paid accounts, MRR, refunds and renewals under a stated attribution model.
That is the point where a normal web analytics comparison becomes too shallow. The question is not "can GA4 count visitors?" It can. The question is "how much work does your team need to do before GA4 answers revenue questions that your payment system already knows are true?"
If your decision is already to keep GA4, use the [Stripe and Google Analytics integration tutorial](https://attribiq.com/guides/stripe-google-analytics-integration) for the client-ID handoff, payment events and validation steps.
## Quick comparison
| Question | AttribIQ | Google Analytics 4 |
| --- | --- | --- |
| Main job | SaaS revenue attribution from traffic, checkout, and payment events | Broad web and app analytics |
| Payment workflow | Native Stripe path plus Payment API for custom billing and unsupported providers | Implement ecommerce or custom events, then build the reports you need |
| Revenue events | Subscription starts, renewals, upgrades, refunds, cancellations, churn | Purchases, refunds, and other ecommerce/custom events when instrumented |
| Best attribution question | Which source, campaign, page or path receives credit under the selected model? | How did users interact with a site or app, especially inside Google's ecosystem? |
| Privacy posture | EU-hosted, privacy-minimizing defaults, cookieless base layer | Requires careful consent, tag, data transfer, and retention decisions |
| Best buyer | SaaS builders who need payment-aware reporting without a data team | Teams invested in Google Ads, BigQuery, app analytics, or enterprise reporting |
## Where GA4 is still strong
GA4 is not a bad product just because many people dislike using it. It is broad, heavily integrated, and still actively developed.
Keep GA4 when these jobs matter:
- Google Ads reporting, audiences, conversion imports, and bidding workflows.
- BigQuery export and warehouse analysis.
- Ecommerce measurement where your team already maintains the event model.
- App analytics or cross-platform web/app reporting.
- Analyst-led exploration, custom dimensions, and ad-platform reporting.
- Existing dashboards that the business already trusts.
Google's own ecommerce documentation shows the depth of the model: item views, cart actions, checkout steps, purchases, refunds, promotions, currency, item arrays, and dynamic remarketing hooks. That depth is useful for ecommerce and advertising teams. It is also more implementation work than many SaaS founders want to own.
The mistake is treating "GA4 can do it" as "GA4 is the best workflow for it." Those are different claims.
## Why SaaS revenue attribution gets awkward in GA4
Your payment system is the source of truth for money. For many SaaS products that means Stripe. For others it might mean Paddle, Polar, Lemon Squeezy, Chargebee, Shopify, WooCommerce, or an internal billing table. That system knows when a checkout completes, when an invoice is paid, when a subscription renews, when a refund happens, and when a customer churns.
The browser does not know all of that. A redirect success page can be missed, refreshed, blocked, or visited before the payment is actually settled. A client-side analytics event can say "purchase happened", but the durable event is the payment processor webhook.
A useful SaaS revenue report needs three pieces:
1. The earlier acquisition context: referrer, UTM source, campaign, landing page, first touch, last touch, and session.
2. The checkout bridge: stable visitor and session identifiers copied into your backend and payment metadata.
3. The payment event: Stripe webhook or normalized Payment API event with amount, currency, customer, subscription, renewal, refund, cancellation, or churn context.
GA4 can receive purchase and custom events, but the team still has to design the bridge, send the events, avoid duplicates, map subscription events into a reporting model, and build the analysis surface. That may be fine if you already have an analytics owner. It is a drag if the founder or developer only wants to answer "which channel created paying customers?"
AttribIQ is designed around that narrower path.
## Not only Stripe
Stripe is the first native integration because it is common in SaaS and gives a clean webhook model for subscriptions, renewals, refunds, and churn.
The underlying attribution model is not Stripe-specific. AttribIQ normalizes payment activity into a shared revenue event shape: provider, transaction ID, event type, amount, currency, timestamp, and any available visitor, session, or customer hash. Native adapters are convenience layers on top of that model.
If you use custom billing or a provider that does not have a native adapter yet, send the same revenue events through the [Payment API reference](https://attribiq.com/guides/payment-api-reference). That covers providers such as Polar, Paddle, Lemon Squeezy, Chargebee, Shopify, WooCommerce, and internal billing systems before a dedicated integration exists.
The tradeoff is ownership. A native Stripe integration can automate more of the ingestion path. The Payment API asks your backend to normalize the event and pass stable identifiers, but it keeps non-Stripe teams from being blocked.
Read [generic Payment API revenue tracking](https://attribiq.com/guides/generic-payment-api-revenue-tracking) for the implementation pattern.
## What changed with Google Analytics
Universal Analytics stopped processing standard properties on July 1, 2023. Starting the week of July 1, 2024, Google ended access to Universal Analytics properties and historical UA data for most users unless it had already been exported. GA4 is the replacement, not a skin over the old product.
That matters because many teams did not merely upgrade a familiar dashboard. They had to move to a different event model, different reports, different retention behavior, and different setup expectations.
GA4 data retention also needs careful reading. Google's retention setting for standard GA4 properties can be set to 2 or 14 months for user-level data, and the setting affects explorations and funnel reports rather than standard aggregated reports. For teams that depend on long-running funnel analysis, that detail matters.
Consent mode adds another layer. Google's documentation explains that when users decline analytics cookies, GA4 may use behavioral modeling if the property and implementation meet eligibility requirements. Modeling can be useful, but it changes what a report means. Smaller properties may not qualify, and teams still need to understand the difference between observed and modeled data.
None of this means GA4 is unusable. It means the cost of "free" analytics includes setup time, consent decisions, modeling literacy, and report maintenance.
## The AttribIQ workflow
AttribIQ starts with the same base layer every analytics product needs: pageviews, sessions, referrers, UTMs, sources, devices, countries, events, and goals.
The difference is what happens when money moves. For Stripe, the path is:
1. Install the web tracker on marketing pages, docs, pricing, signup, and app entry points.
2. Read the browser attribution object when checkout starts.
3. Send that object to your backend with the checkout request.
4. Copy the AttribIQ visitor and session identifiers into Stripe Checkout metadata.
5. Let Stripe webhooks send durable payment events.
6. Read revenue by source, campaign, landing page, first touch, last touch, and session touch.
For non-Stripe systems, keep the same first three steps. Then store the attribution identifiers in your checkout or billing record and send the resulting revenue event to `/v1/revenue` through the Payment API.
That is intentionally less general than GA4. It does not try to become a complete Google Marketing Platform replacement. It tries to make the money report hard to miss.
Use [Install AttribIQ](https://attribiq.com/guides/install-attribiq) for the full setup path, [How to pass attribution to Stripe Checkout](https://attribiq.com/guides/pass-attribution-to-stripe-checkout) for the Stripe checkout bridge, [Stripe revenue attribution for SaaS](https://attribiq.com/guides/stripe-revenue-attribution) for the native payment model, and [generic Payment API revenue tracking](https://attribiq.com/guides/generic-payment-api-revenue-tracking) for custom billing.
## A practical report example
Imagine three channels over the last 30 days:
| Source | Visits | Signups | New MRR | Refunds | Net MRR |
| --- | ---: | ---: | ---: | ---: | ---: |
| Google organic | 4,200 | 126 | EUR 3,100 | EUR 200 | EUR 2,900 |
| LinkedIn paid | 850 | 41 | EUR 4,700 | EUR 1,600 | EUR 3,100 |
| Founder newsletter | 320 | 19 | EUR 2,400 | EUR 0 | EUR 2,400 |
A traffic dashboard might push the team toward Google organic because it has the most visits and signups. A revenue dashboard changes the discussion. LinkedIn paid produced more gross MRR, but refund quality needs review. The newsletter had lower volume but clean revenue. Google organic is still useful, but it may not deserve all the next content effort.
This is why revenue attribution should not be buried in a custom exploration that only one person knows how to rebuild. It should be a normal operating report.
## Migration plan
Do not rip out GA4 on day one.
Run both systems for a validation window:
1. Keep GA4 active for existing reports, Google Ads, and historical continuity.
2. Add AttribIQ to the marketing site, pricing pages, docs, signup, and app entry points.
3. Pass attribution into Stripe Checkout metadata or your own checkout/billing record.
4. Confirm Stripe webhooks or Payment API calls are creating purchases, renewals, refunds, cancellations, and churn events.
5. Compare payment-provider revenue totals against AttribIQ revenue totals.
6. Review unattributed revenue and fix missing checkout metadata before making decisions.
7. Move channel review from visits and signups to net revenue once the bridge is reliable.
This keeps the risk low. GA4 can remain the broad analytics and advertising tool while AttribIQ becomes the revenue attribution layer. If AttribIQ eventually covers every report your team uses, then replacing GA4 becomes a cleaner decision.
## When to choose each tool
Choose AttribIQ when:
- You sell SaaS subscriptions through Stripe or a custom payment backend.
- You need revenue by source, campaign, landing page, and attribution model.
- You want renewals, refunds, upgrades, cancellations, and churn in the same reporting vocabulary.
- You prefer EU-hosted analytics and privacy-minimizing defaults.
- Your team does not want to maintain a custom GA4 revenue model.
Choose GA4 when:
- Google Ads reporting and audience workflows are central.
- BigQuery export is part of your analytics stack.
- You need broad app and web analytics.
- You already have an analytics team maintaining GA4 events and reports.
- You need a free default analytics product more than a focused revenue workflow.
Choose both when:
- Paid search still runs through Google Ads, but SaaS revenue reporting needs better payment context.
- You use a non-Stripe payment provider and want a normalized Payment API path before a native adapter exists.
- Existing GA4 reports are useful, but founders do not trust them for revenue decisions.
- The team is migrating gradually and wants a side-by-side validation period.
## Privacy and accuracy tradeoffs
Do not oversell any analytics tool as perfectly complete. Browsers, consent choices, ad blockers, private browsing, cross-device journeys, payment redirects, and long trials can all hide parts of the path.
AttribIQ's default posture is privacy-minimizing. Cookieless analytics is useful for traffic reporting and same-session attribution. Longer trial-to-paid journeys may need optional first-party collection or another explicit bridge. That choice should match your notices, consent posture, and legal review.
The important product behavior is honesty: show total revenue, attributed revenue, and unattributed revenue separately. If a payment cannot be tied back to a source, the dashboard should not pretend otherwise.
Read [Cookieless analytics with revenue attribution](https://attribiq.com/guides/cookieless-analytics-with-revenue-attribution) and [GDPR-friendly revenue analytics](https://attribiq.com/guides/gdpr-friendly-revenue-analytics) before changing tracking modes.
## Sources
- [Google Analytics 4 has replaced Universal Analytics](https://support.google.com/analytics/answer/11583528?hl=en)
- [GA4 data retention](https://support.google.com/analytics/answer/7667196?hl=en)
- [GA4 behavioral modeling for consent mode](https://support.google.com/analytics/answer/11161109?hl=en)
- [GA4 ecommerce measurement](https://developers.google.com/analytics/devguides/collection/ga4/ecommerce)
- [Consent mode overview](https://developers.google.com/tag-platform/security/concepts/consent-mode)
- [AttribIQ Google Analytics comparison](https://attribiq.com/comparisons/google-analytics-alternative)
- [AttribIQ Payment API reference](https://attribiq.com/guides/payment-api-reference)
## Frequently asked questions
### Can AttribIQ replace Google Analytics 4?
For focused SaaS revenue attribution, yes. For broad Google Ads reporting, BigQuery workflows, app analytics, or GA4-specific ecommerce reporting, keep GA4 until those needs are replaced.
### Can GA4 track Stripe or other payment revenue?
GA4 can measure purchases and revenue through ecommerce or custom events, but payment attribution usually requires careful event implementation, checkout metadata, and reporting work. AttribIQ treats payment events and checkout identifiers as the core workflow.
### Should we run GA4 and AttribIQ together?
Usually yes during migration. Keep GA4 for existing reports and ad workflows, then add AttribIQ to validate traffic collection, checkout metadata, and Stripe webhook or Payment API revenue before changing team reporting.
### Does revenue attribution require cookies?
Not always. Same-session checkout attribution can work with less browser state. Longer trial-to-paid journeys often need a stable first-party identifier or another explicit bridge between the analytics session and the payment event.
### Is AttribIQ a legal replacement for a consent review?
No. AttribIQ is designed around EU hosting and privacy-minimizing defaults, but legal basis, notices, consent choices, and processor terms still need to match your implementation and jurisdictions.