Use [Experiment Number] – [Step of the Funnel/Page] – [Change] and mirror it in a lowercase, hyphenated flag key. This is the convention we use at 99Ways; the PostHog A/B testing guide covers the rest of the setup.
Why Naming Matters
Choose a name that shows:
- What part of the journey it tests.
- What specific change or idea is being tested.
- How it fits in your overall testing history.
Consistent naming saves time, reduces confusion, and helps teams avoid duplicate or conflicting tests. A sequential number separates similar drafts; a specific surface and change make old results searchable; matching names make it easier to spot when the dashboard and code refer to different tests.
Experiment Naming Format
We use this structure for all experiments:
[Experiment Number] – [Step of the Funnel/Page] – [Change]
Experiment Number
- A sequential 3-digit number (e.g., 001, 002, 003).
- Makes it easy to track and reference, even as the test library grows.
Find the next number in the live PostHog experiment list across all statuses, including drafts, running tests and completed tests. Check the exact name and flag key for duplicates before creation; local notes may not contain every draft.
Step of the Funnel/Page
- Identifies where in the user journey the test runs. Examples: Homepage, Signup, Checkout, Onboarding.
Change
- A short, clear phrase describing the change being tested. Examples: CTA Text, Modal Design, Pricing Layout.
Use PostHog’s separate Hypothesis field for what changes in each variation and why it should affect the outcome. (+) We keep that summary within 400 characters: start with the tested surface and distinguishing changes, then the rationale. “Toggle Design” identifies a change; it does not explain the expected effect.
Feature Flag Naming Format
For feature flags in code, we use a similar format, optimized for implementation:
[Experiment Number]-[funnel-page-change]
- Lowercase, no spaces.
- Use hyphens for readability.
- Often abbreviate or simplify the funnel/page step for consistency in code.
Feature flag keys need to be predictable, consistent, and easy to type or search in codebases. PostHog generates a key from the experiment name; customize it before saving if it does not match the key you agreed for the implementation. (+)
Examples
Experiment Names (for internal docs and dashboards):
010 – Pricing Page – Toggle Design
015 – Onboarding – Welcome Modal
Feature Flag Keys (for code):
010-pricing-page-toggle-design
015-onboarding-welcome-modal
Leading zeros make numbers easier to scan; checking the live register prevents duplicate numbers.
Best Practices
Be specific. Avoid generic names like “Test 1” or “Homepage Experiment.” They’re hard to track later.
Keep it concise. Aim for clarity without long-winded descriptions.
Use consistent terms. Align naming across teams and projects.
Plan for scale. Choose a format that works for dozens or hundreds of tests.
Event names follow the tracking plan. Experiment and feature flag names identify the intervention; event names identify the behavior being measured.
Variant Keys and Display Names
| Test | Machine keys | Meaning |
|---|---|---|
| A/B | control, test | Existing production experience and one treatment. |
| Three or more variants | control, test_group_1, test_group_2, … | One baseline and numbered treatments. |
Give each treatment a human-readable label describing the experience, such as “Test Group 1 – Cost comparison.” Keep that label in the variant description and experiment log; use the machine key in code and events. If you keep a local experiment file, name it after the flag: 010-pricing-page-toggle-design.md.
PostHog uses the variant named control as the results baseline when it exists; otherwise it uses the first variant. No-code web experiments require a control variant. (+) Our convention keeps control tied to production so the baseline is explicit.
If a draft A/B test grows to several treatments, rename test to test_group_1 and update the flag, implementation and log together before exposure begins. Once participants enter, keep machine keys unchanged so the recorded assignments and code keep the same meaning. Use flag inspection without exposure when checking those keys in internal tooling.
Frequently asked questions
How do I name a test with three or more variants?
Keep one experiment name and one flag key. Use control plus test_group_1, test_group_2 and so on. Describe the strategy of each group separately. Give separate experiment numbers only to separate experiments, not to arms of one comparison.
Can I rename an experiment while it is running?
Clarify the human-readable description when needed, but keep the flag key and variant machine keys fixed after exposure starts. Those are the identifiers your implementation and recorded events use. If the tested change itself becomes a different experiment, give it a new number and measurement plan.
Should experiment numbers continue across PostHog projects?
We resolve the next number within the project where the test will run. Use a shared sequence across projects only when the team maintains one register and checks it before creating drafts. Keep the PostHog project in that register so the same short number cannot point to the wrong test.