​

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

​

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

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

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