Say you launch an app for making and sharing a weekly meal plan. You get 20 signups on Monday. What you want to know on Tuesday is whether anyone made a plan they could use. Start by measuring that one result. Add more signals when you know what you'd do differently if a number changed.
What is the first question worth tracking?
Ask whether a new customer completes the job they came to do. For the meal planner, that's saving a plan with at least one meal. For a workshop booking app, it might be getting a confirmed seat. A first useful result like this is often called activation.
Write down the result, where you can see that it happened and how long you will give someone to reach it. Your earliest counts give you a starting point. If you later find a better definition, note when it changed so you can tell a measurement change from a change in customer behavior.
Which actions should you record first?
| What you want to know | Signal to start with | When it should count |
|---|---|---|
| Are people finding the app? | Meal planner landing page view | The chosen page was viewed. Include this if traffic sources affect your next decision. |
| Are people getting into the app? | Account created | The app created the account. A tap on “Sign up” can be recorded separately if you need to investigate that step. |
| Do they reach the first useful result? | Meal plan saved | The app saved a plan that meets the definition you wrote down. A failed save should never count. |
| Did the customer's first payment go through? | First payment confirmed | Count a customer's first successful payment once, after the provider confirms it was paid. Skip this measure if your product does not take payments. A payment can stay pending after checkout. |
There is no need to invent a second event for “first value” if the saved plan is already your definition of success. Use the smallest set of signals that answers your question. PostHog event capture · Stripe payment confirmation
How do you measure a return visit or a missed week?
Start with an action you already record. If the meal planner is meant to be used weekly, count how many customers who saved a plan save another in the next seven days. Allow the whole window to pass for the group before judging it. The same window would make less sense for an app used once a quarter.
A missed week is a result you can calculate from the absence of an action. It does not show why someone stayed away or prove they cancelled. If you want to see whether a new shopping-list feature helps, add a separate event when a list is successfully created. Count it among customers who could actually use the feature.
How do you prove your first event lands in the report?
Write the expected results before you connect anything. On paper, a failed save adds zero plan successes, a saved plan adds one, and reopening the existing plan adds no new save. This is enough to agree on what the measurement should mean.
If you want to run it, check the real destinations first. The test app must write only fictional records to a disposable store, send analytics to a separate test project and keep email, payments and other outgoing integrations test-only or disabled. Use a fictional account. If you cannot verify where those connections go, use the paper exercise.
Run the three cases and compare the report with the saved records. Verify that the report uses the right project, event name and date range. Inspect what was sent and remove unnecessary values such as names, addresses and meal notes. Keep extra collection, such as recording browsing sessions, off while checking the one event.
Traffic reports can answer where visits came from. If your question requires following the same signed-in customer's saved actions over time, choose a tool that supports this and decide what identifier is necessary before you send one. If you choose PostHog, follow its profile's example to check whether the funnel counts the right actions.
What should you do with your first week of results?
Suppose 20 accounts were created and six saved a plan. Try saving a plan yourself, then ask a few people who stopped what they expected to happen. Check that the other 14 had the same opportunity and time to try. The count tells you which step deserves attention. A conversation or observed test can help you decide what to change.
Keep a short note with the measurement, what you checked and the change you want to make. Next week, repeat the same check with the same event definition and report window. Add a new signal only when it would answer a question your current report cannot.