How to build Findymail deliverability dashboards in Metabase

{
  "mcpServers": {
    "findymail": {
      "url": "https://your-gumloop-server-url/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 a Findymail CSV export — creates a table AND a model
mb upload csv --file findymail-contacts.csv --collection root

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

Create a polished Metabase dashboard for Findymail lead-finding analytics.
Work end to end: get the data into Metabase if it isn't there yet, then build.

Goal: Help RevOps and deliverability teams understand match rate, verification
quality, credit usage, and list quality from Findymail data.

Step 1 — Find or load the data:
- First, check what already exists in Metabase (search for Findymail tables and
  models). If durable Findymail 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 Findymail MCP server: searches (finder
  requests), found contacts, verifications (valid/risky/invalid/catch-all),
  lists, and credit/usage events. 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:
Findymail CSV exports are usually flat (one row per found contact, with an email,
verification status, and credits used). Warehouse tables are rawer, often with a
separate searches table and a per-verification row. Inspect the actual tables and
column names first; do not assume exact names or that a searches table exists.

Important:
- Build on whatever data is present; don't claim Metabase connects natively to
  Findymail — it reads a database or CLI-uploaded tables.
- Define match rate as found ÷ searched, and verified/safe-to-send share as
  valid ÷ verified — keep them distinct.
- Treat catch-all separately from valid; it is not a guarantee of deliverability.
- Report credits with a denominator (per usable contact) visible.
- 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: Findymail Deliverability Overview

Sections:
1. Executive summary (KPI cards): Match rate; Valid email share; Catch-all rate;
   Credits used; Credits per usable contact; Usable contacts added.
2. Match rate: By search type; found vs. not found; by domain size.
3. Verification: Valid vs. risky vs. invalid; safe-to-send by list; catch-all.
4. Credits: By week; per usable contact; wasted credits.
5. List quality: Usable contacts added; duplicates vs. CRM; ICP fit.

Filters: Search type, List, Date range.

Reuse the models Metabase auto-created from uploaded CSVs, or (for a warehouse)
create reusable models: modeled_findymail_searches, modeled_findymail_contacts,
modeled_findymail_verifications, and modeled_findymail_credit_events.

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
Findymail's own usage views. Keep it practical, dense, and executive-readable.

Found as a share of searches over the last 90 days.

-- Match rate by search type over the last 90 days
SELECT
  s.search_type,
  COUNT(*)                                             AS searches,
  COUNT(*) FILTER (WHERE s.found)                      AS found,
  ROUND(100.0 * COUNT(*) FILTER (WHERE s.found)
    / NULLIF(COUNT(*), 0), 1)                          AS match_rate_pct
FROM modeled_findymail_searches s
WHERE s.searched_at >= CURRENT_DATE - INTERVAL '90 days'
GROUP BY s.search_type
ORDER BY searches DESC;

Valid, catch-all, and invalid share per list.

-- Verification breakdown by list
SELECT
  c.list_name,
  COUNT(*)                                              AS emails,
  ROUND(100.0 * COUNT(*) FILTER (WHERE v.status = 'valid')
    / NULLIF(COUNT(*), 0), 1)                           AS valid_pct,
  ROUND(100.0 * COUNT(*) FILTER (WHERE v.status = 'catch_all')
    / NULLIF(COUNT(*), 0), 1)                           AS catch_all_pct,
  ROUND(100.0 * COUNT(*) FILTER (WHERE v.status = 'invalid')
    / NULLIF(COUNT(*), 0), 1)                           AS invalid_pct
FROM modeled_findymail_contacts c
JOIN modeled_findymail_verifications v ON v.contact_id = c.id
GROUP BY c.list_name
ORDER BY emails DESC;

Cost efficiency by week, using valid emails as the usable base.

-- Credits per usable contact by week
SELECT
  date_trunc('week', e.used_at) AS week,
  SUM(e.credits)                AS credits_used,
  COUNT(DISTINCT c.id) FILTER (WHERE v.status = 'valid') AS usable_contacts,
  ROUND(SUM(e.credits)::numeric
    / NULLIF(COUNT(DISTINCT c.id) FILTER (WHERE v.status = 'valid'), 0), 2)
    AS credits_per_usable_contact
FROM modeled_findymail_credit_events e
LEFT JOIN modeled_findymail_contacts c      ON c.id = e.contact_id
LEFT JOIN modeled_findymail_verifications v ON v.contact_id = c.id
GROUP BY 1
ORDER BY 1;