Event Tracking 101: Getting Started with KISSmetrics

“Page views tell you someone showed up. Events tell you what they actually did - and that difference is where every meaningful business insight lives.”

If you have ever stared at a Google Analytics dashboard and wondered why 10,000 visitors produced only 50 sign-ups, you already understand the limitation of page view analytics. You know people visited your site. You do not know what they did while they were there, which buttons they clicked, which features they tried, or at exactly which moment they decided to leave. Event tracking closes that gap. It gives you a record of every meaningful action a user takes - from clicking “Start Free Trial” to completing a purchase to inviting a teammate - and connects those actions into a coherent story of how people actually use your product.

This guide is a practical, start-to-finish walkthrough of event tracking. Whether you are setting up analytics for the first time or migrating from a page-view-only tool, you will learn what events to track, how to name and organize them, and how to turn raw event data into funnels, reports, and real business decisions using KISSmetrics.

What Is Event Tracking and Why It Matters

An event is a discrete record of something a user did. Clicked a button. Submitted a form. Watched a video. Completed a checkout. Each event captures the action itself, when it happened, who did it, and any relevant properties - like which plan they selected or which page they were on when they clicked.

Traditional analytics tools were built around page views: someone loaded a URL, and that got counted. That model worked when the web was a collection of static documents. Modern products - SaaS applications, single-page apps, e-commerce stores with dynamic interfaces - do not work that way. A user can perform dozens of meaningful actions on a single page without ever triggering a new URL load, and page view tracking captures none of it.

Event tracking solves this by letting you define and record exactly the actions that matter to your business. Instead of asking “how many people visited the pricing page,” you can ask “how many people clicked the annual billing toggle, then selected the Pro plan, then entered their payment information, then completed the purchase.” That level of specificity is the difference between knowing your conversion rate and knowing how to improve it.

Why Events Are the Foundation of Product Analytics

Every meaningful analytics capability - funnels, cohort analysis, retention curves, feature adoption reports - is built on top of events. Without well-defined events, you cannot build a funnel because you have no steps to measure. You cannot measure retention because you have no definition of “active.” You cannot analyze feature adoption because you have no record of who used which feature.

Events are the raw material. Everything else in analytics is a view built on top of that material. The quality of your events determines the quality of every report, dashboard, and insight you will ever produce.

Events vs. Page Views vs. Sessions

Before diving into implementation, it helps to understand the hierarchy of data in analytics. These three concepts - events, page views, and sessions - represent different levels of granularity, and confusing them leads to flawed analysis.

Page Views

A page view is recorded when a browser loads a URL. It tells you that someone arrived at a specific page, but nothing about what they did there. Page views are useful for measuring content reach - how many people read a blog post, how much traffic a landing page gets - but they are a poor measure of engagement or intent.

Sessions

A session is a group of page views (and potentially events) that happen during a single visit. Sessions typically expire after 30 minutes of inactivity. They are useful for understanding visit-level behavior - how many pages someone viewed, how long they stayed - but they have a critical limitation: sessions are anonymous by default and do not connect a user’s Monday visit to their Wednesday return.

Events

Events are the most flexible and powerful of the three. An event can be anything you define: a button click, a form submission, a feature activation, an API call, a payment completion. Events carry properties (metadata) that add context - which plan was selected, how much was spent, which campaign drove the visit. And in a person-based analytics system like KISSmetrics, events are tied to an identified individual, not just an anonymous session.

Think of it this way: page views tell you where users went. Sessions tell youwhen and how long. Events tell you what they did andwho they are. For product and growth teams, events are where the signal lives.

Core Events Every Product Needs to Track

You do not need to track everything. In fact, tracking everything is one of the most common mistakes teams make (more on that later). Instead, start with the events that map directly to your business model and user journey. Here are the categories that matter for virtually every product.

Acquisition Events

