SaaS Event Schema: The Complete Reference

A complete reference for SaaS product analytics. All lifecycle events — from signup to churn — with parameters, data types, and data layer examples you can copy-paste into your tracking plan.

Most SaaS teams track too little or too much. They either rely on page views alone, missing critical product interactions, or fire hundreds of events with no naming standard, making analysis impossible. This reference gives you the middle ground: a structured schema covering the events that actually drive SaaS metrics.

SaaS Funnel Overview

SaaS analytics tracks users through five lifecycle stages. Each stage has distinct events that map to specific business metrics.

Signup & Authentication Events

These events track how users create accounts and authenticate. They’re the entry point of every SaaS funnel and directly impact your registration-to-activation conversion rate.

The method parameter is reusable across signup, login, and password reset. Values like email, google, github, or saml let you compare authentication paths without creating separate events for each.

Onboarding Events

Onboarding is where most SaaS products lose users. When I audited a project management tool’s analytics, we discovered 68% of users dropped off before completing step 3 of a 5-step onboarding — but nobody knew because they only tracked onboarding_complete. Track each step individually.

Use flow_name consistently across all onboarding events — it lets you compare multiple flows (e.g., setup_wizard, quick_start, team_invite) and run A/B tests between them.

Feature Usage Events

Feature events are the core of SaaS analytics. They tell you what users actually do with your product. The key is using a single feature_used event with descriptive parameters instead of creating a separate event for every feature.

Subscription & Billing Events

Billing events connect product usage to revenue. They’re essential for calculating MRR, LTV, and conversion rates. Always track these server-side for accuracy — client-side billing events can be lost to ad blockers or page refreshes.

Include value and currency on all monetization events. GA4 uses these for revenue reporting. Use ISO 4217 currency codes (EUR, USD) and pass values as numbers, not strings.

Retention & Churn Events

Retention events help you spot at-risk users before they cancel. In my experience, tracking churn_survey_submitted with a reason parameter provides more actionable data than any cohort analysis — you hear directly why people leave.

Naming Convention Reference

All events in this schema follow these rules. Consistent naming prevents the user_signup vs UserSignup vs sign-up chaos that plagues most SaaS analytics setups.

For a deeper dive into GA4 naming rules, event limits, and GTM organization, see GA4 Event Naming Conventions: A Practical Guide.

Data Layer Examples

Push events to the data layer using standard dataLayer.push() calls. GTM, Matomo Tag Manager, or any tag management system can then pick them up.

Signup Event

dataLayer.push({
  event: 'sign_up',
  method: 'google',
  plan_type: 'free_trial',
  referral_source: 'product_hunt'
});

Feature Usage Event

dataLayer.push({
  event: 'feature_used',
  feature_name: 'dashboard',
  feature_category: 'reporting',
  action: 'created'
});

Plan Upgrade Event

dataLayer.push({
  event: 'plan_upgraded',
  previous_plan: 'starter',
  new_plan: 'professional',
  value: 49.00,
  currency: 'EUR'
});

Churn Event

// Server-side recommended for billing events
dataLayer.push({
  event: 'churn_completed',
  plan_name: 'professional',
  mrr_lost: 49.00,
  tenure_days: 186
});

Validation Checklist

Run through this checklist before launching your SaaS tracking implementation.

FAQ

How many events should a SaaS product track?

Start with 10–15 core events covering signup, onboarding, feature usage, and billing. Expand to 25–40 events as your analytics matures. Tracking more than 50 custom events usually means your schema needs consolidation — use generic events like feature_used with descriptive parameters instead.

Should SaaS billing events be tracked client-side or server-side?

Always server-side. Client-side billing events can be blocked by ad blockers, lost to page refreshes during payment processing, or duplicated by retry logic. Use your payment provider’s webhooks (Stripe, Paddle) to fire billing events reliably from your backend.

What is the difference between feature_used and individual feature events?

A single feature_used event with feature_name and action parameters scales better than separate events per feature. GA4 limits you to 500 unique event names. A 50-feature product using individual events would consume 150+ names. The generic approach conserves event slots and simplifies analysis through parameter-based filtering.

How do I track onboarding drop-off points?

Fire onboarding_step_complete with step_number and step_name for each step. Also track onboarding_skip with skipped_at_step. In GA4, create a funnel exploration with each step as a stage — this shows exactly where users abandon the flow and what percentage skip versus complete.

Do I need to track every feature interaction?

No. Track meaningful actions — creating, configuring, or completing something — not every button click or hover. A good test: “Would a product manager make a decision based on this event?” If the answer is no, don’t track it. You can always add events later, but removing noisy data from reports is much harder.

Further Reading

• E-commerce Event Schema: The Complete Reference — If you also sell products alongside your SaaS
• GA4 Event Naming Conventions — Deep dive into naming rules and GTM organization
• Server-Side Tracking: When and How to Use It — Essential for reliable billing event tracking
• UTM Parameters Strategy Guide — Attribution for your acquisition campaigns

---