Sign in

Blog · Board and management reporting · Software

App user behavior analysis: compare funnels and cohorts

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.

The short answerApp user behavior analysis measures what users complete and whether they return, using records already available in an export. Group users by signup date, define the task sequence and observation window, and count distinct eligible users at each stage. Compare funnel conversion and returning-user rates separately so a change in task completion is not mistaken for a change in retention.

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.

Start with a business task and an existing export

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.

Set observation windows before comparing cohorts

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.

Turn the supplied dates into flags

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.

Summarize the funnel and return rate

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.

Reconcile before interpreting

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.

Where it goes wrong

  • Events counted as users. Repeated task attempts inflate completion unless the export is reduced to distinct user records.
  • Unequal observation time. A recent group with an unfinished return window needs a pending label. Its blank result is not zero retention.
  • Dates stored as text. The flag formulas require numeric spreadsheet dates. Validate imported dates before filling the calculations.
  • Missing data called inactivity. Empty activity fields mean no qualifying action only when the export is complete for the stated users and windows.
  • A changed task definition. A renamed or broadened completion action can move the rate even when underlying behavior is unchanged.

Compare your own export in Covirage

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.

Questions people ask

What data do you need for app user behavior analysis?

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.

How is funnel completion different from a returning-user rate?

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.

Why should recent signup cohorts be excluded from retention comparisons?

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.