After launch, every business owner asks the same question: is the app working? Store downloads and website visits feel like the answer, but they say little about whether people actually use the product, or whether it is helping the business.
Analytics tools make it easy to collect everything and understand nothing. This post covers the small set of measurements that matter for most business apps and web products, how to set them up, and what to ignore.
Start from the core action
Every product has one action that represents real value: a completed booking, a paid order, a job closed by a technician, a quote requested. Identify it first. For a booking app like Pro Clean+, it is a confirmed booking. For a field-service platform like NeonTask, it is a work order completed and recorded.
Most of your analytics should revolve around that action: how many people reach it, how quickly, how often they come back to do it again, and where they drop off before it.
The measurements that matter
1. Activation
What share of new users complete the core action for the first time? A user who installs the app and never books has not really started. Track the time from sign-up to first core action too; a long gap often points to friction in onboarding.
2. The main funnel
Break the path to the core action into steps and measure each:
- Opened the app or landing page.
- Chose a service or product.
- Selected a time or options.
- Entered details.
- Confirmed.
The step with the biggest drop is where to focus. Often it is something simple: a confusing form, an unexpected price, no available slots, a forced sign-up too early.
3. Retention
Do users come back? Look at cohorts: of the users who joined in a given week, how many returned in the following weeks or months? Retention shows whether the product is genuinely useful. For services people buy occasionally, such as cleaning or repairs, look at repeat purchase over months rather than daily usage.
4. Business outcomes
Connect product data to the business: bookings, revenue, average order value, cancellations, no-shows. These are often already in your own database, and can be reported from your admin without any analytics tool. See what your admin panel needs.
5. Quality signals
Usage numbers mean little if the app crashes. Track:
- Crash-free sessions on mobile.
- Error rates on the backend.
- Slow screens and endpoints.
- Failed payments or failed submissions.
These come from crash reporting and monitoring rather than product analytics. See monitoring and alerts for a small product.
6. Acquisition, briefly
Where do users come from? Search, ads, social media, referrals, word of mouth. Knowing this helps decide where to spend on marketing. Use campaign parameters on links you share so traffic is attributed correctly.
What to ignore, or at least not obsess over
- Total downloads. They grow forever and say nothing about use.
- Page views and screen views on their own.
- Time spent in the app for task-based products. If people book faster, less time is good.
- Dozens of dashboards nobody opens.
- Vanity metrics in investor-style charts that do not change any decision.
A useful test: if a number changed tomorrow, would you do anything differently? If not, it does not need a dashboard.
Setting up tracking without chaos
Define a tracking plan
Before adding code, write a short list of events with names and properties:
- booking_started (service)
- slot_selected (service, days_ahead)
- booking_confirmed (service, value)
- quote_requested (service, has_photos)
Keep names consistent and few. Twenty well-defined events beat two hundred random ones.
Track key events on the server
Events that matter for the business, such as a confirmed booking or a payment, should be recorded on the server when they actually happen, not only in the app. App-side tracking can be blocked, lost offline or duplicated. Use app-side events for interface steps, server-side for outcomes.
Identify users carefully
Link events to a user ID after sign-in so you can follow journeys across devices, but avoid sending names, phone numbers or emails into analytics tools. An internal ID is enough.
Respect privacy and platform rules
Ask for consent where the law requires it, explain tracking in your privacy policy, and follow app store rules on tracking disclosures. Rules differ between countries, so check what applies where your users are. Collect what you need for decisions, nothing more.
Choose tools sensibly
You need, at most:
- A product analytics tool for events, funnels and retention.
- Crash reporting for the mobile app.
- Error tracking and monitoring for the backend.
- Website analytics and Google Search Console for the marketing site. See website speed and Core Web Vitals.
Many products can start with fewer. Your own database already holds the most important business numbers.
A weekly review
Analytics only help if someone looks at them. A short weekly review is enough for most small teams:
- Core actions this week compared with recent weeks.
- The main funnel: did any step change?
- Retention of recent cohorts.
- Crashes and errors.
- One question to investigate or one change to test next week.
Write down what you changed and when, so you can connect changes to their effects later.
Support messages are data too
Calls, WhatsApp messages and emails to your team are one of the richest sources of insight, and they rarely appear in analytics tools. Tag them by topic for a few weeks: "could not find a slot", "payment question", "app crashed", "wanted to change a booking". The most frequent tags often point straight at the next improvement, and they explain the drops you see in the funnel. A simple shared spreadsheet is enough to start.
Experiments without a big team
You do not need complex A/B testing to learn. Change one thing at a time, such as a simpler first screen, fewer form fields or a clearer price display, and compare the funnel before and after over a few weeks. With low traffic, results are noisy, so look for large, consistent changes rather than small differences.
Talking to a few users and watching them use the app often reveals more than numbers alone. Combine both.
Using analytics to plan the next version
Your "later" list from the first version should now be ranked by evidence: which problems do the funnel, retention and support messages point to? Build what removes the biggest drop-off or brings users back, not what was loudest in the planning meetings. See how to scope the first version of your app and app maintenance after launch.
Common mistakes
- Tracking everything with no plan, then trusting none of it.
- Measuring outcomes only in the app, so numbers do not match the database.
- Sending personal data into analytics tools.
- Ignoring crashes and errors while studying funnels.
- Never reviewing the numbers after the launch excitement fades.
Summary
Pick the core action, measure activation, the funnel and retention, connect them to business outcomes, and keep an eye on quality. Track a small set of well-named events, key outcomes on the server, and review weekly. That is enough to know whether your product is working and what to do next.
If you want help setting up analytics that answer real questions, see my work and get in touch.