<b>DevRel без метрик превращается в шум: что измерять в tooling, а что не считать</b>

<b>DevRel без метрик превращается в шум: что измерять в tooling, а что не считать</b>

Если у вас dev-аудитория, главный риск не «мало охватов», а то, что команда меряет не тот результат. Просмотры поста почти ничего не говорят о том, дошёл ли разработчик до первого запуска SDK или понял ли он, как пройти auth без боли.

Для арб-tooling и SaaS с API полезно смотреть не на «интерес», а на поведение:
— time-to-first-call: сколько шагов до первого рабочего запроса;
— доля дошедших до quickstart без ручной помощи;
— где люди бросают setup: docs, auth, webhook, SDK install;
— сколько повторных обращений в саппорт связано именно с onboarding.

Отдельно считайте контент, который реально снижает нагрузку:
— пример в code block лучше, чем длинная статья;
— один понятный quickstart лучше трёх «обзорных» материалов;
— FAQ по ошибкам важнее очередного поста про vision продукта.

Плохой знак — когда DevRel живёт в отчётах про лайки, а продукт всё ещё требует ручного созвона, чтобы завести ключ и получить первый ответ от API. Хороший знак — когда разработчик сам доходит до результата и уже потом задаёт вопросы по углублению.

Смотрите на DevRel как на часть DX-воронки: не «сколько людей прочитало», а «сколько людей смогло начать».