Owner Metrics for ABX: What to Measure When Every Account Gets Full Depth

Someone is going to ask how you know this is working. A CFO, a board member, a VP of Sales who still remembers when marketing reported MQLs and wants to know why this quarter's dashboard doesn't. If your ABX motion is engineered rather than bought off a platform, ABX itself isn't the hard part to explain. But the measurement layer is, and it's what our ABM guide's measurement step only sketched. This formalizes it.

Why MQL-era metrics break at full depth

MQL, MQA, and every platform engagement score share a job they were built for: rationing a fixed, purchased pool of attention across an anonymous audience. Sales can't call every lead that fills out a form, so someone has to decide who gets the next touch first, and that's the question those metrics are answering. Who deserves attention now, given that attention is scarce.

That's a real constraint in a purchased-list world, and it's not a knock on the metric to say so. A platform sells you a fixed slate of accounts plus a scoring model to triage them, and MQA does what it was built to do inside that box: turn a pile of anonymous engagement into a ranked queue. Call it a metric built for a constraint that stops applying the moment you've already committed to researching every account fully, not a bad metric on its own terms.

An engineered motion doesn't run into that scarcity problem in the same place, because every account in scope gets researched (the research itself is built and run rather than purchased per contact). Coverage stops being a variable you're solving for and becomes a given. And that shifts the question that matters, from "who gets attention next" to "did the attention we already committed convert, and what did it cost."

Nobody's built a metric for that shift: nobody selling platform ABM tooling has a reason to build one. Take abmatic.ai's own definition of coverage in its metrics glossary: a target account counts as covered once it has at least one identified contact. That's a list-breadth measure, because breadth of touch is the thing a purchased-list product controls, and it describes what a platform gives you, not what an engineered motion needs to prove. Depth is a given once the research itself is built and run rather than bought per contact, but it was never a given under the platform model, so nobody built the row for measuring it.

That's the gap left standing.

Five metrics. Each with a formula you can compute independently, plus a caveat about what it won't tell you.

The owner metric set

Each of the following stands alone: definition, formula, what it tells you, what it doesn't. Copy the formula into a spreadsheet and two people will land on the same number, which is the whole point. If two people can't reproduce the number from the same formula, it's not really a metric yet, no matter how confident it sounds in a deck.

Four of the five are established enough to name plainly, since the underlying question (did the signal turn into a play, did the research turn into a meeting, how deep did it go, what did it cost) is one every full-depth motion eventually has to answer. The fifth is flagged as a candidate rather than a settled term, because it's newer and less tested, and pretending otherwise would be the same overclaiming this whole set is built to avoid. Where a competitor page defines something adjacent, that gets named directly, because the differentiation only means something if you can see where it sits next to what already exists.

Signal-to-play conversion

Definition. The share of accounts that trigger a qualifying signal (a job change or a funding event, say) in a given period that get moved into an executed play, meaning research kicked off and outreach initiated, within a defined window. Everything else just sat there, detected and ignored.

Formula. Accounts moved to a play, divided by accounts with a qualifying signal, same period.

What it tells you. Whether the system is acting on what it sees. A pipeline of detected signals that never turns into executed plays is expensive noise, and this is the number that catches it early.

What it doesn't tell you. Whether the play worked. Conversion into a play tells you the machinery ran, nothing more, and it says nothing about the quality of what came out the other end.

What breaks under the old metric. A platform engagement score tells you a lead is "hot," full stop, and there's no field anywhere that records whether a human picked it up. A signal can sit in a queue for two weeks, decaying the whole time, and the engagement score won't move, because the score was never watching the queue in the first place. It was watching the click.

Research-to-meeting yield

Definition. The share of accounts that completed full research depth in a given period that convert to a booked meeting.

Formula. Meetings booked, divided by accounts that completed full research depth.

What it tells you. Whether depth is buying anything. This is the metric that separates "we researched every account thoroughly" from "we spent enrichment credits and operator hours on accounts that were never going to move."

