In this guide
Feedback from a beta arrives in chat messages, emails, store consoles and screenshots. A tracker puts it in one place so you can see what is open, what repeats and what you decided. Paste the header below into any spreadsheet tool.
Copy-paste header (tab-separated or CSV)
ID,Date,Source,Tester,Area,Type,Description,Steps to reproduce,Device / OS / version,Severity,Count,Status,Decision,Owner,Fixed in build,Notes
What each column is for
| Column | Purpose | Tip |
|---|---|---|
| ID | Stable reference (F-001) | Never reuse an ID |
| Date | When it arrived | Helps spot clusters after a release |
| Source | Where it came from: private feedback, email, chat, crash report | Lets you see which channel gives useful input |
| Tester | Who reported it | Needed to ask follow-up questions |
| Area | Screen or flow (sign-in, checkout) | Use a short fixed list so you can filter |
| Type | Bug, usability, idea, question | Keeps ideas from drowning bugs |
| Description | One sentence in your own words | Not the raw message |
| Steps to reproduce | Numbered steps | Empty means "needs more info" |
| Device / OS / version | Where it happened | Include the app build |
| Severity | 1 blocker, 2 major, 3 minor, 4 cosmetic | Define the levels once, in writing |
| Count | How many testers reported it | Increase it instead of adding duplicates |
| Status | New, needs info, confirmed, in progress, fixed, won't fix | Keep the list short |
| Decision | Fix now, later, never, plus one-line reason | The reason is what you will want in three months |
| Owner | Who acts | Even if it is always you |
| Fixed in build | Build that contains the fix | So testers know what to re-check |
| Notes | Anything else |
Example rows (illustrative)
F-001,2026-03-02,Private feedback,T4,Sign-in,Bug,Login button does nothing after wrong password,1. Enter wrong password 2. Tap Login twice,Pixel 7 / Android 14 / 0.9.2,2,3,Confirmed,Fix now: blocks all users with typos,Me,0.9.3,
F-002,2026-03-03,Email,T7,Settings,Idea,Wants a dark theme,,,4,1,New,Later: not needed for launch,Me,,
How to use it
- Enter every item, even duplicates: raise Count instead of adding a second row.
- Sort by Severity, then Count. That list is your next build.
- Fill Decision for every row before a release, including "won't fix". Unanswered rows are where trust is lost.
- After each build, filter on Fixed in build and ask the reporters to confirm.
Limits: severity and decisions are your judgment. For deciding between many open items, see how to prioritize app feedback; for turning the pile into plans, turn app reviews into a roadmap.
Related
- Hub: Mobile app testing checklist hub
- Test environment setup checklist
- Privacy policy checklist for mobile apps
AppReviewX feedback comes structured (area, steps, device), so it drops straight into this sheet. One feedback = 1 credit; new accounts start at 0. Start free.