Measuring Product Success Without Surveilling Your Users

When a Nigerian fintech or enterprise software company deploys Google Analytics 4, a session recording tool like Hotjar, and a product analytics platform like Mixpanel, with full event tracking enabled and full cookies running — they have assembled a surveillance apparatus. Not from malicious intent; from default configuration, vendor recommendations, and the reasonable belief that more data is better.

The problem is multi-layered. Under NDPR, collecting behavioural data requires a legal basis — typically consent, because behavioural tracking for analytics does not fit most other bases. Without proper consent, the tracking is non-compliant regardless of how it is used. The data collected is also processed by third-party vendors (Google, Hotjar, Mixpanel) whose data processing agreements need to be in order. And sitting underneath all of this: most companies use a small fraction of the data they collect, making the compliance overhead and user trust cost a poor trade for the analytical value actually extracted.

This article describes a privacy-respectful approach to product measurement that provides the analytical insight product teams actually need without the surveillance overhead they usually cannot justify.

What You Actually Need from Product Analytics

Product analytics answers specific questions that improve the product. Understanding what those questions are first, then designing the data collection to answer them, produces better data with less collection than deploying broad tracking and trying to find insights afterward.

The core questions for most Nigerian business software products:

Adoption and engagement:

Are new users completing onboarding and reaching the core product experience?
Which features are used regularly and which are not?
What is the retention rate: what percentage of new users are still active 30/60/90 days later?

Task completion and friction:

Are users successfully completing the key workflows (the jobs the product was hired to do)?
Where do users abandon workflows they started?
What errors are users encountering and how often?

Business outcomes:

For SaaS: conversion from trial to paid, expansion from base tier to higher tiers, churn rate
For transactional products: successful transaction rate, failure rate by failure category
For operational software: which teams use the system and how heavily?

These questions require relatively specific event data — not comprehensive session recordings of every mouse move.

The Data Minimisation Model

Design analytics collection from the question, not from the data. For each analytics event you instrument, articulate:

What question does this answer?
How will we use the answer?
Is the data collected necessary and sufficient for that purpose?

Example using onboarding analysis:

Question: Where are new users abandoning the onboarding flow?
Events needed: onboarding_step_started (step name), onboarding_step_completed (step name), onboarding_completed, onboarding_abandoned (step name at abandon)
What is NOT needed: mouse coordinates on each screen, recording of what text the user typed, time spent reading each screen sentence-by-sentence

The minimal instrument provides the conversion funnel by step. It does not collect the user's session replay. Both provide the answer to "where do users drop off"; only one creates a surveillance dataset.

Privacy-Preserving Analytics Approaches

Aggregation Over Individual Tracking

