How to set up analytics in your web app (and respect privacy)

Good analytics for a web app starts with three or four questions you want answered, not with a tool. Track page views for traffic, then a short list of named events for the moments that matter (sign-up, the first time a user gets real value, payment, cancellation), send money-related events from your server rather than the browser, and only collect personal data you actually need and have permission for. Ten well-defined events beat two hundred automatic ones nobody reads.

This guide covers how to choose those events, how to name and send them, which kind of tool fits, how consent and privacy fit in, and how to check the data is right before you rely on it.

What should I measure first?

Write down the decisions analytics should help you make. For an early SaaS app they are usually:

1. Where do visitors come from, and which sources sign up? (Marketing.)
2. Do people who sign up reach the point where the product is useful? (Activation.)
3. Do they come back? (Retention.)
4. Do they pay, and when do they stop? (Revenue and churn.)

Each question maps to one or two events. Anything that doesn't serve one of them can wait.

Which events actually matter?

A starting set for most apps:

sign_up, login, begin_checkout and purchase are recommended event names in Google Analytics 4, so reports understand them automatically. Your activation event is specific to your product, and choosing it is the most useful exercise on this list: what is the first thing a user does that means they "got it"?

How should I name events and properties?

• Use one style everywhere: lower case with underscores, verb or object plus past tense (invite_sent, report_exported).
• Put details in properties, not in the name: plan: "pro" rather than purchase_pro.
• Never put email addresses, names or phone numbers in event names or properties. Google Analytics' terms prohibit sending personally identifiable information, and most other tools advise against it too. Use your internal user ID if you need to link events to an account.
• Keep a simple tracking plan (a shared spreadsheet is fine) with each event, when it fires and its properties. AI tools love to add tracking calls with slightly different names in every file; the plan is what keeps them consistent.

Should events come from the browser or the server?

Use the browser for what happens on screen: page views, clicks, onboarding steps. Use the server for anything that must be exact:

• Payments. Send purchase from the code that handles your payment provider's webhook, not from the "thank you" page. Visitors close tabs, block scripts and refresh pages; the webhook arrives regardless. If you're on Stripe, our guide to Stripe subscriptions in your app shows where that handler lives.
• Account changes such as plan upgrades and cancellations.

Browser-side analytics will always undercount somewhat, because ad blockers and privacy settings stop some scripts. That's acceptable for trends; it's not acceptable for revenue.

Which kind of analytics tool should I use?

There are three broad families, and many apps end up with one from the first and one from the second.

• Web analytics (Google Analytics 4, or privacy-focused tools such as Plausible, Fathom or Umami): traffic, sources, landing pages, campaigns. The privacy-focused ones are lighter, simpler and designed to work without cookies.
• Product analytics (PostHog, Mixpanel, Amplitude and similar): funnels, retention, what logged-in users do. These are built around users and events rather than pages.
• Your own database. Signups, payments and plan changes already live there. A simple weekly query is often more trustworthy than any dashboard.

Pick on what you need to answer, where the data is stored (some tools offer EU hosting), and whether you can self-host. Check each vendor's current pricing page rather than relying on old comparisons; plans change often.

How do privacy and consent fit in?

This is a plain-language overview, not legal advice. Rules depend on where your users are, so check with a lawyer for your situation.

• In the EU and UK, storing or reading non-essential cookies or similar identifiers generally needs the visitor's consent first. That covers most analytics and all advertising tags. Privacy-focused, cookieless tools are designed to reduce what you collect, but they don't automatically remove every obligation.
• If you use Google tags, Google's consent mode lets your banner tell its tags what the visitor accepted. Version 2 uses four signals: ad_storage, analytics_storage, ad_user_data and ad_personalization.
• Your privacy policy should list the tools you use and what they collect. Update it when you add one.
• Collect less. If you never send personal data to analytics, there is far less to protect, explain or delete later.

A common mistake in AI-built apps is a cookie banner that looks right but loads every tag before the visitor clicks anything. Open DevTools, clear cookies, reload, and check the Network tab before you accept: nothing from the analytics or ad tools should load yet.

How do I check the data is correct?

1. Use the tool's debug view. GA4 has DebugView; most product analytics tools have a live event feed. Click through your app and confirm each event arrives once, with the right properties.
2. Compare against your database. Count sign-ups and purchases for last week in both places. A gap of a few percent on browser events is normal; a gap on server events means something is broken.
3. Test in an incognito window with and without accepting the consent banner.
4. Tag your links. Use UTM parameters (utm_source, utm_medium, utm_campaign) on newsletters and ads, or they'll all show up as "direct".

Quick answers

Do I need Google Analytics? No. It's free and powerful, but a simpler privacy-focused tool plus your own database answers most early questions.

Why do my analytics numbers not match Stripe? Browser tracking misses some visits and purchases. Send revenue events from your webhook handler and treat the payment provider as the source of truth.

Can I send the user's email to analytics to identify them? Don't. Use an internal user ID instead.

How many events should I track at the start? Around five to ten, each tied to a question you actually ask.

Want help setting it up?

Analytics touches the front end, the server and your privacy policy at the same time, which is why it often ends up half done. Our custom software development team can implement a tracking plan, including server-side payment events, and keep it consistent through maintenance and support. You can start with the free health check to see which scripts your app loads today, or get in touch. For Google's list of event names, see the GA4 recommended events reference.