Glossary & Core Metric Definitions

Welcome to the ConfigBee Reference Glossary. This centralized repository provides precise technical definitions, architectural boundaries, and operational terminologies utilized across our platform, dashboards, and official SDKs.

Whether you are auditing your account’s resource usage, configuring advanced user targeting, or integrating an SDK into your application lifecycle, use this guide to ensure structural alignment with ConfigBee mechanics.

Core Infrastructure Metrics

To provide predictable, transparent scaling and safeguard our unified global delivery networks, ConfigBee provisions account tiers around two fundamental architectural metrics: Monthly Active Visitors (MAVs) and Deployment Units (DUs).

Monthly Active Visitors (MAVs)

MAVs measure the unique volume of client-side end-users and devices interacting with applications connected to a ConfigBee Account within a rolling calendar month. Calculated independently of server-side operations or backend microservice footprints, MAVs track real-world, front-facing client engagement rather than internal team seats.

ConfigBee utilizes a proprietary telemetry framework that works in tandem across our client-side SDKs and our global Object Distribution-Delivery Network (ODN)—leveraging intelligent edge logic and backend synchronization to dynamically monitor traffic and track MAVs.

For all practical purposes, MAVs and MAUs are the exact same metric: they both quantify your active user base. We simply use the term MAV (Monthly Active Visitor) to be fully transparent about how feature flag infrastructure actually counts traffic:

Reporting & Analytics Tools (e.g., Google Analytics): These tools calculate MAUs based on unique tracking IDs or authenticated database records. Their goal is behavioral reporting, meaning anonymous visitors and logged-in users are treated as distinct analytical records.
Feature Management Billing Engines: Industry-standard feature flag platforms use the label “MAU” but are structurally forced to meter usage based on unique client devices or context keys to protect their edge networks from unauthenticated traffic.

ConfigBee uses the term MAV (Monthly Active Visitor) to bring absolute clarity to this model. Because edge networks must evaluate flags for both anonymous pre-login traffic and identified post-login profiles, our device-first baseline tracks both accurately. Crucially, ConfigBee bridges these states so that an anonymous visitor who subsequently logs into an account on the same device does not generate a double-billing penalty.

Session States & Identity Tracking

To balance flexibility and precision, ConfigBee distinguishes between two core operational session states:

Anonymous Sessions: Initialized automatically when a client SDK starts up without defined user targeting properties.
Identified Sessions: Triggered the moment explicit identity vectors (such as user_id, account_id, org_id, user_name, etc.) are set or become available.

When targeting properties are explicitly cleared within the application, the active identified session closes and gracefully reverts back to an anonymous session.

Session Lifecycle & Expiration Rules

To maintain network optimization and data accuracy, visitor interactions are governed by precise platform-specific SDK triggers and lifecycles:

Initialization Trigger: An anonymous session is initialized the exact moment the ConfigBee SDK is initialized on a specific device, regardless of whether a configuration or flag evaluation has taken place yet.
30-Day Inactivity Timeout (Identified Sessions): If an end-user, device, or system operating within an Identified Session records zero configuration requests or evaluations for a continuous period of 30 days, that specific identified profile automatically expires. Subsequent activity after day 30 will initialize a new MAV.
Native Mobile/Desktop Applications: On native platforms, tracking states are securely bound to the unique application instance on that specific device. Standard events—such as installing app updates, minimizing/running the app in the background, or force-closing the application—will keep the existing lifecycle intact. However, explicitly uninstalling and reinstalling the application resets local tracking storage, which will initialize a fresh visitor profile.
Web Origins & Navigation: For web-based applications, active sessions are isolated by domain, subdomain, and specific browser architecture. Standard front-end user actions, including refreshing the browser page or navigating across different URL paths within the same origin, maintain the active session seamlessly.

How MAVs are Calculated

A single hardware or client device typically cycles through a continuous series of anonymous and identified states. ConfigBee evaluates these sequences to calculate actual MAV usage based on the following structural logic:

