Accounts

The Accounts page (sidebar Explore → Accounts) answers customer-level questions about your product: which customers are using it, which are quiet, which are dormant, which versions are deployed, who’s running into errors? Pair it with Licenses for entitlement-level context.

An account in Beacon represents one of your customer organizations — distinct from an actor (a user or device) and a license (an entitlement or contract). Account context is opt-in: your SDK must call SetAccount(...) for events to be associated with an account.

Prerequisites

• Plan: Account and License analytics are available on Trial, Business, and Enterprise. Starter and Pro do not have access — those tenants see a “Available on Business and above” paywall when navigating to the page. Ingestion is tier-blind, so the moment you upgrade to Business the data is already there with zero backfill.
• Permission: view_accounts.
• SDK: your application must call the SDK’s SetAccount(accountId) (or setAccount(...) in JS / C++) before tracking. Until you do, every event arrives without account context and the page shows the “no account data” empty state.

How an account gets into Beacon

There are two ways account_id reaches Beacon:

1. Recommended: your SDK calls the typed context method (tracker.SetAccount("acct_acme") in .NET, beacon.setAccount("acct_acme") in JS, tracker->setAccount("acct_acme") in C++) after login or license activation. From that point on, every event, session start, and exception report carries the account ID until you call the matching Clear* or Reset().
2. Direct API: the account_id field on the event / session / exception payload (see the API reference).

Account IDs are 1-256 chars, opaque, customer-supplied, and never validated by Beacon. Use pseudonymous identifiers — a tenant UUID, a customer slug, or a contract ID — not names or emails.

The same SDK call surface adds license_id via SetLicense(...) for entitlement-level context. See Licenses for how that data flows.

Filters

A filter strip at the top of the page:

• Search — free-text filter over account IDs currently shown on the page.
• Source App — restrict to one product.
• Source Version — narrow further (depends on the selected product).
• Activity — Active, Quiet, or Dormant. See “Activity statuses” below.
• License ID — show only accounts observed using a specific license.
• Used event — (category, name) pair; show only accounts that performed the event.
• Not seen since — show only accounts whose last activity is older than N days.

Search is client-side over the current page. The other filters are server-side and re-fetch on change.

Activity statuses

Status is derived from last_seen_at at request time:

A new account with no activity yet doesn’t appear in the list — only accounts with at least one observed event, session, or exception are tracked.

Sections

Coverage banner

When account coverage drops below 80% in the selected window (events arriving without an account_id), a banner appears at the top suggesting you instrument tracker.SetAccount(...). See Data Governance for the full coverage view.

Stats cards

Five tiles summarising the window:

• Total — total accounts observed.
• Active (7d) — accounts active within the last week.
• Quiet (8-30d) — accounts seen recently but not this week.
• Dormant (>30d) — accounts last seen over a month ago.
• Account coverage % — share of events that carry an account_id.

Accounts table

Sortable rows with: Account, Status, Last seen, Active actors 30d, Sessions 30d, Events 30d, Exceptions 30d, Products, Versions, Licenses, Top feature.

• The Account cell links to the Account Detail page.
• The Licenses cell links to the Account Detail page with the Licenses tab pre-selected.
• Other cells are read-only in the current release.

The list is keyset-paginated with Load more at the bottom.

Account Detail

Clicking an account opens /accounts/[accountId] with tabs:

• Overview — KPI cards (active actors, sessions, events, exceptions, licenses, versions), activity-trend chart, version distribution, top features, recent exceptions.
• Features — feature usage by (category, name) with event count, actor count, first/last seen, and trend.
• Actors — paginated list of actors observed under the account with last seen, events 30d, sessions 30d, top version.
• Licenses — licenses observed under the account; license row click drills into License Detail.
• Sessions / Exceptions / Environment — placeholders that link out to the main pages with account_id already applied as a filter.

The URL preserves the active tab via ?tab= (e.g., /accounts/acct_acme?tab=licenses).

