На Хабре банк обращался к опытным разработчикам
Хабр работает с 2006 года и позиционирует себя как крупнейшее русскоязычное ИТ-сообщество. Значительную часть зарегистрированных читателей составляют разработчики уровня middle и выше. На площадке ведут блоги десятки крупнейших компаний Рунета, среди заметных корпоративных авторов — Сбер. В период проекта аудиторию Хабра оценивали примерно в 11 млн уникальных пользователей в месяц.
Разработчику, который ежедневно работает с технологией, нужны подробности ее применения. В статье он может проверить код, заметить неточный термин или оспорить вывод. Поэтому мы разбирали, как устроено решение, где возникла ошибка и что изменилось после ее исправления.
Через такие материалы банк показывал задачи команды, используемый стек и отношение к инженерной работе. Блог знакомил ИТ-специалистов со Сбером как с возможным работодателем и участвовал в формировании его репутации в профессиональном сообществе.
Мы работали в одном блоге с другими подрядчиками, по общим правилам публикации. При этом у каждой статьи были собственные показатели, по которым клиент мог оценивать работу студий.
Ошибку в статье банка обсуждают публично
Читатели выставляют оценки на виду у всех. Плюсы и минусы складываются в рейтинг публикации; у участников есть карма — оценка сообществом. По правилам периода проекта поставить минус мог участник с кармой не ниже пяти и хотя бы одной публикацией. Рекламная подача рисковала вызвать критику, которая оставалась рядом со статьей в корпоративном блоге.
Техническую часть проверяет сама аудитория. Неточность в коде, архитектуре или цифрах могла стать главной темой комментариев. Поэтому мы проверяли не только отдельные термины, но и логику объяснения. Дополнительно сверяли содержание с позицией банка и учитывали, как спорное высказывание может прозвучать за пределами Хабра.
Одних просмотров для оценки недостаточно. В статистике публикации видны просмотры, рейтинг, комментарии и закладки. Мы выбрали основной метрикой среднее число закладок — сколько раз читатели сохранили статью. Остальные показатели помогали оценить ее распространение и реакцию аудитории.
Обсуждение могло уйти в претензии к банку. Мы хотели получать вопросы, возражения и опыт других инженеров. Но упоминания тарифов, приложений, санкций или персональных данных могли перевести разговор в политику и споры о бренде. При подготовке статьи нужно было дать повод обсудить техническое решение и проверить, какие еще темы поднимают формулировки.
Каждая статья проходила пять проверок
Работа начиналась с вопроса, зачем эту статью откроет инженер. Выбрав тему, мы готовили материал и передавали его по цепочке специалистов, каждый из которых отвечал за свою часть проверки.
Выбирали тему по инженерной задаче. Подходили реальные задачи, нестандартные решения, результаты экспериментов, ошибки и выводы из них. Банк появлялся там, где помогал понять условия работы. Так у читателей оставался предмет для обсуждения, даже если сам бренд их не интересовал.
Наши статьи набирали 15–20 тысяч просмотров против 7–10 тысяч у других подрядчиков в том же блоге. Эту разницу мы отслеживали вместе с закладками и реакцией в комментариях.
Проводили текст через пять специалистов. Филолог отвечал за язык и точность формулировок. Профильный специалист проверял код, термины, логику решения и цифры. Корректор находил пропущенные ошибки. Редактор читал статью целиком и оценивал, понятно ли она изложена для аудитории Хабра. Менеджер сверял содержание с представителями Сбера и уточнял, что допустимо публиковать.
Такая работа обходилась дороже одной вычитки. Для банка она позволяла отдельно проверить техническое объяснение, отредактировать материал и согласовать публичную позицию.
Давали читателю повод дополнить статью. Оставляли открытые инженерные вопросы, объясняли выбор спорных решений и приглашали поделиться опытом. При этом убирали лишние сравнения, общие оценки рынка и темы вне инженерной повестки. Двусмысленные места редактор и менеджер переписывали до публикации.
По наблюдениям команды, обоснованные негативные комментарии стали редкостью. Некоторые статьи вышли без единого отрицательного голоса.
Почему мы считали закладки
Просмотр фиксирует обращение к публикации, закладка — ее сохранение. Нам было важно, как часто читатели сохраняют наши материалы, и среднее значение выросло с 10 до 18. Закладки не раскрывают мотив читателя или дальнейшее использование статьи; просмотры, в свою очередь, не равны числу уникальных людей.
Для сравнения брали публикации других подрядчиков в том же блоге за период совместной работы. Наши статьи получали 15–20 тысяч просмотров, остальные — 7–10 тысяч. Темы и даты выхода различались, поэтому эти данные показывают разницу между публикациями, но не выделяют влияние одного редакционного приема.
В комментариях смотрели на тональность и обоснованные претензии. Претензий стало меньше — это было значимо для проекта, где каждый материал проверяли несколько специалистов. Отдельных количественных данных о влиянии проверки на этот показатель нет.
Рост подписчиков складывался из работы всех подрядчиков и интереса к бренду. За нашу часть говорили показатели наших статей и решение Сбера передать нам весь блог. Мы вели его целиком несколько месяцев, до смены позиционирования бренда в интернете.
05 — Результат
Что получилось
Рост подписчиков относится ко всему блогу, который вели несколько команд. Закладки — к нашим статьям; просмотры сопоставлены с публикациями других подрядчиков.
06 — FAQ
Что про работу с Хабром спрашивают чаще всего
Почему корпоративному блогу на Хабре нужна техническая редактура?
Статьи читают специалисты, которые могут проверить код и оспорить объяснение. Их оценки и замечания видны публично. В проекте Сбера техническую часть проверял профильный эксперт, а публикацию от имени банка дополнительно согласовывал менеджер.
Зачем пять проверок на одну статью?
Проверка кода не заменяет редактуру, а редактор не может согласовать позицию банка за его представителей. Поэтому филолог, технический специалист, корректор, редактор и менеджер последовательно решали разные задачи. Такой состав мы выстроили под требования Сбера и Хабра.
Что означает рост закладок с 10 до 18?
Каждую нашу статью стали сохранять в среднем 18 раз вместо 10. Мы выбрали эту метрику, чтобы оценивать сохранения отдельно от открытий публикации. Она не показывает, прочитал ли человек статью повторно и применил ли ее в работе.
Как вы удерживали дискуссию в теме статьи?
Задавали инженерные вопросы и объясняли спорные решения, чтобы читателю было что добавить по существу. Перед публикацией убирали двусмысленности и отступления, которые могли увести разговор в политику или претензии к банку. Это сокращало поводы для споров вне темы, хотя полностью определять реакцию читателей невозможно.
Чем ваши статьи отличались от материалов других подрядчиков?
Мы выбирали темы по интересу технического читателя и вводили бренд через условия задачи. Наши материалы набирали 15–20 тысяч просмотров против 7–10 тысяч у других студий в том же блоге. На разницу могли влиять и темы, и время публикации, поэтому приписывать ее только подаче было бы неточно.
Подойдет ли этот опыт другой компании?
Он применим там, где аудитория может проверить автора по существу — в ИТ, промышленности, медицине или финансах. Для такого блога нужны темы из практики и доступ к специалистам для проверки. Состав команды и порядок согласования зависят от требований конкретной компании; показатели Сбера не служат прогнозом.