Design · Create · Ops & Automation

Design a cheap parallel channel-test plan with pass/fail thresholds

I get a parallel channel-test plan where every test names one of the 19 canonical traction channels and carries a metric, a small budget, a duration, and a numeric pass threshold, so I can run several cheap experiments at once and read every result the same way.

You receive: A JSON object { tests: [{ channel, metric, budget, durationDays, passThreshold }] } describing the parallel channel-test plan.

Part of Distribution

What's verified: STUD verifies the plan is a JSON document under 120,000 characters with a tests list, that the plan has at least your minimum number of tests (default 3), that every test names one of the 19 canonical traction channels with no channel repeated, that every test carries a non-empty metric name, a budget greater than zero, a duration in days greater than zero, and a numeric pass threshold, and, only when you set a total budget cap, that the planned budgets add up to no more than the cap. STUD also rejects the run if the minimum-tests setting is outside 1 to 19 or the budget cap is not a positive number. STUD does NOT verify that the chosen channels fit your product or audience, that the metrics are measurable or the right ones to learn from, that the budgets or durations are realistic, or that the pass thresholds are sensible. Your product, customer, current-channel, and learning-goal answers are context for the operator and are not checked by the validator.