> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kameleoon.com/llms.txt
> Use this file to discover all available pages before exploring further.

# How Kameleoon tracks and counts unique users

> Understand the differences between Monthly Unique Users (MUU), Monthly Tracked Users (MTU), and Annual Tracked Users (ATU) measurement models and how Kameleoon calculates usage.

Kameleoon tracks your usage based on one of several measurement models, depending on your chosen pricing plan: **Monthly Unique Users (MUU)**, **Monthly Tracked Users (MTU)**, or **Annual Tracked Users (ATU)**.

Kameleoon features a native consent management system and only collects data from users who provide consent. [Learn more about Kameleoon’s consent management policy](../../project-management/consent-management-policy).

If your website experiences bot traffic, exclude it from your campaign results. [Learn how Kameleoon filters bot traffic](../../experiment-analytics/troubleshooting/data-discrepancies#how-does-kameleoon-filter-bot-traffic-from-my-results).

Kameleoon counts users only once, even if they participate in different experiments or feature flags across multiple devices.

## Measurement models

Kameleoon offers three measurement models. The main difference between them is whether you pay for your **potential traffic** or your **actual campaign engagement**, and for engagement-based plans, whether your quota renews every month or arrives as a single annual grant.

### Monthly unique users (MUU)

Kameleoon bases the **MUU model** (standard for Enterprise plans) on the **total traffic** visiting your website or app.

* **How it works**: Kameleoon calculates your usage based on the average number of unique monthly visitors over a 12-month period. It counts a user when they visit your site, regardless of whether they interact with an experiment.
* **Why choose it?**: It provides **cost predictability**. Because you pay based on total traffic, you can run unlimited experiments and allocate 100% of your traffic to them without additional costs.
* **Suited for**: Teams that run many experiments or high-traffic tests and want to avoid worrying about "spending" a quota on every test.

### Monthly tracked users (MTU)

Kameleoon bases the **MTU model** (standard for Starter plans) on **campaign engagement**.

* **How it works**: Kameleoon only counts a user as an MTU when they **interact with an active campaign**, such as an experiment or a feature flag.
* **Why choose it?**: It provides **cost flexibility**. You only pay for the visitors you reach with your experiments. This model is ideal if you only test on specific visitor segments or low-traffic journeys.
* **The trade-off**: Pushing high-traffic experiments (like a 100% allocation to a winning variant) or experiencing traffic spikes in an experiment will consume your MTU quota faster.
* **Suited for**: Brands with selective testing needs or those who want to scale their costs exactly with their testing activity.

### Annual tracked users (ATU)

The **ATU model** uses the same engagement-based pricing as MTU, but grants your entire year's quota upfront instead of resetting it every month.

* **How it works**: Kameleoon multiplies your monthly MTU allowance by 12 and grants that full amount as a single pool at the start of your annual contract period. For example, a plan with a 100,000 MTU monthly allowance receives 1,200,000 ATU upfront. You draw down against this pool as visitors interact with your experiments and feature flags, using the same de-duplication and visitor-identification logic as MTU.
* **Why choose it?**: It removes the monthly reset, so you can front-load testing during peak periods and taper off later without losing access to capacity you didn't use in a given month.
* **The trade-off**: Your quota doesn't renew until your contract renews, so spending it faster than a 12-month pace leaves you without capacity for the rest of the period. For example, if you exhaust your pool after 9 months, you can't run new experiments or feature flags for the remaining 3 months unless you upgrade to a higher plan.
* **Suited for**: Brands with seasonal or uneven testing activity who want flexibility in when they use their quota, not just how much they use.

### Model comparison at a glance

| Comparison | MUU Model (Total Exposure) | MTU Model (Engagement Based) | ATU Model (Annualized Engagement) |
| :- | :- | :- | :- |
| **Which visitors does Kameleoon count?** | Every visitor to your site. | Only visitors in an experiment/flag. | Only visitors in an experiment/flag. |
| **Predictability** | High; costs stay stable as you test more. | Variable; costs depend on your testing activity. | Variable within the year; costs depend on your testing pace against the annual pool. |
| **Experiment limits** | Unlimited; no campaign or traffic caps. | Capped; limited by your monthly user quota. | Capped; limited by your annual user quota. |
| **Traffic spikes** | Spikes in site traffic don't affect billing. | Spikes in experiment traffic can reach limits. | Spikes in experiment traffic can reach limits. |
| **Winning variants** | Pushing 100% traffic is "free." | Pushing 100% traffic costs more MTUs. | Pushing 100% traffic costs more ATUs. |
| **Quota renewal** | Averaged over a rolling 12-month period. | Resets every calendar month. | Granted once per year; doesn't reset monthly. |

## Web Experimentation

Kameleoon measures users based on cookies. A cookie is a file that the system places in a browser that contains an anonymous unique identifier, called the Kameleoon `visitorcode`, randomly assigned to a user. Kameleoon uses this ID to identify a browser. Kameleoon stores a `visitorcode` for 365 days in the user's browser.

## Feature Experimentation

For more information on how Kameleoon counts and tracks unique users in Feature Experimentation, see the [FAQ in the developer documentation](../../../developer-docs/feature-experimentation/technical-reference/faq-global#when-does-the-sdk-send-a-tracking-request-for-analytics).

## MTU details

**MTU** represents the number of unique visitors exposed to at least one Kameleoon experiment or feature flag within a calendar month.

Kameleoon uses the following logic to count MTUs:

* **De-duplication**: Kameleoon counts each visitor only once per calendar month, regardless of how many times they visit your site or how many experiments they trigger. For example, if a user participates in three different experiments in 1 month, they still only count as 1 MTU.
* **Visitor Identification**:
  * **Anonymous visitors**: Kameleoon identifies anonymous visitors using a unique `visitorcode` stored in a browser cookie.
  * **Identified visitors**: If you provide a custom unique ID (such as a login ID), Kameleoon can de-duplicate those users across different devices and browsers, ensuring they only count as 1 MTU.
* **Monthly Reset**: Your MTU count resets to zero at the beginning of each calendar month.

### View MTU counts

You can view your current MTU count on the **Organization page** (click **Admin** and select **Organization**).

<Frame>
  ![](https://storage.googleapis.com/kameleoon-storage-documentation/user-manual/images/account-and-team-management/mtu/mtu.png)
</Frame>

### Threshold notifications

Kameleoon displays warning banners and sends email notifications when you reach the following thresholds:

* 90% of the MTU limit.
* 100% of the MTU limit.
* 3 days after reaching 100% of the MTU limit.

The **Organization page** also reflects these thresholds.

### Reaching the limit

If you reach the MTU limit, Kameleoon grants a three-day grace period to request an upgrade. If you don't upgrade within that period, Kameleoon automatically pauses all active campaigns.

When Kameleoon pauses campaigns, the MTU count resets at the end of the monthly period, and paused campaigns automatically resume.

## ATU details

**ATU** uses the same engagement-based measurement as MTU, except Kameleoon grants your quota once per year instead of resetting it every month.

Kameleoon uses the following logic to count ATUs:

* **Annual allocation**: Kameleoon grants your full annual quota, 12 times your monthly MTU allowance, as a single pool at the start of your contract period, instead of granting a smaller quota every month.
* **De-duplication**: Kameleoon counts each visitor using the same engagement-based de-duplication logic as MTU, then draws that usage from your annual pool rather than a monthly quota.
* **Visitor identification**: Kameleoon identifies anonymous visitors through a `visitorcode` cookie and de-duplicates identified visitors across devices using a custom unique ID, exactly as it does for MTU.

### Reaching the limit

If you exhaust your ATU pool before your annual contract period ends, you can't run experiments or feature flags for the remainder of that period unless you upgrade to a higher plan. For example, if you use your entire annual quota after 9 months, you lose access to new experiments and feature flags for the remaining 3 months unless you upgrade.

## FAQ

<AccordionGroup>
  <Accordion title="Does Kameleoon collect third-party cookies and data?" id="does-kameleoon-collect-third-party-cookies-and-data">
    No. On your website, Kameleoon always stores data in a first-party context tied to your domain and never stores third-party data on Kameleoon-owned domains. Experiments and personalizations keep working when visitors block third-party cookies.

    Kameleoon stores a randomly generated visitor ID in a [first-party cookie](#web-experimentation), so each visitor consistently sees the same variation. Consistent assignment provides accurate results and a seamless user experience.

    Signing in to the Kameleoon app, the Graphic editor, and PBX is different: those tools need third-party cookies enabled in your browser. See [Why can't I log in to Kameleoon tools?](../../experimentation/web-experimentation/graphic-based-experiments/troubleshooting-the-graphic-editor#why-cant-i-log-in-to-kameleoon-tools).

    See the [complete list of data collected by Kameleoon](../../../developer-docs/privacy-and-compliance/data-collection-client-side).
  </Accordion>
</AccordionGroup>
