---
name: test-incrementality
description: Use before scaling a paid channel, or when asked to validate ROAS, lift, or incrementality. Designs a holdout test so decisions are based on incremental lift, not platform-reported ROAS, which can take credit for sales that would have happened anyway.
---

# Test incrementality

Platform-reported ROAS takes credit for sales you'd have gotten anyway. Run a holdout before scaling a channel.

## Instructions

1. **Do not scale a channel solely on platform-reported ROAS or attributed conversions.** Call this limitation out if the human is about to raise budget on that basis.
2. **Design a holdout before the scale-up.** Propose, and wait for approval on:
   - Split method (geo or audience holdout are the default options)
   - What stays in the exposed group vs. the holdout
   - Test window and minimum spend or sample needed
   - The primary lift metric (for example, conversions or revenue in the holdout vs. exposed group)
   - How you will compare that lift to platform-reported ROAS
3. **Do not change budgets or targeting to start the test** until the human approves the design.
4. **When results are in,** report incremental lift first, then platform-reported ROAS as a secondary number. Recommend scaling only if the holdout shows real lift.
5. **Do not claim Markov attribution** or any other attribution model that is not actually being used. If incrementality cannot be measured with the available tools, say so and design the most honest holdout you can.

## Optional: Synter MCP

If Synter MCP is connected, use `measure_incrementality` to help design or read a holdout. Combine it with the approved test design above; do not treat a platform ROAS readout as a substitute.