В сложном проекте, с богатым набором игровых механик, игрок чаще всего не в состоянии (да и не желает) выделить суть проблемы и ее первопричины. Он делится своей болью, т. е. симптомами, а не диагнозом. Так что «проблемный» фидбэк обычно представляет собой описание следствия, а не причины. А если игроки пытаются заниматься «самолечением», т. е. сразу ставить диагноз и предлагать исправления, нужно быть крайне осторожными и не тащить это все в документ без оглядки.

Например, в отзывах к Enlisted было: «Автоматчики побеждают всех, надо их понерфить» (ухудшить характеристики, сделать слабее), а не истинное описание ситуации: «У автоматов нет разброса в движении, а их точность с расстоянием почти не падает, поэтому они являются универсальным игровым оружием и нет смысла брать другое. Соответственно, кругом играют одни автоматчики».

Или классика War Thunder: «После этого обновления меня постоянно убивают в начале боя, вы все поломали!», а не: «На новой локации слишком много зон дальнего прострела, которые позволяют контролировать удобные маршруты перемещения игроков от точки появления, что делает неинтересной игру в движении».

Чувствуете разницу? Где симптом, а где причина, которую можно исправлять? Именно поэтому существует необходимость прекрасно знать проект, менеджером которого ты являешься. Самому замечать описанные игроками проблемы, играя! И тогда в потоке описаний можно выделить их истинную причину.

В то же время важно регистрировать примерное количество повторяющихся по смыслу тем и жалоб. Можно в абсолютных цифрах, например: 120 игроков жалуются на нерегистрацию попаданий выстрела в голову, 84 сообщают, что звук шагов в наушниках слышен не со стороны реального появления противника. Можно по принципу светофора маркировать пункты документа цветами («редко», «часто», «очень часто»). И ранжировать документ согласно частоте – от наиболее массовых к наименее.

При этом надо понимать, что в списке могут быть вещи, которые не слишком массовые (а то и вообще одно сообщение), но по трезвому рассуждению КМ заслуживают внимания (необычный баг или разумное предложение по фиче), тогда их надо просто выделять в списке отдельным примечанием, чтобы не пропали с фокуса, но и не дезинформировали разработчика о реальном масштабе мнений о проблеме.