Data discrepancies
Visits/Visitors discrepancies
How visits and visitors are counted
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. It is stored in the user's browser for 365 days.
Each time the same visitor lands on your site, a new visit is created by Kameleoon and ends as soon as no new activity event (for example, page view, scroll, clicks) has been registered by Kameleoon over the last 30 minutes: Kameleoon creates a new visit after 30 minutes of inactivity.
Ensure the number of visitors and visits are counted the same way in your analytics platform.
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 that must be filtered. The list is a key resource to minimize non-human traffic being counted in Kameleoon's web analytics. Additionally, a Kameleoon visit can be automatically rejected if it is detected as an outlier (bot, troll, tracker bug), which is the case if one of the following conditions is met during a visit:
- 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 does not run on Internet Explorer: visits from Internet Explorer users will be excluded form 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 the Kameleoon. You can set them up from each project's Configuration page.
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 allow them to avoid being blocked by ad blockers. 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 will be one of the first tags to run, so we will send activity events as soon as possible. However, best practices for analytics platforms are often different—most will be loaded in the body
section or after the page has fully loaded. This difference means Kameleoon sends events before most analytics platforms and will be counting more visits and visitors. Visitors may bounce, lose internet connection, or click back. Your analytics platform won't count these visitors, but Kameleoon will.
Analytics platform may be installed on different number of pages than Kameleoon
This issue is a common cause for data discrepancies, especially if you want to run an experiment that is 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 the same Kameleoon snippet has also been installed in your staging environment, your experiment will run there, while your analytics platform likely will not 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 will see the main URLs where the experiment has run, so you can identify URLs where Kameleoon should not 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 that the issue was corrected by receiving fresh data.
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 your events conversions can be compared to Kameleoon results.
Event tracking configuration
You should first check how the event is configured and tracked with your developers and the Kameleoon support team.
Additionally, if you used the Graphic editor to configure your click tracking, ensure the CSS selector attached to you 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 is not measuring the correct event conversions. Refer to this article to learn more.
If you have been using our Activation API to track custom conversions, ensure the API function is called 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, the commands/functions will be instantly executed; otherwise, they will be queued and executed 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 default view on the reporting page is converted visits, 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 visitor conversions are attributed to an experiment by allowing you to define the period of time during which visitors' conversions and transactions are attributed to a variation.
In Kameleoon, visitors' conversions only count toward an experiment when the visit has been targeted by the experiment or during the attribution window, meaning:
- Conversions occurring in subsequent, non-targeted visits are not accounted for in our report unless they happen within the attribution window's timeframe.
- If a conversion event occurs before the targeting decision, it won't be counted in our report, unless the visit was already under the experiment's influence.
In most analytics platforms, it's likely that conversions will continue being counted even if visitors no longer meet the targeting conditions. So, Kameleoon's Results page may show lower total conversions that your analytics platform for the same event.
If you want to learn more about how Kameleoon counts conversions, refer to this article.