Как построить сервис уведомлений об отзыве продукции: от сбора извещений до сопоставления затронутых партий

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

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

Сложность не в сборе извещений, а в определении совпадений

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

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

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

Не сводите разные регуляторные источники в одну универсальную таблицу полей

Записи об отзывах потребительских товаров, продуктов питания, лекарств, транспортных средств, а также записи из разных стран и регионов поступают из разных источников и разных правовых контекстов. Эндпоинт API по продуктам питания openFDA разделяет наборы данных, например enforcement, а пример запросов к отчётам enforcement по продуктам питания показывает фильтрацию по диапазону дат и категориям. Они поддерживают поиск по отчётам enforcement по продуктам питания, но их не стоит превращать в единый API реального времени для всех отзывов продукции.

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

• Единый идентификатор, ведомство-источник, ID записи в источнике, дата извещения и время последней проверки.
• Название продукта, бренд, номер модели, код, партия, регион и период продаж; отсутствующие значения должны оставаться пустыми.
• Описание риска, меры по устранению, каналы связи для потребителей и ссылка на оригинальное извещение.
• Текущий статус, предыдущая версия, изменения полей и статус сбоя при сборе данных.
• Исходные записи или снимки, которые можно связать с источником, чтобы стандартизация не стёрла ключевые уточнения.

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

Результаты сопоставления нужно делить на подтверждённые, предполагаемые и без подтверждений

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

Результаты сопоставления можно разделить на три категории:

1. Подтверждённое совпадение: ключевые идентификаторы в записи совпадают с указанными пользователем данными о товаре, а оригинальное извещение по-прежнему приложено для проверки.
2. Предполагаемое совпадение: часть условий совпадает, но нет данных о партии, дате или регионе; в уведомлении прямо указано, где пользователю найти недостающие идентификаторы.
3. Невозможно определить: в источнике недостаточно структурированных полей или результаты распознавания фото нестабильны; продолжайте наблюдение, не делая выводов.

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

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

Записи об отзывах меняются, и у уведомлений должны быть версии

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

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

Если страница источника ненадолго недоступна, интерфейс должен показывать «эта проверка не завершена», а не «новых отзывов нет». Руководство по ошибкам API и самовосстановлению на сайте объясняет, почему тайм-ауты, лимиты запросов, ошибки доступа и ошибки источника данных нужно обрабатывать по отдельности; в сценарии с отзывами особенно важно не выдавать перерывы в покрытии за безопасное состояние.

Пользователям нужны следующие шаги, а не просто сводка

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

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

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

Список вещей сам по себе — чувствительный информационный актив

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

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

Для продавцов исходные данные об отзывах, внутреннее сопоставление SKU и контакты клиентов должны быть разделены по уровням и правам доступа. Сотрудникам, проверяющим отзывы, не обязательно видеть полные профили клиентов, а сотрудники, отвечающие за уведомления, не должны иметь возможности менять исходные подтверждения. В журнале аудита должно быть как минимум указано, кто подтвердил совпадение, какая версия извещения использовалась и какие действия были запущены в отношении каких объектов.

MVP должен проверять цикл сопоставления, а не наращивать количество извещений

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

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

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