A review may contain more than one friction. For example, “I cannot cancel my subscription and support never replies” receives both pricing_paywall and support_service.
| Code | Include | Exclude | Product-action starting point |
|---|---|---|---|
access_account |
login, password, registration, verification, account access | general failure to launch the app | audit recovery flows and make login errors actionable |
stability_performance |
crash, freeze, slowness, loading failure, technical error | inability to find an existing feature | segment failure rates by app version and device |
navigation_usability |
confusion, inability to find something, difficult use, interface or navigation | request for a missing feature | usability-test the affected core task |
pricing_paywall |
subscription, price, fee, trial, payment, refund, locked content | feature request with no commercial issue | clarify trial, renewal, cancellation, and locked-content expectations |
feature_gap |
missing option, new feature, customisation need | existing feature that is technically broken | cluster requests by user goal before selecting solutions |
notifications |
notification, reminder, alert | general in-app messages | audit permissions, scheduling controls, and delivery reliability |
privacy_trust |
data, permissions, security, privacy, trust | “data” used only to mean statistics | clarify data use and request permissions at the moment of need |
support_service |
support, customer service, unanswered contact | automated technical error message | measure contact reasons, response time, and resolution rate |
content_quality |
audio, video, exercise, session, or library-content issue | complaint only about content being behind a paywall | review content coverage, quality, and accessibility |
other_unclear |
friction that cannot yet be assigned confidently | review with a clear existing category | inspect manually and open a new code only when a pattern repeats |
- Read the review without viewing the automatic code and assign one primary reviewer code.
- Add any secondary code or uncertainty to
notes. - After all 50 reviews are complete, compare them with the separate validation key.
- Label disagreements as an automation error, reviewer ambiguity, or codebook gap.
- Add a new category only after observing at least three comparable examples.
The purpose of v0.1 is not to create an impression of accuracy with an opaque model. It is to make the researcher's assumptions visible and revisable. The rules will make errors, which is why the blinded 50-review second pass is part of the success criteria. A human audit remains preferable when time and access allow it.