How to build Apollo.io prospecting dashboards in Metabase

{
  "mcpServers": {
    "apollo": {
      "url": "https://mcp.apollo.io/mcp"
    }
  }
}

# Install the Metabase CLI
npm install -g @metabase/cli

# Log in (opens your browser; requires Metabase v62+)
mb auth login --url https://your-metabase.example.com

# Load an Apollo CSV export — creates a table AND a model
mb upload csv --file apollo-sequences.csv --collection root

# Refresh that same table later from a new export
mb upload replace <table-id> --file apollo-sequences.csv

Create a polished Metabase dashboard for Apollo.io prospecting analytics.
Work end to end: get the data into Metabase if it isn't there yet, then build.

Goal: Help SDR leaders understand the prospecting funnel, sequence performance,
data quality, and rep activity from Apollo.io data.

Step 1 — Find or load the data:
- First, check what already exists in Metabase (search for Apollo tables and
  models). If durable Apollo data is already present — synced from a warehouse or
  uploaded earlier — use it and skip to Step 2.
- If nothing is there, pull it with the Apollo MCP server: contacts, accounts,
  sequences and steps, email events (sent/delivered/opened/replied/bounced),
  calls, and tasks. Write each result to a CSV, then load it with the Metabase
  CLI — run "mb upload csv --file <export>.csv" so each upload creates a table and
  a ready-to-query model. Use "mb upload replace <table-id> --file <export>.csv"
  to refresh an existing table instead of creating duplicates.

Step 2 — Inspect before querying:
Apollo CSV exports are usually flat and pre-aggregated (one row per contact or
sequence, with columns like reply rate, bounce rate, and meetings booked).
Warehouse tables are raw and event-grained (an email-events table with sent,
delivered, opened, replied, and bounced timestamps). Inspect the actual tables
and column names first; do not assume exact names or that an event-level table
exists.

Important:
- Build on whatever data is present; don't claim Metabase connects natively to
  Apollo — it reads a database or CLI-uploaded tables.
- If the data already provides rates, chart them directly; only recompute open
  and reply rates over the delivered (not sent) base when raw counts are
  available, and track bounce rate separately.
- Count a "meeting booked" from a consistent signal (meeting task, calendar
  event, or reply classified as positive) and state which one.
- Report rates with their denominators visible; small sequences look noisy.
- Only build a card if its underlying column/metric exists in the data.
- A single CSV is a point-in-time snapshot: only build trend cards if there is a
  usable date column or multiple periods have been uploaded.

Dashboard title: Apollo Prospecting Overview

Sections:
1. Executive summary (KPI cards): Contacts enrolled; Reply rate; Meetings booked;
   Bounce rate; Enrichment coverage; Credits per meeting.
2. Funnel: Enrolled → contacted → replied → meeting; conversion by segment.
3. Sequences: Open and reply rate by sequence; reply rate by step; bounce rate.
4. Data quality: Enrichment coverage by field; verified vs. risky emails;
   duplicates vs. CRM.
5. Activity: Emails and calls by rep; tasks completed; accounts touched.

Filters: Sequence, Rep, Segment, Date range.

Reuse the models Metabase auto-created from uploaded CSVs, or (for a warehouse)
create reusable models: modeled_apollo_contacts, modeled_apollo_sequences,
modeled_apollo_email_events, modeled_apollo_calls, and modeled_apollo_tasks.

Output: Build the dashboard if you have permission; otherwise provide the exact
questions, SQL, model definitions, and layout. Include caveats for any metric
that cannot be calculated from the available data. Reconcile totals against
Apollo's own analytics. Keep it practical, dense, and executive-readable.

Enrolled → contacted → replied → meeting over the last 90 days.

-- Prospecting funnel over the last 90 days
SELECT
  COUNT(DISTINCT c.id)                                          AS enrolled,
  COUNT(DISTINCT e.contact_id) FILTER (WHERE e.status <> 'bounced') AS contacted,
  COUNT(DISTINCT e.contact_id) FILTER (WHERE e.replied_at IS NOT NULL) AS replied,
  COUNT(DISTINCT m.contact_id)                                  AS meetings_booked
FROM modeled_apollo_contacts c
LEFT JOIN modeled_apollo_email_events e ON e.contact_id = c.id
LEFT JOIN modeled_apollo_meetings m     ON m.contact_id = c.id
WHERE c.enrolled_at >= CURRENT_DATE - INTERVAL '90 days';

Both based on delivered emails, so bounces don't distort them.

-- Open and reply rate by sequence (delivered as the base)
SELECT
  s.name AS sequence,
  COUNT(*) FILTER (WHERE e.status <> 'bounced')            AS delivered,
  ROUND(100.0 * COUNT(*) FILTER (WHERE e.opened_at IS NOT NULL)
    / NULLIF(COUNT(*) FILTER (WHERE e.status <> 'bounced'), 0), 1) AS open_rate_pct,
  ROUND(100.0 * COUNT(*) FILTER (WHERE e.replied_at IS NOT NULL)
    / NULLIF(COUNT(*) FILTER (WHERE e.status <> 'bounced'), 0), 1) AS reply_rate_pct
FROM modeled_apollo_email_events e
JOIN modeled_apollo_sequences s ON s.id = e.sequence_id
WHERE e.sent_at >= CURRENT_DATE - INTERVAL '90 days'
GROUP BY s.name
ORDER BY delivered DESC;

Share of contacts with an email, phone, and title.

-- Enrichment coverage by field
SELECT
  COUNT(*)                                             AS contacts,
  ROUND(100.0 * COUNT(email) / COUNT(*), 1)            AS pct_with_email,
  ROUND(100.0 * COUNT(phone) / COUNT(*), 1)            AS pct_with_phone,
  ROUND(100.0 * COUNT(title) / COUNT(*), 1)            AS pct_with_title
FROM modeled_apollo_contacts;