Skip to main content
@biqli/analytics runs only in browsers and accepts only a biqli_pk_... publishable key.
For a site without a package manager, load https://biq.li/sdk/dist/auto.global.js with a data-publishable-key attribute. See the HTML guide.

Configuration

The SDK writes bq_id as a first-party cookie. If the browser rejects that cookie, it uses controlled local-storage fallback where available.

Retry queue defaults

Instance methods

storeStripeSession() is available for Biqli’s browser-to-Stripe attribution adapter. New custom payment implementations should normally persist bq_id in their own backend and send sales with the server SDK.

Tracking inputs

Client click

Shared customer identity

Every lead and sale accepts these fields: Lead-specific fields are eventName (required), eventId, and eventQuantity (default 1). Sale-specific fields are amount (required integer minor units), currency, eventName, paymentProcessor, invoiceId, eventId, and leadEventName. Use a stable lead eventId. For a sale, use stable paymentProcessor and invoiceId values whenever they exist.

Results and errors

A successful tracking call returns the created or replayed event, customer, click, link, and request_id. During a retryable browser outage it can instead return:
Rejected calls throw BiqliError with code, status, requestId, details, and retryable properties. A queued result is not proof that the server has received the event; it means the SDK will retry within its configured queue limits.

Module helpers

inject() replaces and tears down the previous injected instance. Use the class directly when your application owns instance lifecycle.

React exports

The hook exposes the SDK, tracking methods, click ID access, consent control, and URL decoration. It must be called under BiqliProvider.

Global script API

The automatic script exposes:
See the browser quickstart, HTML guide, and React guide.