How to set up event tracking in Amplitude correctly

by

TL;DR

You can go from zero to live event tracking in Amplitude in under two hours if you have developer access to your app’s codebase. you will need an Amplitude account on the free Starter plan (up to 50,000 monthly tracked users), a working web or mobile app, and a clear list of the actions you want to track. the result is a real-time stream of user behaviour data you can query, chart, and share without writing SQL.

What You Need Before You Start

Before you touch a single line of code, get these in order:

  • Amplitude account on the free Starter plan. sign up at amplitude.com. no credit card required.
  • A project created inside Amplitude. one project per product environment is the standard setup (e.g., “My App – Production” and “My App – Dev”).
  • Developer access to your app. you need to be able to add a JavaScript package (npm), a script tag, or an iOS/Android SDK dependency. if you cannot do this yourself, loop in a frontend engineer for 30 minutes.
  • Node 18+ or a modern browser build pipeline (Webpack, Vite, etc.) if you are using the npm package route.
  • A drafted event taxonomy (even a rough Google Sheet works). list the 10-15 actions you care most about before you write code. this prevents the most common mistake people make, which is tracking everything and analysing nothing.
  • Optional: Segment if your company already uses a customer data platform. Amplitude has a native Segment destination that means you may not need to touch the SDK directly.
  • Optional: Google Tag Manager if your engineering team is bottlenecked. GTM can fire Amplitude events without a code deploy, at the cost of some flexibility.

Step 1: Create Your Amplitude Project and Grab Your API Key

Log into Amplitude, click the grid icon in the top-left, then Settings > Projects > Create Project. Name it something obvious like “My App – Dev”. Amplitude will generate a unique API key for this project.

Copy that API key. you will use it in every SDK initialisation call. store it somewhere accessible, like a .env file, not hardcoded in your source. if you accidentally expose it, anyone can write junk events into your project, which pollutes your data permanently.

Sanity check: your project card in the Projects list shows a green “Active” badge and the API key is visible under “General” settings.

Step 2: Install the Amplitude Browser SDK

For a web app, open your terminal and run:

npm install @amplitude/analytics-browser

If you are using a script tag instead (no build pipeline), add this to your HTML <head>:

<script type="text/javascript">
  !function(){"use strict";!function(e,t){var r=e.amplitude||{_q:[],_iq:{}};
  /* abbreviated Amplitude snippet */
  }(window,document)}();
</script>

For React Native, use @amplitude/analytics-react-native. For iOS, install Amplitude-Swift via Swift Package Manager. for Android, add com.amplitude:analytics-android to your Gradle dependencies.

The npm route is strongly preferred for web apps because it gives you TypeScript types, tree-shaking, and proper version pinning.

Sanity check: running npm list @amplitude/analytics-browser in your project root shows a version number (2.x as of 2026) with no peer dependency warnings.

Step 3: Initialise the SDK

In your app’s entry file (e.g., index.ts, App.tsx, or main.js), add the initialisation call as early as possible:

import * as amplitude from '@amplitude/analytics-browser';

amplitude.init('YOUR_API_KEY', {
  autocapture: false,          // turn this off until you understand what it sends
  defaultTracking: false,      // same reason
  logLevel: amplitude.Types.LogLevel.Warn,
});

The two false flags are deliberate. Amplitude’s autocapture feature records every click and page view automatically, which sounds helpful but fills your event stream with noise before you have defined what actually matters. you will turn these on selectively later if you want them.

Replace 'YOUR_API_KEY' with the value from Step 1, pulled from your environment variables:

amplitude.init(process.env.AMPLITUDE_API_KEY!, { ... });

Sanity check: open your browser’s network tab, reload the page, and filter requests by “amplitude”. you should see a POST request to api2.amplitude.com with a 200 response.

Step 4: Define Your Event Taxonomy in a Spreadsheet First

Stop here before you write your first track() call. this is the step most product managers skip, and it causes years of messy data.

Open a Google Sheet and create columns: Event Name, Trigger (when it fires), Properties (key/value pairs attached to the event), Owner, Status.

A good event name follows the Object-Action pattern:

Button Clicked          ← too generic
Signup Form Submitted   ← better
Upgrade Plan Clicked    ← good, specific object + action

