Naming convention template for Fintech

The naming convention with three segments a regulated financial product needs: which product a campaign sells, which market it may run in, and which review cleared the creative inside it.

Everything else is the general convention, unchanged. One row per segment, fixed positions, a closed list of values with an owner, one separator and a change rule that does not break reporting history.

Adopt it before the first campaign is built. The questions this category eventually has to answer — what ran where, under which review — are answerable from names if the tokens are there and effectively unanswerable if they are not.

Use it again whenever a product is added or a market opens, because both positions have closed lists that somebody has to extend deliberately.

Regulated advertising eventually has to answer a narrow question: what was running, in which market, under which review, on a given date.

Most teams answer it badly. The information exists, scattered across ad account change histories, a folder of creative files, a review inbox and somebody's memory, and assembling it takes days. The irony is that the ad names were being written anyway, and a convention with three extra positions would have made the answer a filter.

That is the whole argument for this version. The product, the market and the review reference are things every ad already has; putting them in the name costs nothing at build time and converts a reconstruction exercise into an export.

The review reference is a property of creative, not of a campaign, so it sits in the ad-level name and in the creative file name, and it matches the reference on the creative brief row and the flight plan row.

Once those four agree, a rate change becomes a work list. Filter every live ad whose reference predates the change, and you have the set that needs replacing, with owners attached. Without the token, the same job is opening every ad.

The strict rule that makes this work is that a new review means a new ad. Updating creative inside an existing ad and leaving the old reference in its name produces a record that is actively misleading — worse than no record, because somebody will trust it.

The product position sets the economics and the review; the jurisdiction position sets the permission. Both should be single-valued, which means campaigns are single-product and single-market.

The jurisdiction position deserves its own defence, because the obvious objection is that a market restriction is a targeting setting. It is, and targeting settings are edited by people who never read the plan, while a name appears in every export and every screenshot. A market in the name is a record that survives the settings being changed, and it makes an error visible at a glance rather than three levels into an interface.

Keep the list matched to your authorisations, with an owner who hears when one changes.

Review references usually contain punctuation, and punctuation is exactly what breaks a split.

So the convention specifies the token form: the reference with its punctuation removed, lower case, no spaces. The meaning column carries the mapping back to the original format, so a reader can find the review from the token.

This is the one position where a store of allowed values is impractical — references are issued continuously — so the rule replaces the list: any current reference, formatted this way, issued by the review process. The owner column names who confirms that a reference in a name is real.

A small addition worth making at ad set level: a token that identifies a retargeting audience built from application starts.

The reason is not reporting, it is care. That audience is defined by a financial circumstance, and what may be said to it is narrower than what may be said to a cold audience. An ad set whose name makes that visible is one that a reviewer, an auditor or a new team member can spot immediately, and it reduces the chance of prospecting creative being duplicated into it without a second look.

The token costs four characters and makes a category of mistake visible in an export.

Renaming a live object rewrites its history in most reporting. In this category there is a second reason not to do it: the name is part of the record, and a record that can be edited retrospectively is not a record.

So the change rule is strict. A product change is a new campaign. A market change is a new campaign. A review change is a new ad. Where a rename genuinely has to happen, the old name, the new name, the date and the reason go in the notes, and both exports either side of the change can still be reconciled.

Ads in this category almost always point at a page carrying an obligation — a fee summary, an eligibility statement, a comparison. Which page an ad used is as much a part of the record as which review cleared the creative.

The name cannot reasonably carry a URL, so this belongs in the tracking parameters instead, built from the same tokens: the product, the market, the review reference, and a short page identifier. Then a click can be traced from an ad to a page version without anybody consulting a deployment history.

Put the parameter format in the where-it-appears column for each position, and test one live link before a flight starts. Ten minutes of checking finds the mismatches that would otherwise surface months later in the one week they matter.

Seven checks. One separator everywhere, never inside a value, and review references formatted so they cannot contain it. Every ad-level name carries the reference of the creative in it, matching the creative brief and the flight plan. The jurisdiction list matches your authorisations and has an owner. The product list has an owner who hears when a product changes. Retargeting audiences are identifiable from the name. New creative under a new review is a new ad. And retired values are recorded rather than deleted.