Поступил заказ на управление пиаром застройщика ЖК Ясный. Все бы ничего, но предыдущие исполнители, которые не осилили ведение проекта, немного наломали дров, поэтому в ход пришлось пускать тяжелую артиллерию. Учитывая масштаб предстоящих работ, для анализа оперативной обстановки и формирования бюджета средств поисковиков здесь явно было недостаточно, используя их, задачу пришлось бы решать неоправданно долго, я решил подключить немного магии в лице продвинутого сервиса мониторинга и анализа медиа.
Оговорюсь сразу: этот материал не претендует на звание исчерпывающего руководства по сервису, более того, я даже название его называть не могу по условиям NDA (соглашения о неразглашении), поэтому в дальнейшем буду писать просто “Сервис”. Здесь, скорее, первые впечатления “по горячим следам” — разбираться пришлось на ходу, плюс, немного сумбура вносило то, что застройщик оказался не один, а 3, и анализировать пришлось не только жилой квартал “Ясный”, а общую обстановку в жилом районе Светлый, включающего в себя еще французский и альпийский квартал. Итоговая аналитика производилась на основе информации о ЖК Ясный. И нет, это не реклама вышеупомянутого жилого комплекса или Сервиса, который нельзя называть. Более того, впечатления от последнего остались, скорее смешанные. Но здесь следует делать поправку на то, что сервис развесистый и разухабистый, а разбираться с ним пришлось в ускоренном режиме. Но обо всем по порядку.
Мониторинг социальных сетей
Итак, конкурентная разведка началась. Прежде всего, необходимо было изучить настроения публики в социальных сетях, для чего я воспользовался Сервисом. Если кратко, то его работу с соцсетями можно описать следующим образом: он автоматически индексирует множество постов и комментариев, предоставляя пользователям возможность делать выборки с помощью встроенного языка запросов очень отдаленно напоминающего SQL, но со своими нюансами. Далее есть возможность фильтровать результаты по различным параметрам, начиная даты и региональной привязки, заканчивая тональностью (позитивное или негативное сообщение). Последнее в контексте решаемой задачи выглядит особенно привлекательно, впрочем, забегая вперед, скажу, что большинство сообщений все равно помечаются как нейтральные.
Составление запроса для фильтрации постов
Как я уже говорил выше, для создания выборок в Системе используется собственный язык запросов, к редактору прилагается краткое руководство по использованию его операторов, коих насчитывается чуть более десятка:
Пример некоторых операторов из руководства
Некоторые операторы этого языка, вроде “OR” или “AND”, могут показаться вам знакомыми, если вы составляли запросы к СУБД, здесь они выполняют похожие функции задания логических условий. Вооружившись памяткой и видеоуроками, предлагаемыми сервисом, я приступил к экспериментам. В процессе пришло понимание, что первое впечатление было обманчивым — инструментарий оказался ближе к поисковикам, чем к диалектам SQL.
По умолчанию Сервис варьирует словоформы и рандомизирует порядок слов, входящих в запрос. Это удобно, однако запрос необходимо составлять очень аккуратно, чтобы он не захватывал лишних результатов. Фильтровать их вручную было бы сомнительным удовольствием. Моя задача немного усложнялась тем, что, в отличие от, скажем, СБЕРа или Мерседеса, в названии ЖК Ясный используется общеупотребимое, и часто используемое слово, которое автоматически превращалось в производные от “ясный”, также необходимо было учитывать, что в Новосибирске существует жилой комплекс с похожим названием “Ясный берег”. Нетрудно догадаться, что эти два факта должны были бы давать в выборке огромное количество ложных результатов. Немного поразмыслив, я составил первый уже более-менее работающий вариант запроса:
Составление запроса для поиска сообщений в социальных сетях я начал с указания названия ЖК Ясного в разных падежах, добавив к каждому из вариантов “!”, чтобы использовалась точная словоформа. Это избавит нас от огромного количества нерелевантных результатов, где кому-то что-то ясно или он восхищается ясным небом. Конструкция “AND NOT Берег” избавит нас от вариантов, относящихся к жилому комплексу “Ясный берег”. Затем я дополнил запрос уточняющими ключами, предназначение которых дать системе понять, что мы ищем сообщения, связанные с жилищными комплексами, арендой и покупкой жилья и т.п. Следует учитывать, что вхождение слов ищется в любом месте в текста в любом порядке, поэтому, чтобы повысить релевантность результатов, я добавил оператор “/10”, указывающий, какое количество слов может стоять между искомыми ключами. Тем самым мы захватываем сообщения, содержащие обороты, вроде “Квартал высокой культуры Ясный”, и исключаем варианты где эти слова могут входить в разные абзацы и не относиться к искомому жилищному комплексу. Почему именно 10? Я пришел к такому значению, проанализировав реальные случаи употребления названия и взяв небольшой запас. Да, прямо так, на глаз. Здесь нет серебряной пули, оптимальное значение может отличаться от запроса к запросу, но не может превышать 25 — ограничение системы.
Дело сделано, скелет запроса составлен. В нем, конечно, есть еще потенциал для улучшения — можно дополнить ключами и улучшить фильтрацию сообщений, не относящихся к ЖК Ясный, но пора бы его протестировать. Запустив формирование отчета и выставив глубину поиска в 3 месяца, чтобы Сервис нашел наиболее актуальные сообщения, я откинулся на спинку стула и принялся наблюдать за индикатором выполнения задачи. Не прошло и 5 минут, как отчет был сгенерирован, и я не без удивления обнаружил, что ничего не работает. Хотя должно. Но не работает.
Стою на асфальте я в лыжи обутый…
Ну то есть как не работает — синтаксически запрос был составлен корректно, редактор никаких ошибок не подсвечивал, документации он полностью соответствовал, составление отчета успешно запускалось и даже релевантные результаты по нему находились. Но был один нюанс: сообщений было найдено неприлично мало — целых 2, вернее, даже одно, поскольку второе оказалось репостом первого.
Я раз за разом перепроверял синтаксис запроса и логические операторы, которые в него входили, думая, что где-то здесь закралась ошибка. Если рассудить логически, составление запросов для мониторинга социальных сетей — это процесс нахождения баланса между заданием искомого вхождения и отсечением лишних результатов. Поначалу мне казалось, что отсекается слишком много, поэтому начал распутывать этот клубок с исключения сегмента запроса, который, по задумке, должен был убирать лишнее. Найденных результатов прибавилось, однако, среди них отсутствовали релевантные, зато содержались сообщения с оборотами, не относящимися к кварталу Ясный, о необходимости отбрасывания которых я писал выше. Хорошая новость заключалась в том, что эта часть запроса работала корректно, плохая — пляски с бубном продолжались.
Следующим очевидным шагом стало расширение количества ключей, по которым будет происходить поиск, что в теории должно было дать существенно больше результатов. В ход пошло все от названия города Новосибирска до номера телефона ЖК Ясный “+7 (383) 318-14-26”, а также конструкции вроде “жилой район Светлый отзывы”, “Альпийский квартал отзывы”, "ЖК Ясный отзывы". Одним словом, все, что могло релевантно расширить поиск. И это незамедлительно дало плоды — отчет увеличился на 400%! Жаль только, что это всего 4 сообщения.
Складывалась парадоксальная ситуация: запрос составлен вроде бы правильно, содержит большое количество ключей, система выглядит внушительно, приличных денег стоит, а результат — кот наплакал. Медленно подступали фрустрация и отчаяние. Смеркалось.
Рассудив, что дело может быть не в запросе, я начал перепроверять другие параметры поиска:
Другие параметры поиска
Здесь все вроде бы тоже в порядке, глубина стоит 3 месяца. Не может же за такой период во всех социальных сетях, в которых производится мониторинг, быть так мало сообщений, соответствующих моему многоэтажному запросу? 3 месяца, 3 месяца… И тут меня словно током ударило.
А ларчик просто открывался
Вспомнилось, что когда я убирал часть запроса и появилось много неподходящих сообщений, все они датировались подозрительно близко. В ходе дальнейших поисков я обнаружил на удивление неочевидное с точки зрения юзабилити интерфейсное решение:
Ю — юзабилити
Оказалось, что какой бы период в форме поиска мы ни выбрали, при выводе отчета по умолчанию зачем-то автоматически устанавливался неприметный дополнительный фильтр по дате, охватывающий лишь последние 4 дня, а все остальные результаты оказываются скрыты. “Почему? Зачем? В чью светлую голову пришло такая гениальная идея? Какого [CENSORED]?“ — на эти вопросы науке еще предстоит найти ответы. Ведь очевидно же, что, если в форме поиска пользователь выбрал временной интервал, то и в результаты он ожидает увидеть соответствующие ему сообщения. Не такого я ожидал от сервиса, который позиционирует себя как серьезный инструмент для мониторинга СМИ и социальных сетей.
Когда выяснилось, что на самом деле мой запрос прекрасно работает, немного дополнить его, сформировать и выгрузить необходимые отчеты оказалось делом времени:
Выгружаем отчет в необходимом формате
Проанализировав опыт взаимодействия с Сервисом, я пришел к некоторым выводам и мыслям:
- Сервис обладает обширным охватом и позволяет автоматизировать множество рутинных действий и сэкономить немало времени — поиск несколько сотен постов и комментариев средствами поисковых систем был бы существенно более трудоемок. Если бы необходим был мониторинг постов и сообщений на протяжении продолжительного времени, это превратилось бы в каторгу. Автоматизация — это прекрасно.
- При анализе отчетов необходимо учитывать, что индекс, по которому делается выборка, составляется лишь по открытым группам и сообществам. Соответственно, посты и сообщения из закрытых групп в отчете фигурировать не будут, что может создать некоторое искажение информации о текущем положении дел.
- Высокая стоимость сервиса (а она высокая) не гарантирует его всесторонней продуманности и внимания к мелочам, из которых и складывается пользовательский опыт. Если бы Сервис был проработан с точки зрения UI/UX чуть более компетентно, это сэкономило бы мне несколько часов. И, что-то мне подсказывает, что не один я споткнулся об эту неочевидную его особенность.
- Не все пользователи в явном виде выражают свое мнение, либо же определение тональности сообщения оказалось недостаточно совершенным, либо попалась такая особенная выборка. Как бы там ни было, в этом конкретном случае функция, на которую я возлагал большие надежды, оказалась бесполезной, 99% сообщений она определяла как нейтральные, и лишь ~1% посчитала позитивными или негативными.
