How to Track Trial User Activity for SaaS Analytics

Trial user activity tracking is the practice of instrumenting and analyzing every meaningful action a free trial user takes in your SaaS product. Unlike general product analytics, trial-specific tracking focuses on behaviors that predict conversion: which features they use, how often they return, how quickly they reach first value, and how their engagement changes over the trial period. SaaS companies that implement data-driven trial management convert 3x more trial users to paid compared to those that treat all trial users the same.

The challenge is not collecting data—most products already have analytics—but knowing which data matters for trial conversion, how to structure it for actionable insights, and how to turn those insights into timely interventions. This guide covers the complete pipeline: from choosing metrics and implementing event tracking to building a trial health score and using it to trigger conversion actions. We also show how TrialMoments uses activity signals to optimize the timing of its conversion moments.

Not all user activity is equally predictive of conversion. These five metrics, when tracked together, give you the clearest picture of trial health and conversion likelihood. Each metric answers a different question about the user's trial journey. For a broader view of trial user activation, see our dedicated guide.

Event tracking for trial users requires a structured approach. Every event needs standard properties (user ID, trial day, plan) plus event-specific properties. Here is a production-ready event tracking layer that works with Segment, Mixpanel, Amplitude, or a custom backend.

The Trial Event Tracker

// lib/trial-analytics.ts

interface TrialContext {
  userId: string;
  trialStartDate: string;
  trialEndDate: string;
  plan: string;
}

interface TrackingEvent {
  event: string;
  properties: Record<string, unknown>;
  timestamp: string;
}

export class TrialAnalytics {
  private context: TrialContext;
  private providers: AnalyticsProvider[];

  constructor(context: TrialContext, providers: AnalyticsProvider[]) {
    this.context = context;
    this.providers = providers;
  }

  private getTrialDay(): number {
    const start = new Date(this.context.trialStartDate).getTime();
    return Math.floor((Date.now() - start) / (1000 * 60 * 60 * 24)) + 1;
  }

  private getDaysRemaining(): number {
    const end = new Date(this.context.trialEndDate).getTime();
    return Math.max(0, Math.ceil((end - Date.now()) / (1000 * 60 * 60 * 24)));
  }

  track(event: string, properties: Record<string, unknown> = {}) {
    const enrichedEvent: TrackingEvent = {
      event,
      properties: {
        ...properties,
        // Standard trial properties added to every event
        userId: this.context.userId,
        plan: this.context.plan,
        trialDay: this.getTrialDay(),
        trialDaysRemaining: this.getDaysRemaining(),
        isTrialUser: this.context.plan === 'trial',
        timestamp: new Date().toISOString(),
      },
      timestamp: new Date().toISOString(),
    };

    // Send to all configured providers
    this.providers.forEach(provider => {
      try {
        provider.track(enrichedEvent);
      } catch (error) {
        console.error(`Analytics provider error: ${error}`);
      }
    });
  }

  // Convenience methods for common trial events
  trackFeatureUsed(featureName: string, depth: number = 1) {
    this.track('feature_used', { featureName, depth });
  }

  trackSessionStart() {
    this.track('session_start', {
      referrer: document.referrer,
      url: window.location.href,
    });
  }

  trackActivationEvent(eventName: string) {
    this.track('activation_event', {
      activationEvent: eventName,
      timeSinceSignup: Date.now() - new Date(this.context.trialStartDate).getTime(),
    });
  }

  trackUpgradeIntent(source: string) {
    this.track('upgrade_intent', { source });
  }
}

interface AnalyticsProvider {
  track(event: TrackingEvent): void;
}

Provider Implementations

Here are adapters for the most common analytics tools. The adapter pattern means you can switch providers without touching your tracking calls.

// lib/analytics-providers.ts

// Segment adapter
export class SegmentProvider implements AnalyticsProvider {
  track(event: TrackingEvent) {
    window.analytics?.track(event.event, event.properties);
  }
}

// Mixpanel adapter
export class MixpanelProvider implements AnalyticsProvider {
  track(event: TrackingEvent) {
    window.mixpanel?.track(event.event, event.properties);
  }
}

// Custom API adapter (send to your own backend)
export class CustomAPIProvider implements AnalyticsProvider {
  private endpoint: string;
  private buffer: TrackingEvent[] = [];
  private flushTimeout: NodeJS.Timeout | null = null;

  constructor(endpoint: string) {
    this.endpoint = endpoint;
  }

  track(event: TrackingEvent) {
    this.buffer.push(event);

    // Batch events and flush every 5 seconds
    if (!this.flushTimeout) {
      this.flushTimeout = setTimeout(() => this.flush(), 5000);
    }
  }

  private async flush() {
    const events = [...this.buffer];
    this.buffer = [];
    this.flushTimeout = null;

    if (events.length === 0) return;

    try {
      await fetch(this.endpoint, {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ events }),
      });
    } catch (error) {
      // Re-add failed events to buffer for retry
      this.buffer.unshift(...events);
    }
  }
}

Initialization in your app:

