If your team can't find a winning test in 30 seconds, the name is broken.
I care about experiment naming conventions because I've watched bad names slow reporting, muddy attribution, and weaken budget decisions. What looks like admin work turns into real cost once your A/B testing program moves past a handful of tests.
The fix isn't a big framework. It's a naming system that helps you search fast, group results cleanly, and make the next call with less guesswork.
Bad names don't waste minutes, they distort decisions
Decision making gets worse long before anyone notices the naming problem.
It starts small. A founder asks, "Didn't we already test annual pricing copy?" Someone searches the backlog and finds three possible candidates: "pricing test," "pricing exp v2," and "homepage message update." No one is sure which one hit activation, which one touched checkout, or which one ran on paid traffic only.
Now the team is flying on memory. Memory is a bad database.
This matters more in startup growth than most teams admit. When you run 20, 50, or 100 experiments a year, naming isn't clerical. It's part of measurement. If a test can't be retrieved, compared, and rolled into clean analytics, it may as well not exist.
I've seen this break quarterly reporting in simple ways. A pricing-page test gets grouped with homepage tests. A paywall test gets left out of the conversion report because the analyst filtered for "checkout." A team repeats the same idea six months later because the old result was buried under vague labels. That's not harmless duplication. It's wasted traffic, wasted engineering time, and sometimes a bad forecast.
If 0.2 points of conversion is worth real money on your funnel, retrieval is a finance problem. It's also a growth strategy problem. You can't build compounding learning on top of hidden evidence.
That's why I treat naming as part of the operating system for experimentation. The name is the handle that connects the test to search, reporting, and review. If you want a stronger base for documentation, this piece on an A/B testing documentation framework is a good companion.
A clean name won't save a weak test. But a weak name can bury a strong one.
What a useful experiment name needs to tell me
I don't want the name to tell me everything. I want it to tell me the few things I need under pressure.
For most teams, that means five fields: where the test ran, who it targeted, what changed, which primary metric mattered, and when or which version it was. That's enough context to search fast and report cleanly.
I do not put the whole hypothesis in the name. I do not put the expected outcome in the name. And I never use names like "winner," "better flow," or "pricing improvement." Those labels sneak opinion into the archive before the data is settled.
That matters more than it sounds. In behavioral science, labels shape interpretation. If the title already says "improvement," people start reading the result through that frame. Keep the name descriptive. Keep the judgment in the analysis.
A few examples make this obvious:
| Bad name | Better name | Why it works |
|---|---|---|
| Homepage test 3 | Homepage_NewVisitors_HeroCTA_SignupRate_2026Q2 | I know the surface, audience, change, metric, and timing |
| Pricing update | Pricing_TrialUsers_AnnualPlanCopy_CheckoutCVR_v1 | I can find it in pricing or checkout reporting |
| AI flow test | Onboarding_FreeUsers_AIRecap_ActivationRate_v2 | The AI element is clear without extra narrative |
| Checkout winner | Checkout_MobileUsers_PaymentPlan_AuthorizationRate_202606 | No bias, just facts |
The basics of A/B testing from NN/G still hold here. Start with a clear hypothesis and a clear outcome metric. I simply don't force both into the name.
If a name can't tell me where the test ran, what changed, and which metric mattered, I don't ship it.
That's the standard I use because it holds up later, when the people searching the archive weren't in the room.
The naming pattern I use in real teams
The pattern I use most often is simple: SurfaceAudienceChangePrimaryMetricDateOrVersion.
It isn't pretty. That's fine. Pretty names don't help search.
A few examples: "SignupNewUsersFormLengthCompletionRate2026Q2" "CheckoutReturningUsersPaymentIconsAuthorizationRatev3" "OnboardingTeamAdminsAISetupPromptActivationRate202606"
I like this structure because each field answers a retrieval question. Surface helps me group by funnel stage. Audience helps when product-led growth creates different behavior across free users, trial users, and paid accounts. Change tells me what the intervention was. Metric tells me what success meant. Version or date gives me order without rewriting history.
I keep separators consistent, usually underscores. I don't mix spaces, slashes, and hyphens at random. Search breaks when tokens drift.
I also keep a controlled vocabulary. If one person says "checkout" and another says "cart," reporting gets messy. If one person writes "CVR" and another writes "conversion," your filters miss things. Pick one label and stick with it.
This is where a lot of experiment programs wobble. The naming rule exists, but the schema around it doesn't. If you're building a repository, this guide to experiment schema and tagging strategy is useful because naming works best when it matches the rest of the retrieval system.
Applied AI makes consistency even more valuable. If you want to use AI to summarize learnings, cluster similar tests, or retrieve prior experiments for planning, structured names help the model pull the right history. Messy names poison that layer fast.
If you want a more complete logging setup, including IDs and hypothesis fields, I like this approach to structuring experiment logs and tracking systems.
Who should keep this lighter? A team running fewer than 10 tests a year. In that case, use a test ID and a plain descriptive name. Don't build overhead you won't maintain.
Where naming conventions fail, and how I keep them clean
Most naming systems fail because people stuff too much into the title.
I've seen names that include owner, channel, platform, country, date, expected lift, and internal project code. At that point, the name stops helping. It becomes a luggage tag.
I cut hard. If a field isn't needed for search or top-line reporting, it belongs in metadata, not the title. Owner can change. Hypothesis can evolve. Tags can capture channel, geography, device, or segment depth.
The second failure is mutable names. A test starts as "Hero copy" and later gets renamed to "Homepage win." Now you've lost the original description and baked outcome bias into the record. Don't rename titles to match results. Add results in metadata.
The third failure is language drift across teams. Marketing says "lead gen." Product says "activation." Sales says "qualified signup." All three may point to the same step. If your naming doesn't map to your reporting taxonomy, your analytics layer turns into translation work.
I also watch for borrowed language that adds confusion. If your team uses "champion" and "challenger," which Unbounce explains here, keep those labels out of the core title unless they are part of your reporting schema. Otherwise you get titles like "new challenger pricing," which tell me almost nothing six months later.
One more trap: don't let naming become proxy status. A long, tidy title doesn't make the test rigorous. I still want sound sample logic, guardrails, and a credible read on incrementality. Conversion rate optimization isn't improved by better labels alone.
My short rule is this: if someone outside the project can't understand the test in 15 seconds, the name needs work.
A quick takeaway you can use today:
- Rename the last 20 experiments in your archive with one consistent pattern.
- Try to find three old tests by surface, audience, and metric.
- If search still feels fuzzy, your fields are wrong, not your memory.
The name should earn its place
A good experiment name is small infrastructure. It helps me find the past fast enough to make a better next decision.
That's why I keep the title descriptive, stable, and tied to reporting. When naming supports search, analytics, and clean review, experimentation stops feeling like scattered activity and starts compounding into a real learning system.
If I were fixing this tomorrow, I'd pick one format, rename the recent backlog, and test it against a real reporting question. If the answer comes back faster, keep it. If not, cut fields until the name does real work.
Related reading: what 200+ tests taught me, underpowered A/B tests, and experimentation governance. I built GrowthLayer to make experimentation repeatable across a program; for more field notes, subscribe to Lean Experiments.