> ## 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.

# Conversion Methods and Event Types Reference

> Lead, sale, and custom event tracking methods, status handling, attribution quality, and reconciliation guidance

# Conversion Methods and Event Types Reference

This page focuses on conversion instrumentation depth.

## Conversion classes

Linquid supports three practical classes:

* lead outcomes
* sale outcomes
* custom lifecycle outcomes

### Where each class appears in the UI

| Class  | Primary surfaces                                      | Typical interpretation                                  |
| ------ | ----------------------------------------------------- | ------------------------------------------------------- |
| Lead   | Conversions page, analytics lead tabs, events stream  | Funnel progression and acquisition quality              |
| Sale   | Conversions page, analytics sales tabs, finance views | Revenue outcomes and commercial efficiency              |
| Custom | Events stream, conversions breakdowns, custom reports | Lifecycle milestones and operational automation signals |

## Tracking methods

Common tracking methods:

* browser/client-side instrumentation
* server-to-server instrumentation
* provider/integration-fed conversion ingestion
* SDK-based tracking flows for client and server contexts
* deferred/open-tracking flows for deep-link/open telemetry

Recommended usage pattern:

* use browser/client tracking for immediate front-end milestones
* use S2S for authoritative payment/subscription outcomes
* use integration ingestion for provider-managed lifecycle events

Common implementation surfaces:

* campaign/link tracking snippets for browser events
* publishable-key based client tracking
* S2S postback from backend/payment systems
* lead-specific and sale-specific tracking workflows
* dedicated track lead / track sale style flows for explicit event class handling
* track-open style flows where deep-link open behavior is measured
* SDK track flows (`sdk-track`) for standardized event submission
* tracking pixels for campaign-level conversion attribution

## Event naming guidance

Use stable naming conventions so reports remain interpretable over time.

Recommended structure:

* one canonical name per business milestone
* avoid multiple aliases for the same milestone
* version naming only when semantics change

Common built-in business event families include:

* ecommerce: purchase, sale, order, checkout, add\_to\_cart
* lead-gen: lead, signup, registration, form\_submit, inquiry
* subscription/SaaS: trial\_start, renewal, upgrade, downgrade, cancellation
* app/mobile: install, app\_open, in\_app\_purchase
* engagement/custom: click, view, download, referral, review, custom event names

## Status handling

Event status changes may include:

* pending
* approved
* rejected
* refunded
* duplicate
* fraud/flagged

Status affects revenue, payout, and partner analytics differently.

Status expectations:

* pending: provisional outcome, often pre-approval
* approved: counted as accepted conversion outcome
* refunded/chargeback/cancelled: revenue-impacting reversal states
* duplicate/fraud: excluded from trustworthy performance totals

## Identity and attribution quality

Better attribution requires:

* reliable click identifiers
* transaction/order identifiers
* customer identity signals when available

Without identity signals, conversion totals can exist while customer detail remains sparse or fragmented.

## Deduplication and idempotency guidance

To avoid overcounting:

* pass stable transaction/order IDs for sale events
* reuse the same transaction ID on retries
* keep event payloads deterministic for retried deliveries
* treat receivers/processors as idempotent

Duplicate transaction IDs are expected to be recognized and safely ignored.

## Non-sale and non-lead use cases

Custom events are useful for:

* product activation milestones
* renewal and upsell lifecycle steps
* funnel diagnostics and partner-quality analysis

Common custom event examples:

* onboarding\_completed
* subscription\_renewed
* trial\_converted
* feature\_adopted
* account\_reactivated

Expected display behavior:

* custom events increase conversion activity totals where custom class is included
* custom events appear in events stream with event name and status context
* custom events do not automatically imply sale revenue unless value/currency and event policy classify them accordingly

## Currency and amount behavior

Operational conventions:

* send conversion amount in major units with explicit currency
* use consistent currency code formatting across sources
* align reporting currency when reconciling across pages

## Pixel and SDK tracking considerations

* use publishable credentials only in browser/client contexts
* keep secret credentials server-side for S2S
* validate event payload shape before production rollout
* test lead and sale paths independently before enabling full automation
* validate SDK track and track-open events independently before rollout

## Reconciliation checklist

1. align date range and timezone
2. align scope (workspace, campaign, link)
3. align status filters
4. align currency and cost model context
5. compare against exports when needed

Related:

* `/user-guides/manual/data/conversion-tracking-setup-playbook`
* `/user-guides/manual/data/conversions-customers`
* `/user-guides/manual/data/analytics-views-reference`
* `/user-guides/manual/monetization/currencies-cost-models-and-fx`