A launch is approved on Tuesday. On Wednesday, someone replaces a headline, another person updates the landing page and a third changes the reporting configuration. Each edit looks small in isolation. By launch time, the team is no longer releasing the combination it reviewed.
A change freeze creates a temporary boundary around that combination. It is an internal operating arrangement, not a claimed feature of ChatGPT Ads. Its value comes from a clear scope and an agreed way to handle exceptions. A vague instruction to avoid changes is difficult to follow because nobody knows which changes count.
Name the release being protected
Write down the account and campaign identifiers, the intended launch window and the version of the material that has passed review. Include the relevant destinations and measurement dependencies. Keep this record short enough that the person making an edit can identify whether the edit falls inside the boundary.
Do not describe the scope only as the campaign name. A website deployment can change the offer behind an unchanged ad. A reporting configuration can change what the team sees after launch without changing the creative. These dependencies belong in the freeze when their stability is necessary for the release decision.
The approval evidence should identify the approved combination. The freeze then protects it for a specified interval. Approval and freezing solve different problems: one records a decision, while the other controls what happens between that decision and release.
Decide what may continue
Reading reports, investigating an issue and drafting future copy do not necessarily alter the protected release. Those activities can continue if the team keeps drafts separate from live configuration. Blocking all work creates an unnecessary queue and encourages people to work around the arrangement.
Classify actions by whether they alter a protected object or dependency. For example, preparing an alternative headline in a draft document can remain outside the freeze. Applying that headline to the release candidate belongs inside it. Editing an unrelated help page may be outside the boundary, while changing the advertised offer page belongs inside.
| Activity | Suggested treatment during a freeze |
|---|---|
| Read the existing campaign report | Continue without altering its definition |
| Draft next month’s creative | Keep separate from the protected version |
| Replace the launch destination | Require an exception decision and renewed checks |
| Correct a dangerous or misleading offer | Escalate immediately through the exception route |
These are examples for planning, not universal rules. The team must choose a boundary that fits the actual release and its dependencies.
Make exceptions usable under pressure
An exception route needs a named decision owner, a backup and a place to record the request. State what the requester must provide: the affected object, the reason waiting would cause a problem, the proposed change and the checks that will be repeated afterward.
Avoid requiring a long document for an urgent correction. The record needs enough information to preserve the decision and its consequences. If the responsible person cannot be reached, the team should know whether the launch is held, contained or escalated. Silence should not become accidental permission.
A hypothetical retailer discovers that the advertised bundle is unavailable shortly before launch. Keeping the reviewed but inaccurate offer would defeat the purpose of the freeze. The owner can hold the affected release, approve a corrected offer and require another check of the ad-to-destination path. The exception protects the launch decision rather than bypassing it.
Recheck the consequences of an accepted edit
The size of a text edit is not a reliable measure of its effect. Changing a single eligibility term can alter who the offer is for. Replacing a destination can affect the expected action and measurement. Determine which checks the accepted change invalidates, then repeat those checks before treating the release as ready.
OpenAI’s campaign documentation explains that updating creative submits a new version and starts another review. Recheck that state after an accepted late edit instead of treating the earlier review as approval of the replacement. An internal deadline cannot guarantee a platform review outcome or that the ad will be eligible by launch time.
Use the change request record when an exception needs a fuller explanation. Preserve the prior state and the selected recovery route in the rollback record if restoration might be required. Neither document should be used to imply that every platform action is reversible.
May the change pass the freeze?
- Inside the boundary?
Identify the object or dependency being changed.
- Must happen now?
The decision owner assesses why the edit cannot wait.
- Checked again?
Repeat the checks invalidated by the exception.
Checkpoint
Reopen with an owner and a queue
Specify the intended end of the freeze, but also name who confirms it has ended. A delayed launch can make the original end time inappropriate. Conversely, extending a freeze indefinitely prevents normal improvements without explaining what condition the team is waiting for.
At reopening, review queued changes before applying them. Some requests may have been made against an older version, and others may conflict. Decide which changes remain relevant, who owns them and whether they need a separate review. Releasing the entire queue simultaneously recreates the uncertainty the freeze was intended to prevent.
Retain the frozen version reference, accepted exceptions and actual reopening time with the launch record. That makes later questions answerable: what was reviewed, what changed afterward and what finally went live? A useful freeze gives those questions a clear answer while leaving room for justified corrections.
Sources and scope
Define a temporary change freeze that protects a checked launch version, including exceptions and responsibility for reopening changes.
Working methods and examples are editorial suggestions. Check current platform requirements and available features before implementation.