Kissmetrics Event Tracking: Person-Based Analytics

Person-Based Event Model

Kissmetrics differs from session-based analytics (like GA4) by tying every event to a specific person. The identity chain works like this:

1. Anonymous visitor lands on your site → Kissmetrics assigns a random ID.
2. Visitor signs up or logs in → you call identify with their email or user ID.
3. Kissmetrics merges the anonymous activity with the identified person.
4. All future events on any device are attributed to the same person (if identified).

This person-centric model makes Kissmetrics particularly strong for SaaS metrics (trial-to-paid conversion, feature adoption), subscription businesses (churn analysis, LTV), and B2B funnels (lead-to-close attribution).

Recording Events

// Basic event
_kmq.push(['record', 'Signed Up']);

// Event with properties (key-value pairs)
_kmq.push(['record', 'Signed Up', {
  'Plan': 'Premium',
  'Source': 'Website',
  'Referrer': document.referrer
}]);

// The 'Revenue' property is special — Kissmetrics
// uses it for revenue reports automatically
_kmq.push(['record', 'Purchased', {
  'Revenue': 99.99,
  'Plan': 'Pro Annual',
  'Billing Cycle': 'Annual'
}]);

Event naming convention: Use Title Case with past tense for completed actions (Signed Up, Purchased, Upgraded Plan). Present tense for ongoing states (Viewing Pricing, Using Feature X). Keep names consistent — Signed Up and signed up are separate events in Kissmetrics.

Identifying Users

// Identify by email (most common)
_kmq.push(['identify', 'jane@example.com']);

// Or by a stable user ID
_kmq.push(['identify', 'user_12345']);

When to call identify:

• After login / signup — the critical moment that connects anonymous browsing to a known person.
• After form submission where email is captured (newsletter signup, lead form).
• On every authenticated page load — Kissmetrics deduplicates, so repeated calls with the same identity are safe.

Identity merging: If a visitor browses anonymously, then signs up, Kissmetrics retroactively attaches all their anonymous activity to their identified profile. This only works forward — you can't retroactively merge two already-identified users.

// Common SaaS pattern: identify on signup, then on every login
// Signup page
_kmq.push(['identify', 'jane@example.com']);
_kmq.push(['record', 'Signed Up', { 'Plan': 'Free Trial' }]);

// On subsequent logins (in your auth callback)
_kmq.push(['identify', 'jane@example.com']);
_kmq.push(['record', 'Logged In']);

Setting Person Properties

Properties describe who the person is (not what they did — that's events):

_kmq.push(['set', {
  'Plan': 'Enterprise',
  'Company Size': '50-100',
  'Industry': 'SaaS',
  'MRR': 499,
  'Signup Date': '2025-01-15'
}]);

Properties persist on the person's profile and can be used for segmentation in reports. Use set for attributes that change over time (plan, MRR, company size). The latest value wins — Kissmetrics doesn't maintain a property history (use events for that).

Revenue Tracking

Kissmetrics has built-in revenue reporting that keys off the Revenue property name:

// One-time purchase
_kmq.push(['record', 'Purchased', {
  'Revenue': 299.99,
  'Product': 'Annual Pro License',
  'Payment Method': 'Credit Card'
}]);

// Subscription revenue (track each billing event)
_kmq.push(['record', 'Billed', {
  'Revenue': 49.99,
  'Plan': 'Pro Monthly',
  'Billing Period': 'March 2025'
}]);

// Refund (use negative revenue)
_kmq.push(['record', 'Refunded', {
  'Revenue': -49.99,
  'Reason': 'Downgrade to free'
}]);

The Revenue Report (Kissmetrics → Revenue) automatically aggregates:

• Total revenue over time
• Revenue per person
• Average revenue per paying user
• Revenue by acquisition source (requires UTM tracking or source properties)

Automatic Event Tracking

Kissmetrics can auto-track clicks and form submissions without custom JavaScript:

// Track clicks on a specific element
_kmq.push(['trackClick', 'signup-button', 'Clicked Signup CTA']);

// Track form submissions
_kmq.push(['trackSubmit', 'signup-form', 'Submitted Signup Form']);

// Track clicks on all elements with a CSS selector
_kmq.push(['trackClickOnOutboundLink', 'a.external', 'Clicked External Link']);

Auto-tracked by default (if enabled in Settings → Tracking):

• Page views (with URL and referrer)
• Ad campaign visits (UTM parameters → person properties)
• Search engine visits (keyword and engine)

Funnel Analysis

Kissmetrics funnels track person-based conversion through a sequence of events:

Example SaaS funnel:

1. Visited Pricing Page
2. Started Free Trial
3. Completed Onboarding
4. Purchased

Build this in Kissmetrics → Funnels → New Funnel. Select events in order. The funnel shows:

• Conversion rate between each step
• Time between steps (median and distribution)
• Drop-off analysis with person-level drill-down
• Segment comparison (e.g., organic vs. paid traffic)

Funnel vs. GA4 funnels: Kissmetrics funnels are person-based with no time window by default — a person who does Step 1 in January and Step 2 in March still counts as converting. GA4 funnels are session-scoped by default.

Cohort Analysis

Cohort reports group people by when they first did something, then track their behavior over time:

Example: Group users by signup month, then track what percentage return each week.

Build in Kissmetrics → Cohort Report:

• Group by: First time person did Signed Up (monthly)
• Then did: Logged In (weekly buckets)

This produces a retention triangle showing week-over-week retention by signup cohort — essential for measuring onboarding improvements, feature launches, and churn trends.

A/B Test Measurement

Track experiment variants as person properties:

// When assigning a variant
_kmq.push(['set', {
  'Pricing Page Experiment': 'Variant B - Annual Highlighted'
}]);

// Track the conversion event as usual
_kmq.push(['record', 'Started Free Trial']);

Then in Kissmetrics → Funnels, segment the funnel by Pricing Page Experiment to compare conversion rates between variants. Since Kissmetrics is person-based, you get true per-person conversion without session-based double-counting.

Server-Side Tracking

For backend events that don't happen in the browser:

# Python — track server-side events via Kissmetrics API
import requests

requests.get('https://trk.kissmetrics.io/e', params={
    '_k': 'YOUR_API_KEY',
    '_p': 'jane@example.com',  # Person identity
    '_n': 'Subscription Renewed',
    'Revenue': 49.99,
    'Plan': 'Pro Monthly'
})

# cURL example
curl "https://trk.kissmetrics.io/e?_k=YOUR_API_KEY&_p=jane@example.com&_n=Subscription%20Renewed&Revenue=49.99"

Use server-side tracking for: subscription renewals, backend-processed purchases, webhook-triggered events (Stripe payments, support tickets), and any event that occurs outside the browser.

Best Practices

• Identify early and often: Call identify at every authentication touchpoint (login, signup, email click). The earlier you identify, the more anonymous activity gets attributed.
• Use consistent event names: Create a tracking plan document listing every event name and its properties. Share it across engineering, product, and marketing.
• Track meaningful actions, not everything: Focus on events that represent business value — signups, feature activations, purchases, churns. Page views are automatic; you don't need custom events for every click.
• Always include Revenue on purchase events: This property name is magic — it powers the entire Revenue Report. Use negative values for refunds.
• Set person properties for segmentation: Properties like Plan, Company Size, Industry, and Signup Date enable powerful segmentation in funnels and cohort reports.
• Test with Kissmetrics Live: Kissmetrics → Live shows events firing in real-time. Use this during development to verify event names, properties, and identity resolution before deploying to production.