Debug Kameleoon in Chrome DevTools

What Kameleoon traffic looks like

Kameleoon runs experiments client-side, server-side, or as a hybrid of both, and that architecture is the first thing to establish when debugging it. An experiment that is genuinely running may produce no client-side traffic at all.

Endpoint pattern

The engine loads from static.kameleoon.com, keyed by the site code; data collection and configuration run on kameleoon.com and kameleoon.eu hosts, the latter being the European data-residency option and directly visible in the request

Transport

Script load for the engine, then collection calls for visits, experiment exposures, and custom goals

Client API

The kameleoonQueue array for deferred calls, and the Kameleoon.API namespace for visitor data, goal triggering, and variation information

Key parameters

The site code identifies the account · experiment and variation identifiers appear on exposure calls, which are what populate the campaign report · a visitor identifier ties the session together

Notes

The engine is placed high in the document to close the flicker window. Where it lands in the load order is visible in the stream and is usually the explanation for flicker complaints

Debugging Kameleoon with Event Watcher

• No dedicated parser. Requests are matched by hostname, named Kameleoon, badged with the A/B Testing category, and shown with parsed query and body parameters plus cookies set and sent.
• The exposure call is the one that matters. A visitor can be bucketed into a variation and see the modified page while the exposure never reaches Kameleoon, which produces a live experiment with an empty report. Look for the call carrying the experiment and variation identifiers, not merely for the engine loading.
• Which host answered tells you which data region the account runs in. A kameleoon.eu request is the European residency option in use, worth capturing in a data-flow record rather than taking on trust.
• Silence is a valid result. A server-side experiment assigns before the page is delivered, so there is nothing client-side to observe. Confirm the architecture before treating an empty stream as a fault.
• Script Tree shows whether the engine came from the page's own markup or was injected by a tag manager, which is what decides the flicker window.

Kameleoon and consent

Event Watcher checks Kameleoon against the functional consent category.

Experimentation is commonly classified as functional, on the argument that variation assignment is part of delivering the page. That holds for the assignment and weakens for the measurement, since exposure and goal calls are analytics by any ordinary reading. Kameleoon can bucket while queuing its calls until the CMP answers, which is the posture worth verifying: not whether the engine loaded, but when the first collection call fired.

Common debugging scenarios

• The experiment shows no traffic. Look for the exposure call with the expected experiment id. Engine loads alone do not populate a report.
• The report is empty but the variation is visible. The same finding from the other direction, and the most common Kameleoon issue worth catching early.
• Flicker on the original content. Check where the engine load sits relative to the page's own rendering.
• Which region is this account on? Read the host: kameleoon.eu or kameleoon.com.
• Goals not counting. Confirm the goal call fires at the moment of the interaction and carries the expected identifier.