Documentation Index
Fetch the complete documentation index at: https://docs.linquid.io/llms.txt
Use this file to discover all available pages before exploring further.
Conversions and Customers
Conversions capture outcomes. Customer records organize those outcomes by identity.
Mental model
- Conversion: one event occurrence (lead, sale, or custom milestone).
- Customer: identity-level profile stitched from one or more events.
You can have many conversions for one customer, or conversions with no stitched customer profile yet.
Why this distinction matters
- finance teams usually reconcile event-level conversions.
- success and CRM teams usually work from customer-level profiles.
- mismatch between the two often indicates incomplete identity signals, not missing conversions.
Conversion event types
Linquid supports:
- lead-class events
- sale-class events
- custom events for lifecycle or behavioral milestones
Ingestion methods
Common methods:
- browser or SDK-style tracking
- server-to-server tracking
- partner/provider-fed conversion signals
Event data quality minimums
For reliable reporting, each conversion event should include:
- event type and timestamp.
- stable transaction/order identifier for dedupe scenarios.
- value and currency when financial metrics are required.
- customer identity signal (email or external customer ID) when customer stitching is required.
Attribution behavior
Attribution quality depends on:
- click identifiers
- consistent event naming
- transaction identifiers for dedupe
- customer identity fields for stitching
Best identity signals:
- customer email
- external customer ID from your CRM/billing system
- stable customer name/metadata conventions
Attribution and stitching pitfalls
| Pitfall | Result | Fix |
|---|
| Missing transaction ID on retries | Duplicate event totals | Add idempotent transaction identifiers |
| Missing customer identity | Conversions without customer profile | Send email or external customer ID consistently |
| Inconsistent event naming | Fragmented event reports | Standardize event naming dictionary |
| Mixed currency value payloads | Distorted revenue reporting | Normalize currency usage and validate payload |
Status and lifecycle
Conversion events can pass through statuses such as pending, approved, refunded, rejected, or flagged.
These statuses affect revenue, payout, and analytics views differently.
Operational guidance:
- Define who can change statuses.
- Document status transition policy.
- Reconcile status changes in finance windows.
- Treat refunded/chargeback events separately from gross sales.
Non-sale/lead custom events
Custom events are valid first-class outcomes when you need lifecycle instrumentation beyond leads and sales.
Examples:
- onboarding completed
- trial activated
- feature milestone reached
- subscription renewal attempt
These events improve funnel intelligence even when they do not represent direct revenue.
UI display expectations by event class
| Event class | Should affect conversion counts | Should affect revenue cards |
|---|
| Lead | Yes | Usually no (unless value policy explicitly treats lead value financially) |
| Sale | Yes | Yes when value and currency are provided |
| Custom | Yes in custom-included views | Only if configured with monetary value semantics |
Customers vs conversion events
- Conversion events are event-level records.
- Customers represent stitched identity-level summaries.
This means sales can exist while customer records remain sparse if identity fields were not provided.
Affiliate-facing customer views are intentionally scoped differently from workspace-wide customer views:
- workspace customer views reflect full workspace-level customer outcomes
- affiliate customer views reflect partner/program-attributed customer outcomes only
Customer profile interpretation checklist
- Confirm customer identifier consistency across sources.
- Confirm repeat events map to existing customer profile.
- Confirm customer value reflects approved events as expected.
- Confirm affiliate-scoped customer counts are interpreted as subset views.
Reconciliation workflow
When numbers look different between pages:
- Match date range and timezone.
- Match scope (workspace, campaign, link).
- Match event-type and status filters.
- Validate currency and cost model context.
- Confirm whether you are in workspace analytics or affiliate-scoped analytics.
Troubleshooting scenarios
| Scenario | Likely cause | First action |
|---|
| Revenue shown but Customers page sparse | Missing customer identity in event payloads | Inspect recent events for identity fields |
| More events than expected | Duplicate submissions from retry logic | Check transaction IDs and retry policy |
| Affiliate customer counts lower than workspace customers | Scope attribution difference | Confirm partner attribution filters |
| Sales totals differ from payout expectations | Status or commission logic differences | Compare approved/paid states and commission rules |
/user-guides/manual/data/conversion-tracking-setup-playbook/user-guides/manual/data/analytics-and-reporting/user-guides/manual/ecosystem/affiliates-and-partners/user-guides/manual/data/events-and-customers-operations-reference
