> ## Documentation Index
> Fetch the complete documentation index at: https://learn.biq.li/llms.txt
> Use this file to discover all available pages before exploring further.

# How attribution works

> Understand clicks, customers, leads, sales, attribution models, and deleted links.

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.

```text theme={null}
Short link -> click ID -> customer -> lead or sale
```

## 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.

<Info>
  The model controls which click the browser retains. Server events can also reuse an eligible attribution already associated with the same workspace customer.
</Info>

## Direct attribution

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

```json theme={null}
{
  "clickId": "qPa4lSpsKj3B",
  "eventName": "Signed up",
  "customerExternalId": "customer_1842"
}
```

## 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.

## Deleted links

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.