For properties, be consistent with types. if plan_name is a string in one event and planName is a camelCase string in another, Amplitude will treat them as two different properties. decide on snake_case or camelCase now and stick to it across your entire codebase.

Aim for 10-20 events to start. you can always add more. you cannot easily clean up 200 events that nobody understands.

Sanity check: every event name in your sheet has at least one property beyond the defaults, and no two event names are ambiguous enough to be confused with each other.

Step 5: Implement Your First track() Call

With your taxonomy in hand, add tracking to a real user action. here is a signup button click:

import * as amplitude from '@amplitude/analytics-browser';

function handleSignupSubmit(formData: SignupFormData) {
  amplitude.track('Signup Form Submitted', {
    plan_name: formData.selectedPlan,
    referral_source: formData.referralCode ?? 'none',
    form_version: 'v2',
  });

  // rest of your submit logic
}

Call amplitude.track() after the action succeeds, not before. if you track the click before the API call completes and the request fails, you will have a phantom “success” event in your data.

For page views, track them explicitly in your router:

router.on('routeChange', (route) => {
  amplitude.track('Page Viewed', {
    page_name: route.name,
    page_path: route.path,
  });
});

Sanity check: trigger the action in your browser, then go to Amplitude and open Data > Events > Live Event Stream. your event should appear within 5-10 seconds with all properties visible.

Step 6: Identify Your Users

Anonymous event data is useful but limited. when a user logs in, call identify() so Amplitude can stitch sessions together and build per-user profiles:

amplitude.setUserId(user.id);  // your internal user ID, not email

const identifyObj = new amplitude.Identify();
identifyObj.set('plan', user.plan);
identifyObj.set('signup_date', user.createdAt);
identifyObj.set('company_size', user.company.employeeCount);
amplitude.identify(identifyObj);

Use your internal user ID (a UUID or database integer) as the Amplitude user ID, not the user’s email address. email addresses change. internal IDs do not. this matters for GDPR deletion requests too, since you can delete by user ID without worrying about old email addresses.

When a user logs out, call amplitude.reset() to clear the user ID and start a new anonymous session.

Sanity check: go to Data > Users in Amplitude, search for the user ID you just set, and confirm the user properties you sent are visible on their profile card.

Step 7: Validate Data in the Amplitude Debugger

Before you ship to production, use the Amplitude SDK Debugger to confirm your events look right. install the Amplitude Chrome Extension or use the built-in logger:

amplitude.init('YOUR_API_KEY', {
  logLevel: amplitude.Types.LogLevel.Debug,
});

Check these things for every event:

  • event name matches your taxonomy exactly (case-sensitive)
  • all expected properties are present and have the right data types
  • user ID is set correctly after login, and null before login
  • no duplicate events firing (happens when track() is inside a render loop by mistake)

For teams shipping fast, it helps to write a small test utility that asserts event shapes before merging pull requests. see how other teams structure analytics testing for patterns that work at scale.

Sanity check: the debug console shows each event firing exactly once per user action, with no missing properties and no type errors.

Step 8: Build Your First Chart in Amplitude

Raw events are only useful when you can visualise them. go to Analytics > Charts > + New Chart and select Event Segmentation.

Add your “Signup Form Submitted” event. set the Y-axis to “Unique Users”. set the date range to “Last 7 days”. group by plan_name to see which plan attracts the most signups.

Click Save to Dashboard and name the dashboard “Core Acquisition Metrics”.

This first chart proves your tracking is working end to end. once you have confirmed a few events are flowing cleanly, you can build funnels (go to Funnel Analysis) to see where users drop off between steps. for a full comparison of what Amplitude can do versus alternatives, see our Amplitude vs Mixpanel breakdown.

Sanity check: the chart shows data that roughly matches what you expect. if signups are zero but you know users signed up today, something is wrong in the tracking code, not the chart.

Step 9: Set Up a Governance Process

Tracking code without a governance process breaks within six months. people add events ad-hoc, names drift, and nobody knows which events are still in use.

