Agency work and campaign operations

Keep a usable rollback record for a ChatGPT campaign

Keep the evidence needed to reverse a ChatGPT campaign change. Record previous values, dependent changes, approval and checks of the resulting state.

Start reading
Editorial illustration: Indigo fabric has a partly rewoven area, a rust patch folded aside and an intact ivory repair.
Editorial illustrationThe local repair illustrates restoring the intended parts while preserving a later valid correction.
The working guide

What you can work through.

Agency work and campaign operations
  • Preserve the exact fields affected by the change.
  • Check for later edits before restoring an earlier value.
  • Verify the resulting state rather than relying on a successful request.

The instruction “put it back” is surprisingly incomplete. Back to which version of the ChatGPT campaign, at what time, and with which exceptions? A budget adjustment might have happened after the change that caused trouble. Restoring yesterday’s entire configuration could remove that valid adjustment along with the unwanted edit.

A rollback record answers a narrower question than an incident report: what would be restored, why is that restoration appropriate now, and how will someone verify it? It belongs beside the change record, where the person making a decision can find it before touching the campaign again.

Describe the boundary of the reversal

Start with the affected account and resource IDs. Names help a colleague recognize a campaign, but identifiers distinguish two campaigns with similar names. Record the object type as well. A campaign, ad group and individual ad are different places to make a change, with different effects on the surrounding structure.

List the fields that actually changed. Avoid presenting a full export as if every field should be sent back to the platform. Some values may be calculated, read-only or no longer relevant. The record should separate previous observed values from the subset proposed for restoration.

For example, a hypothetical change replaced an ad group’s hint list. The rollback evidence needs the complete earlier list, the submitted replacement and the reason to restore it. It does not automatically justify reverting the campaign budget or another ad’s destination. This boundary makes the proposal reviewable.

Preserve a before state that someone can interpret

Capture the previous value before the original change, when possible. Include the observation time and its time zone. If the team discovers the problem later, say where the reconstructed value came from and what remains uncertain. An unverified memory should not become an authoritative configuration merely because the team is under pressure.

Keep the evidence in a controlled project record, without credentials or unrelated customer data. A screenshot can explain what an operator saw, while an export can preserve exact values. Neither is useful if the relevant account, object or observation time is missing.

Field Question it answers
Affected object Which account and resource will change?
Earlier value What was observed before the original edit?
Current value What is present immediately before restoration?
Proposed restoration Which specific fields should change now?
Verification What evidence will show that the intended state exists?

Attach the supporting files rather than copying sensitive material into a broadly shared discussion. The aim is reproducibility for the authorized operator, not unrestricted access to every system involved.

Check the changes that came afterwards

Compare the current configuration with both the earlier state and the original submitted change. A difference can represent legitimate work by another colleague. If several people or integrations manage the account, the record must explain how those later edits will be preserved or explicitly replaced.

Suppose a destination URL was corrected after a creative revision. Reapplying the entire old creative could restore the broken destination. The intended rollback may therefore require a carefully assembled version containing the earlier message and the corrected URL. Call that a new corrective configuration, rather than pretending it is an exact return to the past.

Check dependencies outside the advertising account too. An earlier offer may have expired, the advertised item may be unavailable, or the landing page may have changed. A technically valid old configuration can still describe an offer that the business no longer supports.

Some earlier settings cannot be restored through an update. For example, OpenAI’s budget rules permit moving from a lifetime budget to a daily budget, but require a new campaign to move back. A lifetime limit also cannot be reduced below spend already incurred. Record such constraints before approving a rollback so the recovery plan does not depend on a rejected operation.

Workflow

Restore the right parts

  1. Before the change

    Message A and a destination later found to be wrong.

  2. Current state

    Message B, with the destination already corrected by a colleague.

  3. Corrective version

    Restore message A. Keep and verify the corrected destination.

    Checkpoint
Illustrative example: restore an earlier message while preserving a corrected destination.

Separate acceptance from completed recovery

OpenAI’s campaign-management documentation describes different update and status operations. It also explains that successful operations in a bulk job are not automatically undone when other operations fail. Treat restoration as an explicit operation with its own evidence, not as an assumed consequence of an error.

A successful request response is only part of that evidence. Read the resulting resource and compare the intended fields. Where creative review or serving eligibility matters, check the relevant state rather than assuming that the old appearance means the campaign is ready to serve.

Do not promise that a previous performance level will return. Restoring settings cannot recreate the earlier auction, audience demand or surrounding business conditions. The verification should first establish configuration correctness; subsequent performance monitoring answers a separate question.

Close the record with the actual outcome

Record who authorized the restoration, who performed it, the completion time and the verification result. If only part succeeded, list the remaining differences. If the team abandoned restoration in favor of a different correction, preserve that decision and its reason.

Link the record to the original campaign change request and the report snapshot that informed the decision. These connections prevent a future reviewer from mistaking a deliberate recovery for an unexplained campaign edit.

Use the eventual incident review to improve the process. Perhaps the earlier hint list was not saved, or a later URL fix was nearly overwritten. A useful improvement changes what the next operator records before making a similar edit. Check the applicable operations in OpenAI campaign management whenever the restoration procedure is implemented or revised.

Sources and scope

Preserve previous campaign values, dependencies and verification criteria so an approved rollback does not overwrite subsequent changes.

Working methods and examples are editorial suggestions. Check current platform requirements and available features before implementation.

Your next chapter

Explore the workflow for your clients.

See the agency workflow in AthillyAds, from a client's website to campaign material your team can review.