The Device & Context Baseline: At its core, MAV tracking counts unique hardware/client devices. A MAV is initialized when a new device is first detected and seamlessly tracks through its subsequent anonymous and identified cycles.
State Transition Rules (Anonymous 🔄 Identified): Moving a device from an anonymous session to an identified session (or vice versa) does not generate an additional MAV. They are bound together as part of the same unique visitor lifecycle.
Context Mutation Boundaries: If multiple distinct identities are explicitly authenticated sequentially on the same physical device (e.g., swapping from user_id = 1 to user_id = 2), each unique identified profile is recognized as an additional, isolated context vector and increments the MAV count. Conversely, if the same identity switches sessions or re-authenticates across different cycles on that same device, it continues to resolve as a single collective MAV.
High-Density Identity Guardrail: In highly exceptional, extreme scenarios where the volume of distinct, unique identified sessions vastly outpaces the physical count of unique identified devices, the ConfigBee ODN may systematically utilize the unique identified session volume as the overarching MAV metric for that period to ensure network stabilization.
Environment, Project & Domain Isolation: Client journeys are securely bound within the structural limits of each specific project, operational stage environment, and web origin. If a device interacts across separate standalone applications or environments (e.g., Staging vs. Production), it resolves as isolated environment vectors and contributes to the aggregated account-wide MAV sum.
Incognito & Sandbox Environments: Actions initiated inside private browsing modes, incognito windows, or cleared-cache environments do not share persistent local storage. Each unique instance triggers a distinct, fresh device profile.

Anti-Abuse & Multiplexing Guardrails

Our MAV model is designed to scale generously with your user base, assuming standard architectures where individual end-users, devices, or systems map to individual sessions.

The Multiplexing Restriction: Funneling traffic from multiple distinct customers, independent companies, or separate downstream entities through a single, static identity profile (user_id or account_id) to artificially deflate MAV counts violates platform policy.
Automated / Bot Traffic: Automated headless traffic, high-frequency web scraping, or automated testing suites that rapidly cycle or randomize device profiles or context parameters will distort MAV counts. If you are running massive automated end-to-end testing suites, please contact support to help isolate testing environments from production MAV calculations.

Deployment Units (DUs)

DUs represent the structural footprint of your architecture on ConfigBee’s global delivery network. While MAVs measure user-facing runtime traffic, DUs quantify the number of distinct, isolated configuration containers managed under your account.

Think of a Deployment Unit as a secure, independent logical sandbox. Within this sandbox, a specific set of feature flags, remote configurations, and targeting rules live and execute at the edge. DU count is entirely independent of how many frontend apps, websites, or background microservices choose to consume those flags.

How Deployment Units are Calculated?

DUs are calculated systematically by adding up the number of environments running across all your projects:

Total Deployment Units (DUs) = Sum of all active Environments across all Projects

Projects: The top-level logical boundary for a distinct software product, microservice, or major system module. A Project shares a unified set of feature flags and option schemas across all platforms.
Environments: The operational stages within each project used throughout your release pipeline (e.g., Production, Staging, Development). Each individual environment instance contains its own distinct flag evaluations and option values, and counts as one DU.

Example Calculation: Let’s say your ConfigBee Account runs 2 Projects:

E-Commerce-Platform - uses 3 environments: Production, Staging, Development

Core-Billing-API - uses 2 environments: Production, Staging

Your total account consumption is calculated as: 3 Environments + 2 Environments = 5 DUs

Note: Connecting multiple client interfaces (e.g., iOS App, Android App, Web App, and Website) to the same project and environment does not increase your DU count.

If you are migrating from or comparing ConfigBee to platforms that meter usage based on “Service Connections”, please note a crucial architectural difference:

The Service Connections Model: Tethers billing directly to your active infrastructure scale. Under that model, if you scale a backend API from 2 server instances to 50 pods in a Kubernetes cluster during peak traffic, your bill multiplies linearly with that pod count.
The ConfigBee DU Model: Disconnects your billing from your infrastructure footprint entirely. ConfigBee focuses purely on your logical organization. If you have 3 environments running across your projects, you consume exactly 3 DUs—whether those environments are serving 1 local developer laptop or an auto-scaling cluster with 1,000 backend microservice instances.

A Note on Backend Microservices:
When your backend microservice instances establish persistent links to ConfigBee, they fall under our standard Concurrent Connections limit outlined in our Fair Usage Policy (FUP). Rather than penalizing you for scaling, this limit is designed to scale generously alongside your tier’s MAV allowance, ensuring that standard backend infrastructure auto-scaling is fully supported without unexpected overages.