How to use PostHog plugins to enrich analytics data

If you’re using analytics but finding your data a little underwhelming or messy, you’re not alone. Most out-of-the-box analytics tools spit out raw data that needs a lot of cleaning up—or just plain more context—before it’s actually useful. That’s where PostHog plugins come in. If you’re a product manager, developer, or anyone tasked with making sense of product data, this guide is for you. You’ll learn how to use plugins to enrich your analytics, avoid common pitfalls, and skip the hype.

What Are PostHog Plugins, Really?

PostHog is an open-source product analytics suite. Out of the box, it tracks events, users, and funnels. But real-world data is rarely neat or complete. PostHog plugins let you process, transform, and enrich incoming data before it lands in your dashboard.

Think of plugins as “middleware” for your analytics: you can clean up dirty properties, tag users with extra info, call external APIs, or even send data elsewhere. Unlike most integrations, plugins run inside your PostHog instance—no need to set up a separate ETL pipeline or write brittle scripts.

But just because you can run code on every event doesn’t mean you should go wild. Plugins are powerful, but they have real trade-offs. More on that soon.

Why Would You Enrich Analytics Data?

Let’s get specific. Here are a few reasons you might want to enrich analytics data:

  • Add context: Attach geo-location, company info, or device details to events.
  • Clean up data: Standardize inconsistent property names, fix typos, or drop junk events.
  • Enhance privacy: Strip out sensitive data before it’s stored.
  • Integrate with other tools: Enrich events with info from your CRM or support system.

If you’ve ever stared at a dashboard and thought, “This doesn’t tell me nearly enough,” enrichment is what you’re missing.

When Should You Use Plugins? (And When Shouldn’t You?)

When plugins shine: - Small to medium data volumes (think tens or hundreds of thousands of events per day, not tens of millions). - Quick fixes: cleaning up, tagging, or minor enrichments. - When you want to keep logic close to your analytics—without extra infrastructure.

When they don’t: - Heavy-duty ETL or anything that needs to call slow external APIs on every event. Plugins can slow ingestion and jack up your PostHog compute costs. - Anything requiring complex state, long-term storage, or heavy computation. - When you’re already using a proper ETL/data warehouse pipeline—don’t try to bolt on critical business logic at the analytics layer.

Pro tip: Plugins are not a replacement for good client-side or backend tracking. Fix what you can at the source, and use plugins for what you can’t.

Step 1: Review Your Data (And Your Pain Points)

Before you even touch plugins, look at your existing events and properties. Ask:

  • Are user properties missing or inconsistent?
  • Do you have “dirty” data from different sources or teams?
  • Is there context you wish you had, like user plan, company size, or device details?
  • Are there junk events cluttering things up?

Don’t start with plugins. Start with a list of what you want to fix or add. This avoids the “solution looking for a problem” trap.

Step 2: Explore the Plugin Library

PostHog ships with a plugin library that covers a lot of common use cases. Here’s how to check it out:

  1. Head to the Plugins section: In your PostHog instance, go to the “Plugins” tab in the sidebar.
  2. Browse the library: You’ll see both official and community plugins. Popular ones include:
  3. GeoIP (adds location data to events)
  4. Enrich by Clearbit (adds company/person data via Clearbit)
  5. Sentry integration (links errors to PostHog events)

If you see a plugin that matches your use case, great. Check: - When it was last updated (abandoned plugins are a red flag) - How many people use it - Whether you trust the data source (especially with “enrichment” plugins that call third-party APIs)

Honest take: Most people use 1–2 plugins, max. Don’t install everything that looks shiny.

Step 3: Install and Configure a Plugin

Let’s walk through installing a plugin step by step. We’ll use the GeoIP plugin as an example—it’s a safe, useful default.

  1. Click “Install” next to the plugin in the library.
  2. Configure options: Most plugins let you tweak settings (e.g., which properties to add, API keys if needed).
  3. Enable the plugin: Toggle it on. You can run it on all events or just specific ones.

Pro tip: Always test plugins on a staging or test project first. Some plugins will modify all incoming data, and there’s no “undo” button.

What’s Happening Under the Hood?

Plugins in PostHog run small bits of JavaScript (or TypeScript) on every event as it comes in. They can: - Read/modify event properties - Make external API calls (careful: this slows things down!) - Drop events or create new ones

You can see the source code for any plugin—don’t be afraid to peek inside if you’re curious or worried about what it’s doing.

Step 4: Write a Custom Plugin (When the Library Isn’t Enough)

Can’t find what you need? You can write your own plugin. Here’s how:

  1. In the Plugins tab, click “New Plugin.”
  2. Choose “Create locally.” You’ll get a code editor right in the browser.
  3. Write your JavaScript logic.

Here’s a basic template that adds a “company_domain” property to every event, based on the user’s email:

js export function processEvent(event, { cache, global }) { const email = event.properties?.$email if (email && email.includes('@')) { event.properties.company_domain = email.split('@')[1] } return event }

  • processEvent: Runs on every incoming event.
  • You can do more (call APIs, set properties, drop events), but keep it simple.

Pitfalls to avoid: - Don’t call slow APIs unless you really need to. It bottlenecks everything. - Remember: any bug here can break all your data. Test thoroughly. - If you need to store API keys or secrets, use plugin “secrets,” not hardcoded strings.

Pro tip: Start with a fork of an existing plugin if you’re new to this.

Step 5: Monitor, Test, and Iterate

Once a plugin is live, watch how it behaves:

  • Use the “Logs” and “Metrics” tabs for plugins to see if there are errors or slowdowns.
  • Check random events in your dashboard—do you see the new/enriched properties?
  • If you’re using a third-party enrichment API, keep an eye on your quota and possible costs.

If things break, it’s better to disable the plugin and investigate than to let bad data pile up.

What Works, What Doesn’t, and What to Skip

What works well: - Adding simple, derived properties (like device type, company domain, or cleaned-up names). - Tagging or filtering out junk events. - Integrating with reliable, fast enrichment APIs (GeoIP, etc.).

What doesn’t: - Making slow HTTP calls on every event—your data pipeline grinds to a halt. - Writing complex logic that should really live in your app, not your analytics tool. - Using plugins as a crutch for bad tracking elsewhere. Garbage in, garbage out.

What to skip: - Plugins that haven’t been updated in ages, or have zero users. - Plugins that ask for more permissions or API access than they reasonably need.

Pro tip: Less is more. The more plugins you chain together, the more things can silently go wrong.

Common Real-World Use Cases

  • Geo-locate users: Add city/country info for better funnel segmentation.
  • Tag users by plan/tier: If your tracking only sends a user ID, a plugin can look up their plan from an internal API or database.
  • Standardize property names: If you have userId, user_id, and userid floating around, a plugin can normalize this.
  • Enrich with company info: Use a tool like Clearbit to attach company size, industry, etc., to B2B events.

Final Thoughts: Keep It Simple, Ship, and Iterate

PostHog plugins can turn messy, basic analytics into something you can actually act on. But don’t get carried away—start with the smallest possible change, see if the data is genuinely more useful, and only add complexity if you really need it.

Spend your time cleaning up tracking in your codebase first, then use plugins for the weird edge cases and the stuff you can’t control. Analytics is a marathon, not a sprint. Simple, well-documented plugins beat a magical Rube Goldberg machine every time.