Do these three things now, while the project is small:

  1. Create a shared “Event Registry” document (the spreadsheet from Step 4) and make it the source of truth. link it in your team’s wiki.
  2. Use Amplitude’s Schema feature (available on the free plan) to block unexpected event names from being ingested. go to Data > Schema and toggle “Block Unplanned Events” to on.
  3. Review the event list quarterly. archive events that have not fired in 90 days. Amplitude lets you mark events as “Inactive” without deleting the historical data.

For teams managing tracking across multiple platforms, a customer data platform like Segment can centralise governance so you define events once and route them everywhere. it is worth evaluating once you have more than two data destinations.

Sanity check: your Schema settings show at least your core 10-15 events as “Planned”, and the block rule is active in the dev project.

Common Mistakes To Avoid

  • Tracking every possible event on day one. you end up with 300 events, no naming convention, and a data team that cannot answer a single business question. start with 10-15 events tied to your OKRs.
  • Using display strings as event names. naming an event “Buy Now” because that is the button label means you have to rename all your historical data when marketing changes the button copy. use semantic names like “Purchase Intent Clicked” instead.
  • Calling track() before the API confirms success. if a user clicks “Upgrade” but the payment fails, you should not have an “Upgrade Completed” event in Amplitude. track outcomes, not attempts.
  • Not setting a user ID on login. anonymous events from before login and authenticated events after login stay as separate users in Amplitude forever. you lose the full user journey for every converted visitor.
  • Skipping the dev project. shipping tracking changes directly to your production Amplitude project means your charts get polluted with test events every time a developer runs the app locally. always use a separate project for dev and CI environments.
  • Ignoring property data types. if item_count is sometimes a string (“3”) and sometimes an integer (3), Amplitude will treat them inconsistently. enforce types at the point where you call track().

When To Level Up

The Amplitude free Starter plan covers 50,000 monthly tracked users, which is enough for most early-stage products. the setup described here scales comfortably to a few million events per month without architectural changes.

You will hit its limits when you need cross-product identity resolution (users who exist in two separate apps), warehouse-native analytics (querying Amplitude data alongside your transactional database in BigQuery or Snowflake), or strict SOC 2 / HIPAA compliance controls that require data residency.

At that point, the conversation shifts from “how do I set up tracking” to “what is my analytics infrastructure strategy”. a customer data platform sitting in front of Amplitude, or a full migration to a warehouse-native tool like Mixpanel, Heap, or PostHog, becomes worth evaluating seriously. browse our data analysis tools category for side-by-side comparisons of tools at that level.

Frequently Asked Questions

Does Amplitude track users across devices automatically?
No. Amplitude links sessions across devices only when you call setUserId() with the same user ID on each device after login. anonymous sessions on different devices stay separate until a user authenticates.

Can I use Amplitude without a developer?
You can use Google Tag Manager to fire Amplitude events without a code deploy, but someone still needs to set up GTM correctly and map data layer variables to event properties. for anything beyond basic page views, a developer’s time investment is 2-4 hours and pays for itself immediately.

How long does it take for events to appear in Amplitude charts?
Live Event Stream shows events within seconds. chart data in Analytics can have a delay of 5-15 minutes for the most recent hour. Amplitude publishes current ingestion latency on their status page.

Is the Amplitude free plan genuinely free?
Yes. the Starter plan has no time limit and no credit card requirement. the main constraints are 50,000 monthly tracked users, limited chart types (no funnel analysis or retention on the free tier as of 2026), and no data export. check the Amplitude pricing page for the current feature list since it changes.

What is the difference between an event and a user property?
An event is something that happened at a specific moment (“Signup Form Submitted at 2:14pm”). a user property describes the current state of the user (“plan: pro”). use events for actions and timestamps. use user properties for dimensions you want to filter and group by across any event in a user’s history.

Bottom Line

Setting up Amplitude event tracking correctly comes down to four habits: define your events before you code them, initialise the SDK with autocapture off, identify users the moment they log in, and enforce a naming convention from day one. the technical setup takes an afternoon. the discipline to keep the data clean is what separates a useful analytics setup from a pile of noise six months later. if you follow the nine steps above, you will have a live event stream, a validated user profile, and at least one meaningful chart before the end of your next sprint. for your next step, explore the data analysis tools on this site to understand how Amplitude fits into a broader analytics stack as your product and team grow.