Licenses

The Licenses page (sidebar Explore → Licenses) shows the entitlements, contracts, and SKUs your customers are exercising — distinct from accounts (the customer organisation) and actors (the user or device). Use it to answer which licenses are active, which are dormant, and which span multiple customer organisations.

A license in Beacon is an opaque, customer-supplied identifier set via the SDK’s SetLicense(licenseId) call. Beacon observes license usage; it does not validate licenses or decide entitlement. The platform is descriptive, not authoritative.

Prerequisites

Plan: Business or Enterprise (same gate as Accounts). Trial tenants also get the page during the 21-day evaluation window. Starter and Pro see the upgrade paywall.
Permission: view_accounts.
SDK: your application must call SetLicense(licenseId) before tracking. Until you do, every event arrives without license context.

Modeling licenses — per-contract vs per-user

Beacon’s analytics are designed around per-contract license IDs: one identifier shared by every user of a customer’s subscription, site, or bundle. Examples:

sub_acme_team_annual
site_acme_corp_hq
bundle_pro_2026

This pattern unlocks the richest License Detail experience — per-license active-actor counts answer “how widely is this contract being exercised?”, and the multi-account warning fires when the same license appears under more than one customer organisation.

Beacon also accepts per-user / per-seat license IDs (one license_id per user, ≈ 1:1 with actor_id), but the License Detail page then shows roughly the same shape as the Actor Identities view, and the multi-account warning never fires by construction. If the platform detects this pattern (Data Governance reports distinct licenses > 50% of distinct actors), Beacon surfaces a non-blocking notice nudging you toward per-contract IDs.

If you need both contract-level analytics and per-seat entitlement tracking, use license_id for the contract and surface seat identity via actor_id or a custom event property.

Validation tip: SetLicense accepts 1-256 chars, no whitespace-only, no control characters. Empty / invalid inputs are silently ignored — the call never throws.

Filters

Search — free-text over license IDs on the current page.
Status — Active / Quiet / Dormant. Same thresholds as accounts (7d / 8-30d / >30d).
Min active actors — show only licenses with at least N active actors in the last 30 days.
Seen under multiple accounts — toggle to show only licenses where distinct_account_count_30d > 1.

Stats cards

The header carries summary tiles for the window: Total, Active, Quiet, Dormant, and (when relevant) a small High-cardinality badge if Data Governance detects per-user licensing.

Licenses table

Sortable columns:

License ID — clickable, opens /licenses/[licenseId].
Status — derived from last_seen_at.
Latest observed account — the account on the most recent observation row carrying this license. If the license has only been observed without account context, this cell is blank.
Distinct accounts (30d) — how many customer organisations have used this license recently. > 1 is what powers the multi-account badge.
Active actors (30d), Events (30d), Products, Versions, First seen, Last seen.

The whole row is clickable. Pagination uses Load more at the bottom.

License Detail

/licenses/[licenseId] shows:

Breadcrumb: Accounts › {latest_observed_account_id} › Licenses › {licenseId}. Both account references link to Account Detail (with the Licenses tab pre-selected).
Header: license ID, status badge, multi-account warning badge (when applicable), first/last seen.
KPI row: distinct accounts (30d), active actors (30d), events (30d), products, versions.
Observed accounts table — every account this license has been seen under, with a per-row link back to Account Detail. When distinct_account_count_30d > 1 an explanatory banner reminds you this is observational, not enforcement.
Products / versions table.
Active actors sample.
Recent activity feed — interleaved events, sessions, and exceptions for this license.

All copy uses “Observed license usage” language — Beacon never asserts a license is valid, only that activity was recorded under it.

Data freshness

License rollups are maintained by the same observation job that powers the Accounts list. Default cadence: 60 seconds. Counts are over rolling 30-day windows from now; first_seen_at is monotonic (only moves backward to capture earlier observations), last_seen_at advances on every recompute.

Common questions

The license I’m sending isn’t showing up. Wait ~1 minute for the observation job to pick it up. If it still doesn’t appear, check Invalid Events for invalid_license_id (validation failure) or reserved_property_key (you sent it inside properties instead of as a top-level field).

Why does the “multi-account” badge fire on a license that’s only used by one customer? Most likely you have a few stray events emitted under one account ID and the rest under another for the same license. The 30-day count tolerates this — investigate the offending events via Event Explorer filtered by license ID.

My license counts grew to almost one-per-user. Likely per-user licensing. Beacon supports it but the analytics are thinner. See “Modeling licenses” above and the high-cardinality notice on the Data Governance page.

Can I export the license list? Not from the Licenses page UI today. GET /v1/licenses is available for direct API consumption.

→ Funnels (with account-level counting)