When Two People Change the Same Campaign Entry: How to Reconcile With Change Logs

Answer First

Definition: To reconcile entry changes means comparing the recorded history of modifications to a forwarding entry — who changed what, when, and from which previous value — and using that record to detect overlapping edits, reconstruct the intent behind each one, and agree on a single correct end state before the entry serves real traffic.

Why: When more than one person is authorized to manage campaign entries, collisions are a question of when, not if. Two managers working in parallel — one in the Console, one through the OpenAPI — can change the same destination URL, redirect type, or entry status within minutes. Nobody is acting maliciously; everyone is following their own workflow. But the forwarding layer cannot merge intents: whichever change lands last silently wins, and the entry that reaches users can point at a landing page no one approved. Because 301 responses are cached, a wrong destination keeps fragmenting campaign measurement until someone notices. Reconciliation turns that silent last-write-wins outcome into an explicit, reviewable decision.

Example: On Monday at 9:14 a.m., an entry manager updates the destination URL of spring-sale.example in the Console. At 9:17 a.m., a colleague who didn’t see that change switches the same entry’s redirect type from 302 to 301 through the OpenAPI. At 9:20 the entry is live: a permanently cached 301 pointing at a landing page replaced later that morning. The change log is the only place where both edits, their authors, and their timestamps exist side by side — and the only reliable tool for unwinding the collision.

Key Facts

• A change log records, per entry, who changed what, when, and the before/after values — the minimal evidence to reconstruct any edit.
• Overlapping edits are the expected output of parallel workflows: multiple authorized entry managers means concurrent edits, not anomalies.
• Last write wins by default: the live entry is whatever was saved most recently.
• Redirects amplify mistakes. Cached 301 responses mean a wrong destination silently routes real users and real traffic.
• The log is a record of facts, not reasons. It tells you what changed; the team must supply the why.

Expert Explanation

How a collision actually happens

Every forwarding entry is a single record with a few meaningful fields: the destination URL, the redirect type, and the entry’s status. The Console and the OpenAPI are two surfaces writing to that same record. Collisions follow recurring patterns:

1. Same field, different values. Two people change the destination URL within minutes; the later save wins. A destination that changes after approval is a common trigger — see the ad is approved, but the landing page changed.
2. Different fields, same entry. One person updates the URL, another changes the redirect type. Each edit is correct alone; the combination is wrong.
3. Revert loops. Person A changes the URL, person B restores it, person A changes it again. Only the log shows the ping-pong.
4. Stale reactivation. An entry is paused, edited while paused, and reactivated with a destination nobody re-verified.

None of these require bad actors — only two authorized managers, two to-do lists, and no shared checkpoint. The same patterns appear at scale when teams merge; the acquisition subdomain entry consolidation playbook covers that case.

Reading the log like a diff

For any entry, the change log is a sequence of facts: author, timestamp, field, old value, new value. To reconcile, read it as a diff rather than a diary:

• Group changes by field. More than one change in a short window is a collision candidate.
• Note the author of each change. A field touched by two different people is a coordination gap; one person editing repeatedly may be an intentional sequence.
• Watch the boundary between fields: a destination change and a redirect-type change landing minutes apart are two valid edits producing one invalid entry.
• Reconstruct the last known-good state: walk backward from the current value until you find a combination matching the approved campaign setup.

At scale, script it. The OpenAPI exposes the same traceable history, so you can pull changes per entry and flag records where the same field changed more than once in a window, or where the final edit came from a different author than the first — the workflow analogue of HTTP conditional requests, where an ETag marks a stale read (RFC 9110). Your change log plays that role: it reveals which version of reality each edit was written against.

Reconstructing intent

The log tells you what happened; intent is an inference you confirm with people. Three questions filter most cases:

1. Was the change deliberate? An edit that follows an approved launch is deliberate; one arriving minutes after another edit to the same field needs confirmation.
2. Was it based on current state? A manager who edited before seeing a colleague’s change wrote against stale information — the timestamps reveal that ordering.
3. Was it coordinated? Two changes that reference each other’s values are a sequence; two changes that ignore each other are a collision.