• Visited Site. The entry point. Record the traffic source, campaign, and landing page as properties. This is the top of every funnel.
• Signed Up. The moment a visitor becomes a known user. Include the signup method (email, Google SSO, GitHub) and the plan or tier they selected.

Activation Events

• Completed Onboarding. Whatever your onboarding flow includes - connecting a data source, creating a first project, inviting a teammate - track the completion of each step and the overall completion.
• Reached Aha Moment. The event that correlates most strongly with long-term retention. For a project management tool, this might be “Created Third Task.” For an analytics tool, it might be “Viewed First Report.” Identifying and tracking your activation event is one of the most important things you will do.

Engagement Events

• Used Core Feature. Track usage of each major feature in your product. For KISSmetrics, these would be events like “Ran Funnel Report,” “Created Population,” and “Viewed Activity Feed.”
• Logged In. Simple but valuable. Login frequency is one of the strongest predictors of retention and expansion.

Monetization Events

• Started Trial. If you have a free trial, this is a critical funnel step between signup and payment.
• Upgraded Plan / Completed Purchase. The revenue event. Include the plan name, billing cycle (monthly or annual), and revenue amount as properties.
• Churned / Cancelled. Just as important as the purchase event. Include the reason if you collect one during the cancellation flow.

Start with 10 to 15 events that cover these four categories. You can always add more later, but you cannot retroactively fix months of messy, unstructured data.

Designing Your Event Taxonomy

A taxonomy is the naming system and organizational structure for your events and their properties. Getting this right early saves you from the slow-motion disaster of inconsistent data that becomes unusable over time. If you have ever seen an analytics tool with events named “signup,” “user_signed_up,” “Sign Up,” and “registration_complete” - all meaning the same thing - you understand why taxonomy matters.

Choose a Naming Convention and Stick to It

The two most common formats are:

• Object-Action. Examples: “Account Created,” “Report Viewed,” “Plan Upgraded.” This format reads naturally and groups related events together alphabetically (all Account events appear together, all Report events appear together).
• Action-Object. Examples: “Created Account,” “Viewed Report,” “Upgraded Plan.” Some teams prefer this because it emphasizes the verb, but it scatters related events across your event list.

Either format works. What matters is consistency. Pick one, document it, and enforce it across every team that implements tracking. For most teams, Object-Action is the better choice because it keeps related events grouped together in dropdown menus and reports.

Use Title Case, Not snake_case

Events named “Plan Upgraded” are easier to read in reports than “plan_upgraded” or “PLAN_UPGRADED.” KISSmetrics displays event names exactly as you send them, so use the format you want to see in your reports. Title Case with spaces is the standard recommendation.

Define Properties for Every Event

Properties are the metadata attached to an event. They turn a generic event into a specific, queryable data point. For example, a “Plan Upgraded” event without properties tells you someone upgraded. The same event with properties tells you they upgraded from the Starter plan to the Pro plan, chose annual billing, and the new MRR is $99. Here are guidelines for properties:

• Keep property names consistent. If one event uses “plan_name” and another uses “Plan” for the same concept, your queries will miss data.
• Use lowercase with underscores for property names. This is the convention most analytics platforms expect: “plan_name,” “billing_cycle,” “revenue_amount.”
• Include identifiers. Properties like “plan_name,” “feature_name,” and “campaign_source” let you segment and filter your event data in reports.
• Avoid high-cardinality free text. A property value of “Pro Plan” is queryable. A property value of “User typed: I want the pro plan please” is not.

Document Everything in a Tracking Plan

A tracking plan is a spreadsheet or document that lists every event, its description, its properties, the expected data types, and where in the product it fires. This is your single source of truth. Without it, naming conventions drift, events get duplicated, and new team members have no way to understand what the existing events mean.

Getting Started with KISSmetrics Event Tracking

With your event taxonomy defined, here is how to implement tracking in KISSmetrics. The process is straightforward - most teams have their first events flowing within an hour.

Step 1: Install the KISSmetrics JavaScript Library

