Skip to main content

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

PitfallResultFix
Missing transaction ID on retriesDuplicate event totalsAdd idempotent transaction identifiers
Missing customer identityConversions without customer profileSend email or external customer ID consistently
Inconsistent event namingFragmented event reportsStandardize event naming dictionary
Mixed currency value payloadsDistorted revenue reportingNormalize 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:
  1. Define who can change statuses.
  2. Document status transition policy.
  3. Reconcile status changes in finance windows.
  4. 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 classShould affect conversion countsShould affect revenue cards
LeadYesUsually no (unless value policy explicitly treats lead value financially)
SaleYesYes when value and currency are provided
CustomYes in custom-included viewsOnly if configured with monetary value semantics
If an event appears in activity but not in revenue, check event class, status, and value/currency payload first.

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

  1. Confirm customer identifier consistency across sources.
  2. Confirm repeat events map to existing customer profile.
  3. Confirm customer value reflects approved events as expected.
  4. Confirm affiliate-scoped customer counts are interpreted as subset views.

Reconciliation workflow

When numbers look different between pages:
  1. Match date range and timezone.
  2. Match scope (workspace, campaign, link).
  3. Match event-type and status filters.
  4. Validate currency and cost model context.
  5. Confirm whether you are in workspace analytics or affiliate-scoped analytics.

Troubleshooting scenarios

ScenarioLikely causeFirst action
Revenue shown but Customers page sparseMissing customer identity in event payloadsInspect recent events for identity fields
More events than expectedDuplicate submissions from retry logicCheck transaction IDs and retry policy
Affiliate customer counts lower than workspace customersScope attribution differenceConfirm partner attribution filters
Sales totals differ from payout expectationsStatus or commission logic differencesCompare approved/paid states and commission rules
Related:
  • /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