Concepts

This section is understanding-oriented. Read it when you want to know why Binoban works the way it does — not to copy a snippet (that's the Quick Start and the how-to guides under Track customer data) or to look up a field (that's Reference — SDKs, APIs, event spec, ops — or the identify/track call spec).

Everything you integrate sits on a few core ideas. Once these click, the rest of the docs are just detail.

The data flow

A Binoban integration does one thing at its core: it gets data about your customers into Binoban, where it becomes a unified profile your team can act on.

your app / site / backend
        │
        │  identify(), track(), page()   ← Web SDK, Native SDK, or REST
        ▼
  POST /api/tracker/sdk/{sourceIdentifier}/…
        │
        ▼
   your source  ──►  unified customer profile  ──►  Audience · Engage · Retail Media

Whether the call comes from the browser (Web SDK), a mobile app (Native SDK), or your server (the Tracking API), it lands on the same ingestion contract and resolves into the same profile. The transport differs; the data model doesn't.

Sources and sourceIdentifier

A source is one origin of data — a website, a mobile app, a backend service. Each source has a sourceIdentifier (which routes events to it) and an apiKey (which authenticates them). You'll often have several sources feeding one workspace; sourceIdentifier is how Binoban keeps them straight.

Identity: anonymous, then known

Binoban tracks a person before it knows who they are. The SDK assigns an anonymous ID on first contact and attaches it to everything. When the person signs in, you call identify with your own user ID, and Binoban stitches the earlier anonymous activity to that known user.

Getting this right is the difference between one coherent profile and several fragments. See Identity strategy for the full model across web, mobile, and server.

Events are a contract

track("signed_up", { plan: "Enterprise" }) only has meaning because everyone agrees what signed_up and plan mean. Event and property names are an API between your app and everything downstream — audiences, campaigns, reports. Name them deliberately and keep them stable.

The semantic spec defines the shape of identify/track/page and a standard ecommerce event catalogue so common retail actions mean the same thing everywhere.

Hosts and deployment

Binoban runs in three shapes, and your host configuration is what differs:

• Cloud — you point at Binoban's hosted endpoints.
• On-prem — you point at your organization's own deployment.
• Air-gapped — an on-prem deployment with no outbound internet; the SDKs and these docs are designed to work fully offline.

Because of this, hosts are always explicit in your SDK setup rather than hard-coded — the same integration code runs against any deployment by changing the host values.

Versioning and contracts

SDKs, APIs, and these docs evolve together, and your integration depends on those contracts staying stable. Versioning & contracts explains how changes are versioned and communicated so an upgrade never silently breaks you.

Where to go next

• Learn by doing → Quick Start
• Understand identity → Identity strategy
• Look up the contracts → Reference · Track/Identify call spec