curved-accountant-6477
04/15/2026, 1:57 PMcurved-accountant-6477
04/15/2026, 1:58 PMastonishing-engineer-93454
04/15/2026, 8:35 PMMaybe you'd find this helpful and not a hallucination.astonishing-engineer-93454
04/15/2026, 8:39 PMWhat you can try inside the platform, as a workaround, that gets a part of the way there:
1. Use an Experiment Dimension to represent the other experiment's state at exposure time
GrowthBook supports Experiment Dimensions by adding extra columns to the experiment assignment query, and those dimensions can be used to drill down results. In practice, that means you can attach something like other_exp_variant or pricing_test_bucket to the exposure record for experiment A, then view A's results sliced by whether the user was in B-control vs B-treatment.
2. Interpret that as exploratory heterogeneity, not a formal interaction test
GrowthBook's own docs are pretty explicit that dimensions are best treated as an exploratory tool for debugging and hypothesis generation, not as something to draw strong conclusions from directly, because looking at many slices increases false-positive risk.
3. Use Namespaces when overlap itself is the problem
If the concern is less "measure the interaction" and more "avoid the interaction," Namespaces are the native platform solution. They make experiments mutually exclusive as long as they share the same hash attribute.
4. Use holdouts for cumulative real-world combined effects
GrowthBook's holdout docs (<https://docs.growthbook.io/kb/experiments/holdouts>) are relevant here: they recommend holdouts as the gold standard for measuring the combined long-run impact of multiple changes, including interactions, rather than trying to sum standalone experiment effects. That does not estimate a clean pairwise interaction coefficient, but it does measure the net combined effect of overlapping shipped changes.