Fundamentals
Naming Conventions Best Practices
Whether you are naming a database table, a file, or a marketing campaign, the same four principles decide whether the convention actually holds up.
Published July 6, 2026
Key takeaways
- Good naming conventions rest on four principles: consistency, clarity over cleverness, controlled values over free text, and documented ownership.
- A "database name" (the name of a database, table, or field) follows the same logic as a campaign name: a fixed structure applied to every instance, not a fresh decision each time.
- The system being named changes; the discipline does not — which is why the same governance approach that fixes messy database naming also fixes messy campaign naming.
- A naming convention that lives only in a document is a suggestion. One that is validated at the point of creation is a standard.
- For marketing teams specifically, the deeper reference is a campaign taxonomy — the controlled dimensions and values a naming convention formats into a name.
What is a naming convention?
A naming convention is a fixed set of rules for how names are constructed within a system: what order the parts follow, what separator is used, what casing applies, and which values are allowed. It turns naming from a fresh decision every time into a repeatable structure applied consistently.
The four principles behind good naming conventions
Across every domain — databases, code, files, or campaigns — durable naming conventions share the same four principles:
| Principle | What it means | Common anti-pattern |
|---|---|---|
| Consistency | The same structure, every time, by everyone | One person uses underscores, another uses dashes |
| Clarity over cleverness | A name should be readable without extra context | "final_v2_USE_THIS" instead of a dated, structured name |
| Controlled values | Each part of the name comes from an approved list | Free text that gets misspelled or abbreviated differently each time |
| Documented ownership | Someone owns the convention and approves exceptions | No one remembers why the rule exists or who can change it |
The same principles, different systems
What changes from system to system is the format, not the discipline. A database name follows conventions like lowercase, underscore-separated, and plural table names (users, accounts, not Tbl_Usr1). A file name benefits from a date prefix and a version number instead of "final" and "final_v2". A marketing campaign name follows a taxonomy of country, objective, channel, and product, in a fixed order — the same underlying idea as a well-named database table, applied to campaign data instead of schema data.
A campaign naming convention, briefly
Applied to marketing, a naming convention formats the dimensions defined by a campaign taxonomy — country, objective, channel, product, audience — into a single, parseable name such as cr_acquisition_paidsearch_creditcards_prospecting_google_2026q3. The campaign taxonomy guide linked below covers this in full, including a worked breakdown of every segment.
Documenting a convention vs. enforcing one
A naming convention written in a wiki or spreadsheet is a suggestion — useful as a reference, but nothing stops someone from ignoring it under deadline pressure. A naming convention becomes a standard only when it is validated at the point of creation: a database migration tool that rejects a bad table name, or a campaign taxonomy platform that rejects a campaign name before it goes live. Documentation explains the rule; validation is what makes the rule real.
Frequently asked questions
What are naming conventions best practices?
The core best practices are: stay consistent (one structure, applied every time), prioritize clarity over cleverness, pull values from a controlled list rather than free text, and document who owns the convention and can approve exceptions.
What is a database name?
A database name is the identifier assigned to a database, table, or field, ideally following a naming convention — lowercase, consistent separators, and plural table names are common conventions (e.g., "users" rather than "Tbl_Usr1").
What is the difference between a naming convention and a taxonomy?
A taxonomy defines what needs to be captured — the dimensions and their allowed values. A naming convention defines how those dimensions are formatted into a single name — the order, separators, and casing. You need both: a taxonomy without a naming convention has no consistent output, and a naming convention without a taxonomy has nothing meaningful to format.
Do naming conventions apply outside of software development?
Yes. The same principles — consistency, clarity, controlled values, documented ownership — apply to file naming, folder structures, and marketing campaign names just as much as to database tables or code variables. Only the specific format differs by domain.
How do you enforce a naming convention instead of just documenting it?
Validate names at the point of creation rather than relying on people remembering the rules. For marketing campaigns specifically, that means checking a campaign name against the taxonomy and naming convention before the campaign launches — the same principle a database migration tool applies when it rejects a malformed table name.
Why do naming conventions matter for marketing campaigns specifically?
Marketing campaign names double as the primary key that dashboards, attribution, and reporting group data by. An inconsistent campaign naming convention fragments that grouping, the same way an inconsistent database naming convention makes a schema hard to query and maintain.
Put this into practice
Standardize and validate campaign names, UTMs, and metadata with UseTaxonomy.
Request accessCampaign taxonomy software →