Разработка мобильного приложения для сравнения цен (Price Comparison)

Почему сравнение цен ломается на реальных каталогах

Магазины и маркетплейсы отдают каталоги в разном виде: CSV-выгрузки, XML-прайсы, JSON по интерфейсу, а часть источников приходится разбирать прямо из разметки страниц. У одного и того же товара в двух каталогах расходятся порядок слов в названии, разделители в артикулах, единицы измерения и набор характеристик. Сопоставление по точному совпадению строки на разнородных каталогах промахивается в десятках процентов случаев, и это ещё без учёта человеческого фактора в самих данных.

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

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

Добивает качество данных о товарах: пустые характеристики, разные обозначения цвета и объёма, бренд то в названии, то в отдельном поле. Поэтому сопоставление строят не на одной строке, а на наборе признаков — артикул и глобальный идентификатор, бренд, ключевые атрибуты, близость наименований, — а правила нормализации и пороги совпадения настраиваются под конкретный каталог. Ниже разбираем, как это закрывается: от приёма выгрузок до правил склейки и контроля свежести.

Что даёт точное сравнение цен: охват, свежесть, доверие

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

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

Свежесть цен держится на расписании обновлений. Быстрые категории опрашиваются часто и небольшими порциями, медленные — реже, по расписанию; вместо полной перезагрузки каталога обновляются только изменившиеся позиции, поэтому цена доходит до приложения за минуты, а не за сутки. Отдельно настраивается поведение при недоступном источнике: последняя подтверждённая цена сохраняется с меткой времени, а не подменяется догадкой.

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

Варианты получения данных: регулярные выгрузки и сбор с витрин

Каталог сравнения цен — это всегда набор разнородных источников. Магазины отдают прайсы файлами по расписанию, партнёрские программы — потоком через интерфейс, а часть продавцов доступна только через публичную витрину. От выбранного режима зависит свежесть цен, нагрузка на источники и объём ручной работы с расхождениями в сопоставлении товаров.

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

Этапы работ: от разбора данных до запуска и передачи

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

1. Разбор источников. Смотрим, как магазины отдают каталоги: выгрузки, открытые интерфейсы, разметка страниц. Фиксируем частоту обновления, наличие артикула и штрихкода, ограничения по нагрузке на источник.
2. Схема сопоставления. Проектируем правила сведения товара в одну карточку: точные идентификаторы, затем связка «бренд + модель», затем разбор названия. Отдельно описываем категории и единицы измерения — иначе сравнение цен даёт ложные пары.
3. Настройка обновлений. Цены пересчитываются чаще, каталог реже. Настраиваем очередь запросов, повторы при недоступности источника и накопление истории цен — без неё не показать динамику.
4. Проверка на реальных данных. Прогоняем поток за период и сверяем: доля сведённых карточек, ложные склейки, пропущенные позиции. Приёмка идёт на живых категориях, а не на подготовленной выборке.
5. Запуск. Выводим обновления в рабочий контур, включаем оповещения о падении источника и медленных ответах, проверяем поведение приложения при неполных данных.
6. Передача проекта. Отдаём документацию по источникам и правилам, регламент обновлений, доступы и обучаем команду заказчика работе с разметкой.

Каждый этап закрывается артефактом, который можно проверить: описание источников, правила сопоставления, регламент, отчёт по сверке — работу принимают по факту, а не по ощущению.

Состав поставки: схемы данных, регламенты обновления, доступы

Поставка закрывается не датой релиза, а пакетом артефактов, по которому приложение можно развивать и поддерживать без нас. Ниже — что именно остаётся у вашей команды вместе с исходным кодом.

• Схема данных. Сущности товара, магазина, предложения и истории цены, их связи и ключи — по схеме сразу видно, где хранится источник истины для каждой карточки и как строится выдача при сравнении.
• Описание источников. Перечень каналов поступления цен (выгрузка по расписанию, файл, открытый интерфейс магазина), их формат, частота и ограничения по числу обращений.
• Правила сопоставления. Нормализация названий, моделей и характеристик, пороги совпадения и очередь ручного разбора спорных пар — чтобы один и тот же товар не распадался на несколько карточек.
• Регламент обновления. Расписание пересборки цен, порядок действий при недоступности источника и правило, по которому устаревшее предложение скрывается, а не показывается с прошлой ценой.
• Передача доступов. Учётные записи сервисов и панелей, ключи интеграций, права на публикацию сборок, контакты ответственных на стороне магазинов.
• Внутренняя документация. Карта сервисов, схема развёртывания, порядок отката релиза и типовые операции поддержки с описанием ожидаемого результата.
• Метрики сбора. Панель с долей успешно принятых источников, процентом сопоставленных позиций и задержкой между изменением цены и её показом пользователю.

