Browser-Side Conversion Tracking

How Does It Work

Browser-side conversion tracking records outcome events at the moment a user action is completed in the frontend experience.

This approach is commonly used when:

• the conversion happens entirely within the web interface
• the confirmation state is visible in the UI
• fast signal transmission is more important than backend validation

Typical browser-side conversion scenarios include:

• successful form submission confirmation
• subscription upgrade success screen
• checkout completion page
• account registration success view

Implementation Concept

In browser tracking, the SDK is initialized once during application startup.

Conversion signals are then sent when a qualifying UI state is reached.

Key characteristics:

• event is triggered by frontend logic
• visitor attribution context is already available
• signal is sent immediately after user interaction

This allows:

• near real-time attribution updates
• quick campaign performance feedback
• simplified implementation in static or SPA websites

Example

For example, on a checkout success page:

import { Mark } from '@crelora/mark'

// activity signal
Mark.track('Checkout Started', {
  value: 12900,
  currency: 'usd',
})

// outcome signal
Mark.conversion('Purchase Completed', {
  order_id: 'ord_789',
  value: 12900,
  currency: 'usd',
})

In this pattern:

• track() records behavioural activity signals
• conversion() records confirmed business outcome signals
• both signals inherit attribution context collected earlier in the session

This separation allows OneLence to distinguish user intent from measurable results.

Use Case Limitation

Browser-side conversion tracking is suitable when:

• business outcomes do not require server verification
• payment or fulfillment logic is handled externally
• tracking accuracy is not affected by ad-blockers or network interruptions

However, developers should be aware that browser environments can introduce:

• script blocking
• consent gating delays
• session interruption risks

For critical revenue events, a server-side or hybrid approach is often recommended.