Minimum App Analytics: Three Events and One User Identifier
What Disappears When You Market Without Measurement
What disappears is causality. Your ad console and the app stores will tell you how much you spent and how many installs you received. What the installer did after opening the app is visible only inside the app. Skip that stretch and the question of which channel brought real users stays a guess forever.
Store dashboards give you installs, uninstalls, ratings and country distribution. Ad consoles give you impressions, clicks and cost per install. Both are numbers from outside the product. Whether a person stalled on the first screen, made it through signup, or used the core feature even once appears on neither. When the inside of the app is dark and you keep optimizing ads, the objective quietly collapses into cost per install. The campaign that manufactures the cheapest installs wins, even when most of those installs vanish on day one.
The second casualty is the basis for product argument. Without measurement, meeting-room reasoning fills with impressions. One person says onboarding is too long, another says people abandon it even when it is short, and the loudest voice decides. After you change a screen you cannot tell whether it improved anything, so you cannot order the next round of work either. Let that run a few months and the team starts adding features instead of improving them, because visible additions feel safer than improvements nobody can verify.
The third loss is the largest. Measurement is not retroactive. An event you add today accumulates from today. The weeks right after launch are the only stretch in which people meet the product for the first time, and without records that stretch cannot be reconstructed. When a partner or investor later asks about early reception, there is no material to show. Losing data you cannot regenerate costs more than a few weeks of ad budget.
In practice, the more common failure is not a decision to skip measurement. It is a tracking plan drawn so large that nothing gets implemented. Once the event list reaches forty items it slides to the bottom of the development schedule, ships in that state, and after launch nobody owns it. Even when the code lands, half the events fire in the wrong place and months pass before anyone notices. The starting point should therefore be a minimum design that will certainly survive, not a complete one.
The goal of a minimum design is not to collect less data. It is to secure numbers you can trust first. Three numbers with clear definitions are far more useful for decisions than forty nobody believes. Once those three run steadily, expanding is easy. Reverse the order and most teams end up back at the beginning.
The Test for Cutting Down to Three Events
There is one test. When that number moves, does the team actually behave differently. Events that pass it tend to converge on three: the moment someone opens the app for the first time, the moment they experience the core value once, and the moment they repeat that experience. Call them acquisition, activation and repeat.
The first is the initial open. Most analytics tools collect first launch and session start automatically, so there is little to define yourself. Automatic collection differs by tool, though, so check what already arrives before designing the rest. If you skip that check and hand-instrument the same moment, your numbers double at the very first step.
The real design work sits in the second event. Activation is the moment a user first holds the value the product promised. Its definition changes with the product. For an attendance service, one recorded attendance entry is a candidate. For a service that connects learners with teachers, it is the moment a connection request actually reaches the other side. For a job service, it is a submitted application received. The common thread is that a result was left behind rather than a screen being viewed. If a record was created or something was delivered to another party, that person used the product instead of browsing it.
The third event is that same action repeated. The common mistake here is inventing a separate return-visit event. Two names for one action split the definition and the totals stop reconciling. Receive the second event again and let the identifier decide whether it was the same person. Repetition is a property of per-person aggregation, not of an event name. In that sense the third event is closer to a new question than to a new event.
What you leave out matters as much as what you include. Button taps, screen views, scroll depth, banner impressions and toggle changes belong outside the initial list. They can be added later, when a specific question needs them. Include them from the start and the naming convention loosens, the number of places needing verification grows, and every release carries a review cost. The longer the list, the higher the odds the entire list ends up abandoned.
Cutting to three is a consensus exercise, not an engineering one. When the definition of activation is written as one sentence and product, engineering and marketing all agree to that sentence, half the measurement work is done. Without it, people read the same dashboard and tell different stories. Write the conditions alongside the definition: whether cancelled requests count, whether test accounts are excluded, how failed attempts are handled. Only with those lines is the sentence complete.
Why You Need a User Identifier and How to Handle It
Without an identifier you cannot tell whether three events came from three people or one. Repetition presumes a single subject by definition, so return visits and retention are simply not computable without it. Identifiers touch personal data directly, though. Handle them on a foundation of consent and minimal collection, and remember requirements differ by region.
In practice identifiers come in two layers. One is the anonymous identifier a tool issues when the app is installed. It attaches to an installation rather than a person, so deleting and reinstalling produces a different value. The other attaches to a signed-in account and follows the person across devices. You use both layers so that pre-login and post-login behavior can be read as one continuous thread. Without logic that links the two values at sign-in, everything a person did before registering stays severed from everything after.
The core of this section is what you use as the account identifier. Do not use an email address, phone number, name, employee number or any civil identification number directly. Mint a meaningless value that carries significance only inside your own systems. The reason is plain: analytics systems get opened by many people, exported to other tools, and sometimes wired into external dashboards. A value that enters is hard to fully retract. The same principle governs event parameters. Keep search terms, note contents, addresses, contact details and anything else that can single out a person out of parameters. Shipping free-text input verbatim is the most common route to an incident.
Consent is the starting condition for measurement. Do not fire events before consent, and do not queue them for later delivery either. Write the consent screen in language a person can read, stating what is collected and for what purpose. Provide a path inside the app to withdraw consent. Decide in advance what stops and what remains when someone withdraws. An app with no withdrawal flow has no mechanism to respond when a problem arrives.
Minimal collection is both a principle and a defensive line. Do not attach attributes without a clear purpose. Precise location, contact lists and device advertising identifiers deserve attention only when the question they answer is explicit. Set a retention period as well. Indefinite storage is a deferred decision, not a policy. When an account deletion request arrives you must be able to find the analytics-side identifier, so decide in advance where the mapping between internal accounts and analytics identifiers lives and in what form. Starting the search after the request is late.
Legal requirements differ by region. Korea, Vietnam, Europe and other jurisdictions do not align on how consent is obtained, what must be disclosed, or how cross-border transfers are handled. App store policies impose their own requirements separately from law. Apps aimed at children, or handling sensitive categories such as health or finance, carry additional conditions. This article covers design principles only and asserts no specific provision. Before real deployment, check the requirements of the regions you serve and the store policies that apply, and seek legal review where needed.
Minimum Conventions Against Duplicates and Gaps
Four lines are enough to start. Name things one way, fix the firing moment in one sentence, block double sends on retries and screen returns, and handle offline delivery so nothing is lost. Write those four lines as a single-page table and keep it next to the code.
Naming rules look trivial and outlast everything else. Pick one convention, such as lowercase with underscores and a fixed object-then-action order, and allow no exceptions. Reserved names, length limits and parameter count limits differ by tool, so read that tool's documentation before you begin and name within what you verified. Naming from memory and renaming later splits your data at the moment of the rename.
Most incidents originate at the firing moment, where two different occurrences get mixed under one name. If you have not decided between sending on button tap and sending on a successful server response, failed attempts are counted as successes. For actions that leave a result, anchoring on the successful response is easier to interpret. If you also want to see attempts, that is a separate question and can become a separate event later. Writing the definition as a sentence spares whoever touches the code months later from re-deciding it.
Duplicates accumulate quietly. Returning to a screen, pressing back, resuming from background, retrying after a network failure and double-tapping quickly are the usual routes. The remedy is simple: mint one unique key per occurrence and send only once for that key. Where blocking on the client is hard, you can collect first and drop duplicate keys during aggregation. Either way, the team must know where deduplication happens.
Gaps are the opposite failure, where events raised during a force-quit or a network outage simply vanish. Many tools buffer locally and send later. Behavior and buffering conditions vary, so verify how your tool actually handles it and set expectations within that. A dashboard that updates slowly because of batched delivery is not a defect. Without knowing that distinction, teams spend hours hunting a bug that does not exist.
Verification by eye comes before automation. Before a release, fire all three events once on a real device and watch them arrive in whatever real-time inspection view the tool provides. Tracking code fails without stopping the app, so months can pass unnoticed. Keep a one-page event dictionary listing name, firing moment, parameters, owner and the app version that introduced it inside the code repository, and edit it in the same change that edits the event. Documentation that drifts away from the code goes stale without exception.
What to Solidify Before Adding More
The condition for expanding is a state, not a duration. When the three events arrive without interruption for several weeks, everyone on the team reads those numbers the same way, and they still fire correctly after an app update, expand then. Expand earlier and you only add noise until nobody opens the dashboard.
The first condition is stability. Measurement breaks silently. Restructuring a screen, upgrading a library or editing a conditional can drop an event while the app still looks fine. Add one line to the release checklist confirming all three events survived. When a weekly chart suddenly shows a stretch near zero, the cause is more often broken tracking than changed behavior.
The second condition is agreement on interpretation. Write the activation definition as a sentence and post it where the whole team sees it. If the definition must change, record the date and stop comparing numbers across that boundary. Reading two differently defined stretches as a single trend line makes you see a change that never happened. Fixing what a number means matters more than increasing how many numbers you have.
The third condition is the existence of a question. When adding an event, write down the question it answers and the action that would change based on the answer. If those two lines cannot be written, the event is not needed yet. Once the conditions hold, worthwhile additions include acquisition source attribution, payment or conversion moments, the steps where drop-off concentrates, and comparison experiments. Each carries a different cost: attribution requires integration with ad tooling, payment demands designing for failures and refunds, and experimentation consumes analyst time continuously.
Yeowubie Interaction builds for clients and operates its own products at the same time. onSpots, an attendance service, Langtori, a matching and mapping service connecting Korean language learners with teachers, and Job Connect VN, a job service for the Vietnamese market, each define activation differently. Same company, different core actions, different content in those three events. That is also why this article carries no measurement figures from our own products. We do not yet have numbers organized enough to publish, and we do not invent numbers that do not exist.
The order, then, is this. Define activation in one sentence, instrument three events, link the anonymous identifier to the account identifier, strip personally identifying values out of parameters, write the anti-duplicate and anti-gap conventions on one page, and verify at every release. Once those six hold, everything after is straightforward. Teams that fail at their first instrumentation usually did not design too little. They started too big.