The Campaign Naming Decision Log: Preserve Context After the Team Changes

A campaign name is a compact label, not a durable explanation. It may tell a reader the channel, region, offer and date while leaving out the most important context: why the campaign exists, which trade-offs were accepted and what must remain unchanged for the result to be interpretable.

That context usually lives in messages, meetings or the memory of the person who launched the work. When the team changes, the campaign remains but the reasoning disappears. A campaign naming decision log preserves the operational meaning that cannot fit inside the name.

What belongs in the name—and what belongs in the log

Use the name for stable attributes needed to find, group and route the campaign. Typical components include:

• channel or platform;
• market or business unit;
• objective or program;
• audience or offer family;
• version or launch period;
• status where the platform does not provide a reliable field.

Use the decision log for reasoning and evidence:

• the business problem;
• the hypothesis;
• the chosen option and rejected alternatives;
• the primary success measure;
• known constraints;
• dependencies and measurement requirements;
• change history;
• stop and review conditions.

If the team keeps adding abbreviations until the name explains the entire strategy, the taxonomy becomes unreadable. If the name contains almost nothing, reporting and automation become fragile. The log allows both systems to do the job they are suited to do.

The minimum decision-log record

Field	Question it answers
Stable campaign ID	Which exact object does this record describe?
Current campaign name	How is it found in the platform?
Decision owner	Who can approve a material change?
Business problem	Why does the campaign exist?
Hypothesis	What relationship is being tested or used?
Primary measure	What decides whether the action worked?
Guardrails	What must not deteriorate while optimizing?
Constraints	What limits the design or interpretation?
Measurement state	Which events and CRM outcomes are available?
Review condition	When must the decision be reconsidered?
Change history	What changed, when, by whom and why?

Write a hypothesis that can survive handoff

“Improve performance” is not a useful hypothesis. A handoff-ready hypothesis names the change, audience, expected outcome and decision metric. For example:

For existing high-intent search themes, routing traffic to the shorter qualification page is expected to increase the share of sales-accepted inquiries without exceeding the agreed cost per accepted inquiry. The landing page is the only planned test variable.

This statement does more than document ambition. It tells the next operator which audience is in scope, what “better” means and which concurrent changes would damage the test.

Google Ads recommends a clear hypothesis tied to a business goal, selecting success metrics before the experiment and testing one variable at a time. Those practices become easier to maintain when the reasoning remains attached to a durable record rather than a temporary chat.

Record rejected alternatives

A decision is easier to reverse intelligently when the team knows what was considered. Do not write a long essay. Use a compact format:

• Option: change bidding and landing page together;
• Reason rejected: the team would not be able to isolate which change affected the outcome;
• Revisit when: the landing-page test is complete or the campaign lacks enough volume for the planned design.

This prevents a future teammate from repeating the same debate without new evidence. It also stops a temporary constraint from becoming an unexplained permanent rule.

Make changes append-only

Do not silently rewrite the original decision after results appear. Add a dated entry with:

1. the observed evidence;
2. the decision made;
3. the exact platform or landing-page change;
4. the person who approved it;
5. the effect on measurement continuity;
6. the next review condition.

An append-only history distinguishes what the team believed at launch from what it learned later. That distinction is essential when reviewing whether the process was sound, even if the outcome was unfavorable.

Connect the log without creating another database

The log can live in an existing project system, spreadsheet or lightweight database. The implementation matters less than four controls:

• the campaign has a stable ID that does not depend on its display name;
• operators can reach the record from the normal workflow;
• material changes require a dated reason;
• old records remain searchable after a team or agency transition.

A URL field in the campaign build sheet can connect the platform object to the decision record. For systems that support custom fields or labels, store the stable ID there. Avoid using a row number that changes when the sheet is sorted.

Decision-log template

1. ID and current name:
2. Owner and approver:
3. Business problem:
4. Audience and offer:
5. Hypothesis:
6. Primary measure and guardrails:
7. Measurement requirements:
8. Alternatives rejected:
9. Launch constraints:
10. Stop or review condition:
11. Change entries: date, evidence, decision, operator, impact.

A good naming convention helps the team find a campaign. A good decision log helps the team understand it. Together they reduce the cost of handoffs, make experiments more interpretable and prevent old platform objects from becoming unexplained infrastructure.

Source and further reading

• Google Ads: Test with confidence with the Experiments page