Skip to main content
This page is a workbook. You fill in each section to define your own experiment ID SOP, and every section has a “Concept review” dropdown that explains the idea behind it. The dropdowns explain the tradeoffs; they don’t tell you what to choose. Greyed E.g. text is an example you replace with your own answer.
Work through the sections in order. By the end you’ll have a complete, team-specific SOP: a defined ID pattern, formatting rules, and a logging process. The examples throughout use one invented team, the Doughnut Labs growth team, so you can see what a finished answer looks like.
1

Define your pattern and rules first

Sections A through C set the rules everyone will follow. Decide these as a team so the choices stick.
2

Then define your process

Sections D and E cover when to create an ID and how to log it, so the rules get applied the same way every time.
3

Read the concept reviews where a choice is unclear

Each dropdown explains why the section exists and what the tradeoffs are, so you can decide rather than guess.

​
A. Your ID pattern

Which pattern will your team use for every experiment ID? Write the pattern and two or three example IDs in that pattern: E.g. Random alphanumeric, four characters after a dash. Examples: TEST-8H2P, TEST-4K9M, TEST-2X7R. We run many tests at once across three people, so sequential numbers would collide.
An experiment ID is a short, unique code tied to one test. It rides on the end of a campaign, ad set, or ad name so the test stays identifiable wherever you look it up, and it stays with that test even if you clone the campaign or rename the other segments later.There are a few common shapes, and each fits a different situation. A sequential number (TEST01, TEST02) is easy to read and works when one person runs tests in a single queue. A date-based ID (TEST-0714) puts the launch date in front of you at a glance. A random alphanumeric ID (TEST-8H2P) avoids collisions when several people are spinning up tests at the same time and a running counter would be hard to keep in sync.The pattern you pick matters less than everyone using the same one, every time. A queue that mixes three patterns is harder to scan than any single pattern would have been.

​
B. Your formatting rules

Fill in the formatting rules your team commits to. Edit the examples to match your own decisions:
These rules aren’t cosmetic. Each one prevents a specific failure downstream.Length and character choices affect where the ID travels. Long strings get cut off in ad platform reports and are harder to scan in a list. Symbols such as &, #, or / can break UTM tracking parameters and throw errors when a reporting tool imports campaign data, so an ID that looks fine in a spreadsheet can quietly corrupt a dashboard. Consistent length (always the same number of digits or characters) keeps a column of IDs easy to skim.The look-alike character rule matters only if a human ever reads or retypes an ID: O versus 0, or I, l, and 1, are easy to confuse by eye or by ear. If your IDs are always copied and pasted by machine, this one may not apply to you, which is exactly the kind of call this section is asking you to make.

​
C. What “unique” means for your team

How will you guarantee no two tests share an ID? Describe your rule: E.g. Every ID is checked against the experiment log before it’s assigned. Because we use random four-character codes, we also regenerate on the rare occasion the log already shows a match.
The whole value of an experiment ID is that it points to one test and only that test. Two live tests sharing a code means every comparison, filter, and trace-back after that point is suspect, and you often won’t notice until the numbers stop making sense.How you protect uniqueness depends on your pattern. A sequential counter is self-protecting as long as one source owns the count. A date-based ID can collide when two tests launch the same day, so those teams usually add a suffix. Random codes rarely collide but can, which is why a pre-assignment check against a shared log is the common safeguard. The right rule is the one that matches the pattern you chose in section A.

​
D. When you create the ID

Write the point in your process where the ID gets created, and the steps for creating it: E.g. We create the ID when we set up the experiment brief, before the test launches on any platform. Steps: (1) open the brief in Notion, (2) generate a random four-character code, (3) check it against the experiment log, (4) save it in the brief, (5) add it to the campaign name in Meta, (6) add it to the utm_content on the landing page.
Creating the ID at the brief stage, before launch, is what lets the ID link three things together: the brief that documents the hypothesis, the live campaign, and every report that references the test. Create it later and you’ve usually already named the campaign or fired a UTM without it, so the links have gaps.The rule that carries the most weight here is not changing an ID after a test goes live. Once a test launches, the code is referenced by the live campaign, by any dashboard filter, and by data that’s already been collected. Change it and you sever the link between the brief, the campaign, and the reports that already used the old code, and there’s no clean way to stitch them back together.

​
E. Your experiment log

Describe where your single experiment log lives and what each entry records. Fill in the columns you’ll track: Where the log lives: E.g. A single database view in Notion, shared with the whole growth team.
The log does two jobs. Before you assign an ID, it’s the thing you check to confirm the code isn’t already taken. After a test is running, it’s the one place anyone can scan the full test history without opening every brief one by one.Both jobs fall apart the moment there’s more than one log. If IDs are recorded in two spreadsheets, the uniqueness check only sees half the picture, and collisions slip through. If test history is scattered across individual briefs, no one can see the whole queue at a glance, which is usually the exact thing a teammate needs when they’re deciding what to test next. A single shared location is what keeps the check reliable and the history legible.

​
Where the ID gets used

Confirm every place the ID needs to appear in your stack. Keep the ones that apply, add any that are specific to you:
  • The experiment brief in your project management tool
  • The campaign, ad set, or ad name in the ad platform
  • Tags, filters, or dashboards in your BI tool
  • UTM parameters such as utm_content or utm_campaign, if the test links to a tracked landing page
  • [add your own destination]
An experiment ID only earns its keep if it appears everywhere the test shows up. The point is to trace one test across tools without searching by full campaign name and without confusing two similarly named campaigns.If the ID lives in the brief but never makes it into the BI tool, you can’t filter reports by it. If it’s in the campaign name but not the UTM, the landing-page data won’t connect to the ad data. Each surface you skip is a place the trail goes cold, so this list is worth walking through deliberately for your own stack rather than assuming the defaults cover it.

​
Your SOP at a glance

1

Pattern

We use [your pattern from A] for every experiment ID.
2

Format

IDs follow the length, character, and delimiter rules in B.
3

Create at the brief

We generate the ID at the brief stage, before launch, and never change it after (D).
4

Check the log, then log it

Every ID is checked against and recorded in our single experiment log (E).
5

Apply it everywhere

The same ID goes on every surface the test touches.
This workbook is built from the “Experiment IDs” concept SOP. Read that document for the full background; use this page to define the version your team will actually follow.
Last modified on July 17, 2026