Cost per Conversion by Campaign: Ask Your MCP Server

A trustworthy cost per conversion by campaign divides each platform's reported spend by one deduplicated conversion count, measured under one stated attribution model and lookback, and withholds the ratio when the count is too small to trust. Curve MCP gives an AI assistant that number for Google Ads and Meta campaigns: platform-reported spend divided by the people Curve's server-side tracking saw convert, credited last touch within 30 days. Platform conversion columns fail across platforms, because each grades its own work. Curve signs a BAA on every plan; the AI vendor you connect sits outside it, so the connector releases only rounded, organization-level figures.

Easy math, contested denominator

Cost per conversion is spend divided by conversions. The fight is over which ones: a clinic with server-side tracking has three kinds of count to choose from, each answering a different question.

Platform-reported conversions

In Google Ads, "Cost / conv." divides cost by the "Conversions" column, which counts primary conversion actions only. Secondary actions and view-through conversions land in "All conv.", so promoting a form-start action to primary can drop cost per conversion overnight without one extra booking.

Meta's default window counts actions within 7 days of a click or 1 day of a view. So Meta credits a person who scrolled past an ad and booked the next day, while Google credits the search click she made before booking. Add the two columns and one booking becomes two conversions.

Platform columns are the right denominator inside one platform, since its bidding optimizes toward them, and the wrong one for moving budget between platforms.

Server-side sent and accepted conversions

If you send conversions server-side (Meta Conversions API, Google enhanced conversions, TikTok Events API), you get two more counts: what your tracking sent and what the platform matched to an ad. The gap shows whether the pipe works. It is a diagnostic, not a denominator (see sent vs accepted conversions), and the matched count is still the platform's attribution.

First-party attributed conversions

The third count comes from your own tracking: the people who booked or submitted a form on your site, each conversion credited to one campaign under one written rule, so the rows do not stack the way platform columns do, as long as every campaign carries a unique tag. The costs are real: the rule decides which campaigns look good, and it can only credit clicks tied to a campaign. Still, it is the only one of the three that credits a conversion to a single campaign across platforms, and that is what a budget decision needs.

Spend: one source, the same seven days

Spend is the one number the platforms own outright, so take it from them per campaign, not from the invoice or a fee-loaded agency figure. Three things still go wrong.

• Units. The Google Ads API returns cost in micros, so metrics.cost_micros must be divided by 1,000,000. Skip that and a campaign appears to spend a million times what it did.
• Dates and time zones. Spend and conversions must cover the same seven days in the same time zone.
• Stale syncs. A spend feed that quietly stopped updating makes cost per conversion look wonderful. The connector's answer states its dates but not when each platform last synced, so check each platform's total spend for those dates against Google Ads and Ads Manager. If every row from one platform vanishes, suspect the sync before the campaigns.

Curve MCP's campaign rows cover Google Ads and Meta only, so take TikTok and Microsoft Advertising spend from each platform's own reporting and note which conversion count you divided it by. Their tagged clicks still count as touches in your first-party tracking, so a patient whose last tagged ad click came from TikTok or Microsoft is credited to no listed row, and the Google and Meta rows are not padded with conversions another platform closed.

Attribution model and lookback: say them out loud

Every cost per conversion carries a model and a lookback, stated or not, and they explain most disagreements before anything is broken.

• Google Ads. Data-driven attribution is the default for most conversion actions and can split one conversion into fractions across campaigns. The default click-through window is 30 days, and the "Conversions" column dates each conversion to the click, not the conversion.
• Meta. The default window is 7-day click or 1-day view, so view-through credit is inside the number. Its API can date an action to the impression or to the conversion, through the action_report_time parameter.
• TikTok. Click-through windows are 1 or 7 days, with separate engaged-view (1 or 7 days) and view-through (off or 1 day) windows, so check which ones a conversion column uses before dividing.
• Microsoft Advertising. Each conversion goal sets its own click window (up to 90 days), view-through window (up to 30), attribution model (data-driven, last touch or last click) and All or Unique counting per click. Goals excluded from "Conversions" still land in "All conversions".
• The connector's rule. Last touch with a 30-day lookback: each person who converted is credited to the last campaign-tagged click in the 30 days before, counted once per campaign, in the week the conversion happened.

