An FTD target tells you how many regs the test needs

An FTD target becomes a test plan when you can say how many regs it may take, what would make the result too fragile to use, and where spending ends. Start there. The budget is a separate limit agreed before launch. It gives the test room to run. The conversion assumption still has to meet the actual player result.

Choose the question before the target

“Let’s see whether influencer traffic works” is too loose. The test should establish whether a particular geo and creator type brings enough FTDs, with a reg-to-FTD rate and later deposit behaviour that the brand wants to test at greater volume. Changing the geo halfway through means the original question no longer has a clean answer.

An FTD target is easy to move after the first report if nobody has agreed what decision it should support. A target can be missed narrowly in a clean test, or reached in a test whose tracking broke. Explain whether the shortfall was in volume or whether the records themselves became unreliable. Neither becomes clearer by changing the target at the end.

The launch note needs a working FTD target, the geo and creator type, the budget limit and the planned review point. It also needs someone who can act when a limit or blocker is reached. A report that nobody can act on is just a running total. The person reading it should know whether they can pause the test or need to call someone who can.

Settle the counting rules through the deposit report before planning volume. Keep the budget discussion focused on how much usable test data you can gather.

A narrow test keeps the volume plan readable. Its report stays at geo and creator type, with the agency handling individual creators. If the real question requires several different geos or creator types, each needs its own test and volume plan. Putting them into one total makes it harder to see which part deserves more volume.

Work back from FTDs to regs

The first calculation is straightforward: take the FTD target and divide it by an assumed reg-to-FTD rate. Use a range. If the brand has results from a comparable journey, they can help set that range. If it has no relevant history, the assumptions stay hypothetical until the test produces checked figures.

Planned regs = target FTDs ÷ assumed reg-to-FTD rate

This gives the brand a concrete volume question. Can the agreed test plausibly collect the regs needed under the weaker scenario within its duration and budget limit? That is something to discuss before launch. If the answer is unclear, reduce the scope of the question or accept that the first test may end with less data than planned.

The first report then checks the assumptions against actual regs and FTDs. A slower flow of regs and a lower reg-to-FTD rate are different problems: one reduces the amount of data, the other changes what that data says about the geo and creator type. The forecast should show which changed.

Don’t fill the gap with a more cheerful scenario. If the weaker case is happening, the remaining volume plan has to reflect it. The budget limit still holds. A target is useful precisely because it shows the shortfall before everyone starts explaining it away.

Check how easily the result falls apart

“Enough FTDs” means enough to support the next decision without a handful of uncertain records carrying it. There is no magic count, but there is a practical check: recalculate with disputed FTDs removed, then look at the same test by reporting period. If either view changes the verdict, the headline total needs work.

We get wary when a strong total disappears as soon as the report is split by week. Find out what changed: the cashier, attribution, geo mix or creator type. The report should retain its geo and creator-type breakdown, with weekly cohorts added where that question matters.

Before comparing those periods, give their players the same time to deposit. The cohort method sets out the clock. Once the periods are comparable, a strong early result followed by a weak later one is a reason to question scaling the pooled total.

This is a working test-size check, with no statistical promise attached. Try the decision again with the doubtful records removed. Then look at each comparable period: would a weaker week change the case for a larger test? If the result remains close, say which records or period need checking before the final review.

Pause for a blocker; stop at the limit

A broken cashier makes the test answer the wrong question. Players cannot show deposit intent through a payment route that rejects valid attempts. Missing attribution causes another problem: completed deposits reach the brand, but the test loses them. Continuing to spend while either fault is active only adds more results you will struggle to use.

These are operational pauses. Name the failure, the affected period and the check that will allow the test to resume. “Payments look better now” is too vague. A completed payment through the affected route, with the correct source attached in both reports, is something the teams can check. The tracking checks explain what to compare when that connection fails.

The budget ceiling is different. When it is reached, new spending ends under the agreed plan. The brand can still review the players already acquired and receive the later cohort report. Continuing just because the result is close changes the test the brand agreed to run.

Checks between weekly reports help catch blockers. They shouldn’t become a daily vote on whether the test is good enough. Decide the performance review point before launch, alongside the target and budget limit. Then use immediate pauses for real faults and the planned review for the final result.

If the product changes after a repair, the affected period stays visible. The brand and agency should agree which part of the test can still answer the original question. A repair can make the next period usable. Keep the interruption visible in the earlier report.

Finish with a decision the test can carry

The final choice is to scale, change geo or creator type, or stop. A shortfall in the planned volume belongs in the explanation for that choice. It is not a fourth outcome. The brand needs to know what the test supports and what remains unresolved before committing to another step.

Scaling needs more than a reached FTD target. The result should survive the record check, make sense across comparable periods and come from a journey that remained usable. More volume can still change the result. The report should explain what made scaling worth testing and which weak point will need watching.

Changing geo or creator type needs a reason tied to the test. If the cashier failed, repair the cashier before blaming the geo. If checked cohorts show that the current pair brings regs without enough FTDs, a different pair is a clear next question. Keep the variables straight so the next test answers it.

Stopping is also an answer. The budget limit may have been reached before enough usable volume was gathered, or the corrected result may have remained too weak to justify another test. Say that directly, and show whether the original volume plan or the deposit result fell short. A test that ran out of room tells the brand something different from a test that reached enough players and still missed its goal.

Close against the question agreed at launch. Moving the target now won’t improve the result.