feat(debug): Make data reliable when debuging

[jrosendahl-opt]

Summary

When you are debuging a page the sampling and a/b infrastructure get in the way. This change makes it so when you are in debug mode you are also in the production group and there is no analytics sampling.

• Analytics sampling: shouldSample() now returns true immediately when optableDebug is set, regardless of the configured samplingRate
• AB test group: optableDebug forces the production/treatment group, same as optableControlGroup=0 — explicit optableControlGroup=1 still takes priority
• Bot detection: SkipTargetingForBots() returns false immediately when optableDebug is set, so targeting always runs even in bot-like environments (e.g. headless browsers during development)

Activated via ?optableDebug URL param or sessionStorage.setItem("optableDebug", "1") in the browser console, using the existing flags system.

Test plan

• optableDebug in sessionStorage causes shouldSample() to return true even with samplingRate: 0
• optableDebug forces production group assignment even when random bucket would land in control
• optableControlGroup=1 overrides optableDebug (explicit control override still works)
• SkipTargetingForBots() returns false when optableDebug is set
• All existing tests pass (npx jest)

🤖 Generated with Claude Code

[jplaroche]

Personally, I'd bind this to optableControlGroup instead of optableDebug.

[jrosendahl-opt]

This PR has both controlGroup and the sample rate tied to debug with the assumption that when you are debugging you don't want activity hidden by sampling.

Most of the time the first question is did x happen. If id does not happen because of some sampling issue, debugging becomes non-intuitive until you realize sampling is the issue, and then you have to figure out how to turn sampling off.

Is there a use case where logging + sampling + control + turning off bot detection this would present a problem?

If so we could use a different parameter than optableDebug.

[jplaroche]

left a comment