Glossary

Quick definitions of Beacon’s key concepts. Cross-links point to the manual page explaining each in full.

A

Actor. The person or entity an event is about. Identified by actor_id — supply a stable identifier (user ID, license key) for production; a clearly fake one (test-user-1) during development.

Actor identity. A link between two actor_id values for the same person — typically an anonymous-to-signed-in transition. Recorded by your SDK’s Identify call and surfaced on the Actor Identities page within seconds.

Aggregation. Beacon’s background data refresh, running every 15 minutes. Most dashboard pages read this refreshed view, so events you just sent take up to 15 minutes to appear. A few pages (Invalid Events, Actor Identities, Funnels, Property Explorer’s key list and summary) read raw events and update in seconds. See Events not showing up.

Allowlist. A whitelist of events that Beacon will accept for a specific product and version. Without one, every well-formed event is accepted; with an active allowlist, only the event types on the list are accepted (anything else is rejected to Invalid Events). Useful for catching typos in production. See Create your first allowlist.

API key. A credential your SDK uses to authenticate to Beacon. Tenant-scoped — one key works for any product in your organization. The plaintext value is shown once at creation; lost keys must be revoked and replaced. See Generate an API key.

C

Cap state. Your tenant’s ingestion status — the colored badge on the Billing page. Monthly-allotment states: Active, Soft Cap Exceeded, Grace Period Active, Hard Capped (cap-policy plans only). Terminal states: Cancelled, Trial Expired. See Cap exceeded behavior.

Cap-policy plan. A plan that stops accepting new events once you exceed your monthly allotment (Trial and Starter). Charge-policy plans (Pro and Business) accept the overage events and bill for them instead.

Category. A required event field grouping events by feature area — for example, reports, auth, settings. The category plus the event’s name together identify what kind of event it is.

D

Dead letter. A rejected event preserved for debugging. Surfaced on the Invalid Events page with the rejection code (UNRECOGNIZED_PRODUCT, ALLOWLIST_REJECTED, UNREGISTERED_VERSION, etc.) and a human-readable reason.

E

Event. A single occurrence of something interesting in your application — a feature used, a button clicked, a milestone reached. Required fields: event_id, category, name, timestamp, actor_id, source_app, source_version. Optional: properties and session_id. Max 4 KB per event.

event_id. A required unique identifier for each event. UUID v7 recommended (time-ordered). Used for deduplication — re-sending an event with the same event_id is a no-op.

F

Funnel. A saved sequence of step events measuring how many actors convert from one step to the next within a configurable time window. See Funnels.

G

Grace period. The window between hitting your monthly allotment and ingestion being hard-capped. 3 days on Trial and Starter. The cap state during this window is Grace Period Active.

I

Identify. The SDK call that records an actor identity. Maps an anonymous actor_id to a real one without losing prior history.

Invalid Events. The dashboard page listing dead letters. Updates within seconds of ingestion.

P

Plan. Your subscription tier: Trial (21d free), Starter ($79), Pro ($199), Business ($499), Enterprise (custom). Sets event allotment, retention, team size, overage policy. See View your plan & usage.

Product. A registered application in your Beacon tenant. Each event’s source_app must match a product’s slug or the event is rejected with UNRECOGNIZED_PRODUCT. Any tier can create as many products as needed. See Create a product.

Property. Optional key/value pair on an event for filtering and grouping. Flat only. Max 20 keys per event; key max 64 chars; value max 256 chars.

R

release_date. An optional date on a version recording when it shipped to users. Used today as a tie-breaker for the version selector’s “Latest” option; reserved for future release-window analytics.

Retention. How long Beacon keeps your raw event data before purging. Per plan: 30 days (Trial), 1 year (Starter), 2 years (Pro), 3 years (Business), 10 years default on Enterprise (contract override available).

S

SDK. The library your application uses to send events. Available for .NET, C++, and JavaScript / TypeScript. All three handle batching, retry, and session management. .NET and C++ persist queued events to local storage so they survive restarts and outages; JS uses an in-memory queue. See the SDK docs.

Segment. A saved set of rules identifying actors by behavior — e.g., “users who exported a report 5+ times last month but never opened the dashboard.” See Segments.

Session. A bounded period of user activity. Started by your SDK, ended explicitly or by an automatic timeout. Surfaces on the Sessions page.

session_id. An optional unique identifier linking an event to a session. Set automatically by the SDK when a session is active. On regular events, a malformed session_id is rejected as INVALID_FIELD_FORMAT. On exception reports, a malformed value is silently ignored (the exception is still recorded).

source_app. The product slug carried on every event, session, exception, and identify call. Must match a registered product in your tenant.

source_version. The version of your application that emitted the event. Auto-registered on first sight by default; must be pre-registered when strict version mode is on.

Strict version mode. A per-product setting that rejects events whose source_version isn’t pre-registered. Useful for teams who want to lock down which versions can produce data. See Strict version mode.

T

Tenant. Your Beacon organization. Your data is isolated from every other tenant’s at multiple layers — you only ever see your own events, products, users, and billing state.

V

Version. A specific application version your SDK reports for a product (1.2.0, 2026.10-rc1, whatever convention you use). Auto-registered on first ingestion by default; can also be registered explicitly via the portal, where you can optionally set a release date. See Register a version.