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

# Introduction

> Choose the right Biqli tracking path and understand the complete conversion journey.

Biqli shows which short-link visits become customers, leads, and sales.

You can add tracking with a browser SDK, a server SDK, a direct REST request, or a supported integration. This guide helps you choose the safest path before you write code.

## Start with the journey

1. A visitor opens a conversion-enabled Biqli short link.
2. Biqli records the click and forwards its click identifier as `bq_id`.
3. Your website captures that identifier.
4. Your application identifies the visitor with a stable customer ID.
5. Your browser or server reports a lead or sale.
6. Biqli connects the conversion to the workspace, customer, click, and link.

<Note>
  A click is the attribution starting point. A customer is your stable identity for a person or account. A lead is a meaningful non-revenue action. A sale is a confirmed revenue event.
</Note>

## Choose an implementation

<CardGroup cols={2}>
  <Card title="Browser tracking" icon="browser" href="/developers/browser/quickstart">
    Capture `bq_id`, track browser-side events, and support single-page applications.
  </Card>

  <Card title="Server tracking" icon="server" href="/developers/server/quickstart">
    Send trusted leads and sales from Node.js, Next.js, PHP, Laravel, or REST.
  </Card>

  <Card title="Stripe" icon="credit-card" href="/developers/integrations/stripe">
    Attribute confirmed Stripe payments from verified webhooks.
  </Card>

  <Card title="Shopify" icon="store" href="/developers/integrations/shopify">
    Connect a Shopify store and use Biqli's managed conversion flow.
  </Card>
</CardGroup>

## Browser versus server tracking

| Question                       | Browser tracking                              | Server tracking                                                          |
| :----------------------------- | :-------------------------------------------- | :----------------------------------------------------------------------- |
| Where does it run?             | In the visitor's browser                      | On infrastructure you control                                            |
| Credential                     | Publishable key beginning with `biqli_pk_`    | Secret workspace API key beginning with `biqli_`                         |
| Best for                       | Capturing attribution and client-only actions | Signups, subscriptions, payments, renewals, and verified business events |
| Can privacy tools block it?    | Yes                                           | Usually no                                                               |
| Can it safely confirm payment? | No                                            | Yes                                                                      |

Most production applications use both. The browser captures the click ID and forwards it to your backend. The backend sends the trusted conversion.

## Recommended learning order

If this is your first tracking integration, read these pages in order:

1. [How attribution works](/developers/getting-started/attribution)
2. [Choose the correct credential](/developers/getting-started/credentials)
3. [Understand customers and events](/developers/getting-started/event-contracts)
4. Complete the [browser quickstart](/developers/browser/quickstart)
5. Move trusted events to the [server quickstart](/developers/server/quickstart)
6. Use [Debug tracking](/developers/operations/debugging) before launch

## What Biqli protects for you

* Workspace-scoped credentials and data isolation
* Allowed-origin checks for browser tracking
* Permission checks for secret API keys
* Stable public resource identifiers
* Idempotent lead and sale creation
* Preserved attribution when a link is later deleted
* Structured errors and request IDs

You still need to protect secret keys, choose stable customer and event identifiers, request consent where required, and send only events your application has verified.