Features of The Marketing Ops Manager

The Marketing Ops Manager is marketing ops monitoring software. Each section below describes one feature that exists in the product today, what it stores or shows, and a concrete example.

Campaign journeys

A campaign holds an ordered journey of steps: ad, landing page, form, tracking, CRM and lead handoff. You pick the system for each step and enter its settings, such as the landing page URL, the HubSpot form ID or the GA4 event name.

Data it stores: Campaign name, objective, owner, dates, budget, check interval and the configuration of every step.
Example: A webinar campaign with a Google Ads campaign, the registration page, a HubSpot form, the GA4 event generate_lead, contact creation and owner assignment.

Scheduled checks

Checks run on a schedule and on demand. They request the landing page as a desktop and a mobile browser, compare the ad final URL, look up the HubSpot form and its submissions, compare GA4 event counts with a 7-day baseline and check that new HubSpot contacts have an owner. Checks only read from your tools and never submit test leads.

Data it stores: Every check run with its result per step, status codes, response times and the API responses used as evidence.
Example: The registration page returns 200 in 1.2 seconds, but the generate_lead event count is zero against a baseline of 41 per day, so the tracking step turns critical.

Campaign health score

Each campaign gets a status of healthy, at risk, critical, paused or unknown, plus a score from 0 to 100. Healthy steps raise the score, warnings count partly, and every critical step lowers it.

Data it stores: The current status and score of each campaign and the status of each step.
Example: A campaign with six steps, five healthy and one critical, shows the status critical and a score of 68.

Incidents with evidence

When a check fails, the product opens an incident for the failing step, or updates the one that is already open. You can assign an owner, add notes and change the status. An incident resolves only when the failing check passes again.

Data it stores: Incident number, severity, status, owner, timeline events, notes and the evidence of each failing check.
Example: INC-12 is opened for a missing form, assigned to the campaign owner, and resolved automatically after the next check finds the form again.

Approvals

Changes to connected systems go through an approval request. The request names the action, its parameters, a risk level and the rationale. A person approves or rejects it in the web app, and only an approved action runs with the workspace credentials. Available actions include changing a Google Ads daily budget, creating a Jira issue or Asana task, posting a Slack message and updating a HubSpot contact property.

Data it stores: The action type, parameters, risk, requester, approver, decision time and the result of the execution.
Example: Claude asks to post an alert to a Slack channel. You open Approvals, review the message and approve it. The result is stored with the request.

Connections

You connect HubSpot, Google Analytics 4, Google Ads, Slack, Jira and Asana with API credentials. Each credential is validated against the provider before it is stored. The browser never receives the secret again, only a masked hint and the connection status.

Data it stores: Connection status, account label, last check time and the credentials, which only the server can read.
Example: You paste a HubSpot private app token. The product tests it, shows the portal ID as the account label and marks the connection as connected.

Slack alerts

After you connect a Slack incoming webhook, the product posts incident and approval messages to that channel. In Settings you choose which severities and which events are posted.

Data it stores: The webhook secret (server-side only) and your routing choices per severity and event type.
Example: Critical and high incidents and new approval requests are posted to the channel, while low severity incidents stay in the app.

Activity log

Every detection, note, proposal, approval and status change is written to one timeline. Each entry shows who did it: a person, an AI agent such as Claude or ChatGPT, or the monitor.

Data it stores: Time, actor, source (web, Claude, ChatGPT, MCP client or monitor), a short text and links to the campaign, incident or approval.
Example: At 09:12 the monitor opened an incident, at 09:14 Claude requested an approval, and at 09:21 a teammate approved it.

Workspaces and roles

A workspace holds your campaigns, connections and team. Owners and admins invite colleagues by email and give them the role admin, editor or viewer. Row-level security in the database keeps workspaces apart.

Data it stores: Members and their roles, pending invitations and workspace settings such as time zone and check thresholds.
Example: A demand generation manager is an editor who manages campaigns, and the head of marketing is a viewer who reads the incidents.

MCP server

The product includes a Model Context Protocol server with 11 tools. AI assistants such as Claude, ChatGPT and Cursor read campaigns, run audits, list incidents, add notes, create monitors and request approvals. Each access token belongs to one workspace and is stored only as a hash. The MCP page explains the setup.

Data it stores: The token name, client, prefix, hash, last use time and revocation time. The token itself is shown once.
Example: You ask Claude to audit your Q4 webinar campaign. It calls audit_campaign, runs the checks now and returns the failing steps with their evidence.