A consistent naming convention is the unglamorous habit that turns a pile of one-off tests into a searchable program. Here's a simple structure for naming every experiment, and why the short reference matters more than the label.

Carlos Trujillo

Intelligems cover: the post title on a blue gradient beside a white Test Library card listing named experiments (Ex44 PDP Strikethrough Price, Ex45 Cart Free Shipping, Ex46 Checkout Trust Badges

If you run enough experiments, the hard part stops being the tests and becomes finding them again. A team runs "homepage revamp," then "new hero v2," then "Q2 pricing," and six months later nobody can say what won, what changed, or whether you already tried the idea you're about to run again. A naming convention fixes that before it starts: you give every experiment a structured name and a short reference before it launches, so anyone can look at it later and know the surface, what was tested, and when. It's the least exciting habit in experimentation, and one of the few that quietly decides whether your program scales. Here's how to build one.

A Test Name Is Institutional Memory

Every test produces something more valuable than its result. It produces a record: what you tried, what you believed, what happened. That record is what makes your next test smarter... you stop repeating yourself, you build on what already worked, and you onboard a new hire by pointing them at history instead of your own memory. That record might live in a spreadsheet, a Notion database, or your experiment archive in Intelligems.

But a record you can't search isn't memory. It's a junk drawer. The name is the index. Ex44 | PDP | Strikethrough Price Variant | Dec 2025 you can pull up in a report a year later and reference in a thread today. "The pricing thing from spring" you can't.

What a Good Name Looks Like

There's no single right way to do this. The exact format varies from one org to the next... but mature experimentation programs always land on some version of it. A good name answers a few questions at a glance: where it ran, what was tested, and when. A convention that reads cleanly usually strings together:

A short reference ... a sequential tag like Ex44 that never repeats
The surface ... where it ran (PDP, cart, homepage, collection, checkout)
A short descriptor ... what was tested, in a few words ("Strikethrough Price Variant," "Free Shipping Threshold")
The date ... the month and year, so history sorts itself

A structure worth stealing:

Ex[number] | Surface | Descriptor | Month Year

So the 44th test becomes:

Ex44 | PDP | Strikethrough Price Variant | Dec 2025

The best part is you don't have to type that by hand. In Notion, Airtable, or Google Sheets, a single formula column can build the name from fields you already fill in... you enter the surface and a short description, the number increments on its own, and the full name writes itself. A convention nobody follows is worse than none, and the surest way to get one followed is to make it automatic.

Test Management view listing six experiments named with the Ex## | Surface | Descriptor | Month Year convention, with separate Status and Surface columns

The Reference Does the Real Work

The descriptor is the fun part to argue about. The reference is the part that does the work. Something as small as Ex44 means you can drop it into a Slack thread, a roadmap, or a QA handoff and everyone knows exactly which test you mean, even after the description gets rewritten.

You know it's working when a stakeholder uses the reference unprompted, asking how Ex44 did instead of "that checkout test we ran a while back." At that point people are thinking in experiments, not one-off projects. And because the references are sequential, they add up to a library: a year in, you can look back and see which surfaces you've tested most and which hypotheses keep winning. Re-running an old idea? Give it its own next number rather than a recycled one, so each attempt stays a separate entry with its own result.

Where Teams Get It Wrong

Over-engineering it. Ten fields, three of them mandatory, none filled in consistently. The more you ask people to encode, the less they comply. Start with fewer fields than you think you need.

Naming after launch. A name written once the test is already running is written from memory, which defeats the purpose. Make it a rule that no test launches without a name and a reference attached.

A descriptor that says nothing. "Homepage test" tells you nothing in six months. Name what was tested in a few specific words ("Banner Price Variant," "Anchor Price Removal") so it's recognizable at a glance.

Start Small

You don't need to rename your backlog. Pick three or four fields, write the format on one page so it isn't living in one person's head, and make it the rule that nothing launches without a name that follows it. Apply it to your next test, then the one after that.

Consistency from here beats a perfect system applied to nothing. The team on Ex200 with a plain, boring convention will run circles around the team with a beautiful taxonomy they abandoned at test three. That's what a consistent testing program is built on: small habits that hold up under volume.

Naming conventions will never be the exciting part of experimentation. But it's the quiet infrastructure that lets a program remember what it's learned and hand that knowledge to the next person without a meeting. The boring habit is the one that compounds.