Add the KISSmetrics tracking snippet to your site. This is a small JavaScript file that loads asynchronously and provides the _kmq global object you will use to record events. Place it in the <head> of every page, or use a tag manager to deploy it site-wide. The snippet is available in your KISSmetrics account settings under the tracking code section.

Step 2: Identify Your Users

Call _kmq.push(['identify', 'user@example.com']) as soon as you know who the user is - typically after login or signup. This is the critical step that transforms anonymous event data into person-level analytics. Before identification, KISSmetrics tracks the user with an anonymous ID. After identification, it merges all previous anonymous activity with the identified person, creating a complete timeline from first visit through every subsequent action.

Step 3: Record Your First Events

Use _kmq.push(['record', 'Event Name', {property: 'value'}]) to fire an event. For example:

• _kmq.push(['record', 'Account Created', {plan_name: 'Pro', signup_method: 'Google SSO'}])
• _kmq.push(['record', 'Report Viewed', {report_type: 'Funnel'}])
• _kmq.push(['record', 'Plan Upgraded', {from_plan: 'Starter', to_plan: 'Pro', billing_cycle: 'annual'}])

Place these calls at the exact moment the action occurs - in the success callback of a form submission, after a payment is confirmed, when a feature is loaded. Do not fire events on page load unless the event genuinely corresponds to a page load action.

Step 4: Verify in the Live Stream

KISSmetrics provides a real-time event stream where you can watch events as they fire. Walk through your product, trigger each event you have implemented, and confirm that the event name and properties appear correctly in the live stream. This is also the time to catch common bugs: events firing twice, missing properties, or incorrect property values.

Step 5: Set User Properties

In addition to events, set user-level properties that describe who the person is: their plan, their company, their role, their signup date. Use _kmq.push(['set', {plan: 'Pro', company_size: '50-200'}]) to attach properties to the current user. These properties let you segment your reports - for example, showing funnel conversion rates for Enterprise users versus Starter users.

Person-Level Events: Tying Actions to Individuals

This is where KISSmetrics fundamentally differs from session-based analytics tools. In most analytics platforms, events are associated with a session or a device. If a user visits your site on Monday from a Google ad, comes back on Wednesday by typing your URL directly, and converts on Friday from an email link - traditional tools see three separate sessions from three separate “users.”

KISSmetrics ties every event to a person, not a session. That Monday ad click, the Wednesday direct visit, and the Friday email conversion are all attributed to one identified individual with a single, continuous timeline. This person-level connection is what makes it possible to answer the questions that actually drive business decisions: Which marketing channel produces users who convert to paid? Which onboarding steps correlate with long-term retention? Which features do your highest-value customers use most?

How Identity Resolution Works

When a user first visits your site, KISSmetrics assigns an anonymous ID stored in a cookie. Every event that user triggers is associated with that anonymous ID. When the user later identifies themselves - by signing up, logging in, or entering their email - KISSmetrics merges the anonymous activity with the identified person. If that same person later uses a different device and logs in, the activity from the new device is also merged into the same person record.

The result is a complete person-level timeline that spans devices, sessions, and months of activity. You can look up any individual user and see every event they have ever triggered, from their very first anonymous page view to their most recent feature usage.

Why Person-Level Matters for Revenue

When you can connect a specific user’s behavior to their revenue, you unlock the most valuable type of analytics: revenue attribution at the individual level. You can see that users who complete onboarding within 24 hours have 3x higher lifetime value. You can identify that users acquired through webinars churn at half the rate of users from paid ads. These are not aggregate correlations - they are traceable paths from specific actions to specific revenue outcomes.

Common Event Tracking Mistakes

Most event tracking implementations fail not because of technical problems but because of planning problems. Here are the mistakes that trip up even experienced teams - and how to avoid them.

Mistake 1: Tracking Everything

