Skip to main content

Visits/visitors discrepancies

How Kameleoon counts visits and visitors

Kameleoon measures unique visitors based on cookies and local storage. A cookie is a file placed on a browser that contains an anonymous identifier called the Kameleoon visitor code. The cookie stays in the user’s browser for 365 days. Each time the same visitor lands on your site, Kameleoon creates a new visit. A visit ends when Kameleoon registers no new activity event (for example, page view, scroll, clicks) for 30 minutes: Kameleoon creates a new visit after 30 minutes of inactivity. Ensure your analytics platform counts visitors and visits the same way.

Bot filtering

Kameleoon offers built-in bot filtering, which may differ from your analytics platform. Kameleoon uses the IAB/ABC International Spiders and Bots List to detect events to filter. The list is a key resource to minimize the non-human traffic that Kameleoon’s web analytics counts. Additionally, Kameleoon can automatically reject a visit if it detects the visit as an outlier (bot, troll, tracker bug), which is the case if a visit meets one of the following conditions:
  • Visit lasts longer than 120 minutes.
  • The number of events (such as conversions, clicks, targeting, product page views) is greater than 10,000.

Browser compatibility

Kameleoon doesn’t run on Internet Explorer: Kameleoon excludes visits from Internet Explorer users from your experiment reports. Also note that Kameleoon only maintains full compatibility with the last three versions of any browser, meaning some visits may not appear in your reports.

IP exclusion

In most analytics platforms, you can add IP filtering rules, which let you exclude certain IP ranges from showing up in your campaign results. You should have the same filters in Kameleoon. You can set them up with the Exclude certain IP addresses from reporting option in the Data section of each project’s Settings tab. Kameleoon’s IP exclusion only filters Kameleoon events and the Results pages in the Kameleoon platform. It doesn’t extend to Google Analytics 4 or other integrations, so visitors excluded from your Kameleoon results can still appear in your analytics platform’s own campaign data. Kameleoon’s IP exclusion isn’t retroactive. Visits collected before you add an IP address stay in your Kameleoon results, so older data can still include visitors from that address.

Ad/content blockers

Many visitors use ad blockers to block trackers and advertisers. Some ad blockers can also block client-side trackers, such as analytics events, including Kameleoon client-side events. So, if a significant portion of your visitors use ad blockers, it’s likely the number of visits will vary between Kameleoon and your analytics platform. Some analytics platforms offer “on premise” tracking request URLs that keep ad blockers from blocking them. Note that Kameleoon offers the same capabilities. Contact your Customer Success Manager for assistance. If you believe a large portion of your visitors are using ad blockers, you should send an event to your analytics platform when Kameleoon loads, so you have a better understanding of how many visitors are using ad blockers. To do so, use Kameleoon’s Activation API events to send an event to your analytics platform when Kameleoon loads.

Loading timing/implementation differences

You should implement the Kameleoon snippet in the <head> section of your source code to prevent any flickering from occurring in your experiments. This setup also means that Kameleoon is one of the first tags to run, so Kameleoon sends activity events as early as possible. However, best practices for analytics platforms are often different: most load in the body section or after the page has fully loaded. This difference means Kameleoon sends events before most analytics platforms and counts more visits and visitors. Visitors may bounce, lose internet connection, or click back. Your analytics platform won’t count these visitors, but Kameleoon will.

Your analytics platform may cover a different number of pages than Kameleoon

This issue is a common cause for data discrepancies, especially if you want to run an experiment that’s targeting the entire site. When you select this targeting, Kameleoon executes your experiment’s code on all pages where the Kameleoon snippet is present. Essentially, there’s no specific targeting at all, which could cause differences in your analytic platform’s reporting. For instance, if you also installed the same Kameleoon snippet in your staging environment, your experiment runs there, while your analytics platform likely won’t receive any visits from this environment. You can identify if this is the discrepancy’s cause by breaking down your data by Visited page URL. You see the main URLs where the experiment has run, so you can identify URLs where Kameleoon shouldn’t have loaded (such as other environments and webviews on mobile apps). To avoid this type of discrepancy:
  • Always run an A/A test on a small part of your website to ensure you fully master the scope of your experiment.
  • If you must make targeting adjustments to an A/A test, never do it on the same experiment. Stop that one, and run another A/A test to verify with fresh data that you corrected the issue.

