Привет, Хабр!
Мы уделяем особенное внимание проверке интеграции при подключении нового клиента к платформе и постоянно отслеживаем статус интеграции в процессе работы. Почему это критически важно? Потому что сбор данных — основа формирования качественных рекомендаций.
Работа рекомендательной системы строится на нескольких важных составляющих: сбор данных, их хранение, обработка, выдача рекомендаций и growth hacking. Плюс «железо» для обеспечения вычислительных мощностей алгоритмов и процесс верстки. Таким образом мы получаем как минимум 7 пунктов, от которых зависит качество рекомендаций, не говоря уже о дорогой команде аналитиков. Как внешний сервис, так и внутренняя система рекомендаций интернет-магазина, должны охватывать все эти пункты и качественно обеспечивать работу на всех этапах.
Алгоритмы считаются черным ящиком, и бытует мнение, что можно быстро получить 50-70% эффективности рекомендательной системы на основе open source ПО. Но ПО — лишь один из семи пунктов, который если и даст эффективность 50-70%, то только одного пункта. Т.е. без остальных составляющих это примерно 7-10% эффективности системы.
Мы так или иначе общаемся практически со всеми технологическими компаниями на рынке России и в других странах, где ведем операции, и можем с уверенностью утверждать, что наш подход к обеспечению качества обмена данными один из самых продуманных в мире.
За годы практики мы накопили огромную экспертизу в каждом пункте. Мы часто рассказываем о том, какие результаты дают наши алгоритмы и каких успехов для магазинов добивается команда Growth Hacker’ов, но сегодня хотим остановится на самом первом пункте — сборе данных.
Если на этапе сбора возникают какие-то проблемы, они будут напрямую влиять на дальнейшие этапы формирования рекомендаций и, таким образом, могут уничтожить практически всю ценность, которую мог получить интернет-магазин. Именно поэтому мы предъявляем такие высокие требования к качеству и полноте данных.
В своей практике мы встречали различные случаи, когда из-за особенностей внутренних процессов, технических сбоев или просто по невнимательности передаются некорректные или неполные данные, что негативно сказывается на качестве работы сервиса. Например, id товара или категории меняется несколько раз в неделю, товары дублируются или наоборот передаются не все и т.д. Такие факторы сильно влияют на точность формирования рекомендаций.
Мы предлагаем клиентам не только свои технологии, но и экспертизу, в том числе в части контроля качества обмена данными, поэтому расскажем о нескольких важных параметрах, которые нужно учитывать при передаче данных в рекомендательную систему.
Интеграция с системой Retail Rocket проводится через установку трекинг-кодов. На разных страницах сайта размещаются скрипты по определенным правилам. Непосредственно на установку трекинг-кодов требуется около пары часов. Но за счет высоких требований к качеству и полноте данных, процесс может затягиваться. Например, интернет-магазин готовит YML-файл по стандартным требованиям других сервисов и в нем отсутствуют важные детали для формирования рекомендаций. Поскольку для всех дальнейших этапов сбор данных имеет огромное значение, мы тщательно прорабатываем каждый пункт интеграции.
Сразу после установки трекинг-кодов наши специалисты проверяют корректность работы скриптов на всех страницах, а также качество и полноту передаваемых данных. Бывают ситуации, когда коды размещаются не всех страницах, трекаются не все события (добавления в корзину, заказы) или в фиде передаются не все товары, их свойства и другие важные параметры. Для нашей команды это целый процесс, где на каждом этапе за корректностью установки трекеров и передачи данных следят специалисты — от аккаунт-менеджеров до технической поддержки.
Так выглядит часть нашей канбан-доски по интеграции, по которой проходит каждый клиент:
При проведении интеграции мы проверяем десятки параметров. Рассказываем о самых важных.
Корректность и полнота передаваемых товаров и категорий, а также соответствие их товарам и категориям на сайте — один из самых важных параметров для формирования рекомендаций.
Каталог товаров, передаваемый через XML Feed, должен точно соответствовать структуре меню сайта. Для проверки менеджер выбирает ряд случайных товаров из разных категорий, чтобы убедиться, что товар находится в тех же вложенных категориях, что и на сайте интернет-магазина.
Помимо структуры, количество продуктов и категорий в файле должно соответствовать количеству продуктов на сайте. С помощью специальных отчетов, мы можем отслеживать, все ли товары, размещенные на сайте, передаются в YML-файле. Список товаров, которых нет в фиде, формируется на отдельной странице, и аккаунт-менеджер может сразу отправить его клиенту.
Кроме того, важно не удалять товар из фида, когда он уходит из наличия. На товары не в наличии может вести контекстная реклама, ссылки из поиска и других ресурсов. Пользователь, попавший на страницу товара не в наличии, имеет уже сформированный спрос, т.е. он готов к покупке и ему можно рекомендовать максимально похожие альтернативы. Поэтому важно не только не удалять товар не в наличии из фида, но и передавать максимум параметров, чтобы рекомендательные алгоритмы могли сформировать выдачу альтернативных товаров.
Для интернет-магазинов с представительствами в нескольких городах важно передавать данные для каждого из регионов. В разных регионах у товаров может быть разная стоимость и разное наличие, поэтому важно учитывать эти данные и передавать их в фиде.
Кроме того, это может быть важно и для маркетинговых задач, например, в каких-то городах клиентам важнее скидки, а в других — бонусные баллы. С помощью параметра региональности можно оптимизировать маркетинговые кампании.
Еще один важный параметр данных, которые нужно передавать для качественного формирования рекомендаций, это свойства товаров, такие как цвет, размер, бренд и т.д.
Здесь стоит отметить два момента. Во-первых, для некоторых отраслей учет определенных свойств товаров критически важен для формирования правильных рекомендаций. Например, для магазина обуви таким параметром будет размер, потому что рекомендация пусть и очень похожей пары, но 40-го размера вместо 36-го, вряд ли заинтересует покупателя. Для решения этого вопроса, в октябре 2017 года мы усовершенствовали механизмы персонализации для магазинов fashion-сегмента, чтобы учитывать размер одежды или обуви пользователя в блоках рекомендаций.
Во-вторых, если магазины учитывают каждый размер и цвет как отдельный товар, в рекомендациях похожих товаров могут показываться другие размеры/цвета того же товара, поскольку для алгоритма они выглядят как максимально похожие. Например, к кольцу одного размера в качестве альтернатив строятся рекомендации точно таких же колец, но другого размера. В платформе Retail Rocket это решается с помощью групповых товаров.
Если ID или другие свойства товара меняются слишком часто, например, товар постоянно переходит из категории в категорию, качество рекомендаций может заметно упасть. Если в момент расчета рекомендаций сопутствующих товаров, товар находился в одной категории, а в момент запроса рекомендации уже перешел в другую — выдача может получится не релевантной, и потребуется некоторое время, чтобы алгоритм переформировал связи между товарами и категориями.
Кроме того, это может происходить из-за нарушения бизнес-правил, например, когда прописываются условия не рекомендовать товары одной категории к товарам другой. Когда id товаров или категорий меняются, бизнес-правила рушатся и их необходимо прописывать заново, чтобы рекомендации строились качественно.
Еще один важный показатель, по которому можно проверить полноту данных и корректность их передачи — это совпадение между числами в отчете по продажам нашей платформы и системе веб-аналитики клиента (например, Google Analytics). Мы сравниваем количество заказов и объем выручки — разница должна быть минимальной.
Таким образом мы понимаем, все ли трекинг коды работают корректно и точно ли все данные передаются в систему. Если проявляются какие-то различия, мы начинаем «копать» и искать причины. Например, трекинг код может быть не установлен на какой-то странице, и из-за этого данные разнятся. То есть это своеобразный маркер, по которому сразу видно, если что-то не так.
Этот пункт важен по нескольким причинам. Во-первых, благодаря такой синхронизации мы понимаем, насколько эффективно будут работать триггерные письма в конкретном интернет-магазине. Например, можно ли отправить письмо о брошенном просмотре пользователю, чей email есть у магазина.
Также мы ежедневно отслеживаем показатели триггерных писем. Если на графике видим, что сегодня количество отправленных писем меньше, чем средний показатель за определенный период, проверяем, что случилось.
Во-вторых, чтобы получать как можно больше информации о пользователе, важно соединить его профиль на сайте и в email. Наши трекеры отслеживают адреса на всех страницах, где пользователь может согласится на получение рассылок (регистрация, логин, оформление заказа, формы подписки и т.д), чтобы мы могли собрать максимальное количество email’ов клиентов. Таким образом повышается покрытие, количество отправок и, как следствие, увеличивается число заказов.
Кроме того, когда пользователь открывает письмо и переходит по ссылке, у нас есть возможность отслеживать его поведение на сайте, историю просмотров и покупок, и таким образом делать более точные рекомендации на сайте и email-рассылках.
Главная ценность платформы персонализации в ее алгоритмах, но чтобы они работали на полную мощность, необходимо, в том числе, постоянно следить за правильностью интеграции на всех страницах сайта.
Мы часто пишем о том, что одна из наших особенностей состоит в том, что мы не заканчиваем работу на этапе установки, а стараемся постоянно улучшать все метрики. Это касается не только проведения A/B-тестирований различных алгоритмов, но и постоянного трекинга корректности работы наших рекомендаций.
Мы разработали специальный интерфейс, с помощью которого наши специалисты могут в реальном времени следить за статусом интеграции, и оперативно реагировать в случае возникновения каких-то проблем.
Для каждой возможной ситуации автоматически формируется отчет с описанием необходимых действий, который можно отправить представителю интернет-магазина.
Например, у нас разработана отдельная подсистема, которая скачивает картинки с сайта интернет-магазина, ресайзит их и хранит на собственном CDN. В статусе интеграции мы отслеживаем, есть ли проблемы с какими-то изображениями, видим процент таких изображений и сразу можем отправить клиенту отчет и советы по исправлению ситуации, автоматически сформированные системой.
В случае технических сбоев на стороне клиента хранение изображений на нашем CDN помогает сохранить отображение рекомендаций на сайте и в письмах.
Каким бы высоким не было качество внешнего сервиса, какими бы мощными и умными не были алгоритмы, без эффективного обмена данными результаты могут быть более низкими, чем рассчитывает интернет-магазин. Так же как и интеграция может занять больше времени, если трекинг-коды установлены не везде, а в YML-файле не хватает необходимых данных.
Качество обмена данными напрямую влияет на эффективность работы любого внешнего сервиса, но далеко не каждый сервис уделяет достаточно внимания проверке таких деталей. Мы стремимся не только делать нашими алгоритмы эффективными и постоянно их улучшаем, но следим за правильностью интеграции с сайтом клиента.
Мы уделяем особенное внимание проверке интеграции при подключении нового клиента к платформе и постоянно отслеживаем статус интеграции в процессе работы. Почему это критически важно? Потому что сбор данных — основа формирования качественных рекомендаций.
Работа рекомендательной системы строится на нескольких важных составляющих: сбор данных, их хранение, обработка, выдача рекомендаций и growth hacking. Плюс «железо» для обеспечения вычислительных мощностей алгоритмов и процесс верстки. Таким образом мы получаем как минимум 7 пунктов, от которых зависит качество рекомендаций, не говоря уже о дорогой команде аналитиков. Как внешний сервис, так и внутренняя система рекомендаций интернет-магазина, должны охватывать все эти пункты и качественно обеспечивать работу на всех этапах.
Алгоритмы считаются черным ящиком, и бытует мнение, что можно быстро получить 50-70% эффективности рекомендательной системы на основе open source ПО. Но ПО — лишь один из семи пунктов, который если и даст эффективность 50-70%, то только одного пункта. Т.е. без остальных составляющих это примерно 7-10% эффективности системы.
Мы так или иначе общаемся практически со всеми технологическими компаниями на рынке России и в других странах, где ведем операции, и можем с уверенностью утверждать, что наш подход к обеспечению качества обмена данными один из самых продуманных в мире.
За годы практики мы накопили огромную экспертизу в каждом пункте. Мы часто рассказываем о том, какие результаты дают наши алгоритмы и каких успехов для магазинов добивается команда Growth Hacker’ов, но сегодня хотим остановится на самом первом пункте — сборе данных.
Если на этапе сбора возникают какие-то проблемы, они будут напрямую влиять на дальнейшие этапы формирования рекомендаций и, таким образом, могут уничтожить практически всю ценность, которую мог получить интернет-магазин. Именно поэтому мы предъявляем такие высокие требования к качеству и полноте данных.
В своей практике мы встречали различные случаи, когда из-за особенностей внутренних процессов, технических сбоев или просто по невнимательности передаются некорректные или неполные данные, что негативно сказывается на качестве работы сервиса. Например, id товара или категории меняется несколько раз в неделю, товары дублируются или наоборот передаются не все и т.д. Такие факторы сильно влияют на точность формирования рекомендаций.
Мы предлагаем клиентам не только свои технологии, но и экспертизу, в том числе в части контроля качества обмена данными, поэтому расскажем о нескольких важных параметрах, которые нужно учитывать при передаче данных в рекомендательную систему.
Интеграция с Retail Rocket
Интеграция с системой Retail Rocket проводится через установку трекинг-кодов. На разных страницах сайта размещаются скрипты по определенным правилам. Непосредственно на установку трекинг-кодов требуется около пары часов. Но за счет высоких требований к качеству и полноте данных, процесс может затягиваться. Например, интернет-магазин готовит YML-файл по стандартным требованиям других сервисов и в нем отсутствуют важные детали для формирования рекомендаций. Поскольку для всех дальнейших этапов сбор данных имеет огромное значение, мы тщательно прорабатываем каждый пункт интеграции.
Сразу после установки трекинг-кодов наши специалисты проверяют корректность работы скриптов на всех страницах, а также качество и полноту передаваемых данных. Бывают ситуации, когда коды размещаются не всех страницах, трекаются не все события (добавления в корзину, заказы) или в фиде передаются не все товары, их свойства и другие важные параметры. Для нашей команды это целый процесс, где на каждом этапе за корректностью установки трекеров и передачи данных следят специалисты — от аккаунт-менеджеров до технической поддержки.
Так выглядит часть нашей канбан-доски по интеграции, по которой проходит каждый клиент:
Параметры проверки интеграции
При проведении интеграции мы проверяем десятки параметров. Рассказываем о самых важных.
Полнота товарной базы
Корректность и полнота передаваемых товаров и категорий, а также соответствие их товарам и категориям на сайте — один из самых важных параметров для формирования рекомендаций.
Каталог товаров, передаваемый через XML Feed, должен точно соответствовать структуре меню сайта. Для проверки менеджер выбирает ряд случайных товаров из разных категорий, чтобы убедиться, что товар находится в тех же вложенных категориях, что и на сайте интернет-магазина.
Помимо структуры, количество продуктов и категорий в файле должно соответствовать количеству продуктов на сайте. С помощью специальных отчетов, мы можем отслеживать, все ли товары, размещенные на сайте, передаются в YML-файле. Список товаров, которых нет в фиде, формируется на отдельной странице, и аккаунт-менеджер может сразу отправить его клиенту.
Кроме того, важно не удалять товар из фида, когда он уходит из наличия. На товары не в наличии может вести контекстная реклама, ссылки из поиска и других ресурсов. Пользователь, попавший на страницу товара не в наличии, имеет уже сформированный спрос, т.е. он готов к покупке и ему можно рекомендовать максимально похожие альтернативы. Поэтому важно не только не удалять товар не в наличии из фида, но и передавать максимум параметров, чтобы рекомендательные алгоритмы могли сформировать выдачу альтернативных товаров.
Учет параметров регионов
Для интернет-магазинов с представительствами в нескольких городах важно передавать данные для каждого из регионов. В разных регионах у товаров может быть разная стоимость и разное наличие, поэтому важно учитывать эти данные и передавать их в фиде.
Кроме того, это может быть важно и для маркетинговых задач, например, в каких-то городах клиентам важнее скидки, а в других — бонусные баллы. С помощью параметра региональности можно оптимизировать маркетинговые кампании.
Передача свойств товаров
Еще один важный параметр данных, которые нужно передавать для качественного формирования рекомендаций, это свойства товаров, такие как цвет, размер, бренд и т.д.
Здесь стоит отметить два момента. Во-первых, для некоторых отраслей учет определенных свойств товаров критически важен для формирования правильных рекомендаций. Например, для магазина обуви таким параметром будет размер, потому что рекомендация пусть и очень похожей пары, но 40-го размера вместо 36-го, вряд ли заинтересует покупателя. Для решения этого вопроса, в октябре 2017 года мы усовершенствовали механизмы персонализации для магазинов fashion-сегмента, чтобы учитывать размер одежды или обуви пользователя в блоках рекомендаций.
Во-вторых, если магазины учитывают каждый размер и цвет как отдельный товар, в рекомендациях похожих товаров могут показываться другие размеры/цвета того же товара, поскольку для алгоритма они выглядят как максимально похожие. Например, к кольцу одного размера в качестве альтернатив строятся рекомендации точно таких же колец, но другого размера. В платформе Retail Rocket это решается с помощью групповых товаров.
Смена ID товара или его свойств
Если ID или другие свойства товара меняются слишком часто, например, товар постоянно переходит из категории в категорию, качество рекомендаций может заметно упасть. Если в момент расчета рекомендаций сопутствующих товаров, товар находился в одной категории, а в момент запроса рекомендации уже перешел в другую — выдача может получится не релевантной, и потребуется некоторое время, чтобы алгоритм переформировал связи между товарами и категориями.
Кроме того, это может происходить из-за нарушения бизнес-правил, например, когда прописываются условия не рекомендовать товары одной категории к товарам другой. Когда id товаров или категорий меняются, бизнес-правила рушатся и их необходимо прописывать заново, чтобы рекомендации строились качественно.
Сверка данных систем аналитики
Еще один важный показатель, по которому можно проверить полноту данных и корректность их передачи — это совпадение между числами в отчете по продажам нашей платформы и системе веб-аналитики клиента (например, Google Analytics). Мы сравниваем количество заказов и объем выручки — разница должна быть минимальной.
Таким образом мы понимаем, все ли трекинг коды работают корректно и точно ли все данные передаются в систему. Если проявляются какие-то различия, мы начинаем «копать» и искать причины. Например, трекинг код может быть не установлен на какой-то странице, и из-за этого данные разнятся. То есть это своеобразный маркер, по которому сразу видно, если что-то не так.
Синхронизация сайта и email
Этот пункт важен по нескольким причинам. Во-первых, благодаря такой синхронизации мы понимаем, насколько эффективно будут работать триггерные письма в конкретном интернет-магазине. Например, можно ли отправить письмо о брошенном просмотре пользователю, чей email есть у магазина.
Также мы ежедневно отслеживаем показатели триггерных писем. Если на графике видим, что сегодня количество отправленных писем меньше, чем средний показатель за определенный период, проверяем, что случилось.
Во-вторых, чтобы получать как можно больше информации о пользователе, важно соединить его профиль на сайте и в email. Наши трекеры отслеживают адреса на всех страницах, где пользователь может согласится на получение рассылок (регистрация, логин, оформление заказа, формы подписки и т.д), чтобы мы могли собрать максимальное количество email’ов клиентов. Таким образом повышается покрытие, количество отправок и, как следствие, увеличивается число заказов.
Кроме того, когда пользователь открывает письмо и переходит по ссылке, у нас есть возможность отслеживать его поведение на сайте, историю просмотров и покупок, и таким образом делать более точные рекомендации на сайте и email-рассылках.
Отслеживание статуса интеграции в реальном времени
Главная ценность платформы персонализации в ее алгоритмах, но чтобы они работали на полную мощность, необходимо, в том числе, постоянно следить за правильностью интеграции на всех страницах сайта.
Мы часто пишем о том, что одна из наших особенностей состоит в том, что мы не заканчиваем работу на этапе установки, а стараемся постоянно улучшать все метрики. Это касается не только проведения A/B-тестирований различных алгоритмов, но и постоянного трекинга корректности работы наших рекомендаций.
Мы разработали специальный интерфейс, с помощью которого наши специалисты могут в реальном времени следить за статусом интеграции, и оперативно реагировать в случае возникновения каких-то проблем.
Для каждой возможной ситуации автоматически формируется отчет с описанием необходимых действий, который можно отправить представителю интернет-магазина.
Например, у нас разработана отдельная подсистема, которая скачивает картинки с сайта интернет-магазина, ресайзит их и хранит на собственном CDN. В статусе интеграции мы отслеживаем, есть ли проблемы с какими-то изображениями, видим процент таких изображений и сразу можем отправить клиенту отчет и советы по исправлению ситуации, автоматически сформированные системой.
В случае технических сбоев на стороне клиента хранение изображений на нашем CDN помогает сохранить отображение рекомендаций на сайте и в письмах.
Заключение
Каким бы высоким не было качество внешнего сервиса, какими бы мощными и умными не были алгоритмы, без эффективного обмена данными результаты могут быть более низкими, чем рассчитывает интернет-магазин. Так же как и интеграция может занять больше времени, если трекинг-коды установлены не везде, а в YML-файле не хватает необходимых данных.
Качество обмена данными напрямую влияет на эффективность работы любого внешнего сервиса, но далеко не каждый сервис уделяет достаточно внимания проверке таких деталей. Мы стремимся не только делать нашими алгоритмы эффективными и постоянно их улучшаем, но следим за правильностью интеграции с сайтом клиента.