Three consequences for reading the results:

• Last touch favors closers. Branded search and retargeting look cheap, and prospecting that starts journeys on Meta or TikTok looks expensive. That is the model talking (see choosing attribution windows).
• People are not events. Google can count "Every" conversion or "One" per ad interaction, so a patient who books, cancels and rebooks can be two conversions there and one person in a people count.
• Click date vs conversion date. Because Google dates conversions to the click, last week's Google numbers keep growing as late conversions arrive. A conversion-dated count does not grow backward, but this week's conversion may trace to a click, and spend, up to 30 days earlier. Decide on 4 or 13 weeks, not one.

None of these rulers is wrong. Mixing them is; why Meta and Google disagree covers the rest.

Small numbers: why low counts get withheld

A cost per conversion built on three conversions has two problems.

The first is statistical. With $900 of spend, 3 conversions means $300 each; one more booking makes it $225 and one fewer makes it $450. A ratio that swings that far on one patient cannot move budget.

The second is privacy. Spend divided by cost per conversion returns the count, and 3 people on a service-line campaign in one week can be matched to patients by anyone holding the booking calendar. So a connector built to release only aggregates withholds small groups, as small-group rules for MCP answers explains.

How that plays out:

• A withheld campaign disappears, spend and all. A campaign whose conversions fall below the minimum group size is dropped from the list and added to a count of withheld rows, which is itself rounded.
• Missing is not zero. A withheld campaign converted fewer people than the minimum, possibly none, so never let the assistant treat it as zero.
• The campaigns you most need to cut are the ones it will not list. A campaign spending steadily and converting almost nobody sits below the line. Find it from the other side: a campaign with an approved name and spend in the platform's own reporting but no row in the answer is below the line, unless the spend sync stalled. Untagged campaigns land there too.
• Blended figures flatter. Summing the listed rows into an account-wide cost per conversion drops withheld campaigns from spend and conversions alike, so the blend usually looks better than the account is.
• Longer windows help. A campaign converting a few people a week may clear the line over 13 weeks, though weekly rows are checked on their own, so most of its weeks can still read as withheld.

How Curve MCP calculates cost per conversion by campaign

Curve MCP is a read-only connector that answers organization-level questions for any MCP-capable AI assistant, from Claude and ChatGPT to Cursor. For campaigns, it returns one row per Google Ads or Meta campaign, built like this:

• Spend, clicks and impressions as Google Ads and Meta report them, at campaign level. Spend is rounded and follows each ad account's own reporting day, while conversions follow your reporting week, so keep ad accounts in your reporting time zone.
• Conversions as distinct people the server-side tracking recorded converting, under the last-touch, 30-day rule above. A click belongs to a campaign when its utm_campaign value matches that campaign's name or ID.
• Cost per conversion computed from the rounded spend and conversions it releases, and only when the conversion count cleared the minimum group size. Near the withholding line, rounding alone can move a campaign's cost per conversion by tens of percent, so treat close rankings as ties and trust 13-week rows over weekly ones.
• Completed weeks only. Last week, or the last 4, 13 or 52 weeks, as a total plus a week-by-week series. The current week never appears, so figures can run up to a week behind the dashboard, and each answer states the dates it used.
• Approved names. A campaign name appears only if your organization approved it. Otherwise it reads "(label hidden)". A hidden label also means you cannot match that row to the platform's own reporting, so approve the name of every campaign you intend to audit.

It leaves out revenue and ROAS, breakdowns by channel, device, region or page, UTM values and page paths, and anything about an individual. A person-level question gets an "open in Curve" link that needs a login, works once, expires quickly and carries no data.

Underneath, the service runs under its own database role, which cannot read contact details or form answers. It reads event data inside Curve only to count people, and it checks those limits every time it starts. A final guard blocks the whole answer if it finds anything shaped like an email, phone number, ID, date or name, or if the guard itself cannot run.

