Decide what a name must answer
- Write down the questions a name has to answer in a report: which asset, which angle, which format, which audience, which test and which version.
- Keep the list short, and use the same fields in the same order for every client. Every extra field is one more thing to type wrong on every upload.
Build the code lists
- Give every value a short code, such as a fixed word for the format and a numbered code for the angle.
- Keep the code lists in one shared sheet. Version them, and log each new or retired code with its date and the person who approved it.
- Never let one code mean two things. Do not reuse a retired code for a new angle, or old reports will mix the two.
Made-up scenario: a store runs video ads in two formats across four angles. A name such as ANG2_VID_916_V3 gives the angle, the format and the version in one read. Put the same parts in a different order and every reader has to check each field.
Keep names in step with the file
- Put the creative ID in the file name and in the ad name, so a file search and a report search find the same asset.
- Save the name to the creative library record when the file is first stored. Do not rename a live file to fit a new rule, because the history would then point at a different name.
- When only the copy changes, give the asset a new version number. Give it a new creative ID only when its results must be kept apart.
Check names before launch and every month
- Run the naming check before any ad goes live, with the same rule and code lists, and fix the name before budget goes behind it.
- Once a month, sample the live names and count the ones that break the rule. Track the count as a number, not as a feeling.
What to write in the client report
- The naming rule, the code list version in use, and the share of live names that passed the monthly check.
- Any ad still carrying an old name, with the plan to fix it at its next version.










