Skip to main content
Imagine you’ve built a mobile app — users install it, sign in, browse content, and eventually make a purchase or complete a key action. This guide walks through tracking the full app experience using the Zixflow Flutter SDK: from first install and screen navigation to feature usage, push notifications, and offline sessions.

SDK Integration

Flutter SDK Setup

pubspec.yaml:
Initialize on app launch:
SDK behavior:
  • Events batched in memory (max 20 events or 30 seconds)
  • On app background: Immediate flush
  • On network failure: Persist to SQLite, retry with exponential backoff
  • Battery-conscious: Batching reduces network calls by 90%

App Lifecycle Events

App Installed

When: First app launch after install (SDK auto-tracks) What’s tracked automatically:
Manual tracking (if you need attribution):

App Opened

When: App moves from background to foreground Auto-tracked by SDK (if autoTrackAppLifecycle: true):
Manual tracking (if you want custom logic):

App Backgrounded

When: User switches to another app or locks screen
Analytics use cases:
  • Session duration distribution
  • Screens per session
  • Features used per session
  • Session → Conversion rate

Screen Tracking

Enable in SDK config:
What’s tracked:

Manual Screen Tracking (Granular Control)

Use case: You want to add screen-specific properties (product ID, category, etc.)

Feature Usage Events

Feature Discovered

When: User views feature for first time (onboarding, tutorial, tooltip)
Analytics: Feature discovery rate, time to discovery

Feature Used

When: User actively engages with feature

Search Performed

When: User submits search query

Content Shared

When: User shares via native share sheet
Analytics: Viral coefficient, most-shared products

Push Notification Events

Push Permission Requested

When: App asks for notification permission

Push Permission Granted/Denied

When: User responds to system permission prompt
Analytics: Permission grant rate, optimal timing for prompt

Push Received

When: Push notification arrives (app in foreground or background)

Push Opened

When: User taps notification (SDK auto-tracks) Auto-tracked:
Custom handling:

Offline Behavior

Event Queueing

SDK handles offline automatically:
  1. Network unavailable: Events persisted to SQLite
  2. Battery optimization: Batch 20 events per network call
  3. Retry logic: Exponential backoff (1s, 2s, 4s, 8s, 16s)
  4. Max retries: 10 attempts, then discard (prevents infinite queue growth)
Developer control:

Offline Analytics

Track offline sessions separately:
Analytics: Offline usage patterns, feature availability gaps

Performance Monitoring

Screen Load Time


API Call Performance

Analytics: P50/P95/P99 latency by endpoint, error rates

Implementation Checklist

Phase 1: Core Tracking (Week 1)

  • SDK integration (initialization, config)
  • App Installed, Opened, Backgrounded
  • Screen tracking (auto or manual)
  • User identification on signup/login
  • Device token registration

Phase 2: Feature Instrumentation (Week 2)

  • Feature Used events (top 5 features)
  • Search Performed
  • Content Shared
  • Purchase flow events (Product Viewed, Added to Cart, Purchased)
  • Profile attribute updates (plan type, feature usage)

Phase 3: Push Notifications (Week 3)

  • Permission request flow (soft ask + system prompt)
  • Push Received, Opened tracking
  • Deep link handling
  • Campaign: Onboarding push sequence
  • Campaign: Cart abandonment push

Phase 4: Optimization (Week 4)

  • Performance monitoring (screen load, API calls)
  • Offline behavior handling
  • Event batching tuning
  • Retention analysis (DAU/MAU, cohorts)
  • Push notification A/B testing

Next: SaaS product tracking patterns → SaaS Product Tracking