What it doesn't tell you. It's a lagging indicator, so it needs a defined attribution window or you'll end up crediting a meeting to the wrong research cycle entirely, especially on longer sales motions where research happens weeks before a reply ever lands. Pick a window that matches how your accounts behave (shorter for a fast-moving motion, longer for an enterprise cycle where research runs well ahead of a reply) and write the window down somewhere. An undefined window is how two people arguing about whether the metric is trending up quietly discover they were never measuring the same thing.

What breaks under the old metric. MQL-to-meeting or a generic engagement-to-meeting rate credits the meeting to whatever touched the platform most, regardless of whether research depth had anything to do with it. So you end up unable to answer the one question that justifies the whole full-depth approach: is the depth paying for itself, or are you just busier than you used to be.

Coverage depth per account

Definition. Distinct from list-breadth coverage (the percent of a target list with any identified contact), this measures how much of a single account's buying committee and signal surface got researched: stakeholder roles mapped, signal types checked, personalization hooks written, as a percent of that account's defined full-depth spec.

Formula. Research fields completed, divided by research fields in the full-depth spec, per account. Roll it up as a distribution across the book rather than an average, since an average lets a handful of maxed-out accounts hide a long tail of shallow ones underneath it. This also feeds directly into an account-scoring model as one of its more reliable inputs, because a partially researched account will skew any score built on top of it.

Two competitor framings are worth naming directly here. abmatic.ai's coverage metric counts an account as covered once it has at least one identified contact, a list-breadth measure that stops being informative once breadth is a given rather than a variable (which it is, in this model). ZoomInfo's is closer to this territory: it measures buying-committee penetration within an account, nine of twelve people engaged equals seventy-five percent target account coverage, and that's a real depth-within-account measure. What it still misses is everything below headcount, though: whether the roles that were mapped are the right roles, whether signal types were checked per person, whether a personalization hook exists for each one. Headcount tells you who. It doesn't tell you what got done for each of them.

What breaks under the old metric. A committee-mapping exercise that stops at headcount can report high coverage while every person on that list has nothing more than a name and a title attached to it. The number looks complete. The account isn't.

Cost and time per engaged account

