First-Party Website Tracking for SaaS
A technical overview of the small first-party event contract needed to connect website journeys with supported payment outcomes.
Last updated: August 18, 2026
What is first-party website tracking?
First-party website tracking records activity in the context of the website a person is visiting. A lightweight script sends page and engagement events for that website, while the site controls when tracking loads and whether persistent identifiers may be stored.
“First-party” describes the collection context. It does not automatically make tracking exempt from privacy laws or consent requirements. The website operator still needs to choose a lawful setup for its audience and jurisdiction.
Visitor IDs and session IDs serve different purposes
A session ID groups activity within a browsing session. A visitor ID can connect multiple sessions when persistent storage is allowed. Revenue attribution can use either identifier, but the available analysis changes:
| Identifier | Typical scope | What it enables |
|---|---|---|
| Session ID | One active browsing session | Same-session journey attribution |
| Visitor ID | Multiple visits while retained | Returning-visitor and cross-visit analysis |
| Neither | Aggregate event only | Page and traffic totals without a durable identity link |
If consent-required mode is enabled before consent is granted, RevenueUI uses a temporary tab-scoped session rather than writing a persistent first-party visitor cookie. Once consent is granted, persistent visitor and session identifiers can be used.
Keep the event contract small
For revenue journey analysis, collect only fields that change a decision. RevenueUI accepts page-view and page-engagement events with the website public key, origin, path, timestamps, identity mode, consent state, and optional acquisition or device context.
Avoid collecting form values, page text, email addresses, payment card data, or arbitrary custom payloads through a page-view tracker. Those fields are not required to connect a path and session to a supported payment outcome.
Referrers and UTM parameters
Referrer data describes where a browser navigated from when the browser supplies it. UTM parameters describe campaign labels added to a destination URL. Both are useful, but neither is guaranteed:
- Browsers and referrer policies may reduce or omit referrer detail.
- Direct visits can include people returning from bookmarks or untagged links.
- UTM values are only as consistent as the campaign naming convention.
- Cross-device journeys may appear as separate visitors.
Normalize campaign names before comparing them and keep “direct” as an observed category, not a claim that no prior influence existed.
Verification checklist
- Confirm the configured website domain matches the page origin.
- Check that one page view is sent for each navigation you intend to measure.
- Confirm consent-required mode does not write persistent cookies before consent.
- Verify granted consent changes the identity mode as expected.
- Exclude test traffic when interpreting production decisions.
- Complete a checkout and confirm the correct identifier reaches payment metadata.
Related guides
- SaaS revenue attribution fundamentals
- Cookie consent and analytics coverage
- Revenue analytics metrics for SaaS
Tracking quality is part of attribution quality. Review the unattributed share after changing routing, checkout creation, or consent management.