Как собирать обратную связь и запросы новых функций на Reddit, X и Hacker News

Почему обычные каналы обратной связи упускают это

Большинство команд собирают отзывы из трех источников: тикеты поддержки, виджет в приложении и звонки отдела продаж. Все три имеют одно и то же искажение: вы слышите только тех, кто уже общается с вами.

Публичные обсуждения устроены иначе. Тот, кто отказался от подписки в прошлом месяце, не станет заполнять ваш опрос, но с радостью объяснит на Reddit, почему ушел. Потенциальный клиент, сравнивающий инструменты, перечислит недостатки вашего решения в посте «что мне выбрать?». Это обратная связь, которую вы никогда не получили бы иначе, и к ней часто добавляются ответы других пользователей, согласных или несогласных, что показывает реальный масштаб проблемы.

Сложность заключается в объеме. Если вы ищете название своего продукта раз в неделю, вы найдете лишь несколько веток, и отвечать в них будет уже слишком поздно. Если настроить обычное оповещение по названию, вы получите каждое упоминание, включая те, что не имеют никакого отношения к продукту. Секрет в том, чтобы составить оповещения, которые ищут именно обратную связь.

Настройка оповещений для поиска обратной связи

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

Вот начальный набор, где «acme» обозначает название вашего продукта:

1. acme, wish и acme, would be nice для запросов функций
2. acme, bug и acme, broken для отчетов об ошибках
3. acme, switched и acme, cancelled для причин оттока клиентов
4. acme, missing и acme, doesn't support для недостатков, обнаруженных при оценке продукта

Каждая строка — это отдельное оповещение, поскольку оповещение со всеми этими словами потребовало бы наличия каждого из них в одной и той же публикации. Через неделю вы, вероятно, скорректируете формулировки, когда увидите, как общаются ваши пользователи. Люди редко пишут фразу «запрос функции» («feature request»), поэтому ищите фразы, которые они действительно используют, например «было бы здорово, если» («would be great if»).

Большую часть шума отсеивают несколько фильтров. На Reddit и Hacker News включите опцию «Только целые слова» (Whole Words Only), если название вашего продукта короткое или распространенное, чтобы «acme» не совпадало с «acmeplex». Добавьте учетные записи вашей команды в «Исключенные пользователи» (Excluded Users), чтобы ваши ответы и посты о запусках не вызывали срабатываний. Если у вас есть сабреддит продукта, вы можете создать отдельное оповещение для него с помощью «Включенные сабреддиты» (Included Subreddits) и вовсе убрать второе ключевое слово, поскольку почти все публикуемое там в любом случае является обратной связью.

Исключенные ключевые слова работают противоположным образом по сравнению с включенными. Включенные ключевые слова должны совпадать все, а публикация отбрасывается, как только в ней появляется хотя бы одно исключенное ключевое слово. Делайте этот список коротким и точным, иначе вместе с шумом вы отфильтруете и полезные отзывы. Наша статья о снижении шума в оповещениях по ключевым словам подробно рассматривает каждый фильтр.

Где слушать в первую очередь

Не каждая платформа дает одинаковую обратную связь. По моему опыту, на Reddit и Hacker News люди пишут длинные и подробные жалобы. На X сообщения короче и эмоциональнее, что полезно для быстрого обнаружения сбойного релиза. Linkedin — это в основном похвала и анонсы, поэтому он находится ниже в этом списке, если только вы не продаете продукт тем, кто пишет там о своих рабочих инструментах.

Скорость также различается в зависимости от платформы, и это влияет на использование каждого оповещения. Вот частота обновления из нашей документации:

Для обратной связи ни одна из этих скоростей не является медленной. Таблица показывает, что ветка на Hacker News может дойти до вас, пока она еще находится на главной странице — именно в тот момент, когда ответ от члена команды имеет наибольший вес.

Передача информации продуктовой команде

Оповещение, которое никто не читает, — это просто более удобный поиск. Шаг, который команды обычно пропускают, — это решение о том, куда попадают отзывы и кто их просматривает.

Самый простой вариант — отдельный канал в Slack. KWatch позволяет настроить вебхук Slack для каждого оповещения, и индивидуальный вебхук оповещения переопределяет общий вебхук учетной записи. Таким образом, оповещения по продажам могут по-прежнему отправляться в канал продаж, а оповещения по обратной связи — в канал вроде #product-feedback. Продакт-менеджеры и инженеры, которым нужно только читать, могут присоединиться к вашей команде KWatch с ролью Reader: она позволяет получать уведомления, но не дает создавать или удалять оповещения.

Если вы хотите подсчитывать количество запросов со временем, отправляйте те же оповещения на вебхук API. Каждое совпадение передается в виде полезной нагрузки JSON. Вот пример из нашей документации:

{
  "platform": "reddit",
  "query": "Keywords: vllm",
  "datetime": "19 Jan 24 05:52 UTC",
  "link": "https://www.reddit.com/r/LocalLLaMA/comments/19934kd/sglang_new/kijvtk5/",
  "author": "lmzoo",
  "content": "sglang runtime has a different architecture on the higher-level part with vllm.",
  "sentiment": "neutral"
}

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

Оповещения по электронной почте тоже работают, но длинные сообщения в письмах обрезаются. Запросы функций часто бывают подробными, поэтому Slack или вебхук здесь подходят лучше.

Что делать с найденной информацией

Когда поток обратной связи налажен, появляется соблазн отвечать на всё подряд. Я бы рекомендовал немного сдержаться. Короткий полезный ответ от того, кто действительно работает над продуктом («это есть в наших планах, а пока вот временное решение»), дает отличный результат. Серия же ответов, каждый из которых заканчивается ссылкой на регистрацию, приведет к занижению рейтинга (даунвоутам), а на некоторых сабреддитах — и к бану.

Куда более ценная привычка — еженедельный обзор. Раз в неделю кто-то из продуктовой команды просматривает канал или таблицу и размечает каждый пункт: запрос функции, ошибка, причина оттока или не имеет значения. Через месяц у вас будет примерная статистика того, о чем люди просят публично, в сравнении с тем, что они запрашивают через тикеты. И самое интересное обычно начинается там, где эти два списка расходятся.

Если наиболее ценная обратная связь поступает от нескольких конкретных людей (активных пользователей, аналитиков, основателя компании-конкурента), а не по ключевым словам, наш родственный продукт MultiFollow отслеживает определенные учетные записи в Linkedin и X и уведомляет вас об их публикациях, что отлично дополняет оповещения по ключевым словам.