There are some cases where you may want certain users not to count toward your Monthly Active Users (MAU) usage. Common examples include:

• Internal team members using your product
• Test accounts and QA sessions
• Staging or sandbox environments
• Automated or bot traffic

You can control this by excluding specific users from your identify call in your Appcues installation.

What counts as a Monthly Active User (MAU)?

A MAU is typically defined as a unique user ID that:

• Is identified via an identify call, and
• Is active (ie logs in) within the billing period.

If a user never appears in your identify calls they will not count toward your MAU number.

Option 1: Do not call identify for excluded users

The most reliable way to ensure a user never counts toward MAU is to skip the identify call completely for that user.

You can do this by adding a simple condition around your identify logic.

Example: Exclude internal team members by email domain

function shouldIdentifyUser(user) {
	const email = user.email || "";
	const isInternal =
		email.endsWith("@yourcompany.com") ||
		email.endsWith("@contractor-company.com");

	// Skip identify for internal/QA emails
	return !isInternal;
}

if (shouldIdentifyUser(currentUser)) {
	appcues.identify(currentUser.id, {
		email: currentUser.email,
		name: currentUser.name,
		plan: currentUser.plan,
	});
}

In this example:

• Users with @[yourcompany.com](<http://yourcompany.com>) or @[contractor-company.com](<http://contractor-company.com>) emails are not identified.
• Since they are never identified, they will not count as MAU.

Example: Exclude users based on role or feature flag

const user = window.currentUser;

const isNonBillableRole = ["internal", "qa", "demo"].includes(user.role);
const isExcludedByFlag = user.features?.excludeFromMAU === true;

if (!isNonBillableRole && !isExcludedByFlag) {
	appcues.identify(user.id, {
		email: user.email,
		role: user.role,
		account_id: user.accountId,
	});
}

Only users whose role is not internal, qa, or demo, and who do not have an excludeFromMAU flag set, will be identified.

Option 2: Skip identify in non-production environments

If you run Appcues in multiple environments, you can use environment checks to avoid identifying users outside production.

Example: Only identify users in production

const isProduction =
	window.location.hostname === "app.yourproduct.com" ||
	window.location.hostname === "www.yourproduct.com";

if (isProduction) {
	appcues.identify(currentUser.id, {
		email: currentUser.email,
		name: currentUser.name,
	});
} else {
	// Staging/local – do not identify users
	console.debug("Skipping identify in non-production environment");
}

You can also use:

• Environment variables (e.g., process.env.NODE_ENV === "production")
• Custom config flags (e.g., [window.APP](<http://window.APP>)_ENV)

This ensures staging and local testing traffic never appears in MAU calculations.

Recommended best practices

To keep MAU usage clean and predictable:

• Define a clear policy for who should count as a MAU

For example: paying customers and trial users, but not internal staff, QA, or demo accounts.

• Implement a single shared resource

Wrap your identify logic in one reusable function so every part of your app uses the same exclusion rules.

• Exclude at the earliest point possible

Prefer skipping identify entirely for users who should never be billable.

• Keep your exclusion rules versioned and documented

Document which email domains, roles, or flags are considered non-billable, so other teams can safely add or remove cases.