Events discrepancies

If you have discrepancies in the number of visits or visitors, it’s likely you’ll have the same discrepancies for a given event (click tracking, scroll tracking, transaction, or total revenue). So, you should first look at why you have visit or visitor discrepancies. However, if you have similar visit or visitor numbers but different conversions, below are some guidelines to ensure you can compare your events conversions to Kameleoon results.

Event tracking configuration

You should first check with your developers and the Kameleoon support team how you configured and tracked the event. Additionally, if you used the Graphic editor to configure your click tracking, ensure the CSS selector attached to your click tracking is correct. When there is no ID associated with the selected element, Kameleoon selects the element according to its (unique) hierarchical position on the page by creating a hierarchical path from one of the parent blocks containing an HTML ID. So, a data discrepancy may arise from a default CSS selector that isn’t measuring the correct event conversions. Refer to Troubleshooting the Graphic editor to learn more. If you have been using the Activation API to track custom conversions, ensure your code calls the API function after Kameleoon has loaded on your page. You should use the Kameleoon Command Queue, which allows delayed command execution. Instead of calling the Activation API via the Kameleoon.API JavaScript object, you pass commands and functions to another JavaScript object, kameleoonQueue. If the Kameleoon engine is already loaded, Kameleoon executes the commands and functions instantly. Otherwise, Kameleoon queues them and executes them once the engine is ready, ensuring Kameleoon receives all conversion events. Essentially, make sure your events track the same things the same way to match data between Kameleoon and your analytics platform.

Event conversions count

In Kameleoon, you can look at converted visits or all conversions. The reporting page shows converted visits by default, meaning that even if a visitor clicked three times on an element, Kameleoon only counts one converted visit. If you want to compare the total number of conversions, switch to the all conversions view.

Event conversions attribution

The attribution window lets you control how Kameleoon attributes visitor conversions to an experiment: you define the period of time during which Kameleoon attributes visitors’ conversions and transactions to a variation. In Kameleoon, visitors’ conversions only count toward an experiment when the experiment has targeted the visit or during the attribution window, meaning:
  • Kameleoon’s report doesn’t include conversions occurring in subsequent, non-targeted visits unless they happen within the attribution window’s timeframe.
  • If a conversion event occurs before the targeting decision, Kameleoon’s report doesn’t count it, unless the visit was already under the experiment’s influence.
Most analytics platforms likely continue to count conversions even if visitors no longer meet the targeting conditions. So, Kameleoon’s Results page may show lower total conversions than your analytics platform for the same event. If you want to learn more about how Kameleoon counts conversions, refer to How Kameleoon counts conversions.

FAQ

Bots are software applications that run automatically and can bias your campaign results by inflating traffic and conversion metrics. Removing bot traffic is essential for data accuracy.Kameleoon uses two methods to exclude bots:
  1. IAB/ABC International Spiders and Bots List: Kameleoon identifies and excludes known bots from analytics.
  2. Proprietary algorithms: Kameleoon automatically filters visits that it considers outliers (such as trolls or tracker bugs). Kameleoon marks a visit as an outlier if it meets at least one of these conditions:
    • More than 10,000 events.
    • Lasts longer than two hours.
Server-side experiments are more vulnerable to bot traffic. You must pass the user agent to Kameleoon for filtering. Refer to the SDK documentation for implementation details. Client-side SDKs automatically include the user agent.Activate bot filtering
  1. Click Admin > Projects, then click Edit on your project’s row.
  2. On the Settings tab, click Edit in the SDK section.
  3. Turn on Enable bot filtering (for server-side SDK).
  4. Click Save changes.
Ad blockers can affect the Kameleoon production environment, including the engine, client-side SDKs, and tracking requests. Visitors might not see experiments if the browser blocks requests to Kameleoon domains.To avoid these issues, use a custom domain. A custom domain helps bypass ad-blocker detection and ensures your experiments display correctly. Learn more about enabling a custom domain.