Tracking Overview
How Affitor links clicks, signups, and sales together
Affitor tracking links three events into one attribution chain:
- click — a visitor arrives through an affiliate link
- signup/lead — you identify the customer after registration
- sale — revenue is recorded through Server-side tracking or Stripe integration
The Core Model
Every successful integration follows the same three-step shape:
- A tracked affiliate visit creates a click/customer relationship.
- Signup tracking attaches your internal user ID to that relationship.
- Sale tracking records revenue against the same customer/partner relationship.
Identifier consistency matters more than any single code snippet.
The Tracking Flow
affitor_click_idWhat You Need to Implement
1. Click tracking
Install the tracker so affiliate visits are detected automatically:
- Detects
?aff= - Stores
affitor_click_id - Creates the initial relationship Affitor needs for attribution
Guide: Click Tracking
2. Signup tracking
Send your internal customer/user identifier after signup succeeds.
- browser helper:
signup(customerKey, email) - server API:
POST /api/v1/track/leadwithcustomer_key
Guide: Lead Tracking
3. Sale tracking
Choose one supported revenue path:
| Path | Use when |
|---|---|
| Server-side tracking | your backend controls revenue events |
| Stripe metadata + webhook | you already use Stripe Checkout / Stripe integration |
Guide: Payment Tracking
Recommended Identifier Mapping
| Context | Field |
|---|---|
| Signup helper | customerKey |
| Lead API | customer_key |
| Server-side tracking | customer_key |
| Stripe metadata | affitor_customer_key |
| Browser click cookie | affitor_click_id |
| Server-side tracking click field | click_id |
Use one stable internal customer ID everywhere.
Attribution Basics
Default model
Defaults:
- first-party cookie tracking
- the first partner's click keeps the customer: a later click from another partner in the same browser is logged but does not take the customer over
- attribution window: 60 days per program by default, one setting. The click must be at most that many days older than the customer's signup (or their first payment, when no signup was recorded). It is checked once, at the first attributed payment; renewals are not re-checked. The same number is the cookie lifetime.
See Attribution Mechanics for details.
Why the signup step matters
The click cookie is reliable, but the internal customer ID is what keeps attribution working across later payment events — especially when payment happens after signup or on a backend-controlled path.
One-Time vs Subscription Payments
One-time payment
Choose either:
- Send a server-side tracking event (POST /api/v1/track/sale) after payment succeeds.
- Attach Stripe metadata for Stripe integration.
Subscription payment
If you use Stripe subscriptions:
- Include metadata on the checkout session.
- Include the same metadata on
subscription_data.metadata.
Without subscription metadata, renewals may not be attributable.
What Most Teams Choose
Fastest path for Stripe Checkout teams (manual)
- install tracker
- send the lead from your backend with
POST /api/v1/track/leadand your program API key (a browser-onlysignup()lead stays provisional on new programs) - attach Stripe metadata for payment + subscription flows
Fastest path for custom backend teams (manual)
- install tracker
- send the lead from your backend with
POST /api/v1/track/leadand your program API key - send
POST /api/v1/track/salefrom your backend