# Find the biggest funnel drop-off

- **Canonical URL:** https://playbook.affpartners.io/en/practices/quality-funnel/index.html
- **Markdown version:** https://playbook.affpartners.io/en/practices/quality-funnel/index.md
- **Module:** Product quality
- **Time:** 60 minutes for the first audit

You do not need to master every analytics report at once. Map five clear steps, identify the largest drop-off, and choose one change for the next release.

## Outcome

A five-step funnel table with one drop-off point, a likely cause, and an owner for the next change.

## Find one weak spot in the journey, not every problem at once

Think of the user journey as five doors. At every step some people leave. Your task is to see which door loses the most users, understand the likely cause, and fix that first.

## What you will need

- **Access:** AppMetrica, Firebase, Amplitude, or any report where user actions are visible.
- **Colleague:** An analyst or developer for 15 minutes if you do not know the event names.
- **Period:** The last 14–30 days without major incidents or ad-driven traffic spikes.

## Terms in plain language

- **Funnel — A sequence of steps leading to an outcome:** Definition: It compares user counts at each step and reveals the largest drop-off. Example: Install → first open → registration → first useful action → return visit.
- **Conversion — The share of people moving to the next step:** Definition: Shows how many people who started a step completed it or reached the next one. Example: 80 registrations completed from 100 started: 80 ÷ 100 × 100% = 80% conversion.
- **Analytics event — A record of a specific user action:** Definition: The app sends an event when a user opens a screen, taps a button, or completes an action. Example: registration_started and registration_completed reveal how many people abandon registration.
- **FTD — A user's first deposit:** Definition: The first time a registered user funds their account. It is the outcome of the whole journey, not a single button to promote more aggressively. Example: If 100 people complete registration and 24 make a first deposit, FTD conversion is 24%.
- **D1 / D7 / D30 — Return after 1, 7, or 30 days:** Definition: D means day. The metric shows what share of a new user group returned after the selected number of days. Example: D7 = 18% means 18 of every 100 new users returned after seven days.
- **Crash-free rate — The share of users without an app crash:** Definition: The closer it is to 100%, the fewer users experienced an app crash during the selected period. Example: 99.5% crash-free users means 0.5% experienced at least one crash.
- **ANR — An Android app freeze:** Definition: Android records an ANR when the interface does not respond to the user for too long. Example: The user taps a button, the screen freezes, and Android offers to close the app.

## When to use it

Registrations or first useful actions are declining, users complain about the journey, and the team does not know what to fix first.

## Where to get the data

Choose the option the team already has. If analytics is not set up, start with a manual check — the practice will still produce a result.

- **AppMetrica or Firebase**
  - **Source:** Open the “Funnel” report and add: first launch → registration started → registration completed → first useful action → repeat visit.
  - **If access is unavailable:** If the event names are unknown, ask a developer to send the list of events for registration and the first useful action.
- **Spreadsheet or BI report**
  - **Source:** Take the number of users at each step for a single period. Do not mix iOS and Android in the first check.
  - **If access is unavailable:** Five numbers are enough. Do not wait for a perfect dashboard to spot a large drop-off.
- **If there are no events yet**
  - **Source:** Walk the journey on a clean install ten times on iOS and Android. Record errors, delays, and confusing screens.
  - **If access is unavailable:** Write a short technical specification for the events — that will be the first result of the audit.

## Run your first audit in five steps

1. **Draw the journey.** Write down five steps as simple user actions — no internal screen names or team jargon.
   - **Where to do it:** A sheet of paper, FigJam, or the first column of the final table.
   - **Example:** Install → first launch → registration started → first useful action → repeat visit.
2. **Put five numbers next to the steps.** Record how many unique users reached each step during the same period.
   - **Where to do it:** The “Funnel” report in AppMetrica / Firebase, or an export from an analyst.
   - **Example:** 1,000 launched the app, 820 started registration, 460 completed it.
3. **Calculate the conversion between steps.** Divide the number at the next step by the number at the previous one and multiply by 100%. The lowest percentage is the first candidate to investigate.
   - **Where to do it:** In the table, next to each step.
   - **Example:** 460 ÷ 820 × 100% = 56%. That means 44% of those who started registration did not finish it.
4. **Verify the cause.** Review errors and support tickets, then walk through the step yourself. Do not change the interface until you have ruled out a technical problem.
   - **Where to do it:** Crash reports, support tickets, and a clean install of the app.
   - **Example:** On Android 12 the confirmation code arrives late, and resending it is not explained.
5. **Choose one change.** Record the change, its owner, and the metric you will compare after the release. Do not put several screens into your first experiment.
   - **Where to do it:** A task in the backlog or a short plan for the next release.
   - **Example:** Fix code resending; owner — the Android team; check — registration completion rate after 14 days.

## Practical examples

- **Long load after registration:** The user created an account but waits 40 seconds for the first screen and closes the app. The priority is speed and a clear loading status — not another form field.
- **Different journeys per platform:** On Android, registration is completed noticeably less often than on iOS. Check the errors of the specific version first, then change the interface.

## Finished artifact: One table for one team decision

You do not need a big report. Fill in five rows and highlight the one drop-off the team will address in the next release.

| Step | Users | Conversion | What we see |
| --- | --- | --- | --- |
| First launch | 1,000 | — | Starting point |
| Started registration | 820 | 82% | Acceptable drop-off |
| Completed registration | 460 | 56% | Main drop-off point |
| Completed the first useful action | 350 | 76% | Check the hints |
| Returned on D1 | 150 | 43% | Watch after the fix |

Conclusion: check registration on Android first — errors, required fields, and waiting time. Owner: product + Android developer.

## Checklist before the decision

If an item is missing, log it as a separate task — do not guess.

- [ ] The five steps are named as user actions, not internal screens.
- [ ] Each step has a number for the same period.
- [ ] iOS and Android are checked separately.
- [ ] Technical errors and support requests were reviewed before changing the interface.
- [ ] One change is chosen, with an owner and a review date.

## How to know the change helped

- **Main signal:** Conversion at the problem step grew compared with the period before the release.
- **Guardrail metric:** Errors, crashes, and support requests at neighboring steps did not grow.
- **Business result:** More users reached the first useful action and FTD without extra pressure.

## Key rule

FTD is the user's first deposit and the outcome of the whole journey. Make the journey clear and reliable first, then check the business result.

---

- [HTML version](https://playbook.affpartners.io/en/practices/quality-funnel/index.html)
- [All practices](https://playbook.affpartners.io/en/)