Offline & Retry

Queueing model

• track() pushes events to an in-memory queue immediately
• The SDK schedules a flush every ~1 second when queue is non-empty
• analytics.flush() forces an immediate send attempt

analytics.track('checkout_started')
analytics.track('checkout_completed', { order_id: 'ord_123' })
analytics.flush()

Retry behavior

Failed batches retry with exponential backoff + jitter using defaults:maxRetries: 3, baseDelay: 1000,maxDelay: 30000.

Offline persistence

• Pending events are persisted under the project-scoped ra:<public-key>:offline_queue key
• A companion ra:<public-key>:offline_ad_user_data marker prevents unsafe restoration after consent changes
• Stored queue is restored when the client initializes
• Storage is capped at 1000 events

Unload behavior

On visibility change / unload, the SDK attempts delivery withnavigator.sendBeacon. If Beacon is unavailable or declines the batch, the SDK persists it for a later client initialization. It does not use synchronous XHR.

Lifecycle helpers

const pending = analytics.getQueueSize()

analytics.shutdown() // persists pending events + removes listeners

Callbacks

const analytics = createClient({
  publicKey: 'pk_live_xxx',
  onError: (error, events) => {
    console.error(error.message, events.length)
  },
  onSuccess: (_events, receipt) => {
    console.log('newly accepted', receipt.accepted)
    console.log(
      'idempotent duplicates',
      receipt.duplicatesInBatch + receipt.duplicatesPreviouslyAccepted
    )
  },
})

Next Steps

• Configuration
• Tracking events
• REST API payload format