How to build Segment dashboards in Metabase

# Daily event volume by source over a 30-day window (Public API).
# Set the window as ISO-8601 UTC timestamps. To compute them:
#   GNU/Linux:  START_TIME=$(date -u -d '30 days ago' +%Y-%m-%dT00:00:00Z)
#   macOS/BSD:  START_TIME=$(date -u -v-30d +%Y-%m-%dT00:00:00Z)
START_TIME="2026-06-01T00:00:00Z"
END_TIME="2026-07-01T00:00:00Z"
curl "https://api.segmentapis.com/events/volume?granularity=DAY&groupBy=source&startTime=$START_TIME&endTime=$END_TIME" \
  -H "Authorization: Bearer $SEGMENT_PUBLIC_API_TOKEN" > segment-volume.json

# Flatten the JSON to CSV (jq, or a few lines of Python),
# then load it into Metabase
mb upload csv --file segment-event-volume.csv --collection root

# 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 source-event-volume export — creates a table AND a model
mb upload csv --file segment-source-event-volume.csv --collection root

# Refresh that same table later from a new export
mb upload replace <table-id> --file segment-source-event-volume.csv

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

Goal: Help marketing and growth leaders understand event volume, sync reliability, identity resolution, and whether downstream tools receive fresh data from Segment data.

Step 1 — Find or load the data:
- First, check what already exists in Metabase (search for segment tables and
  models). If durable Segment data is already present — synced from a warehouse
  or uploaded earlier — use it and skip to Step 2.
- If nothing is there, pull a scoped, summarized export from the Segment Public API (write and run a short export script):
  source event volume, plus sources, destinations, warehouse syncs.
  Prefer daily aggregates over raw 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:
Do not assume exact table or column names. Inspect available fields, channels,
campaigns, dates, and whether daily history exists before creating trend or
pacing cards.

Important:
- Build on whatever data is present; don't claim Metabase connects natively to
  Segment — it reads a database or CLI-uploaded tables.
- Never try to load raw event or click streams into Metabase; use daily
  aggregates, campaign-grain stats, and entity tables.
- Only compute rates (CTR, conversion rate, ROAS, CAC) when both numerator and
  denominator exist — and state the attribution model when reporting conversions.
- Exclude test campaigns and internal traffic from headline cards, and keep
  currency consistent when spend spans accounts.
- 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: Segment Customer Data Overview

Sections:
1. Executive summary: Events last 7 days; Sync success rate; Stale
   destinations; Identified profile share.
2. Pipeline: Sync success rate and failed runs by destination; latency trend.
3. Volume: Events by source by day; anomalies vs. trailing average.
4. Quality: Schema violations, blocked events, and new event names.
5. Audiences: Sizes over time; sync freshness; rows delivered to activation tools.

Filters: Date range, Channel, Campaign, Country, Device, Segment.

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.

The pipeline-reliability headline from sync run logs.

SELECT
  destination,
  date_trunc('week', run_started_at) AS week,
  COUNT(*) AS runs,
  COUNT(*) FILTER (WHERE status = 'success') AS successful_runs,
  ROUND(
    100.0 * COUNT(*) FILTER (WHERE status = 'success')
    / NULLIF(COUNT(*), 0), 2
  ) AS success_rate_pct,
  SUM(rows_synced) AS rows_synced
FROM cdp_sync_runs
GROUP BY 1, 2
ORDER BY 1, 2;

Catches silent tracking breakages and double-firing.

WITH daily AS (
  SELECT source, event_date, SUM(event_count) AS events
  FROM event_volume_daily
  GROUP BY 1, 2
)
SELECT
  source,
  event_date,
  events,
  ROUND(AVG(events) OVER (
    PARTITION BY source
    ORDER BY event_date
    ROWS BETWEEN 28 PRECEDING AND 1 PRECEDING
  )) AS trailing_28d_avg,
  ROUND(100.0 * events / NULLIF(AVG(events) OVER (
    PARTITION BY source
    ORDER BY event_date
    ROWS BETWEEN 28 PRECEDING AND 1 PRECEDING
  ), 0) - 100, 1) AS pct_vs_trailing
FROM daily
ORDER BY source, event_date DESC;

Freshness check for every downstream tool.

SELECT
  destination,
  MAX(run_finished_at) FILTER (WHERE status = 'success' AND COALESCE(rows_synced, 0) > 0)
    AS last_successful_sync,
  ROUND(EXTRACT(EPOCH FROM (
    NOW() - MAX(run_finished_at) FILTER (WHERE status = 'success' AND COALESCE(rows_synced, 0) > 0)
  )) / 3600, 1) AS hours_since_success
FROM cdp_sync_runs
GROUP BY destination
HAVING MAX(run_finished_at) FILTER (WHERE status = 'success' AND COALESCE(rows_synced, 0) > 0)
  < NOW() - INTERVAL '24 hours'
ORDER BY hours_since_success DESC;