Something interesting happened quietly in a recent ad platform API release: experiment statistics got pulled directly into the same reporting layer as campaign performance data. A/B test results — variant comparisons, lift estimates, significance signals — now live alongside spend, impression, and conversion numbers rather than in a separate testing interface you had to navigate to separately.
That's a small technical change. It's not a small behavioral one.
Why psychological distance kills experiment influence
When experiment data lives in a separate tool, it creates a psychological distance between "we tested something" and "we acted on something." The test becomes its own artifact. You run it, you read the report, you file the insight somewhere, and then — with a gap of days or weeks — you make a campaign decision that may or may not reflect what you learned.
This is a textbook case of what behavioral economists call the availability heuristic working against you. Decisions get made based on information that's mentally accessible, not necessarily information that's most relevant. When experiment results require effort to retrieve, they lose the competition for attention against metrics that are already in front of you.
Collapsing that distance matters more than it sounds.
Decision latency and the proximity effect
In experimentation work across different verticals, one of the most persistent failure modes isn't bad test design — it's good test results that never fully close the loop into action. A team runs a clean experiment, finds a meaningful lift on a bid strategy variation, documents it in a testing tracker, and then three weeks later the campaign manager makes a budget decision based on recent CPL trends rather than the experimental signal. Not because they ignored the result. Because the result wasn't there when the decision was made.
The technical term is decision latency. The behavioral term is proximity effect — we weight information more heavily when it's spatially and temporally close to the decision point.
Embedding experiment stats directly into campaign reporting is a nudge architecture change. It keeps the experimental signal visible at the moment a budget or targeting or bid decision gets made.
The confirmation-bias dynamic
There's a second behavioral dynamic worth naming: confirmation bias in experiment interpretation.
When test results live separately from performance data, there's a subtle pull toward treating the experiment as the "truth" layer and the campaign data as the "noise" layer. You check the experiment to find out what works, then go manage campaigns accordingly.
But those two data streams aren't separate. The experiment is the campaign data, sampled under controlled conditions. When you see them side by side — variant A drove a materially lower CPA in the test period, and that signal persists in the live campaign data over the following weeks — you're looking at corroborating evidence across both lenses simultaneously.
That combination is harder to dismiss. A result that appears in your experiment view and shows up as a directional pattern in your ongoing performance metrics has more behavioral weight than either signal alone. It triggers what Kahneman would call System 2 engagement — slower, more deliberate processing — because the evidence is showing up through multiple channels at once.
More test types, more peeking risk
The new test types unlocked in this API update are worth watching for a different reason.
More test type options means more surface area for the peeking problem. When you can run more kinds of experiments more easily, the temptation to check results early increases. Not because practitioners are unsophisticated — but because more experiments running simultaneously creates more cognitive load, and under load, people default to simple heuristics. "This one is trending positive" becomes a sufficient reason to call a result.
The infrastructure improvement doesn't solve methodological rigor. It has to be paired with predefined stopping rules, minimum runtime commitments, and a team norm that treats early significance as a checkpoint, not a conclusion. What the infrastructure does is make it easier to see everything at once — which is genuinely valuable as long as "seeing" doesn't collapse into "deciding" before the test has enough data to be trusted.
Here's the pattern worth watching across any experimentation program: the best organizations don't win because they run more tests. They win because the tests they run stay visible long enough to actually change behavior.
If experiment data disappears into a separate dashboard, it loses the race against whatever's on the screen when decisions get made.
What you could test
Something to test yourself: Look at your last five experiment results. For each one, identify the decision it was meant to inform and the date that decision actually got made. Then check: was the experiment result visible at that decision point, or did someone have to go looking for it? The gap between those two things is your action latency. That number is worth knowing.
Related reading: underpowered A/B tests, experimentation governance, and how holdout tests prove incremental revenue. I built GrowthLayer to make experimentation repeatable across a program; for more field notes, subscribe to Lean Experiments.