I designed a programmatic split-testing engine for a performance-marketing operation with large advertising budgets. The design combined structured names, reusable experiment setups and automated campaign creation, with results collected in a shared experiment log. The weekly target was 100+ tests across keywords, creatives and landing pages.
The 100+ figure describes the volume the engine was built to support. I don't have a week-by-week test history here that establishes how consistently the operation reached it.
The useful work was organizing what happened around each test. Someone had to create it, monitor it, decide whether to continue spending and leave a result the team could find again. Campaign creation was one part of that job. The shared log connected the activity to what the team learned, including the circumstances in which a test worked or failed.
Manual testing left results hard to track
Manual testing couldn't keep up with the number of hypotheses. Important tests remained in spreadsheets, results were hard to track and the team rarely reused what it learned.
A spreadsheet can hold an idea without making that idea an active experiment. The operating problem extended beyond a backlog. A finished test also needed an identifiable result and enough explanation for someone else to use that result. Otherwise, a later campaign could repeat the work without benefiting from the earlier decision.
Automating campaign creation addressed the setup work. Keeping results in a shared log addressed the continuity problem. The design needed both, because increasing the number of campaigns would also increase the number of results the team had to interpret and recover.
Each test fed a shared log of wins, losses and context
I combined structured naming conventions with templated experiment setups and automated campaign creation.
Names made experiments identifiable. Templates made a setup repeatable. Automated creation reduced the manual work involved in creating campaigns. A shared experiment log kept the outcome and its context available after the team moved on to other tests.
The point of retaining context was to preserve more than a winning label. Keywords, creatives and landing pages were all dimensions of the testing program. Knowing that something worked leaves another person with questions about what was tested and where it worked. The log was intended to keep those circumstances with the result.
This is the operating sequence the design supported:
- Use a repeatable setup to create an identifiable experiment.
- Monitor it and decide whether to continue or retire it.
- Record the outcome as a win or loss, with context for later use.
Google Ads and Facebook Ads supplied the campaign platforms
The stack named in the case was Google Ads and Facebook Ads, scripts and automations, and a shared experiment database. The platforms carried the campaigns. The other components supported creating tests and retaining their results.
The record leaves the implementation details open. It doesn't identify a scripting language, database product or the exact division between an automated action and a media buyer's decision. I wouldn't turn that short stack description into a claim that the system autonomously chose every winner or moved every budget.
A team evaluating the design can still inspect its responsibilities. Campaign creation, monitoring and the experiment history each need an owner.
The engine was built for a weekly target
The documented operating change was that testing became part of the account's weekly work. The design was built to carry a target of 100+ tests a week while making them easier to create, monitor and retire.
The available record doesn't establish a sustained weekly test count or a measured improvement in advertising performance.
I described a similar weekly target in the separate home-decor engagement. I said I'd typically aim for a minimum of 100 tests per week and judge them by their potential to scale. An aim tells someone how I organized the work. An account history would be needed to show the volume and results achieved.
Winning tests stayed in the review cycle
The case's stated budget rule was to check tests every three days, cut losers and increase winners' budgets by 10–20% at a time. The source also names a second check on winners at day six. A test that won once still had to keep performing as its budget increased.
That recurring check connected experimentation to spending. Retiring a losing test stopped further allocation to it. Increasing a winner's budget created another decision to revisit, because the team was now spending more on that test. Logging the result preserved the decision beyond the next review.
My other recorded engagements provide context for that approach, with their own limits. I discussed 10–20% budget increases every few days in the home-decor work. I described reassessing performance every three days in the kitchen-gadgets work. Those are accounts of my practice in those engagements. They don't independently verify this engine's execution history.
The available case material doesn't give a minimum sample size or a statistical decision rule. A three-day review schedule doesn't establish that a test has enough evidence to declare a winner.
Context made a result useful to the next test
The shared log's context was as important to the design as its win and loss labels. A team reusing a result needs to know what decision the result supports. A label alone leaves too much to reconstruct.
Consider an illustrative creative test, separate from the historical case. A creative wins with one landing page. Someone later uses it with a different page. A record that identifies the original combination gives that person a reason to check whether the earlier finding applies. A bare winning label doesn't answer that question.
The same principle explains why the design included retiring tests. A team needs a recoverable reason to stop an experiment as well as a reason to fund one. Keeping those decisions together gives later tests a history to work from, instead of leaving learning with the person who last managed the campaign.
The design suits teams with more tests than they can manage by hand
This case is relevant to teams with enough advertising activity to fund ongoing experiments, but whose process still produces only a few tests a month. The first question is where the work stops. Ideas waiting for setup, campaigns waiting for a decision and results nobody can recover are different constraints.
I wouldn't recommend adopting 100+ tests a week as a goal simply because it appears in this case. A smaller operation can use repeatable setups and a shared history without adopting that volume. Its budget and ability to evaluate the results still govern what it can responsibly test.
Start with a test the account has already finished. Find what changed, what happened, why spending continued or stopped, and the context someone would need to reuse the finding. Any missing answer identifies a specific part of the testing process to improve.