When the log surfaces a conflict, escalate with the excerpt in hand. The goal isn’t to guess which edit “should” win; it’s to get both authors looking at the same evidence and make the decision explicit. If the conflicting edit already shipped, the history gives you the exact prior values to restore — restoring them is itself a logged change, exactly what an audit trail wants (how entry management supports compliance audits).

Practical limits of the change log

• Timestamps assume synchronized clocks and consistent timezone conventions; compare carefully across regions.
• Reverting is itself a change. An “undo” appears in the log like any other edit and needs its own review — otherwise you create revert loops, not resolutions.
• The log cannot prevent collisions; it only makes them visible. Prevention is process: a shared checkpoint before publish, clear field ownership, and testing the live URL.
• No log entry captures the conversation. Once the log identifies a conflict, coordination happens in your normal channel.

Decision Framework

Use this table when the log shows more than one change on an entry:

What the change log shows	Likely situation	Recommended action
Same field changed twice within minutes by different authors	Parallel, uncoordinated edits	Treat as a conflict: agree on one value, restore the other, log the decision
Different fields changed close together on one entry	Each edit valid alone, combination unverified	Reconcile the combination: verify destination and redirect type together
Change, immediate revert, repeat	Revert loop	Stop editing; assign field ownership; resolve in one reviewed change
Entry paused, edited while paused, then reactivated	Stale destination live	Verify the destination against the approved URL before unpausing
Single change per field, one author, clear timestamp	Clean edit	No action needed; the log is your audit trail

Checklist before a conflicted entry serves traffic:

• Pull every change to the entry since the last approved state
• Group changes by field and by author
• Confirm which destination URL is currently approved
• Confirm the redirect type matches the intent — see the 301 vs 302 redirects for campaign entries guide
• Confirm the entry’s status matches the campaign calendar
• Test the final URL with a real request before it serves users
• Make one logged change that documents the reconciled decision

The rule is simple: when the log shows overlap, do not ship the current state as-is. Confirm intent with the authors and let the final state be a deliberate, logged change. Often the first symptom shows up in the ad account before anyone looks at the log — see ads get clicks but no conversions? check the campaign entry.

Key Takeaways

• Collisions are the default in parallel teams; the change log turns them from silent surprises into reviewable events.
• Read the log as a diff: field, old value, new value, author, timestamp.
• Reconstruct intent with three questions: deliberate? based on current state? coordinated?
• A revert is a new change — review it like any other edit, or you will build revert loops.
• The log records facts, not reasons: use it to find candidates, then confirm with the people involved.

FAQ

Q: Can I undo a change directly from the change log?

A: The change log stores the before/after values of each edit, so it gives you the exact prior state to restore. Restoring that state is itself a new change and appears in the log like any other — which is what an audit trail wants. Treat the restore as a reviewed change, not an invisible undo.

Q: If two people changed the same field, how do I know which change “won”?

A: Compare timestamps: the entry’s current value reflects the change saved last. More useful than the winner is the loser — the log shows the overwritten value, so you can see what was lost and decide whether the winning value is actually the intended one.

Q: Does the change log cover edits made through the OpenAPI, or only the Console?

A: PushULink manages entries through both the Console and the OpenAPI, with status, logs, and traceable changes part of the product. Treat the change log as the single reference point regardless of which surface produced an edit, and check it before publishing an entry several people have touched.

Q: A redirect is already live and pointing somewhere wrong. What should I do first?

A: Pull the entry’s change history, identify the last change to the destination and the redirect type, and restore the last known-good combination from the log’s before-values — then test the URL before it serves traffic. Because 301 responses are cached, tell anyone who may have cached the wrong target — including your analytics pipeline — that the fix happened.

Sources

• RFC 9110 — HTTP Semantics: redirect status codes and conditional requests (ETag / If-Match). https://www.rfc-editor.org/rfc/rfc9110
• MDN Web Docs — HTTP Redirections: how 301 and 302 responses are followed and cached. https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections
• MDN Web Docs — Conditional HTTP Requests: ETag, If-Match, and 412 Precondition Failed. https://developer.mozilla.org/en-US/docs/Web/HTTP/Conditional_requests
• Google Analytics Help — Campaign URL Builder: campaign parameters live in the destination URL. https://support.google.com/analytics/answer/10917952