// app/providers.tsx
import { TrialAnalytics } from '@/lib/trial-analytics';
import { SegmentProvider, CustomAPIProvider } from '@/lib/analytics-providers';

const trialAnalytics = new TrialAnalytics(
  {
    userId: user.id,
    trialStartDate: user.trialStartDate,
    trialEndDate: user.trialEndDate,
    plan: user.plan,
  },
  [
    new SegmentProvider(),
    new CustomAPIProvider('/api/analytics/events'),
  ]
);

// Track a feature being used
trialAnalytics.trackFeatureUsed('dashboard-builder', 3);

// Track an activation event
trialAnalytics.trackActivationEvent('first-report-created');

// Track session start
trialAnalytics.trackSessionStart();

A trial health score condenses multiple activity signals into a single 0-100 number that predicts conversion likelihood. It answers the question: "Is this trial user on track to convert?" The score drives automated interventions: low-score users get re-engagement emails, high-score users get well-timed upgrade prompts.

// lib/trial-health-score.ts

interface UserActivity {
  totalSessions: number;
  sessionsLast3Days: number;
  sessionsFirst3Days: number;
  featuresUsed: number;
  activationEventsCompleted: number;
  totalActivationEvents: number;
  minutesSinceLastSession: number;
  trialDayNumber: number;
  trialLengthDays: number;
}

interface HealthScoreResult {
  score: number;          // 0-100
  level: 'critical' | 'at-risk' | 'healthy' | 'champion';
  factors: HealthFactor[];
}

interface HealthFactor {
  name: string;
  score: number;
  weight: number;
  description: string;
}

export function calculateTrialHealthScore(
  activity: UserActivity
): HealthScoreResult {
  const factors: HealthFactor[] = [];

  // Factor 1: Session frequency (weight: 30%)
  const expectedSessions = activity.trialDayNumber * 0.7; // ~5 sessions/week
  const sessionScore = Math.min(100,
    (activity.totalSessions / Math.max(1, expectedSessions)) * 100
  );
  factors.push({
    name: 'Session Frequency',
    score: sessionScore,
    weight: 0.30,
    description: `${activity.totalSessions} sessions in ${activity.trialDayNumber} days`,
  });

  // Factor 2: Feature depth (weight: 25%)
  const featureScore = Math.min(100, (activity.featuresUsed / 5) * 100);
  factors.push({
    name: 'Feature Depth',
    score: featureScore,
    weight: 0.25,
    description: `${activity.featuresUsed} features explored`,
  });

  // Factor 3: Activation progress (weight: 25%)
  const activationScore = activity.totalActivationEvents > 0
    ? (activity.activationEventsCompleted / activity.totalActivationEvents) * 100
    : 0;
  factors.push({
    name: 'Activation Progress',
    score: activationScore,
    weight: 0.25,
    description: `${activity.activationEventsCompleted}/${activity.totalActivationEvents} events`,
  });

  // Factor 4: Engagement velocity (weight: 20%)
  const velocity = activity.sessionsFirst3Days > 0
    ? activity.sessionsLast3Days / activity.sessionsFirst3Days
    : activity.sessionsLast3Days > 0 ? 1.5 : 0;
  const velocityScore = Math.min(100, velocity * 50);
  factors.push({
    name: 'Engagement Velocity',
    score: velocityScore,
    weight: 0.20,
    description: velocity >= 1.0 ? 'Increasing usage' : 'Declining usage',
  });

  // Calculate weighted score
  const score = Math.round(
    factors.reduce((sum, f) => sum + f.score * f.weight, 0)
  );

  // Determine health level
  let level: HealthScoreResult['level'];
  if (score >= 70) level = 'champion';
  else if (score >= 50) level = 'healthy';
  else if (score >= 30) level = 'at-risk';
  else level = 'critical';

  return { score, level, factors };
}

At-risk trial users are those whose activity signals predict they will churn before converting. Identifying them early—within 48-72 hours of disengagement—gives you a window to intervene before they mentally abandon your product. This is one of the most impactful strategies for reducing trial drop-off.

// lib/at-risk-detection.ts

interface AtRiskSignal {
  type: 'session_gap' | 'no_activation' | 'declining_usage' | 'shallow_engagement';
  severity: 'warning' | 'critical';
  message: string;
  recommendedAction: string;
}

