Привет, Хабр!

Мы уделяем особенное внимание проверке интеграции при подключении нового клиента к платформе и постоянно отслеживаем статус интеграции в процессе работы. Почему это критически важно? Потому что сбор данных — основа формирования качественных рекомендаций.



Работа рекомендательной системы строится на нескольких важных составляющих: сбор данных, их хранение, обработка, выдача рекомендаций и growth hacking. Плюс «железо» для обеспечения вычислительных мощностей алгоритмов и процесс верстки. Таким образом мы получаем как минимум 7 пунктов, от которых зависит качество рекомендаций, не говоря уже о дорогой команде аналитиков. Как внешний сервис, так и внутренняя система рекомендаций интернет-магазина, должны охватывать все эти пункты и качественно обеспечивать работу на всех этапах.

Привет, Хабр!

О геймификации говорят много и часто, но далеко не всегда у компаний получается применить полученные в играх знания на практике. Мы в Retail Rocket считаем, что обучение через игру помогает гораздо лучше понять особенности различных процессов и учитывать этот опыт при работе над проектами.

Сегодня мы хотим рассказать, как игра «Playing Lean» помогает не только погрузиться в методологию бережливого производства, но и применить этот опыт на практике — в разработке продуктов и новых фич.

Привет, Хабр! Сегодня мы хотим поделиться с сообществом подборкой лучших материалов конференции ACM Recommender Systems (RecSys), которые обязательно нужно прочитать каждому специалисту, который занимается рекомендательными системами.

Привет, Хабр! Как директор по аналитике Retail Rocket, я периодически посещаю различные профильные мероприятия, и в сентябре 2016 года мне посчастливилось побывать на конференции RecSys, посвященной рекомендательным системам, в Бостоне. Было очень много интересных докладов, но мы решили сделать перевод одного из них Lessons Learned from Building Real­-Life Recommender Systems. Он очень интересен с позиции того, как Machine Learning применять в production системах. Про сам ML написано множество статей: алгоритмы, практика применения, конкурсы Kaggle. Но вывод алгоритмов в production — это отдельная и большая работа. Скажу по секрету, разработка алгоритма занимает всего 10%-20% времени, а вывод его в бой все 80-90%. Здесь появляется множество ограничений: какие данные где обрабатывать (в онлайне или оффлайне), время обучения модели, время применения модели на серверах в онлайне и т.д. Критически важным аспектом также является выбор оффлайн/онлайн метрик и их корреляция. На этой же конференции мы делали похожий доклад Hypothesis Testing: How to Eliminate Ideas as Soon as Possible, но выбрали вышеупомянутый учебный доклад от Quora, т.к. он менее специфичный и его можно применять за пределами рекомендательных систем.

Привет, Хабр! В своей работе мы используем парное программирование и сегодня хотим поделиться с сообществом советами, которые помогают нам повысить эффективность этого метода.



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

Когда речь заходит о разработке, менеджеры и управленцы сразу вспоминают накопившийся массив задач, которые ждут своей очереди, непредсказуемые сроки их реализации, имеющие свойство постоянно меняться, натянутые отношения с IT-отделом, который использует систему «свой-чужой», и множество других проблем, тормозящих развитие бизнеса. Чтобы решить все эти проблемы, необходимо научиться грамотно ставить задачи и общаться с разработчиками. О том, как менеджеры должны ставить задачи, чтобы они были выполнены в срок и в соответствии с заданием, рассказывает Николай Хлебинский, СЕО и сооснователь платформы Retail Rocket.

В прошлом посте мы рассказали о том, как работаем с бэклогом, а сегодня поделимся подробностями о процессе планирования, который в нашем случае не только полезный, но и увлекательный, поскольку оценку задач мы проводим с помощью «Planning Poker».

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

Несколько месяцев назад один из наших конкурентов начал делать странное – предлагать нашим клиентам сравнение своей системы рекомендаций с Retail Rocket через АБ-тесты в формате «пари» с обязательством заплатить 100 000 рублей в случае проигрыша.

Подобные истории для нас не редкость — за время существования компании нашу систему сравнивали практически со всеми существующими рекомендательными системами в России и за рубежом, и мы всегда показывали отличные результаты (ни в одном тесте мы не проиграли по эффективности).

Первый тест с Rees не заставил себя ждать, но в ходе его проведения мы столкнулись с довольно странными результатами, которые вылились в серьезное исследование. То, что мы обнаружили в итоге, удивило нас так сильно, что мы хотим поделиться деталями этого исследования и вынести его результаты на суд IT-сообщества и индустрии электронной коммерции в России.

