How to set up custom event tracking in Amplitude for product analytics

Ever feel like your analytics are just collecting dust, not actually helping you build a better product? You’re not alone. Out-of-the-box dashboards rarely answer the questions that matter. If you want real insights—what features people use, where they drop off, or what drives signups—you need to set up custom event tracking. This guide is for product managers, startup founders, and devs who want to stop guessing and start making decisions based on real product data.

I’ll walk you through setting up custom event tracking in Amplitude so you can stop flying blind and actually learn from your users. No fluff, no vague advice—just the steps, the gotchas, and what to skip.

Why bother with custom events?

Here’s the thing: default events like “Page Viewed” or “Session Started” tell you basically nothing about what matters in your product. If you want to answer questions like “What features do power users love?” or “Why do people abandon onboarding?” you need to track specific actions—stuff that’s unique to your app.

Custom event tracking lets you:

  • Measure what actually matters for your business.
  • Debug issues faster (no more “I have no idea what happened here…”).
  • Tie product changes to real user behavior.

Ready? Let’s get your event tracking set up, step by step.

Step 1: Decide what you actually want to learn

Before you touch Amplitude, get clear about what you want to know. Don’t fall into the trap of tracking everything just because you can—“event soup” makes analysis a nightmare.

Ask yourself:

  • What are your key user journeys? (e.g., onboarding, checkout, sharing)
  • What behaviors signal success or failure? (e.g., completed profile, abandoned cart)
  • What do you wish you knew about your users right now?

Pro tip: Sit down with your team (product, dev, marketing) and list out the top 5-10 questions you want answered. Work backwards from those to define which events you need.

What to skip: Tracking every button click “just in case.” If you don’t know why you’d use the data, don’t track it (yet).

Step 2: Define your custom events and properties

Now, for each question you want answered, define:

  • Event Name: Use clear, plain-English names. E.g., Completed Onboarding, Shared Article, Added Item to Cart.
  • Event Properties: Extra data tied to the event. For Shared Article, you might want article_title, share_method, or user_role.

Why properties matter: They let you segment and drill down later. For example, knowing a user shared an article is good—knowing they shared via Twitter vs. email is better.

Naming conventions (don’t ignore this)

Pick a consistent naming scheme. CamelCase (CompletedOnboarding) or snake_case (completed_onboarding) are both fine—just be consistent. Don’t use spaces or random abbreviations.

Anti-patterns:

  • button123_clicked
  • misc_event_1

These will haunt you six months from now.

Step 3: Set up your Amplitude project

If you haven’t already, create an Amplitude project for your app. This is where your data will live.

To do:

  1. Go to Amplitude and create a new project. Keep it one project per product/platform (web, iOS, Android).
  2. Get your API key from the project settings—you’ll need this to send events.

Common mistake: Don’t mix data from different products or environments (prod vs. staging) unless you enjoy headaches.

Step 4: Instrument your events in code

Here’s where you (or your devs) add event tracking to your app. This usually means calling Amplitude’s SDK whenever a user does something important.

Basic example in JavaScript (Web)

js amplitude.getInstance().logEvent('Completed Onboarding', { plan: 'free', signup_method: 'google' });

In mobile apps (iOS/Android)

Find the relevant SDK (docs here) and use a similar method.

Tips:

  • Instrument events as close as possible to when the action actually happens. Don’t fire “Completed Onboarding” until the last onboarding step is done.
  • Pass properties every time, not just sometimes. Consistency is key.

What to ignore: Don’t bother with “Page Viewed” or “App Opened” unless you have a specific use case. Focus on events that drive your key metrics.

Step 5: Test your event tracking

Don’t trust that it “just works.” Amplitude has a Live View where you can watch events come in real time.

  • Perform the action in your app (e.g., complete onboarding).
  • Check Live View in Amplitude—does the event show up? Are the properties correct?
  • Try it with different user types, devices, or flows.

What trips people up:

  • Event names don’t match between code and Amplitude dashboard.
  • Properties missing or spelled inconsistently (plan vs. Plan).
  • Events not firing at all (often a dev environment issue).

Pro tip: Get someone else to test too. They’ll do things you didn’t think of.

Step 6: Validate your data with real users (not just you)

It’s easy to think your tracking is perfect because it works for you. Reality check: real users do weird things.

  • Release to a test group or wait a day or two after launch.
  • Spot-check data in Amplitude—is anything off? (e.g., impossible values, way too many/few events)
  • Look for missing data in key funnels or cohorts.

What to fix: Any ambiguity—if your event names or properties confuse you now, they’ll be 10x worse in a month.

Step 7: Set up charts, funnels, and dashboards

Now that you’re tracking the right stuff, build out actual reports that answer your original questions.

  • Use Funnel Analysis to see drop-offs (e.g., signup → onboarding → first action).
  • Use Segmentation to compare groups (e.g., “free” vs. “paid” users).
  • Build Dashboards for your team—don’t keep insights locked away.

Honest take: Most Amplitude charts are easy to build, but it’s easy to over-complicate. Start with a handful of key charts and iterate.

Step 8: Document your events (future you will thank you)

You will forget what ClickedCTA means three months from now. Write it down:

  • Event name, what it means, where it’s tracked in code.
  • List of all properties, with allowed values and examples.
  • Who to ask if something looks off.

Store this in your repo, Notion, or wherever your team keeps docs.

Skip: Overly complex event taxonomies or trying to map every possible action. Just document what you track and why.

Step 9: Review and refine—don’t set and forget

Analytics isn’t a one-and-done thing. Every time your product changes, your events probably need a tweak.

  • Set a recurring reminder (monthly or per release) to review tracked events.
  • Prune unused or confusing events.
  • Add new ones as your questions evolve.

Real talk: Nobody gets this perfect the first time. That’s fine.

Quick cheatsheet: What works, what doesn’t

Works:

  • Tracking a handful of meaningful events tied to real product questions.
  • Consistent naming and properties.
  • Regularly reviewing what you track.

Doesn’t work:

  • Tracking everything “just in case.”
  • Vague event names.
  • Never looking at the data you collect.

Wrapping up: Keep it simple and iterate

Setting up custom event tracking in Amplitude isn’t rocket science, but it’s easy to overthink. Focus on the handful of events that actually help you make decisions. Ignore the rest (for now). As you learn, tweak and improve your tracking. You’ll get better questions—and better answers—over time.

Don’t let analytics become another thing you dread. Keep your setup lean, document as you go, and remember: you can always add more later.