Analytics and telemetry are not the same thing, even though plugin developers use the terms interchangeably. Telemetry tells you that a crash happened; analytics tells you why nobody uses the feature that caused it. If you only build one of these into your plugin, you’ll eventually need the other — and retrofitting tracking into a plugin with an established user base is a much bigger job than adding it during initial development.
This post ranks five approaches to adding analytics tracking to a Figma plugin, from the simplest to the most involved, and weighs what each one actually tells you against what it costs to set up and maintain.
A Quick Note on the Constraint You Can’t Design Around
Figma plugins run inside a sandboxed iframe with no direct access to localStorage, fetch restrictions that vary by context, and a strict separation between the plugin’s main thread (which touches the Figma document) and the UI thread (which can talk to the network). Every approach below has to route data through figma.ui.postMessage and an <iframe> that makes the actual network request, because the main sandbox can’t call external APIs directly in most plugin architectures.
This constraint shapes every option on this list. It’s worth understanding once, up front, rather than rediscovering it separately for each tool.
5. Manual console.log and Local Testing
What it is: Logging events to the console during development and checking them manually, with no persistent storage or aggregation.
What it tells you: Whether an event fires at the right time, during development. Nothing about real usage patterns once the plugin ships.
Setup cost: Essentially none.
This isn’t really analytics — it’s debugging — but it earns a spot on this list because too many plugins ship with this as the only instrumentation in place, and the gap only becomes obvious after launch, when there’s no data to explain a sudden drop in usage or a support ticket about a feature nobody remembers building. If this is where your plugin currently sits, treat it as a starting point rather than a finish line.
Best for: Pre-launch development. Nothing further along than that.
4. A Custom Endpoint with a Lightweight Backend
What it is: Standing up your own API endpoint — a serverless function on Vercel or Cloudflare Workers works fine — that receives event payloads from your plugin’s UI thread and writes them to a database.
What it tells you: Exactly what you decide to log. Custom endpoints give full control over event schema, so you can capture plugin-specific actions (a particular tool used, a specific export format chosen) that generic analytics platforms weren’t built to model out of the box.
Setup cost: Moderate to high. You’re maintaining infrastructure, not just adding a script tag.
The tradeoff here is ownership versus effort. Nothing about your event schema is dictated by a third party’s dashboard conventions, which matters if your plugin has usage patterns that don’t map cleanly onto generic “page view” or “click” metrics. But you’re also now responsible for uptime, for handling malformed payloads, and for building your own reporting layer on top of raw event data — work that a hosted analytics tool would otherwise do for you.
// ui.html — inside the plugin's UI iframe
fetch('https://your-endpoint.workers.dev/track', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
event: 'export_completed',
format: 'svg',
timestamp: Date.now()
})
});
Best for: Teams with backend experience who need event schemas that off-the-shelf tools don’t naturally support.
3. A Hosted Analytics Platform (Mixpanel, PostHog, Amplitude)
What it is: Sending event data to a third-party analytics platform via its SDK or REST API, called from the plugin’s UI thread.
What it tells you: Funnels, retention curves, feature adoption over time, and cohort comparisons — the kind of analysis that would take real engineering effort to build from scratch on top of a custom endpoint.
Setup cost: Low to moderate. Most of these platforms offer a simple HTTP tracking API that doesn’t require their full client-side SDK, which matters because heavier SDKs can behave unpredictably inside a sandboxed iframe.
This is where most plugins that outgrow console logging end up, and for good reason. The dashboarding and segmentation work is already built, which frees up development time for the plugin itself rather than a homegrown reporting tool. The main thing to get right is initialization: call the platform’s HTTP tracking endpoint directly from ui.html rather than trying to load a full SDK bundle, since Figma’s iframe sandbox and Content Security Policy can block scripts that assume a normal browser environment.
// ui.html — using PostHog's simple HTTP API, no SDK needed
fetch('https://app.posthog.com/capture/', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
api_key: 'YOUR_PROJECT_API_KEY',
event: 'plugin_opened',
properties: { distinct_id: userId },
})
});
Best for: Plugins with enough users to justify wanting cohort and retention data, but without the resources to build custom infrastructure.
2. Figma’s Own Plugin Analytics (For Community Plugins)
What it is: The built-in analytics dashboard Figma provides for plugins published to the Community, covering install counts, run counts, and basic usage trends — no code required.
What it tells you: High-level adoption numbers. How many people installed the plugin, how often it’s being run, and broad trend lines over time.
Setup cost: None. It’s automatic for any published Community plugin.
The obvious limitation is granularity. Figma’s dashboard won’t tell you which specific feature inside your plugin gets used, whether users complete a multi-step workflow, or where they drop off. It answers “is this plugin being used” but not “how is it being used” — which is a meaningful gap for any plugin complex enough to have more than one primary action. Still, for a first signal on whether a plugin has found an audience at all, this costs nothing and requires no additional decisions.
Best for: A baseline check on adoption before investing in custom event tracking.
1. A Layered Approach: Figma’s Dashboard Plus Custom Events
What it is: Using Figma’s native analytics as a top-level adoption signal, combined with a hosted analytics platform (or custom endpoint) for granular, feature-level event tracking inside the plugin itself.
What it tells you: Both halves of the picture — whether people are installing and returning to the plugin, and what they’re actually doing once they open it. Install counts alone can’t explain a retention drop; event-level data alone can’t tell you how that behavior compares to the plugin’s overall reach.
Setup cost: Moderate. This is really options 2 and 3 run together rather than a new technique, which is what makes it practical rather than an additional burden.
This ranks first because the two data sources answer different questions, and relying on just one leaves a blind spot that eventually costs more time to diagnose than the combined setup would have taken upfront. A plugin with declining installs but strong event-level engagement among existing users has a discovery problem, not a retention problem — and that distinction changes what you fix first. Without both layers, that distinction is invisible.
// code.ts — main thread relays events to the UI for tracking
figma.ui.postMessage({ type: 'log-event', event: 'component_inserted' });
// ui.html — UI thread forwards to the analytics platform
window.onmessage = (e) => {
if (e.data.pluginMessage?.type === 'log-event') {
fetch('https://app.posthog.com/capture/', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
api_key: 'YOUR_PROJECT_API_KEY',
event: e.data.pluginMessage.event,
})
});
}
};
Best for: Any plugin past the early prototype stage that has real users and a roadmap decision riding on usage data.
What About Privacy?
Every option above that leaves the plugin sandbox involves sending data over the network, and that comes with obligations regardless of which platform you choose. Figma’s plugin guidelines require disclosure of data collection in your plugin’s description, and depending on what you’re logging — user IDs, file names, document content — you may need to think about GDPR compliance if your user base includes anyone in the EU. The safest default is to track behavioral events (which feature was used, how often) and avoid capturing document content or personally identifying details unless there’s a specific, disclosed reason to do so.
Ranked Comparison at a Glance
| Rank | Approach | Setup Cost | What It Reveals |
|---|---|---|---|
| 5 | Console logging | None | Debugging only, no post-launch data |
| 4 | Custom endpoint | Moderate–High | Full schema control, no built-in reporting |
| 3 | Hosted analytics platform | Low–Moderate | Funnels, retention, feature adoption |
| 2 | Figma’s native dashboard | None | Install and run counts, no granularity |
| 1 | Layered (native + custom events) | Moderate | Full picture: adoption and behavior together |
Where you land on this list should depend on your plugin’s current stage, not on which tool sounds most sophisticated. A plugin with a dozen users doesn’t need a layered setup with a custom backend — but a plugin with a genuine feature roadmap and a growing user base will eventually feel the limits of Figma’s dashboard alone. Which rung of this list matches where your plugin is right now?