The instinct is understandable: track every click, every scroll, every hover, so you never miss anything. In practice, this creates so much noise that the signal becomes impossible to find. You end up with 500 events, most of which nobody looks at, and the few that matter are buried in a list so long that new team members cannot figure out which events are important. Start with 10 to 15 core events. You can always add more once you have built reports around the ones that matter.

Mistake 2: Inconsistent Naming

This is the silent killer of analytics implementations. One developer names an event “signup_complete.” Another names the same action “User Signed Up.” A third uses “registration.” Three months later, your funnel report only captures one-third of actual sign-ups because it is filtered to a single event name. The fix is simple: maintain a tracking plan document and require every new event to be added to it before implementation.

Mistake 3: Missing Properties

An event without properties is like a sentence without context. “Plan Upgraded” is useful. “Plan Upgraded (from Starter to Pro, annual billing, $99/month)” is ten times more useful. When you skip properties at implementation time, you cannot go back and retroactively add them to historical events. Think through your properties before you write the tracking code.

Mistake 4: Not Validating Data Quality

Many teams implement tracking, assume it works, and do not check until months later when a report looks wrong. By then, you have months of unreliable data. Always verify your events immediately after implementation using the real-time event stream. Check a week later to confirm volume looks reasonable. Check again when you release new features or change your codebase.

Mistake 5: Tracking Events on the Wrong Trigger

A “Purchase Completed” event should fire after the payment processor confirms success - not when the user clicks the submit button. A “Form Submitted” event should fire after successful validation - not before. Firing events on the wrong trigger inflates your numbers with actions that did not actually complete, which corrupts your funnel data and makes your conversion rates look better than they are.

From Events to Insights: Building Funnels and Reports

Events are the raw material. The value comes from what you build with them. Once your events are flowing reliably, here is how to turn that data into actionable insights.

Build Your First Funnel

A funnel is a sequence of events that represents a user journey you want to measure. The most common first funnel is the acquisition funnel: Visited Site, Signed Up, Completed Onboarding, Upgraded to Paid. In KISSmetrics, creating a funnel takes minutes - select the events that define each step, set the time window, and the platform calculates conversion rates between each step automatically.

Your funnel will immediately reveal where users drop off. If 1,000 people visit your site but only 30 sign up, your visit-to-signup conversion rate is 3% - and that is your first optimization target. If 30 people sign up but only 5 complete onboarding, your onboarding is the bottleneck, not your landing page.

Create Segmented Reports

The real power of event-based analytics emerges when you segment. Break your funnel by traffic source and you might find that organic search converts at 5% while paid social converts at 1%. Break it by plan type and you might discover that users who start on the free plan convert to paid at half the rate of users who start on a trial. These segments tell you not just what is happening but why - and they point directly to what to fix.

Use the Activity Feed for Qualitative Insight

Numbers tell you what is happening at scale. Individual user timelines tell you the story behind the numbers. Use KISSmetrics’ activity feed to look at specific users who dropped off at your funnel’s bottleneck step. What events did they trigger before dropping off? How long did they spend at each step? Did they attempt an action multiple times before giving up? This qualitative analysis often reveals the specific UX problem or missing information that aggregate data can only hint at.

Set Up Recurring Reports

Do not make analytics a one-time exercise. Set up weekly or monthly reports that track your core funnel conversion rates, feature adoption rates, and revenue metrics. Over time, these reports create a baseline that makes it immediately obvious when something changes - a new feature launch that improved activation, a pricing change that affected upgrades, or a bug that broke a critical event.

Key Takeaways

Event tracking is the foundation of modern product analytics. It replaces the vague picture painted by page views with a detailed, actionable record of what users actually do inside your product. Getting it right from the start - with a clear taxonomy, a documented tracking plan, and person-level identity resolution - saves you months of cleanup and gives you the data you need to make confident decisions.

The teams that understand their users best are the ones that defined their events carefully, tracked them consistently, and built the habit of turning event data into weekly decisions. That process starts with the steps in this guide - and it compounds with every week of clean data you collect.