Core concepts

Understanding these concepts will help you configure and use SaaS Tracker correctly.

SaaS Tracker is built for B2B SaaS. Every event is linked to a customer_org_id, which represents your paying customer (the end customer’s organization). Unlike user-based analytics tools, SaaS Tracker aggregates usage at the organization level by default.

How data flows

1. Your application sends events to the Ingest API.
2. Events are validated and stored.
3. Data is aggregated into organization-level metrics.
4. Dashboards, Event stream, Feature adoption, and Org health use these aggregates.

Company

A company is your organization in SaaS Tracker (your customer account). It has members, a plan/subscription, and one or more applications. Multi-tenant isolation is at the company level: each company only sees its own apps and data.

Application (app)

An application is a product or service you track. Each app has:

• Its own ingest credentials (e.g. API key) and ingest URL
• Its own event stream and analytics
• Optional environments (e.g. production, staging) if you use the environment field

Plan limits may cap the number of apps per company (see Plans & limits).

Organization (B2B tenant)

In event payloads, customer_org_id identifies the B2B tenant (the end customer’s organization). For example, if you sell to Acme Corp, you might send customer_org_id: "acme_corp". The UI shows Organizations as the list of these IDs with activity and, on supported plans, organization health scores.

In the current version we use a single level of organization; sub-org hierarchies may be discussed in future.

Event

An event is a single row you send to the Ingest API: e.g. a page view, a feature use, or a signup. Required fields: event, user_hash (exactly 64 characters), customer_org_id. You should also send path for page views and page-level analytics. Optional: path, session_id, ts_epoch, environment, plan. (See Event schema for the full list.)

Events are stored and aggregated for dashboards, event stream, event explorer, and health metrics.

Session

A session groups events from the same user visit. If you send session_id from your client, we use it. If you don’t send it, the system infers a session_id (from context and a time window) so that events can still be grouped into approximate sessions. For more accurate session-based metrics we recommend sending a stable session_id from the client.

Feature definitions

Feature definitions (Settings → Feature definitions) describe what “using a feature” means (e.g. which events or conditions). They power Feature adoption and Organization health so the system knows which usage to count.

Plans and limits

Your plan (Trial, Starter, Growth, Enterprise) defines limits (e.g. apps, events per month) and features (e.g. org health model editor). See Plans & limits for details.

Next: Ingest API overview or 10-minute guide.