Marketing Ops is an agentic marketing-operations automation engine for GA4, Search Console, Tag Manager and Google Ads. On a schedule and on demand, it pulls your reads from all four into one findings file and runs a deterministic detector over the baseline. Claude interprets what moved and why; each actionable finding becomes a gated proposal — a readable narrative paired with a machine-checkable change spec. Approving it triggers a separate scripted step that re-verifies the change before anything live is touched. The model analyses and judges; it never mutates a property.
- Proactive and cross-property. Today someone has to notice a number move in a dashboard. marketing-ops sweeps GA4, GSC, GTM and Ads on a daily and weekly cadence — the analysis happens whether or not anyone is watching.
- Gated by design. Nothing mutates unattended. Every change is an approval surface — a PR diff or a signed Slack click — and the agent only proposes; a human always says yes first.
- The change that ships is the change that was reviewed. Approved proposals are fingerprinted, and a no-model script re-checks that fingerprint before touching anything — so a late edit can't slip through.
- The riskiest path is the most constrained. Google Ads spends real money, so it auto-applies only narrow, revenue-checked changes — budgets and targets stay propose-only, and any cap breach rejects the whole proposal.
01 · Why proactive marketing-ops automation beats a dashboard copilot
Marketing decisions are reactive, bottlenecked on a person noticing something in a dashboard — no proactive sweep, no thresholds as code, no audit trail. An in-console copilot or a dashboard SaaS doesn't cover it. This is orchestration across all four properties at once — one reviewable approval surface, the applied change bound to the reviewed one.
02 · Shape of the system
Everything specific to your setup — data sources, thresholds, business calendar, action posture, notification routing, compliance rules — lives in configuration, not code. The same skills run two ways.
| Mode | How it runs |
|---|---|
| On-demand | Open the repo and invoke a skill conversationally in Claude. Nothing scheduled runs — local reads, local execution, a PR at the end. |
| Autonomous | A daily anomaly sweep and a weekly opportunity sweep you can toggle on or off, under hard caps on spend and runtime. The scheduled pipeline is the on-demand one with a fixed prompt. |
The pull request is the queue and the merge is the gate — no separate dashboard to run. The daily sweep opens a PR only for the most severe anomalies and sends everything lower to a Slack digest, so the approval surface never floods.
03 · How it works — the pipeline
- Gather & Detect — scripts pull your reads from each connector into one findings file, then a no-model statistical pass flags what moved against each metric's own rolling baseline (robust, and weekday/weekend aware, so a quiet Sunday doesn't read as a crash). It honours data freshness, so nothing fires on unsettled data.
- Analyze & Propose — the one judgement step. Claude reads the findings alongside your calendar, thresholds and known issues, then turns each actionable finding into a typed change spec — a GTM operation, an Ads operation, a site issue, or a content brief — with its cited narrative.
- Review — deterministic gates first and the model last, ending in one blocking verdict.
- Approve & Apply — a person merges the PR or clicks Approve in Slack; a scripted, no-model step re-verifies the change against the review, re-checks the guardrails, then makes it.
04 · Proposal types & blast radius
Five proposal types, one schema. Each type's gate is set by how much damage it could do and whether it can be undone.
| Type | Blast radius | Reversible? | Default gate |
|---|---|---|---|
| anomaly | None — digest / scorecard only | n/a | Acknowledge |
| gtm-change | Medium — alters tracking | Yes — container versions | Single approval |
| site-issue | Low — opens an issue | Yes | Single approval |
| content-opportunity | Low — opens a cross-repo PR | Yes | Single approval |
| ads-recommendation | Highest — spends client budget | No | Budget-owner gate |
Two paths carry extra teeth. Tag Manager never publishes itself: the apply edits a workspace and saves a version, and a human publishes in the GTM UI. Ads is the most constrained: it auto-applies only narrow, ad-group-scoped, revenue-checked negative keywords. Budgets, targets and bids stay propose-only, new campaigns launch paused, and hard spend caps reject the whole proposal if any operation crosses one.
05 · Approval surfaces — GitHub + Slack
The PR has always been the approval surface. A Slack self-serve gate moves the approval point into Slack for the paths where a single human approval is safe, while keeping the GitHub budget-owner gate for the one path where it is not.
A small, always-on gate service is the approval authority and nothing more: it holds no Google credentials, keeps the reviewed proposal, confirms each click genuinely came from Slack and from an approver on your allowlist, enforces single-use and a time limit, then hands off to the same scripted apply that still does every re-verification and guardrail check.
| Path | Default gate |
|---|---|
| Reversible — a tracking change, site issue, or content brief | One Slack approval (recoverable through versions or trivially undone) |
| Irreversible — an Ads change that spends real money | Budget owner, by default |
Every gating choice is a toggle with a safe default — it ships with the gate off and Slack approvals disabled, switched on only when you want them.
06 · Security & guardrails
The non-negotiables, each enforced in code rather than convention:
| Rule | What it guarantees |
|---|---|
| No model on the apply path | Gather, detection and apply are deterministic scripts; the model only analyses and judges. |
| Applied equals approved | The apply re-checks the reviewed proposal's fingerprint and refuses to run on any mismatch. |
| Grounded or nothing | Before applying, the script checks every operation traces back to the evidence the proposal cited, and refuses anything that doesn't. |
| Ads stays human-gated | A budget owner always approves the spend, the caps reject the whole proposal on any breach, and new campaigns launch paused. |
| Pinned, read-only connectors | Every data connector is version-pinned and limited to read access; no write path is ever exposed to the model. |
| Credential isolation | Secrets live only in your own secret store; no real credential is ever written into the codebase. |
07 · Models
Pinned per skill, hardcoded — not config-driven — so the system can't silently drift onto a model the guardrails weren't tuned for. Every model is from Anthropic.
| Model | Role | Default? |
|---|---|---|
| Claude Sonnet | Analysis, proposal enrichment and review | Yes |
| Claude Haiku | Optional PR-body summaries | Opt-in |
| Claude Opus | Hardest investigations | Opt-in |
08 · Integrations
marketing-ops connects to your Google marketing stack — we enable the properties you run and skip the ones you don't.
| Category | Examples |
|---|---|
| Analytics | Google Analytics (GA4) |
| Search | Google Search Console |
| Tag management | Google Tag Manager |
| Advertising | Google Ads |
| Shopping | Merchant Center · when you run a feed |
| Approvals & alerts | Slack, GitHub |
Run only the Google properties you actually use, and route approvals to wherever your team lives — Slack, GitHub, or both. We tailor the set to your stack.
What Marketing Ops is, in short
- End-to-end pipeline. The full gather-to-apply flow across GA4, GSC, GTM and Ads, with the review passes and the applied-equals-approved guarantee built in.
- Slack self-serve gate. In-Slack approve / dismiss for the reversible paths and a trigger-sweep button, with Ads kept on the budget-owner gate by default.
- Configuration-driven. Thresholds, posture and routing are all tunable without touching code, so the system fits how your team works.
Built on the same owned-in-code, human-gated pattern as Blogsmith and Outbound Agent.