Note: Account Detail does not include a Funnels or Retention tab. Those are dedicated pages with their own filters and Count by toggle. See “Counting by account” below.

Counting by account

When account context is enabled, the Segments, Funnels, Retention, and Churn pages get a Count by toggle with two options:

• User — the default; counts individual users (your existing behaviour).
• Account — counts customer accounts; an account “matches” if at least one of its users does.

On the Funnels detail page, switching to Account changes step counts from distinct users to distinct accounts. An account counts as having converted a step if any of its users did, anchored on the user that first hit step 1.

The toggle is locked with a tooltip on Starter and Pro — same plan gate as the Accounts page.

Funnel member drill-down

A related improvement that landed in the same release: on the Funnels detail page, the count next to each step is now clickable. Clicking opens a side drawer listing the users (or accounts, when Count by is set to Account) the count represents. Each row deep-links: account rows link to Account Detail; user rows are copyable code chips. See Funnels for details.

Account & License filters on existing pages

These pages accept account/license filters when you’re on Business+:

• Event Explorer — filter events to one account or license.
• Sessions — filter the table and charts to sessions tagged with the given account/license.
• Exceptions — filter the exception list to one account or license; exception detail surfaces affected-account counts.
• Environment — filter the per-OS / runtime summaries.

On Starter and Pro the filter chips and dropdowns are hidden; the rest of the page works as before.

Data freshness

The Accounts list and license rollups are recomputed by a background observation job that runs every 60 seconds. New accounts appear within ~1 minute of the first event under that ID. Coverage percentages are computed on each request and reflect the data available at that moment.

The job is tier-blind — your account/license context is captured on every plan, even before you upgrade to Business. When you do upgrade, historical analytics are immediately available with no backfill latency.

Common questions

What’s the difference between accounts, licenses, and actors? Three lenses on the same usage data:

A single account usually has one or more licenses. Each license is exercised by one or more actors. Picture a CAD vendor whose customer “Acme Corp” buys two SKUs — a 10-seat Designer license and a 5-seat Renderer add-on. A year in, the Designer license is humming and the Renderer is dormant. Three different business questions land on three different lenses:

• “Is Acme engaged enough to renew?” → account level. (Yes — Designer is heavily used.)
• “Are they getting value from the Renderer add-on?” → license level. (No — quiet. Upsell signal or churn warning.)
• “Which individual users have barely opened the app?” → actor level. (For your customer-success rep’s outreach list.)

You don’t need all three. If you sell one product with one SKU per customer, account_id alone is enough — leave license_id null. If you’re solo desktop software with no per-customer concept, set only actor_id. The fields are independent; Beacon never assumes you populated all of them.

The page says “Available on Business and above” — but I’m sending account_id already. Ingestion accepts and stores the field on every plan. Visibility is what’s gated. Upgrade to Business or Enterprise and the data you’ve already sent becomes queryable.

I sent events with account_id but no accounts appear. Three reasons: (1) the observation job hasn’t run yet — wait ~1 minute; (2) the field was sent inside properties instead of as a top-level field, which is rejected; (3) the value failed validation (empty, whitespace-only, contains control chars, or > 256 chars). Check Invalid Events for rejected payloads.

Why a User toggle rather than Actor? The product surface uses end-user-friendly terminology (“Count by User / Account”). Under the hood, the value is still actor — the SDK field name didn’t change.

My counts seem too high — one account per actor. Likely you accidentally set account_id to the same value as actor_id. Data Governance surfaces this as a high-cardinality warning when distinct accounts > 50% of distinct actors over the window. See Data Governance.

One license is observed under multiple accounts — is that a bug? Often it’s a license-sharing report (one contract used across two customer organisations) that you’ll want to investigate. License Detail surfaces this with a badge and a “seen under multiple accounts” warning. If the license is intentionally shared (e.g., a marketplace SKU), ignore the badge.

Next

→ Licenses