Your cost per lead can improve three months in a row while your paid program gets worse. The MQL to SQL conversion rate is the number that shows it, and most paid reports leave it off the page.
What a falling MQL to SQL conversion rate tells you
The MQL to SQL conversion rate is the share of marketing qualified leads that sales accepts as sales qualified. When that rate falls for paid-sourced leads while MQL volume holds or climbs, paid media is almost always buying a different, weaker buyer than it was before. It is the earliest lead-quality alarm a B2B paid program has, and it usually goes off a quarter or two before the pipeline numbers do.
The definitions matter, so use the ones your CRM already enforces. In HubSpot's default lifecycle stages, a marketing qualified lead is a contact "that your marketing team has qualified as ready for the sales team," and a sales qualified lead is one "that your sales team has qualified as a potential customer" (HubSpot). The rate is simply the second count divided by the first.
The way this usually plays out is boring, which is why it gets missed. Leads are up. Cost per lead is down. The monthly report is green. Sales starts saying the leads are bad, marketing points at the volume chart, and two quarters go by in that argument.
When somebody finally pulls the rate, it has dropped by half. Nobody hid it. It was just never on the page.
Ready for paid ads that pay off?
Book your free auditWhy lead volume reports hide the decline
Cheaper leads can cost more. That is the whole problem in one sentence.
Take an illustrative program. Paid produces MQLs at $200 each and 30% of them become SQLs, so each SQL costs about $667. A few changes go in over the next quarter. Cost per MQL drops to $150, and the SQL rate falls to 15%. Each SQL now costs $1,000.
The report shows cost per lead down 25%. The business is paying 50% more for every conversation sales actually wants to have.
The math behind it is simple: cost per SQL equals cost per MQL divided by the SQL rate. A report that shows the first number without the second can show steady improvement while the program degrades underneath it. I would rather see the SQL rate on page one of a paid report than any cost per lead chart.
The paid changes that usually push the rate down
A falling rate is rarely mysterious. In the accounts we review, it almost always traces back to something that widened who the ads reach or lowered the effort it takes to become a lead.
→ Broader matching. Moving keywords to broad match, switching on AI Max, or folding search budget into Performance Max all hand query selection to the system. Even tight accounts drift, because Google states that "By default, all keyword match types are eligible to match to close variants. There's no way to opt out." (Google Ads Help).
→ New surfaces. Display, Demand Gen and video placements reach people earlier and with less intent. Google's documentation says optimized targeting "is automatically turned on for all campaigns" that support it, and that "Your ads may show to users beyond your selected signals." (Google Ads Help). Nobody has to make a decision for your audience to get wider.
→ Lower-friction forms. LinkedIn Lead Gen Forms come "pre-filled with accurate LinkedIn profile data" (LinkedIn). That is great for completion rate. It also means becoming an MQL takes two clicks and almost no intent, so the meaning of an MQL quietly changes the day you launch them. We cover the fix side of this in our post on LinkedIn Ads lead quality.
→ New campaigns for a new product line or segment. These bring in buyers sales has not learned to qualify yet, and they get blended into the same MQL total as the mature campaigns.
→ Bidding toward the form fill. If the bid strategy optimizes for raw lead submissions, it gets very good at finding people who fill out forms. That is a different person from someone who buys, which is the argument behind optimizing B2B paid search for lead quality instead of volume.
Notice what is on that list. Every item is a reasonable change that most teams make on purpose, and every one of them makes the cost per lead chart look better in the short run.
Rule out the causes that are not paid
Before anyone touches a campaign, check three things that move the rate without any change in who the ads reach.
The MQL definition changed. A new lead scoring model, a new MQL source such as webinar attendees, or a lowered score threshold inflates the denominator overnight. The rate falls and the ads did nothing.
Sales capacity changed. Fewer reps, a reassigned territory or slower follow-up means good leads go stale before anyone qualifies them. Check time to first touch for the same cohort before you blame the traffic.
Duplicate records. When the marketing automation platform and the CRM both create a lead from the same form submission, one person becomes two MQLs and at most one SQL. Duplicates also scramble the click IDs that get sent back to the ad platforms, so deduplication belongs in the fix before anybody judges bidding.
If none of the three moved, the decline is coming from paid.
How to read the rate without fooling yourself
Most teams that do track this rate track it in a way that produces false alarms and misses real ones. Three rules fix most of that.
1.) Read it per source, never blended. A blended rate averages your branded search campaign, which usually qualifies well, with whatever new campaign is sliding. Break it out at least by channel and by campaign type, and by campaign wherever volume allows.
2.) Read it by the month the MQL was created, not the month the SQL happened. A lead created in March that qualifies in May belongs to March. Reported the other way, the most recent month always looks worst because its leads have not had time to qualify. Ad platforms have the same lag problem on their side: "Because Google Ads reports conversions by query date, you may not always see the most updated conversion numbers." (Google Ads Help). Treat any cohort younger than your typical MQL to SQL time as provisional.
3.) Wait for enough volume. A campaign with 20 MQLs a month that moves from 30% to 20% has lost two SQLs. That could be noise. Roll small sources up into a trailing quarter until each line carries something like 50 MQLs before you call a trend.
Our working alarm is simple. When a source's rate falls by a quarter or more against its own trailing two-quarter average, for two mature cohorts in a row, treat it as a real change and go find the cause.
What is a good MQL to SQL conversion rate?
A good MQL to SQL conversion rate is the one your own paid sources were producing before you changed something. Industry benchmarks for this number mix companies with completely different MQL definitions, sales motions and deal sizes, so they tell you very little about your own program.
This is the part people push back on. They want a target to put in a slide. The trouble is that a 15% rate can be healthy for a program where an MQL is anyone who downloads a guide, and alarming for a program where an MQL is a demo request. Compare each source against its own history, and compare sources against each other on cost per SQL, because that number survives definition differences far better than the rate does.
Put the rate next to the changes you made
A falling rate is only useful if the report also says what changed in the month it fell. Executive reports should carry one line per paid source with MQL volume, SQL rate by cohort and cost per SQL, and next to it the changes made in that period.
Google Ads keeps most of this for you. Change history "lists the changes made to your account, campaigns, and ad groups during the past 2 years" (Google Ads Help), including who made each change. When a cohort drops, the first question is what went live in that cohort month, and an annotated change log answers it in a few minutes instead of a few meetings.
This fits inside a lean report rather than replacing it. If you already run something like our four-pillar paid media report, the SQL rate belongs in the results section and the change log belongs next to it.
What to do when the alarm goes off
Once the rate drop is real and traced to paid, work through it in this order.
1.) Name the sources whose cohorts dropped, and leave the healthy ones alone.
2.) Match the drop to the change that went live in that cohort month.
3.) Reverse or fence that change. Tighten the match types, exclude the placements, or add one qualifying question to the lead form that a casual clicker will not bother to answer.
4.) Move bidding toward the SQL itself with offline conversion imports, so the platform stops rewarding the cheap MQLs that caused the problem.
5.) Write down the SQL definition with sales and freeze it for the quarter, so the next reading compares like with like.
Do not respond by cutting budget across the board. The sources that kept their rate are usually producing your best pipeline, and a flat cut punishes them for a problem somewhere else.
Where this rule bends
Two situations call for a different read.
If you deliberately launched into a new segment, a lower rate for the first few months is expected. Announce it before launch, give that campaign its own line, and judge it on cost per SQL against a ceiling you agreed in advance.
If you run a self-serve or product-led motion where most revenue never touches a sales rep, MQL to SQL is the wrong gate. Track the share of paid signups that reach your activation or product-qualified milestone instead. The logic is identical, only the stage changes.
The one change to make this month
Add a single line per paid source to your next report: MQLs, SQL rate by creation cohort, and cost per SQL. If your team cannot produce that line, the gap between the ad platforms and the CRM is the first thing to fix, ahead of any campaign change.
Pulling that rate by source and cohort is one of the first things we do in a B2B Google Ads audit, because it tells us within a day whether an account has a volume problem or a buyer problem.