Definition. Total loaded cost, meaning tool spend plus operator time, divided by accounts that cross a defined engagement threshold (a reply, a meeting, or an equivalent you've defined in advance) within a period.

Formula. Total loaded cost, divided by accounts crossing the engagement threshold.

No dollar figures belong here, because the number only means anything against your own tool stack and your own team's loaded rate, and a number borrowed from someone else's stack won't tell you a thing about yours.

What it tells you. Whether full depth for every account is sustainable. This is the economic governor on the whole approach: without it, "research everything thoroughly" has no ceiling, and spend rises until someone notices.

What breaks under the old metric. Without a cost-per-engaged-account number, the answer to "is this working" ends up being a story about effort. A CFO doesn't want a story. They want a number they can compare quarter over quarter, and this is the one they're asking for, even when what comes out of their mouth is "MQLs."

Signal-to-play latency (candidate metric)

Definition. Time elapsed between signal detection and play execution.

This one comes with a flag: it's a candidate, not an established term. Nobody in the competitive set formalizes it. I'm including it anyway, because signals decay, and latency is a lever an engineered motion can pull that a platform-bought program can't.

Formula. Timestamp of play execution, minus timestamp of signal detection.

What it tells you. How fast the system responds once it sees something worth acting on. A signal-to-play conversion rate can look healthy even while every conversion crawls, and by the time that shows up, the funding round has closed and the hiring spree is over.

What it doesn't tell you. Whether the pace was worth it. Fast and sloppy beats slow and precise on some signals, and loses on others, and this metric alone won't tell you which situation you're in. Track it alongside research-to-meeting yield rather than instead of it, or you'll end up chasing speed on signals that needed the slower, deeper pass.

A platform-bought program can't compete on this axis even if it wanted to, because its own rationing step is the bottleneck: a signal has to clear a scoring threshold and then wait for capacity to free up before anyone acts on it. An engineered motion doesn't have that queue by design, which is why the number only means anything once the allocation problem is already solved.

How the five metrics relate (a loop, not a funnel)

These aren't sequential funnel stages where an account graduates from one and disappears into the next. They're a loop.

Signal detection feeds signal-to-play conversion. Signal-to-play conversion feeds research depth, since an executed play is what triggers full research in the first place. Research depth feeds research-to-meeting yield. Research-to-meeting yield, weighed against cost and time per engaged account, tells you whether the whole cycle earned its keep. That judgment is supposed to feed back into the front of the loop: what counts as a "qualifying signal" this quarter should get retuned based on which signals produced meetings, not left as a fixed rule someone wrote once and never revisited.

Treat these as five independent numbers on a dashboard and you'll end up improving each one locally, in ways that quietly work against each other. Push signal-to-play conversion up by lowering the bar for what counts as a qualifying signal, and research-to-meeting yield drops right along with it, because you're now running full depth on accounts that were never going to convert in the first place. The loop only works if someone owns the whole thing rather than one row of it.

That ownership question is worth being explicit about, because it's tempting to assign each metric to whoever's team throws off the underlying event: marketing owns signal-to-play conversion, ops owns coverage depth, sales owns research-to-meeting yield, finance owns cost per engaged account. Split it up like that and nobody actually sees the whole loop turning, so the retuning step falls through the gap between teams. Someone has to sit above all five rows for the loop to actually close.

What not to carry over from platform-era ABM measurement

Three metrics specifically don't belong on this dashboard, not because they're bad metrics but because they're built to solve a different problem entirely.

MQA was built to solve allocation under scarcity: which of these accounts gets the next touch, given that touches are limited. There's no allocation problem left to solve once every account already gets full depth. So MQA has nothing left to measure.

A generic platform account engagement score is opaque by design: a weighting the platform built and doesn't fully explain, applied uniformly across every customer regardless of what predicts a reply for you. It's a black box that happens to output a number, and a black box you can't defend to a CFO isn't worth reporting to one in the first place.

Target-account-list coverage percentage answers a question that doesn't really exist anymore in this model. Coverage was the constraint back when a platform decided how many accounts you could afford to touch, but here it's a design decision made up front, not a result you're still chasing after the fact.

Where these numbers come from

None of these five metrics require exotic infrastructure. They fall out of three layers that already need to exist for an engineered motion to run at all. And the discipline is making sure each layer logs the events the formulas need, rather than assuming you can reconstruct them later.

A signal-detection layer watches for the events that qualify as signals in the first place, whatever your signal sources happen to be, and timestamps when each one gets detected. A research and enrichment layer does the per-account work (stakeholder mapping, signal-type checks, personalization hooks) and logs completion per field rather than just per account, which is the only way the coverage-depth distribution is computable at all. A play-execution layer marks when outreach starts and tracks what it produces: replies, meetings, whatever engagement threshold you defined for the cost metric.

In practice, this looks like whatever your own tooling is set up to log at each handoff. The specific stack matters a lot less than the discipline behind it: if a layer doesn't emit a timestamped event, the metric that depends on it can't be computed. And you'll find that out at the worst possible moment, which is when someone asks you for the number and you don't have it.

Related reading

This expands on the measurement claims in our ABM guide, specifically its "Measure it like you own the pipeline" step, where signal-to-play conversion, research-to-meeting yield, and cost and time per engaged account all got named for the first time. What's here is the formal, formula-backed version of those three, plus two more.

For the broader argument that an engineered motion is a different animal than platform ABM, start with what GTM engineering is and how it plays out in an enterprise motion. For the mechanics that feed directly into the coverage-depth formula, the buying committee roles breakdown is the companion piece.