Most analytics dashboards are built for marketers. But when your product is a developer toolkit — specifically an AI-powered CMS plugin ecosystem — the people who need analytics most are the developers building those plugins. They need to know: Is anyone using my plugin? Which endpoints are getting hit? Are there error spikes?
AIKit Plugin Analytics Dashboard solves this by giving every plugin author a real-time, privacy-respecting analytics panel built on Cloudflare D1, Workers, and KV — with zero infrastructure overhead. It surfaces install counts, daily active plugin instances, endpoint-level usage heatmaps, error rates, and latency percentiles. And because it runs entirely on Cloudflare's global network, it scales from one plugin to thousands without any database management.
This is not just a tool feature. It is a developer adoption multiplier. When a plugin author can see their work being used — and can diagnose issues before users report them — they stay engaged, iterate faster, and build more plugins. The analytics dashboard directly drives ecosystem retention.
The Problem — plugin devs lack analytics visibility
Building a plugin for AIKit's EmDash CMS means writing Workers-compatible JavaScript or TypeScript that hooks into CMS lifecycle events, content endpoints, and AI generation pipelines. Plugin authors invest significant effort, but until now they have operated in a blind spot.
The core problems:
- **No adoption data**: A plugin could be installed by 10 sites or 10,000 sites. The author has no way to know.
- **No usage patterns**: Which endpoints are hot? Which features are ignored? Without telemetry, plugin authors guess.
- **Error blind spots**: Plugins fail silently in production. Errors surface only when a site owner complains.
- **No retention metrics**: Did installations grow last month? Did active usage drop after an update? Unknown.
- **Fragmented tooling**: Existing analytics are designed for page views — not plugin-level compute metrics.
Plugin authors are developers, not marketers. They need raw data — request counts, error rates, latency percentiles — surfaced in a developer-friendly interface with programmatic API access.
The Solution — D1-based analytics panel
The AIKit Plugin Analytics Dashboard is a dedicated analytics surface embedded in the AIKit developer console. Every registered plugin automatically receives analytics instrumentation via a lightweight Cloudflare Worker middleware layer.
Key capabilities:
- **Live dashboard**: Real-time request volume, latency p50/p95/p99, error rate, and unique plugin instance count in a single-pane glass UI.
- **Endpoint heatmap**: Per-route breakdown of which hooks and endpoints each plugin serves most frequently.
- **Time-series graphs**: Hourly, daily, and weekly aggregation with configurable date ranges.
- **Error explorer**: Stack traces, failing endpoints, and error frequency grouped by error class.
- **Installation telemetry**: Active install count over time, version distribution, geographic breakdown (via Cloudflare colo location).
- **API access**: All dashboard data via REST endpoints for custom tooling or CI/CD dashboards.
The dashboard is built as an AIKit admin panel extension — reusing the existing EmDash CMS admin UI component system, theme, and authentication layer. Plugin authors access it at `/admin/plugins/{slug}/analytics` without any additional setup.
Architecture — Cloudflare Workers + D1 + KV for dedup
The architecture is deliberately minimal. Every piece runs on Cloudflare's edge network with zero persistent servers to manage.
**Data pipeline:**
1. **Instrumentation Middleware (Workers)**: A transparent middleware wraps every plugin endpoint. On each request, it captures method, path, status code, duration, error flag, plugin slug, and a hash of the client's Cloudflare identifier. Metadata is serialized as JSON and sent to a central ingestion endpoint via `fetch()` — non-blocking, fire-and-forget to avoid impacting plugin response times.
2. **Ingestion Worker (Workers)**: Receives analytics events at a dedicated endpoint. Validates the plugin slug is registered, and rate-limits to 100 events/second per plugin instance. Validated events are batched in-memory for up to 5 seconds or 100 events (whichever comes first) and bulk-inserted into D1.
3. **Deduplication (KV)**: Duplicate events — from retries or network hiccups — are caught using Cloudflare KV with a 60-second TTL. Each event carries a unique `event_id` (UUID v4). Before insertion, the Worker checks KV for that ID. If present, the event is dropped. This keeps data clean without expensive database-side dedup queries.
4. **Storage (D1)**: Cloudflare D1 stores events in a time-partitioned table:
```sql
CREATE TABLE analytics_events (
event_id TEXT PRIMARY KEY,
plugin_slug TEXT NOT NULL,
timestamp INTEGER NOT NULL,
method TEXT,
path TEXT,
status INTEGER,
duration_ms REAL,
is_error INTEGER DEFAULT 0,
error_message TEXT,
instance_hash TEXT,
cf_colo TEXT
);
CREATE INDEX idx_plugin_ts ON analytics_events(plugin_slug, timestamp);
CREATE INDEX idx_plugin_error ON analytics_events(plugin_slug, is_error, timestamp);
```
5. **Aggregation Layer (Workers + D1)**: Dashboard queries never scan raw events. Hourly cron jobs roll up raw events into pre-aggregated tables:
```sql
CREATE TABLE analytics_hourly (
plugin_slug TEXT NOT NULL,
hour INTEGER NOT NULL,
request_count INTEGER,
error_count INTEGER,
avg_duration_ms REAL,
p50_duration_ms REAL,
p95_duration_ms REAL,
p99_duration_ms REAL,
unique_instances INTEGER,
endpoint_breakdown TEXT,
PRIMARY KEY (plugin_slug, hour)
);
```
This gives sub-100ms dashboard queries regardless of raw event volume.
Implementation — SQL queries, chart endpoints, caching
The dashboard backend exposes five key endpoints, each backed by a parameterized D1 query with aggressive HTTP caching.
**Overview endpoint** (`GET /api/plugins/{slug}/analytics/overview`):
```sql
SELECT
COALESCE(SUM(request_count), 0) AS total_requests,
COALESCE(AVG(avg_duration_ms), 0) AS avg_latency,
COALESCE(SUM(error_count), 0) AS total_errors,
COALESCE(MAX(unique_instances), 0) AS peak_instances
FROM analytics_hourly
WHERE plugin_slug = ?
AND hour >= ?
AND hour <= ?;
```
**Time-series endpoint** (`GET /api/plugins/{slug}/analytics/timeseries`):
```sql
SELECT hour, request_count, error_count, avg_duration_ms, unique_instances
FROM analytics_hourly
WHERE plugin_slug = ? AND hour >= ? AND hour <= ?
ORDER BY hour ASC;
```
**Endpoint breakdown** (`GET /api/plugins/{slug}/analytics/endpoints`):
```sql
SELECT hour, endpoint_breakdown
FROM analytics_hourly
WHERE plugin_slug = ? AND hour >= ?
ORDER BY hour DESC LIMIT 24;
```
**Cache strategy**: The overview endpoint uses a 60-second `Cache-Control: public, max-age=60` header. Timeseries uses 300 seconds. Safe because data is only as recent as the last hourly rollup (minute 5 of each hour).
**Frontend rendering**: The dashboard UI is built with Preact (shipped as a single JS bundle via Cloudflare Pages) and renders charts using a lightweight Canvas-based library — no heavy dependencies. The theme matches EmDash CMS's design system.
**Rate-limited ingestion** at the Worker level:
```
const RATE_LIMIT = 100; // events/second per plugin instance
async function checkRateLimit(pluginSlug, instanceHash) {
const key = `ratelimit:${pluginSlug}:${instanceHash}`;
const current = await env.KV.get(key);
const count = current ? parseInt(current, 10) : 0;
if (count >= RATE_LIMIT) return false;
await env.KV.put(key, String(count + 1), { expirationTtl: 2 });
return true;
}
```
Results — developer retention metrics, adoption
Since shipping the Plugin Analytics Dashboard in v2.4.0, AIKit's plugin ecosystem has seen measurable improvements:
- **42% increase in weekly active plugin developers**: Authors check the dashboard an average of 3.2 times per week.
- **28% reduction in average bug-fix cycle time**: With error explorer data, authors identify and patch issues 2.3 days faster.
- **34% cite analytics as the #1 reason they continue developing**: Surveyed authors ranked the dashboard above documentation, SDK quality, and community support.
- **18 new plugins published in the first 60 days**: Directly attributed to the feedback loop from usage visibility.
- **Zero infrastructure cost**: The entire pipeline — Workers, D1, KV, Cron Triggers, Pages — runs within Cloudflare's free tier at the current scale of ~1,200 active plugin instances.
Equally important, the dashboard has become a marketing asset. Plugin listings now display badges like "Used by 47 sites" or "99.2% uptime" — sourced directly from analytics data. This creates a virtuous cycle: visible adoption drives more adoption.
Key Takeaways
1. **Developer-facing analytics is a retention engine**: When plugin authors see their impact, they build more. The dashboard transformed AIKit's ecosystem from a "submit and forget" model into an engaged, iterative community.
2. **Cloudflare D1 is production-ready for analytics pipelines**: With careful schema design and pre-aggregation via cron, D1 handles analytics workloads efficiently. Never query raw event tables — always query pre-rolled summaries.
3. **KV-based deduplication is simpler than database dedup**: Using KV as a short-lived bloom filter for event IDs avoids expensive `ON CONFLICT` patterns at write-heavy ingestion.
4. **Cache aggressively, aggregate hourly**: Hourly rollups with client-side caching give a "real-time enough" feel while keeping database costs near zero.
5. **Build tools that market themselves**: Public adoption badges — powered by the same analytics pipeline — turned an engineering investment into a direct marketing channel. When planning developer tools, always ask: "Can this feature also sell itself?"
The AIKit Plugin Analytics Dashboard is open-source and available as a reference architecture. Clone it, deploy it on your own Cloudflare account, and give every plugin author the visibility they deserve.