Metric

What is reply rate, and how do you measure it in Metabase?

Reply rate is the share of contacted prospects who reply to your outbound. It's the headline efficiency metric for a sales-engagement motion — but it's only meaningful once you fix what counts as "contacted" and what counts as a "reply." Measure it in Metabase from engagement data synced into a database (Outreach, Salesloft, Apollo, Mixmax, and others).

TL;DR — Reply rate = replied ÷ contacted. Decide whether a person is the unit (person replied) or a message is (messages replied), exclude auto-replies and out-of-office, and segment by sequence.

How is reply rate defined?

The formula is simple; the definitions of numerator and denominator are where teams disagree:

  • Replied ÷ contacted (per person) — of the people you reached, how many replied at least once. The most common and most stable.
  • Replies ÷ messages sent — of all messages sent, how many drew a reply. Useful for step-level tuning, but sensitive to volume.

Both are valid. What breaks reporting is switching between them, or counting auto-replies as genuine replies.

Choosing and holding a cohort

A reply rate is meaningless without a cohort. Group by first-contacted date (people first reached in the period) and give recent cohorts time to reply before you judge them — a person contacted yesterday hasn't had a chance to respond.

  • Positive reply rate answers "how many replies were interested?" — needs reply sentiment or manual tagging.
  • Raw reply rate answers "how many replied at all?" — easier to compute, but includes objections and opt-outs.

What data does reply rate need?

  • A membership or activity table with a clear first-contacted timestamp.
  • A replied_at timestamp or reply event per person.
  • A rule for excluding auto-replies and out-of-office from genuine replies.
  • Segmentation columns: sequence, rep, segment, and step.

SQL patterns

Reply rate by month (per person)PostgreSQL
SELECT
  date_trunc('month', m.first_contacted_at) AS month,
  COUNT(*)                                          AS contacted,
  COUNT(*) FILTER (WHERE m.replied_at IS NOT NULL)  AS replied,
  ROUND(
    100.0 * COUNT(*) FILTER (WHERE m.replied_at IS NOT NULL)
      / NULLIF(COUNT(*), 0),
    2
  ) AS reply_rate_pct
FROM modeled_sequence_memberships m
WHERE m.first_contacted_at >= CURRENT_DATE - INTERVAL '12 months'
GROUP BY 1
ORDER BY 1;
Reply rate by sequencePostgreSQL
SELECT
  s.name AS sequence,
  COUNT(*)                                          AS contacted,
  COUNT(*) FILTER (WHERE m.replied_at IS NOT NULL)  AS replied,
  ROUND(
    100.0 * COUNT(*) FILTER (WHERE m.replied_at IS NOT NULL)
      / NULLIF(COUNT(*), 0),
    2
  ) AS reply_rate_pct
FROM modeled_sequence_memberships m
JOIN modeled_sequences s ON s.id = m.sequence_id
GROUP BY s.name
ORDER BY contacted DESC;

Pitfalls

Counting auto-replies as replies.→ Out-of-office and bounce auto-responses inflate reply rate. Filter them out or tag them separately.
Mixing person-level and message-level rates.→ Replies ÷ messages and people replied ÷ people contacted are different metrics — label the one you're showing.
Judging incomplete cohorts.→ People contacted this week haven't had time to reply; recent cohorts look artificially low until they mature.
Ignoring reply quality.→ A high reply rate full of "not interested" isn't a win. Track positive replies where you can.

Where this metric applies

Analytics

Metrics

FAQ

Should I measure reply rate per person or per message?
Per person (people replied ÷ people contacted) is the more stable operational metric. Per message is better for step-level tuning but is sensitive to volume. Pick one per chart and label it.
Do auto-replies count?
No. Out-of-office and system auto-responses aren't genuine engagement — filter them out, or at least tag them so they don't inflate the rate.
What's a good reply rate?
It varies widely by channel, list quality, and segment, so benchmark against your own trend rather than an absolute number. Read reply rate alongside meetings booked and bounce rate.