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

Biqli uses last-click attribution by default. Browser SDK installations that need first-click behavior can set attributionModel: 'first-click' in their SDK configuration.
  • 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 browser SDK stores attribution for 90 days by default. An installation can set cookieOptions.expiresInDays to a value from 1 to 365 when a different lifetime is required.
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.

​
Later customer 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.
This is later server-event attribution for an already known customer. It is different from deferred mobile deep linking, which preserves link context while a person installs an iOS or Android app.
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.