Skip to main content
Attribution answers one question: Which Biqli link helped create this lead or sale?

​
The attribution journey

  1. A visitor opens a conversion-enabled Biqli link.
  2. Biqli records the click and adds bq_id to the destination URL.
  3. The browser SDK stores the click ID after consent is granted.
  4. Your application sends a lead or sale with that click ID.
  5. Biqli saves the event under the same workspace, customer, and link.

​
Customer identity

Every lead and sale includes customerExternalId. Use the permanent ID from your own database, for example customer_1842. Use the same value for that customer across devices, sessions, and future purchases. Do not generate a new value for every event. Avoid using an email address when your application has a permanent customer ID.

​
First-click and last-click models

Choose the browser attribution model in Workspace settings -> Tracking.
  • First click keeps the first eligible click already stored in that browser.
  • Last click replaces the stored click when a newer eligible click arrives.
The SDK stores attribution for the configured cookie lifetime. Its default is 90 days and its supported range is 1 to 365 days.
The model controls which click the browser retains. Server events can also reuse an eligible attribution already associated with the same workspace customer.

​
Direct attribution

Send clickId when your signup, order, or webhook still has the visitor’s bq_id.

​
Deferred attribution

After Biqli has attributed a customer, a later server-side event can omit clickId and use the same customerExternalId. This is useful for renewals and delayed payments. For a sale, leadEventName can prefer a matching lead before Biqli applies the workspace attribution model. Deleting a link does not erase existing customer or conversion history. Biqli freezes the link’s final short URL, destination, and title in an attribution snapshot. Customer timelines then show Deleted link while preserving the historical details. New visits cannot use the deleted link.

​
Retry safety

A network timeout does not tell you whether the server accepted an event. Retry the same logical event with the same identifiers and the same payload:
  • Leads use a stable eventId.
  • Sales should use a stable paymentProcessor and invoiceId.
  • Raw REST requests should also send a stable Idempotency-Key header.
An exact retry returns the original event. Reusing an identifier with different data returns 409 idempotency_conflict.

​
Workspace isolation

A credential, click ID, customer, and event must belong to the same workspace. Biqli does not allow one workspace to claim another workspace’s click. Cross-workspace resource lookups return a scoped not-found response.