Many analytical questions can be answered with aggregated data rather than individual user tracking. Instead of "what did each user do," the question is "what did users as a group do." Aggregate answers have less precision (you cannot drill down to a specific user's session) and are less likely to identify individuals — which is exactly the privacy benefit.

Tools that aggregate at collection rather than at query time include Fathom Analytics, Plausible Analytics, and Umami. These tools are designed as privacy-first and typically do not require cookie consent for GDPR/NDPR purposes because they do not create individual-level profiles.

For Nigerian businesses who need basic web analytics without the compliance burden of full GA4 implementation, Plausible is a direct substitute that is trivially compliant and frankly provides better default dashboards than GA4 for most use cases.

Anonymisation of Collected Data

For product analytics that tracks authenticated user events (inside your application, after login), anonymisation is an important design choice. The analytics platform (whether a third-party like Mixpanel or a self-hosted solution like PostHog) should receive an anonymous user identifier, not the user's email, phone number, or name.

If you need to investigate a specific user's journey (for support or debugging), the link between anonymous ID and identity should exist only in your own systems — not in the analytics vendor's systems.

Consent-First Instrumentation

Where consent is your legal basis for behavioural tracking (and it typically is, under NDPR), the consent must precede the tracking. The architecture:

User loads the application without tracking enabled
Consent is obtained (through the cookie/tracking consent mechanism)
Analytics instrumentation is activated only after consent is granted

If the user opts out or withdraws consent, tracking must stop. The analytics platform must support consent-aware event collection — several (including PostHog) support this natively.

The consent paradox: Tracking opt-out rates are typically 40–70% in regions with active consent management (Europe). This means 40–70% of users are invisible to analytics that depends on consent. This is a real analytical limitation and is inherent to the consent-required model. The practical mitigation is to use aggregate, consent-free analytics (Plausible-style) for top-level metrics, and reserve consent-required detailed behavioural analytics for opted-in users, accepting that opted-in users may not be representative of all users.

Self-Hosting Analytics

For Nigerian businesses with developer capability, self-hosted analytics tools eliminate the third-party data transfer concern entirely. Data stays on your infrastructure — within Nigeria or in your chosen cloud region — and is not shared with any vendor.

PostHog Community Edition: The most comprehensive open-source product analytics platform. Feature flags, session recording (opt-in, consent-gated), event tracking, funnel analysis, retention analysis. Self-hosted on your infrastructure. Zero data sharing with third parties.

Umami: Self-hosted web analytics. Simple, performant, cookie-free by default.

Matomo: Self-hosted Google Analytics alternative. Comprehensive but feature-rich to the point of complexity for many use cases.

Cost: A self-hosted analytics stack on a small cloud instance runs approximately ₦15,000–₦25,000 per month in infrastructure cost for a medium-sized application. Compare this to the NDPR compliance overhead of third-party analytics, the vendor subscription cost of paid analytics platforms, and the data residency uncertainty of sending user data to US-based vendors.

Session Recording: The High-Risk, High-Value Tradeoff

Session recording tools (Hotjar, FullStory, LogRocket) capture what users do visually — where they click, how far they scroll, where they seem confused. The product insight value is genuine; the privacy implications are substantial.

Session recordings can capture sensitive information entered by users: form field contents, financial data, personal information. Even when recording tools mask input fields, the sophistication required to verify complete data masking is significant. Session recordings are stored on the vendor's servers. The legal basis for session recording under NDPR requires explicit, informed consent — "we record video of your screen activity" consent, not buried in terms.

If session recording is used:

Consent must be explicit and specific
Input fields containing sensitive data must be masked
Data retention for recordings must be defined and enforced (30–90 days is typical)
Access to recordings must be controlled (not all employees should be able to watch any user's session)
Third-party input on the recording (an HR candidate's application, a patient's health form) must be masked

For most Nigerian business software, session recording is most valuable for usability testing during development rather than as a permanent analytical tool. Run a recording session with a defined cohort of opted-in users during a new feature's first month, then turn it off and analyse the results.

The Metrics That Actually Matter

The final point: resist the measurement maximalism that says more metrics equals better understanding. Define the five metrics that most directly link to product success. Review them weekly. Act on deviations.

For most Nigerian business software companies:

Weekly Active Users (or whatever frequency makes sense for the use case)
Core workflow completion rate (the job the product was hired to do)
Error rate (broken experiences per session)
Retention cohort (30-day retention by signup cohort)
One business outcome metric (conversion, revenue per user, NPS)

These five metrics, measured consistently, provide more actionable insight than 200 events in a dashboard that nobody looks at. Build the measurement infrastructure that keeps these five accurate and current. Add detail when a specific question demands it — not as a default.

Privacy-respecting analytics is not a compromise of analytical quality. It is a discipline that forces the question "what do we actually need to know?" — and that question produces better products at less cost and less risk than surveillance maximalism.

Privacy-First Analytics for Nigerian Businesses — Choosing analytics tools that respect user privacy
A Cookie Consent System That Works and Converts — Building consent UX that respects users
Nigerian Tech Regulatory Landscape 2026 — Complete reference guide to Nigerian technology regulation