Blog · Board and management reporting · Software
App user behavior analysis compares completed tasks and return activity in existing exports. Build a user-level worksheet, calculate funnel completion and returning-user rates, and compare signup cohorts with equal observation windows.
App user behavior analysis compares task completion and return activity from the app exports your company already has. Put each eligible user on one row, define equal observation windows, and calculate funnel and returning-user rates separately. This reveals where behavior changed without confusing repeated activity with additional users.
Suppose a US subscription software company wants to know whether new users finish creating their first report and return afterward. The product manager owns the task definition; the operations analyst prepares the existing export and reconciles the counts. Customer success adds context about onboarding changes or customer mix.
Choose a precise completion action. Opening the report screen is a start; successfully saving the first report is completion. Keep those definitions consistent across the periods being compared. The broader product funnel analysis guide covers selecting stages; this example focuses on calculating an agreed sequence from supplied records.
Use an existing user-summary export with a stable user key, signup date, first task-start date, first valid completion date and first qualifying activity in the later return window. If the source has repeated activity rows, obtain a distinct user summary before applying these formulas. Summing activity rows would count busy users repeatedly.
The starting population includes all eligible signups, including people with no subsequent activity. An activity-only export cannot supply the denominator for signup conversion or signup-based return rates.
For this example, the initial task window runs from signup through the following six calendar days. The return window covers days seven through thirteen after signup. Both use the same business timezone, and the export is complete through September 21, 2026.
The September 8 group's last eligible return date is September 21, 2026; its window ends at the start of September 22. The export therefore covers both cohorts completely. A more recent group without a complete window would be pending, not a group with zero returns. Google distinguishes cohort inclusion, return criteria and time granularity in its cohort exploration documentation; those are separate choices to document in a spreadsheet, too.
These are signup-date cohorts. Weekly or monthly grouping belongs in a consistent cohort design, covered in app cohort analysis. Do not compare a fixed later window with an older group's lifetime return rate.
Put the following existing user-summary records in columns A:E, with headers in row 1. Dates are spreadsheet date values displayed in US format. A dash in the table means an empty worksheet cell, not the text character -.
| User key | Signup date | Task started | Task completed | Qualifying return date |
|---|---|---|---|---|
| U01 | 9/1/2026 | 9/1/2026 | 9/2/2026 | 9/9/2026 |
| U02 | 9/1/2026 | 9/2/2026 | 9/3/2026 | — |
| U03 | 9/1/2026 | 9/4/2026 | — | 9/10/2026 |
| U04 | 9/1/2026 | — | — | — |
| U05 | 9/8/2026 | 9/8/2026 | 9/9/2026 | 9/16/2026 |
| U06 | 9/8/2026 | 9/10/2026 | — | — |
| U07 | 9/8/2026 | — | — | 9/17/2026 |
| U08 | 9/8/2026 | — | — | — |
Add F1 Started, G1 Completed and H1 Returned. The following formulas use Excel. In F2, require a start inside the initial window:
=--AND(ISNUMBER(C2),C2>=B2,C2<B2+7)
In G2, require a valid start and a completion on or after it, inside the same window:
=--AND(F2=1,ISNUMBER(D2),D2>=C2,D2<B2+7)
In H2, require a qualifying return in the later window:
=--AND(ISNUMBER(E2),E2>=B2+7,E2<B2+14)
Fill the formulas through row 9. Each returns a one or a zero, so each user contributes at most once to each measure. The date limits include the start of each window and exclude the start of the next one, avoiding an overlapping boundary.
| User key | Started | Completed | Returned |
|---|---|---|---|
| U01 | 1 | 1 | 1 |
| U02 | 1 | 1 | 0 |
| U03 | 1 | 0 | 1 |
| U04 | 0 | 0 | 0 |
| U05 | 1 | 1 | 1 |
| U06 | 1 | 0 | 0 |
| U07 | 0 | 0 | 1 |
| U08 | 0 | 0 | 0 |
| Total | 5 | 3 | 4 |
U07 returns without starting the selected task. That is a valid difference between the measures, rather than an inconsistency to remove.
Set J1:N1 to Cohort, Signups, Started, Completed, Returned. Enter the two signup dates as date values in J2:J3. In K2:N2, use these formulas, respectively, then fill down:
=COUNTIFS($B$2:$B$9,J2)
=COUNTIFS($B$2:$B$9,J2,$F$2:$F$9,1)
=COUNTIFS($B$2:$B$9,J2,$G$2:$G$9,1)
=COUNTIFS($B$2:$B$9,J2,$H$2:$H$9,1)
Microsoft documents COUNTIFS as counting rows for which all supplied criteria are met. That makes it suitable here because the source already has one row per user.
| Signup cohort | Signups | Started | Completed | Returned |
|---|---|---|---|---|
| September 1, 2026 | 4 | 3 | 2 | 2 |
| September 8, 2026 | 4 | 2 | 1 | 2 |
| Total | 8 | 5 | 3 | 4 |
Calculate the rates in O2:R2, then fill down. Format as percentages with one decimal place:
=IF(K2=0,"",L2/K2)
=IF(L2=0,"",M2/L2)
=IF(K2=0,"",M2/K2)
=IF(K2=0,"",N2/K2)
| Signup cohort | Start / signup | Complete / start | Complete / signup | Return / signup |
|---|---|---|---|---|
| September 1, 2026 | 75.0% | 66.7% | 50.0% | 50.0% |
| September 8, 2026 | 50.0% | 50.0% | 25.0% | 50.0% |
| Total from counts | 62.5% | 60.0% | 37.5% | 50.0% |
The later group has fewer starts and completions, while its return rate is unchanged. Review the first-report task and onboarding context before assuming a broad retention problem. With only four signups per group, treat the difference as a question to investigate, rather than a reliable estimate of a release's effect.
The summary must contain the same eight users as the source. Its start, completion and return totals must match the flag sums. For each cohort, completed users cannot exceed started users, and started users cannot exceed signups.
Overall completion among starters is 3 / 5 = 60.0%. Calculate that from summed counts; averaging the cohort percentages weights unequal denominators equally. Returning users remain a separate total, as explained in retention analysis.
Keep an exceptions list for completion dates before start dates, missing signup dates and duplicate user keys. Resolve those records rather than silently excluding them from the denominator.
Bring your existing user-summary export with the agreed task and cohort definitions: Covirage maps the columns, and its tools compute and check the counts and rates. The external AI model explains the results with every figure traced to its rows. Create a free Covirage account, which takes about a minute, then set up your business and bring a sample of your own data.
See self-service analytics for the wider workflow. Covirage is not affiliated with Microsoft or Google.
Start with an existing export containing a stable user key, signup date, task-start date, task-completion date and qualifying return activity. A user-summary export is easiest to reconcile. Document the date range, timezone and event definitions before calculating rates, because inconsistent definitions can create apparent behavior changes.
Funnel completion measures progress through an ordered task sequence. A returning-user rate measures whether members of an eligible signup group perform a defined action in a later window. Someone can return without completing the task, so the two measures answer different product questions.
Recent users may not have reached the full return window. Counting their unfinished observation time as inactivity understates their rate. Mark those cohorts as pending, then compare them after the same amount of time has elapsed as for the older cohorts.