Measuring FlutterFlow app success requires tracking four metric categories: engagement (DAU/MAU ratio), retention (day-1, day-7, day-30 cohorts), revenue (MRR, ARPU, churn rate), and performance (load time, crash rate, Firestore read cost). Use Google Analytics via FlutterFlow's native integration for behavior tracking, Firestore for custom events, and build a simple admin KPI dashboard. Downloads and signups are vanity metrics — retained, paying users are what matter.
Why Most Founders Measure the Wrong Things
Total downloads, total signups, and monthly visitors are the metrics most founders track — and they are nearly useless for decision-making. A 10,000-user app where 9,500 users never return after day 1 is a failing product. A 500-user app where 400 users return weekly and 100 pay for a subscription is a healthy business. The metrics that actually predict success are: how often users return (engagement and retention), whether usage deepens over time (feature adoption), and whether the app generates sustainable revenue (monetization efficiency). This tutorial builds a measurement framework for all four dimensions.
Prerequisites
- A FlutterFlow app with real users (even 10-20 beta users are enough to start measuring)
- Google Analytics Firebase integration enabled in FlutterFlow Settings
- A 'appEvents' or 'analytics' Firestore collection for custom event logging
- Basic familiarity with Firestore queries and FlutterFlow Action Flows
Step-by-step guide
Define your core engagement metrics: DAU and MAU ratio
Define your core engagement metrics: DAU and MAU ratio
Daily Active Users (DAU) and Monthly Active Users (MAU) are the foundation of engagement measurement. The DAU/MAU ratio (also called 'stickiness') tells you what percentage of your monthly users return on any given day. A DAU/MAU of 20% is average; 50%+ is excellent (WhatsApp, Instagram level). To track this in your FlutterFlow app: create a Firestore 'sessions' collection. In your app's On Page Load action (Main Page), write a document to this collection: {userId (String), date (String 'YYYY-MM-DD'), sessionStart (Timestamp)}. This gives you one document per user per day. Query this collection in your admin dashboard to compute DAU (distinct userIds with today's date) and MAU (distinct userIds in the last 30 days). The ratio is your stickiness score.
Expected result: Every app open creates a session document in Firestore; your admin dashboard can query session counts to compute DAU and MAU.
Measure retention with day-1, day-7, and day-30 cohorts
Measure retention with day-1, day-7, and day-30 cohorts
Retention cohorts measure: of the users who first opened your app on date X, what percentage returned on day 1 (next day), day 7, and day 30? These are the most predictive metrics for long-term viability. Day-1 retention below 20% means your onboarding is failing. Day-7 retention below 10% means the core value proposition isn't delivering on its promise. In Firestore, store each user's 'firstOpenDate' (Timestamp) on their user document at registration. To compute cohort retention: for each first-open date, count users with that date, then count how many of those users have a session document 1 day later, 7 days later, and 30 days later. Build this query in a Cloud Function (it's too complex for client-side Firestore queries) and cache the result in a Firestore 'metrics' document updated nightly by a scheduled function.
Expected result: Your metrics document shows day-1, day-7, and day-30 retention rates for the most recent monthly cohort.
Set up Google Analytics with custom conversion events
Set up Google Analytics with custom conversion events
In FlutterFlow Settings → Firebase → enable Google Analytics. This automatically tracks screen views. For conversion events, define the 3-5 actions that constitute real value for your users (e.g., 'completed_onboarding', 'created_first_project', 'made_first_purchase', 'invited_teammate'). These are your activation events — users who complete them have significantly higher long-term retention. In FlutterFlow, add a Log Analytics Event action at each conversion point in your Action Flows. Use snake_case event names and include relevant parameters (e.g., for 'made_first_purchase': {amount: 29.99, plan: 'pro'}). View these events in Firebase Analytics console under Events. Set up conversion funnels to see where users drop off between signup and activation.
Expected result: The Firebase Analytics console shows your custom events with counts, and you can see the signup-to-activation funnel with conversion percentages at each step.
Track revenue metrics: MRR, ARPU, and churn rate
Track revenue metrics: MRR, ARPU, and churn rate
If your app is monetized, revenue metrics are more important than engagement metrics. Monthly Recurring Revenue (MRR) is the sum of all active subscription payments per month. Average Revenue Per User (ARPU) is MRR divided by total active users. Monthly churn rate is the percentage of paying users who cancel in a given month. Track these via Stripe webhooks: when a subscription starts (customer.subscription.created), update the user's Firestore document with {plan, planStartDate, mrr: planMonthlyPrice}. When a subscription cancels (customer.subscription.deleted), set {plan: 'free', churnedAt: now}. Aggregate these in a Cloud Function that runs nightly and writes summary metrics to Firestore: totalMRR, totalPayingUsers, avgArpu, monthlyChurnRate.
Expected result: Your admin KPI dashboard shows current MRR, number of paying users, ARPU, and monthly churn rate updated every 24 hours.
Build the KPI dashboard page in FlutterFlow
Build the KPI dashboard page in FlutterFlow
Create an admin-only page named 'KPI Dashboard'. Add a Conditional widget at the top to verify admin role. Build 4 metric card sections: Engagement (DAU, MAU, DAU/MAU ratio, avg session duration), Retention (day-1, day-7, day-30 percentages with trend arrows), Revenue (MRR, paying users, ARPU, churn rate), and Performance (avg page load time from analytics, Firestore read cost from Firebase console data). Each metric displays as a Card widget with a number, label, and trend indicator (up arrow in green if improved vs last week, down arrow in red if worse). Bind all metrics to a single Firestore document 'metrics/summary' that your Cloud Functions update nightly. Add a 'Last updated' timestamp below each section so you know when the data was refreshed.
Expected result: The KPI dashboard page shows all four metric categories with live data from Firestore, visible only to admin users.
Complete working example
1// Cloud Function: aggregateMetrics (scheduled, runs nightly)2// Updates Firestore metrics/summary document with KPIs34const functions = require('firebase-functions');5const admin = require('firebase-admin');67exports.aggregateMetrics = functions.pubsub8 .schedule('0 2 * * *') // 2am UTC daily9 .timeZone('UTC')10 .onRun(async () => {11 const db = admin.firestore();12 const now = new Date();1314 // ── DAU: users with a session today ──────────────────────────15 const today = now.toISOString().split('T')[0];16 const dauSnap = await db17 .collection('sessions')18 .where('date', '==', today)19 .get();20 const dauUsers = new Set(dauSnap.docs.map((d) => d.data().userId));21 const dau = dauUsers.size;2223 // ── MAU: users with a session in last 30 days ─────────────────24 const thirtyDaysAgo = new Date(now - 30 * 86400 * 1000);25 const mauSnap = await db26 .collection('sessions')27 .where('sessionStart', '>=', thirtyDaysAgo)28 .get();29 const mauUsers = new Set(mauSnap.docs.map((d) => d.data().userId));30 const mau = mauUsers.size;3132 // ── MRR: sum of active subscriptions ─────────────────────────33 const payingSnap = await db34 .collection('users')35 .where('plan', '!=', 'free')36 .get();37 let totalMRR = 0;38 let payingCount = 0;39 payingSnap.forEach((doc) => {40 const mrr = doc.data().mrr || 0;41 totalMRR += mrr;42 payingCount++;43 });4445 // ── Churn: users who cancelled in last 30 days ────────────────46 const churnSnap = await db47 .collection('users')48 .where('churnedAt', '>=', thirtyDaysAgo)49 .get();50 const churnedCount = churnSnap.size;51 const churnRate = payingCount > 052 ? (churnedCount / (payingCount + churnedCount)) * 10053 : 0;5455 // ── Write summary ─────────────────────────────────────────────56 await db.collection('metrics').doc('summary').set({57 dau,58 mau,59 dauMauRatio: mau > 0 ? (dau / mau * 100).toFixed(1) : 0,60 totalMRR: totalMRR.toFixed(2),61 payingUsers: payingCount,62 arpu: payingCount > 063 ? (totalMRR / payingCount).toFixed(2)64 : 0,65 monthlyChurnRate: churnRate.toFixed(1),66 updatedAt: admin.firestore.FieldValue.serverTimestamp(),67 }, { merge: false });6869 console.log(70 `Metrics updated: DAU=${dau} MAU=${mau} MRR=$${totalMRR.toFixed(2)}`71 );72 return null;73 });Common mistakes when measuring the Success of Your FlutterFlow Projects
Why it's a problem: Measuring success by total downloads or total signups alone
How to avoid: Define success in terms of activated users (users who completed a key value-delivering action), retained users (returned after day 7), and revenue metrics. Set targets for these metrics before launch so you have a benchmark to measure against.
Why it's a problem: Tracking every possible user action from day one, creating metric overload
How to avoid: Start with exactly 5 metrics: DAU/MAU ratio, day-7 retention, MRR, one activation event rate, and crash-free session rate. These 5 tell you whether your app is healthy. Add more metrics only when a specific business question requires them.
Why it's a problem: Computing retention metrics by querying all raw session data client-side on page load
How to avoid: Pre-compute all metrics in a scheduled Cloud Function that runs nightly and writes the results to a single 'metrics/summary' Firestore document. The admin dashboard reads only this one document — one Firestore read, instant load time.
Best practices
- Set your KPI targets before launch, not after — 'we want 30% day-7 retention by month 3' is actionable; measuring without targets produces interesting data but no decisions.
- Review your KPI dashboard weekly (not daily) to spot trends rather than noise — day-to-day variance in small user bases is statistically meaningless.
- Segment your metrics by user cohort (sign-up month, acquisition source, plan type) — aggregate averages often hide important differences between user groups.
- Log a 'first value moment' event the instant each new user achieves the core value your app promises — the time-to-first-value metric directly predicts day-7 retention.
- Track Firestore read and write costs in the Firebase Console alongside user metrics — rising costs with flat user growth signals inefficient queries that need optimization.
- Set up Firebase Crashlytics alongside Analytics so crash rate appears in your performance KPIs — crashes are invisible in user behavior data but directly cause uninstalls.
- Share your weekly KPI summary with your beta users who are builders or founders — their perspective on what the numbers mean is often more valuable than your own interpretation.
Still stuck?
Copy one of these prompts to get a personalized, step-by-step explanation.
I'm building a FlutterFlow app (subscription SaaS, $29/month Pro plan). I want to set up a metrics tracking system in Firestore. I'll have: a 'sessions' collection (one doc per user per day), a 'users' collection (with plan, planStartDate, churnedAt fields), and a 'events' collection for custom analytics. Write me a Firebase Cloud Function that runs nightly, computes DAU, MAU, MRR, paying user count, ARPU, and monthly churn rate from these collections, and writes the results to a Firestore 'metrics/summary' document.
I have a FlutterFlow admin KPI dashboard page. It reads from a Firestore document 'metrics/summary' with fields: dau (Int), mau (Int), dauMauRatio (String), totalMRR (String), payingUsers (Int), monthlyChurnRate (String), updatedAt (Timestamp). Show me how to display these as metric cards in FlutterFlow: a 2-column GridView with Cards, each showing the metric name, value, and an up/down trend indicator comparing to the 'metrics/previousWeek' document values.
Frequently asked questions
What is a good DAU/MAU ratio for a FlutterFlow app?
It depends on your app category. Messaging and social apps target 50%+ DAU/MAU (users open the app most days). Productivity tools typically see 20-30%. Occasional-use apps (travel booking, job search) may only see 5-10% and that is acceptable for their use pattern. Compare your DAU/MAU to similar apps in your category, not to generic benchmarks.
When should I start measuring metrics — before or after launch?
Set up analytics tracking before your first public user sees the app. Retroactively adding analytics means you have no baseline data for your first users, who are often your most valuable early adopters. The cost of adding Google Analytics and a session logging action in FlutterFlow is 30 minutes — do it before you share your beta link.
How do I measure performance metrics like load time in FlutterFlow?
Google Analytics Firebase automatically tracks screen engagement time. For custom performance metrics like Firestore query duration, use a Custom Action that records DateTime.now() before and after a query, computes the difference in milliseconds, and logs it as a custom analytics event. Track p95 query times (the 95th percentile) — average times hide slow outlier experiences.
What is a realistic day-7 retention benchmark for a new app?
Industry benchmarks vary widely: top apps (Facebook, Instagram) achieve 60%+ day-7 retention. The median across all app categories is 12-15%. For a new consumer app, 20-25% day-7 retention is healthy. For a B2B productivity tool with paying users, 40%+ is achievable. If you're seeing less than 10% day-7 retention, prioritize understanding why users leave before spending any resources on growth.
How do I know if my Firestore costs are growing sustainably?
Check the Firebase Console → Usage and Billing → Firestore section monthly. Your Firestore cost should grow roughly proportionally to active user count — if costs are growing faster than users, you have a query efficiency issue. The key ratio to watch: Firestore reads per daily active user per day. If this exceeds 500-1000 reads per user per day, you likely have unbounded queries that need pagination or caching.
Should I use a third-party analytics tool like Mixpanel or Amplitude instead of Firebase Analytics?
Firebase Analytics (Google Analytics) is sufficient for most FlutterFlow apps up to $1M ARR. Mixpanel and Amplitude offer more powerful cohort analysis, funnel visualization, and retention reports, but cost $25-200/month and require more complex integration. Start with Firebase Analytics and migrate to a dedicated tool when you find yourself constrained by what Firebase can answer — typically when you have 10,000+ monthly active users.
Talk to an Expert
Our team has built 600+ apps. Get personalized help with your project.
Book a free consultation