The upshot: the same spend source, model, lookback and counting unit every week, so the number is worth trending. The same rows reconcile your server-side campaigns, putting platform-reported spend, clicks and impressions beside the conversions Curve's server-side tracking recorded, and one link opens the full sent, accepted and matched view inside Curve (see our weekly reconciliation routine).

Prompts that return a cost per conversion you can use

The connector takes a fixed window and nothing else, so good prompts name the window, ask for the inputs beside the ratio, and say how to treat gaps.

• Rank with the inputs showing. "Rank our Google Ads and Meta campaigns by cost per conversion over the last 13 weeks. Show spend, conversions and cost per conversion for each, and tell me how many campaign rows were withheld."
• Load the rules first. "Before you answer, check what this connector can and cannot return and how it rounds and withholds. Label every cost per conversion as last touch, 30-day lookback, people not events." The answer does not name its attribution model, so say it in the prompt or the assistant may guess.
• Trend without inventing. "Show week-by-week cost per conversion for our three highest-spend campaigns over the last 13 weeks. Mark withheld weeks as withheld, never zero, and do not fill them in."
• Cross-check one platform. "Take the start and end dates from that answer. With the Google Ads connection, query campaign.name, metrics.cost_micros and metrics.conversions for exactly those dates, compute cost per conversion as cost_micros divided by 1,000,000 divided by conversions, and explain each gap between the two figures."

That prompt needs Google's official Google Ads MCP server connected too. It is strictly read-only but reaches anything GAQL can, search terms included, so read our PHI-safe Google Ads setup for Claude first.

And three prompts that fail by design:

• "Which patients converted from the TRT campaign?" returns an "open in Curve" link, never names.
• "Show cost per conversion by landing page, device or state" asks for breakdowns the connector does not return.
• "What is ROAS by campaign?" needs revenue, which it never returns.

Frequently asked questions

Should I divide by platform-reported conversions or my own count?

Both: the platform's column to compare campaigns inside that platform, and one first-party, deduplicated count to compare across platforms, because each platform's column claims the same patients.

Why is the assistant's cost per conversion higher than Google Ads shows?

Google's column can include fractional data-driven credit, repeat conversions counted as "Every", and conversions dated back to the click, while a people count credits each person once per campaign. A steady gap is normal; a sudden one is not.

Why doesn't the answer's spend add up to the ad account's?

Mostly by design. Withheld rows drop their spend with their conversions, TikTok and Microsoft Advertising are not covered, and campaigns with no spend and no clicks in the window are left out without being counted as withheld. Spend is also rounded and follows each account's reporting day. If one platform's total falls far short, suspect a stalled spend sync first.

Can I change the attribution model or lookback?

Not through the connector. Last touch and the 30-day lookback are fixed, so the number means the same thing every week. Anything deeper gets an "open in Curve" link, where your BAA covers the work.

Is a cost per conversion PHI?

Spend on its own is not health information about anyone. A cost per conversion on a small count is different: spend divided by it returns the count, and a count of 2 or 3 tied to a service-line campaign and one week can point at identifiable patients. Hold ratios to the same small-group rules as the counts behind them.

Where to start

First, write your definition at the top of every report: "Cost per conversion = platform-reported spend divided by people who booked, credited last touch within 30 days, completed weeks only." A figure you cannot define in one sentence is not ready for a budget meeting.

Then fix tagging, since a people count can only credit clicks that name a campaign. Every Google Ads and Meta click should carry a utm_campaign equal to the campaign's ID, not its name: IDs are unique across platforms, while a name shared by a Google and a Meta campaign credits the same people to both rows. Auto-tagging's click ID is not a campaign tag. In Google, a final URL suffix using the {campaignid} ValueTrack parameter fills it in automatically; in Meta, the ad's URL parameters take {{campaign.id}}. Our conversion tracking setup for Google, Meta and Microsoft covers the server-side pipe, and the free compliance scanner finds pixels still firing on your site.

To watch Curve MCP answer these prompts, with small groups withheld, every figure rounded and hidden labels in view, book a demo. The rest of how Curve handles health data, BAA on every plan included, is at curvecompliance.com.

Reviewed September 2026. Platform defaults are from Google, Meta, TikTok and Microsoft Advertising documentation.