Такой комплект позволяет передать проект другой команде или вести его своими силами: границы данных, правила и ответственность описаны, а не остались в переписке.

Кейс: сократили расхождения в данных и время обновления

Где ломалось до

Сервис сравнения цен собирал предложения от нескольких сотен магазинов: прайс-выгрузки приходили в разных форматах, а сопоставление позиций шло по строке названия. «Смартфон X 128 ГБ чёрный» и «Смартфон X, 128GB, Black» оставались разными товарами, зато склеивались соседние поколения одной линейки. Доля неверных позиций в выдаче держалась на 12–14%, цена на витрине отставала от сайта магазина на десятки минут, а поддержка разбирала поток однотипных обращений «у вас неверная цена».

Что изменили и что получилось

Мы перевели сопоставление на устойчивый ключ: артикул производителя и штрихкод, где они есть, плюс нормализация названия и характеристик для остальных карточек. Сверку с эталонным каталогом Google Merchant Center сделали регулярной, а расхождения — видимыми: пара получает оценку уверенности, и спорные совпадения уходят на ручную проверку, а не в выдачу. Обновление цен перевели на обработку потока изменений — пересчитываются только затронутые позиции и их соседи по сравнению, а не весь каталог целиком.

Доля неверных позиций упала до 0,6–0,9%, время реакции на изменение цены сократилось с десятков минут до 1–3 минут на горячем потоке. Нагрузка на поддержку снизилась примерно в шесть раз: ручные правки каталога свелись к разбору неоднозначных карточек, а типовые обращения закрылись сами. Метрики до и после вынесены в панель мониторинга, поэтому просадку сопоставления видно в день появления, а не по жалобам — регресс ловится до того, как его заметит покупатель.

Что делать, если источники уже подключены, но данные расходятся?

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

Ревизия начинается с выборки, а не с кода. Выгружаем расхождения за период и раскладываем по классам: товар не нашёл пару, нашёл ложную, сошёлся по названию, но разошёлся в характеристиках. Доля каждого класса задаёт порядок работ — обычно основную часть шума даёт один-два класса.

Затем правила выносятся в слой сопоставления, отдельный от логики выдачи. Первичный ключ — штрихкод или артикул производителя, резервное правило — бренд плюс нормализованное название с порогом схожести; спорные пары уходят в таблицу ручных подтверждений, которую обновление каталога не затирает. Единицы измерения и вес фиксируются отдельно: цена за килограмм или литр расходится чаще всего — так бывает и в выгрузках вроде Google Shopping.

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

Критерий готовности — не «расхождений нет», а управляемая доля и понятный откат: правило, ухудшившее выдачу, снимается настройкой без релиза. Опишите, какие источники подключены и где расходятся, — вернёмся с планом ревизии.

Частые технические сомнения: сопоставление и свежесть данных

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

Ниже — вопросы, которые обычно задают на приёмке: пределы источника, поведение без подключения к сети, добавление новых поставщиков данных.

Что видит человек без подключения к сети?

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

Как подключается новый поставщик данных?

Источник добавляется отдельным модулем: описываем структуру его выдачи, приводим поля к общей схеме и включаем в общий поток. Остальные источники при этом не трогаем. Если поставщик меняет структуру выдачи, правки остаются внутри его модуля, и приложение продолжает работать.

Кто отвечает за достоверность цен?

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

Обсудим задачу: что нужно для оценки и плана работ

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

• Источники цен: партнёрские интерфейсы магазинов, выгрузки каталогов, открытые страницы — что доступно и на каких условиях.
• География и сети: страны и города, нужны ли региональные цены и в какой валюте показываем стоимость.
• Сопоставление товаров: есть ли штрихкоды и артикулы поставщиков, по каким признакам считаем два предложения одним товаром.
• Пользовательские сценарии: поиск, список сравнения, история цены, уведомление о снижении, избранное, вход в аккаунт.
• Нагрузка: сколько товаров и магазинов, как часто пересчитываются цены, насколько свежие данные нужны.
• Доступы и правила: договоры с магазинами, ограничения на использование их данных, требования к персональным данным.
• Аналитика и публикация: что считаем целевым действием, в каких магазинах приложений выкладываемся и кто владеет аккаунтами.

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