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

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

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

В заключительной статье цикла мы рассмотрим несколько алгоритмов и разберем некоторые их компоненты, которые наиболее важны и отличаются от тех, что мы рассмотрели ранее.

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

Компания Retail Rocket более 10-ти лет занимается системами рекомендаций в сфере электронной коммерции. Всё это время мы сталкиваемся с неочевидными свойствами алгоритмов рекомендаций, без которых системы не будут решать свои задачи. Мы выделили и описали в статье такие свойства, как: эффективность, логичность, покрытие, специфичность, охват, актуальность и мультирегиональность. Если у вас есть система рекомендаций, и вы хотите оценить ее качество, либо вы ищете критерии для выбора или разработки системы рекомендаций, то эта статья будет вам полезна.

В этой статье, состоящей из трёх частей, мы рассказываем о нашем исследовании метрик, на которые стоит ориентироваться, чтобы увеличить долгосрочную выручку онлайн-магазина.

Это третья часть статьи, где мы обсудим, как отбирать метрики с точки зрения смысла для бизнеса и на их основе принимать решения, повышающие LTV пользователей, а вместе с ним и долгосрочную выручку онлайн-магазина.

В этой статье, состоящей из трёх частей, мы рассказываем о нашем исследовании метрик, на которые стоит ориентироваться, чтобы увеличить долгосрочную выручку онлайн-магазина.

Это вторая часть статьи, где мы детально объясняем, как можно найти и выбрать полезные прокси-метрики из множества вариантов, насколько хорошо они предсказывают LTV покупателей, смогут ли магазины с разными категориями товаров их использовать и т.д.

В данной статье, состоящей из трёх частей, мы поделимся нашим исследованием о метриках, на которые стоит ориентироваться для увеличения долгосрочной выручки онлайн-магазина.

В этой заметке я поделюсь наблюдениями о проблемах концепции exception в языке C#, именно о тех, которые возникают от самого факта наличия такой ее реализации. И оставлю “за скобками" проблемы, которые появляются от ее неправильного использования. Ниже я перечислю и опишу их.

Пришло время посмотреть на тип модели классов UML, который можно встретить во множестве проектов. А ещё, увы, который часто поощряется в книгах по UML.

В первых двух частях (1, 2) мы обсудили общий принципы UML, о семантике и признаках хорошей модели. В этой части добавим ещё кое-что про хорошие модели и перейдём к плохим.

Я часто собеседую кандидатов на позиции .Net разработчиков в Retail Rocket. В прошлом работал в компаниях с различными командами. И далеко не один раз встречал и продолжаю встречать мнение, что “автотесты хорошо, но на них нет времени, писать их дорого, тестировать должны тестировщики”. Такое мнение не у всех, но встречается нередко (не исключаю, что мне так «везет»). В связи с этим хочу поделиться нашим подходом к автоматическому тестированию и обеспечению качества. Расскажу путь, который мы в Retail Rocket прошли за последние 3-4 года, к чему пришли сейчас, и —  главное — что дают нам автотесты и для чего мы их пишем. Надеюсь, статья кого-нибудь сподвигнет писать автотесты, кого-то — писать больше автотестов, а кому-то, возможно, поможет избежать ошибок, с которыми мы сталкивались.

Вторая часть перевода статьи Леона Старра, инженера программных моделей. Первая часть вот здесь. В этой части — о семантике и о том, что отличает хорошую модель.

Мне показался близким подход Леона Старра к объяснению чётких моделей классов и описанию их преимуществ. Настолько, что мы в Retail Rocket решили сделать перевод его большой статьи "How To Build Articulated UML Class Models". Будем выкладывать по частям, под катом — первая из трёх.

Предыстория