export function detectAtRiskSignals(
  activity: UserActivity
): AtRiskSignal[] {
  const signals: AtRiskSignal[] = [];

  // Signal 1: Session gap (no login in 3+ days)
  const hoursInactive = activity.minutesSinceLastSession / 60;
  if (hoursInactive > 72) {
    signals.push({
      type: 'session_gap',
      severity: hoursInactive > 120 ? 'critical' : 'warning',
      message: `User has not logged in for ${Math.floor(hoursInactive / 24)} days`,
      recommendedAction: 'Send re-engagement email with specific feature highlight',
    });
  }

  // Signal 2: No activation events by trial midpoint
  const isPassedMidpoint = activity.trialDayNumber > activity.trialLengthDays / 2;
  if (isPassedMidpoint && activity.activationEventsCompleted === 0) {
    signals.push({
      type: 'no_activation',
      severity: 'critical',
      message: 'Past trial midpoint with zero activation events',
      recommendedAction: 'Trigger guided onboarding or offer 1:1 demo call',
    });
  }

  // Signal 3: Declining engagement velocity
  if (activity.sessionsFirst3Days > 0 && activity.sessionsLast3Days === 0) {
    signals.push({
      type: 'declining_usage',
      severity: 'critical',
      message: 'User was active initially but has stopped returning',
      recommendedAction: 'Send "we noticed you haven't been back" email with value recap',
    });
  }

  // Signal 4: Shallow feature engagement
  if (activity.trialDayNumber >= 3 && activity.featuresUsed <= 1) {
    signals.push({
      type: 'shallow_engagement',
      severity: 'warning',
      message: 'Only explored 1 feature in 3+ days',
      recommendedAction: 'Show in-app prompt to explore related features',
    });
  }

  return signals;
}

With enough trial data (200+ completed trials is a reasonable minimum), you can build a simple logistic regression model that predicts conversion probability for each active trial user. This is not machine learning complexity—it is basic statistics applied to your trial metrics.

// lib/conversion-prediction.ts

interface PredictionInput {
  sessionsFirstWeek: number;
  featuresUsed: number;
  activationScore: number;   // 0-1
  engagementVelocity: number; // ratio
  trialDay: number;
}

interface PredictionResult {
  probability: number;       // 0-1
  confidence: 'low' | 'medium' | 'high';
  topFactors: string[];
}

// Coefficients derived from historical trial data
// In production, retrain monthly with new data
const MODEL_WEIGHTS = {
  intercept: -2.5,
  sessionsFirstWeek: 0.35,
  featuresUsed: 0.28,
  activationScore: 1.8,
  engagementVelocity: 0.45,
  trialDay: -0.05,  // Later in trial = slightly lower probability
};

export function predictConversion(
  input: PredictionInput
): PredictionResult {
  // Logistic regression: P(convert) = sigmoid(w * x + b)
  const z =
    MODEL_WEIGHTS.intercept +
    MODEL_WEIGHTS.sessionsFirstWeek * input.sessionsFirstWeek +
    MODEL_WEIGHTS.featuresUsed * input.featuresUsed +
    MODEL_WEIGHTS.activationScore * input.activationScore +
    MODEL_WEIGHTS.engagementVelocity * input.engagementVelocity +
    MODEL_WEIGHTS.trialDay * input.trialDay;

  const probability = 1 / (1 + Math.exp(-z));

  // Determine confidence based on trial day (more data = higher confidence)
  let confidence: PredictionResult['confidence'];
  if (input.trialDay >= 7) confidence = 'high';
  else if (input.trialDay >= 3) confidence = 'medium';
  else confidence = 'low';

  // Identify top contributing factors
  const contributions = [
    { name: 'Session frequency', value: MODEL_WEIGHTS.sessionsFirstWeek * input.sessionsFirstWeek },
    { name: 'Feature usage', value: MODEL_WEIGHTS.featuresUsed * input.featuresUsed },
    { name: 'Activation progress', value: MODEL_WEIGHTS.activationScore * input.activationScore },
    { name: 'Engagement trend', value: MODEL_WEIGHTS.engagementVelocity * input.engagementVelocity },
  ].sort((a, b) => Math.abs(b.value) - Math.abs(a.value));

  return {
    probability: Math.round(probability * 100) / 100,
    confidence,
    topFactors: contributions.slice(0, 2).map(c => c.name),
  };
}

The model outputs a probability between 0 and 1. Users with probability above 0.6 are strong conversion candidates and should receive timely upgrade prompts. Users below 0.3 need intervention. The coefficients above are starting points— calibrate them with your actual trial data by running a logistic regression on your historical conversions. Even a basic model improves targeting accuracy by 15% compared to treating all trial users the same.

The real value of trial analytics is not the dashboards—it is the automated actions triggered by the data. Here is a framework for mapping health score levels and signals to specific interventions.

TrialMoments integrates with your activity data to time its conversion moments optimally. Instead of showing upgrade prompts on a fixed schedule (day 3, day 7, day 12), it uses engagement signals to identify the right moment for each individual user.

// Initialize TrialMoments with activity-aware config
TrialMoments.init({
  accountId: 'your-id',
  trialEndDate: '2026-04-15',
  upgradeUrl: '/upgrade',
});

// TrialMoments uses these signals automatically:
// - Time remaining in trial (countdown urgency)
// - User engagement level (when to show prompts)
// - Feature interaction history (what to highlight)
// - Session patterns (optimal timing)

// You can also send explicit signals:
TrialMoments.triggerBlockedFeature('advanced-analytics');
// Shows a conversion prompt specifically about advanced analytics
// timed to the user's engagement level and trial position

The result: upgrade prompts appear when the user has context and motivation, not on arbitrary calendar dates. This approach to using trial data for conversion consistently outperforms fixed-schedule messaging.

FAQ: Trial User Activity Tracking