Worker-first paid traffic operations

The problem was execution ownership

A routine paid-traffic check should not depend on whether an AI assistant has conversation capacity left. In this project, a scheduled check was reported as missed when Claude reached a usage limit. That exposed a dependency I wanted to remove: the same assistant was helping reason about campaigns and carrying routine execution.

Other incidents made the boundary more urgent. A local script and the Worker could both change settings. An overspend incident showed the difference between sending an alert and enforcing a limit. Some requested changes also failed to appear in the destination after a write.

My response was to define which component could act, what evidence it needed and when it had to stop. Faster automation would be useful only if those responsibilities were clear.

I set the rules; Claude helped implement them

I defined the media-buying priorities, separate budget boundaries for Client A and Client B, and the requirement for human approval before spending more. Their budgets remain separate. I also required previews before creative or page publication.

Claude helped translate those requirements into implementation work, code and review tasks. Cloudflare Worker and D1 provide the scheduling and record-keeping layer. The tracker supplies attribution events, while network integrations expose campaign state and supported actions.

The design gives the Worker primary write ownership. Local scripts should report observations rather than compete as a second writer. Claude remains useful for analysis and implementation support; a scheduled guard should not need a new LLM response to execute an already authorized rule.

The architecture and the approval boundary

This diagram explains the operating design. It is not a live dashboard or a claim that every path has been independently tested.

Give automation a narrow operating boundary

I separated protective actions from attempts to improve performance. A conditional pause can reduce exposure when a verified spending boundary is reached. Raising a budget or bid commits more money and needs human approval. A cheaper-looking tracker result is not sufficient permission.

The implementation reports describe separate read and write credentials, destination readback after changes, and controls around protective pauses. These are useful controls to verify; they do not make every API response trustworthy. If a setting does not match the requested state, the workflow should flag the discrepancy rather than treat the write as complete.

Recovery also needs a defined scope. The material describes limits on recovering lines paused by the system, but does not establish one universal approval rule for every recovery path. I am keeping that boundary explicit instead of describing all reopening as either automatic or manual.

Heartbeat checks and deduplicated alerts are intended to make missed work visible without repeatedly sending the same warning. Deployed notification code is only one part of that: successful delivery still needs evidence. An alert-only integration also cannot be described as enforcing a stop.

Unreliable data should narrow the action

A zero-conversion signal can reflect a broken tracking path. The project therefore includes a validation gate: certain conversion-based rules remain alert-only until the relevant tracking check passes. Missing or unreliable data should trigger investigation before aggressive optimization.

The material also described suspected duplicate registration reporting. Closely timed records and differences between systems are diagnostic clues, but they do not independently establish the root cause. The underlying event path and deduplication behavior still need to be reconciled.

Here, “FTD” means a first-deposit event received by the tracker. It is not automatically an approved FTD, deposit value or revenue. Late events also affect cohort maturity: I want decisions to account for the age of acquired traffic, rather than compare a young cohort with one that has had longer to convert. I am not publishing an unverified average delay or claiming a validated correction model.

One decision, with an explicit stopping point

Fictional worked example. The anonymous situations below demonstrate the rules. They are not production logs, client outcomes or records of actions actually taken.

The placement decision method explains the broader pause, hold, bid and scale framework.

What is running, and what is still a proposal

This is an ongoing project with limited live actions. The overall Worker remains in shadow mode: most optimization rules produce proposals rather than change campaigns.

Readback is evidence to inspect, not a headline metric

Claude's implementation reports describe a bid-field correction, pause and recovery readbacks, and a heartbeat repair. They also acknowledge some interface changes that did not persist. Those examples explain why I required destination checks instead of trusting a successful-looking request.

For this case, the underlying production traces and test suite have not been independently re-run. I am therefore not presenting reported test counts or deployment hashes as audited proof. The source supports a description of the work and its reported status, with those limits intact.

There is also no consistent before-and-after time, cost or revenue measurement. I cannot claim an ROI improvement, a percentage saving or fully unattended operation. The outcome I can describe is a clearer operating design, with limited execution reported and substantial validation still open.

The next milestone is a controlled handoff

Before expanding execution, I want the outstanding migration and both debugging passes completed. I also want evidence of scheduled runs and alert delivery, confirmation that write ownership is enforced, and documented limits for each recovery path.

After that, any move from shadow to active should be a separate, bounded decision with its own evidence and approval. Comparable measurements can then test whether the system actually improves reliability or reduces manual effort.

This project reflects the part of media buying I want to make repeatable: defining the event, the spending boundary and the evidence required before the next action.

Related methods

• Pause, hold, bid or scale within a spending boundary
• Trace a conversion before trusting the report
• Change one element in a creative–lander test

Platform background: Cloudflare scheduled triggers and D1 documentation. These describe platform capabilities; they do not verify this project's implementation.