Хабр, привет! Мы продолжаем делиться с сообществом внутренней кухней Retail Rocket, и сегодня расскажем о нашем подходе к работе с бэклогом. Правильная приоритезация задач — это первый шаг в решении таких важных проблем проекта как:

• уменьшение технического долга,
• поддержка скорости работы производства,
• поддержка качества продукта.

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

Вот как эти два принципа воплощаются в правила приоритезации бэклога.

Хабр, привет!

Команда Retail Rocket использует узкоспециализированный стек технологий Hadoop + Spark для вычислительного кластера, о котором мы уже писали обзорный материал в самом первом посте нашего инженерного блога на Хабре.

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

Хабр, привет!

Мы продолжаем приоткрывать дверь в технологическую кухню Retail Rocket. В сегодняшней статье мы решили поделиться историей о нашем «корпоративном backend`е», речь пойдет о рабочем месте для разработчика. Та самая зона комфорта, которая окружает нас в жизни, но является не менее важной, чем выбор стека технологий.

Передо мной встала задача подготовить рабочее место для нового члена команды разработки, казалось бы, что может быть проще? На практике оказалось все гораздо сложнее, чем я ожидал. Раньше мы покупали стол «Галант» в IKEA, любое офисное кресло + MacBook Pro – и у нас готово новое рабочее место.


Старое рабочее место .NET разработчика в офисе Retail Rocket

С тех пор прошло 2 года, мы выросли, у нас изменился стиль работы — пора подбирать новую конфигурацию. Половина нашей команды работает на технологическом стеке от Microsoft. Это большой проект в Visual Studio 2015 + Resharper: 26 приложений, 9 библиотек, 3 проекта с тестами, что в сумме на момент публикации статьи дает 4 312 файлов и более 60 тыс. строк кода. Плюс IIS с компиляцией и запуском приложения на локальной машине, что накладывает повышенные требования к вычислительной мощности используемого оборудования.

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

Привет, Хабр! Мы продолжаем делиться технологической кухней Retail Rocket. В сегодняшней статье мы разберем вопрос выбора БД для хранения больших и часто обновляемых данных.

На самом начальном этапе разработки платформы перед нами возникли следующие задачи:

• Хранить у себя товарные базы магазинов (т.е. сведения о каждом товаре всех подключенных в нашу платформу магазинов с полным обновлением 25 млн. товарных позиций каждые 3 часа).
• Хранить рекомендации для каждого товара (около 100 млн. товаров содержит от 20 и более рекомендуемых товаров для каждого ключа).
• Обеспечение стабильно быстрой выдачи таких данных по запросу.

«Горячая» и часто обсуждаемая сегодня тема оптимизации конверсии привела к безусловной популяризации А/Б-тестирования, как единственного объективного способа узнать правду о работоспособности тех или иных технологий/решений, связанных с увеличением экономической эффективности для онлайн-бизнеса.

За этой популярностью скрывается практически полное отсутствие культуры в организации, проведении и анализе результатов экспериментов. В Retail Rocket мы накопили большую экспертизу в оценке экономической эффективности от систем персонализации в электронной коммерции. За два года был отстроен идеальный процесс проведения A/Б-тестов, которым мы и хотим поделиться в рамках этой статьи.

Очень важно выбрать правильный инструмент для анализа данных. На форумах Kaggle.com, где проводятся международные соревнования по Data Science, часто спрашивают, какой инструмент лучше. Первые строчки популярноcти занимают R и Python. В статье мы расскажем про альтернативный стек технологий анализа данных, сделанный на основе языка программирования Scala и платформы распределенных вычислений Spark.

Как мы пришли к этому? В Retail Rocket мы много занимаемся машинным обучением на очень больших массивах данных. Раньше для разработки прототипов мы использовали связку IPython + Pyhs2 (hive драйвер для Python) + Pandas + Sklearn. В конце лета 2014 года приняли принципиальное решение перейти на Spark, так как эксперименты показали, что мы получим 3-4 кратное повышение производительности на том же парке серверов.

Привет, Хабр!

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

Вкратце, Retail Rocket – платформа для мультиканальной персонализации интернет­-магазина на основе Big Data. Наш сервис анализирует поведение посетителей интернет-магазина, выявляет потребности и в нужный момент показывает интересные именно им предложения на сайте, в email и display кампаниях, увеличивая доход интернет­-магазина за счет роста конверсии, среднего чека и частоты повторных покупок.

Этой статьей мы открываем инженерный блог Retail Rocket (маркетинговый блог мы ведем почти два года) с рассказом об используемых подходах в области анализа данных и кратким перечнем используемых технологий. Ко всему описанному в статье мы пришли итеративно и в следующих статьях постараемся подробно описать наш путь в каждой из областей.