«Мы просто программисты»: REES46 ответил Retail Rocket на обвинения в хакерской атаке

Генеральный директор центра управления конверсией REES46 Михаил Кечинов о скандале вокруг тестирования рекомендательных систем.

За одну лишь пятницу 2 июня мне пришло больше заявок в друзья от участников ecommerce-рынка, чем за предыдущие три года. Говорят, что PR плохим не бывает. Бывает, конечно. Просто нужно уметь его правильно готовить.

То, что вы все уже знаете: REES46 — мошенники, потому что подделывают сегменты при A/B-тесте. Так говорят профессионалы из Retail Rocket. Дальше будет то, чего вы не знаете. А в конце ещё и то, что вам понравится.

С 1 по 28 февраля 2017 года магазин «Дочки&Сыночки» проводил ABC-тест товарных рекомендаций. Результаты теста:

Для примера, если базовая выручка сегмента равна 1000 рублей, а прирост X равен 5%:

Это мог быть потрясающий кейс, если бы показатель X не был непростительно малым. Никак не 5%. Дальше в дело вступают профессионалы Retail Rocket. И это не сарказм.

Я не знаю, как еще можно назвать людей, которые за пару писем и звонков способны убедить крупную компанию «забить» на результаты теста, потратить кучу денег на повторную интеграцию и ещё три месяца на повторное тестирование, причем за эти три месяца от магазина так и не пришла команда: «Всё, тест официально запущен». Это достойно восхищения. У нас так никогда не получалось.

Наверное, это потому, что мы программисты. Зато иногда обращаем внимание на странные вещи. Первая вещь — это сегментация на пять месяцев. Всё бы ничего, вот только у моего пользователя изменился сегмент в момент тестирования товарных рекомендаций. Это было в начале марта.

Как водится, у нас сработал «синдром Навального». И мы решили провести собственное расследование — со скандалами и интригами. Добавили в SDK плохо читаемый код, льющий нам в базу присвоенные пользователям сегменты и прикрыли его от Москвы, чтобы враг не сразу заметил. И стали ждать.

Ждать пришлось недолго — несколько сотен человек меняли свои сегменты ежедневно. Мы обрадовались и стали планировать, как раскопать причины смены сегментов и как это всё потом красиво подать в СМИ. Вот только мне хватило ума задать юристам вопрос: можно ли нам опубликовать такое. В ответ мне сказали: «Если много лишних денег, то можно». Расшифровка будет ниже.

Детективная горячка сразу прошла, у нас нашлось много другой, более важной работы, а смену сегментов мы списали на устаревание куки — сегментатор Retail Rocket стоит на сайте уже давно, просто это старые пользователи, и у них устарела куки. Но всегда есть «но». Об этом тоже ниже.

К апрелю магазин закончил доработки интеграции рекомендательных систем, мы же переделали отслеживание смены сегментов в скрипт инициализации — скрывать-то уже нечего. И стали ждать официального начала A/B-теста. Вот только он не начинался, потому что с завидной регулярностью ребята из Retail Rocket находили, что у них что-то ещё работает не так, писали, что нужно что-то переделать. Ну и стабильно проигрывали, конечно. Так прошел апрель.

В начале мая магазин прислал нам письмо: Retail Rocket нашла, что сегменты пользователей меняются и предлагают удалить из отчета заказы для измененных пользователей. Примечательно, что больше всего измененных пользователей было у нас.

Я ответил, что сегменты меняются из-за программы Retail Rocket и приложил отчет о смене сегментов у 400 пользователей за последние сутки с равномерным распределением пользователей по сегментам. После этого мы еще съездили в гости к представителю магазина и подробно рассказали, почему сегменты меняются (устаревание куки — тогда мы ещё так думали, да).

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

Переделывать сегментатор — это еще две-четыре недели разработки со стороны магазина и месяц ABC-теста. Вот мы и «починили» сегментатор Retail Rocket. Мы стали восстанавливать потерянные сегменты, используя старый и плохо читаемый код в SDK.

У некоторых может возникнуть вопрос, почему же мы не восстанавливаем сегменты для Москвы. Ответ прост: забыли убрать проверку. А кто работает без багов? Отметьтесь в комментариях, я поставлю за вас свечку в церкви.

А потом случилась «грязная пятница». Вместо того, чтобы задать нам вопрос или хотя бы пошантажировать, конкурент решил сыграть в «Скандалы, интриги, расследования».

Вообще у нас ИТ-рынок пока немного диковат: ты можешь ходить по конференциям или офисам и поливать конкурента грязью в кулуарах и тебе за это ничего не будет. До тех пор, пока не сделаешь этого публично. Ребята из Retail Rocket увидели часть нашей функциональности, выдали её за желаемое и раздули из этого скандал.

А мы подали иск. Мы ничего не должны доказывать. Теперь это проблема ответчика — доказать, что это не клевета. Что будет дальше? Дальше шоу будет продолжаться еще месяцев шесть, не меньше. Поэтому попкорна потребуется много. Каждое более или менее значимое действие мы будем освещать.

Ну, и напоследок кое-что для обсуждения. Мы сделали в Google Analytics ровно такой же отчет по переходам пользователей. Вот эти данные за период с 7 по 9 июня:

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

Удобный инструмент. Покликайте по сессиям, чтобы посмотреть историю переходов пользователей между сегментами. История некоторых уходит корнями в начало марта. А еще бывают люди, поменявшие сегмент 865 раз. Почему данные отличаются? Это вопрос к специалистам по Google Analytics. Мы просто программисты.

#Колонка