Configure Tracking via SDK (Developer Setup)

For applications with engineering ownership of the frontend or backend runtime, OneLence tracking can be fully configured through the SDK.

This enables reliable attribution across complex routing flows, identity states, and multi-domain product architectures.

Runtime Initialization Strategy

Initialize the SDK once during application bootstrap to establish attribution capture, identity lifecycle management, and automatic navigation tracking.

Example browser runtime initialization:

import { Mark } from '@crelora/mark';

Mark.init({
  key: 'pk_your_publishable_key',
  require_consent: false, // 'auto': stored consent | true: require consent | false: immediate tracking
  autocapture: { pageview: true },
  track_route_changes: true,
  include_page_context: true,
  site_id: 'your_site_id',
  site_host: 'your-site-host'
});

Multiple initializations within the same runtime may result in duplicate page view or attribution signals.

Cross-Domain Attribution Engineering

Products operating across multiple subdomains or controlled marketing surfaces can maintain visitor continuity using cross-domain configuration.

Example concept:

Mark.init({
  key: 'pk_xxxxx',
  cross_domain: {
    cookie_domain: '.example.com'
  }
});

This enables:

• shared visitor identifiers across subdomains
• stable campaign attribution during domain transitions
• consistent funnel reconstruction

Cross-domain configuration should be aligned with overall infrastructure design.

Identity Linking and Lifecycle Enrichment

When a visitor becomes a known user, identity linking can associate historical activity with authenticated sessions.

Example:

Mark.identify('user_123', {
  email: '[email protected]',
  display_name: 'John Doe',
  language: 'en-US'
});

Identity linking supports:

• lifecycle segmentation
• cross-device attribution analysis
• conversion cohort reporting

Identity calls are typically triggered after login or signup events.

Programmatic Behavioural & Conversion Events

Developers can emit structured events representing user actions or validated business outcomes.

Example behavioural signal:

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

Example conversion signal:

Mark.conversion('Subscription Activated', {
  plan: 'pro',
  value: 4900
});

Payload fields are automatically enriched with attribution context and visitor identity metadata.

Accessing Visitor Identifiers for Hybrid Attribution

In hybrid tracking setups, the browser visitor identifier can be forwarded to backend systems to join server-side events.

Example:

const visitorId = Mark.getVisitorId();

Typical usage:

• include visitor ID in API request headers
• attach visitor ID to checkout or webhook processing
• use visitor ID when emitting server conversion events

Visitor IDs are pseudonymous and scoped to attribution flows.

Server Runtime Configuration Options

Backend environments can emit validated events using the Node SDK factory.

Example:

import { createNodeMark } from '@crelora/mark/node';

const mark = createNodeMark({
  key: process.env.MARK_SECRET_KEY,
  site_id: process.env.MARK_SITE_ID,
  site_host: process.env.MARK_SITE_HOST
});

Advanced server integrations may configure:

• custom storage adapters for queue or session persistence
• storageDefaults to inject visitor context from upstream systems
• custom transport adapters for controlled event delivery pipelines

These options enable integration with:

• serverless runtimes
• background job queues
• distributed checkout systems

Per-event Context Overrides

Multi-tenant or marketplace platforms may need to override site context dynamically for specific events.

Example:

Mark.track('Conversion', {
  site_id: 'secondary-site-uuid',
  site_host: 'checkout.partner.com',
  value: 5000
});

This supports:

• white-label SaaS attribution
• partner checkout tracking
• modular product analytics architectures

Per-event overrides should follow a clearly documented data governance strategy.