01 Контекст и проблема
Клиент предлагал BNPL -продукт, ориентированный на лизинг: клиенты подавали заявку на утверждённый лимит расходов, затем финансировали подходящие покупки и возвращали платежи в рассрочку вместо полной оплаты. Продукт охватывал только арендуемые предметы, такие как мебель, телевизоры и потребительская электроника, а не малоценные расходники, такие как ручки, блокноты и канцелярские товары. Клиент рос, интегрируя свою платёжную опцию напрямую на сайты каждого ритейлера: продажи обращаются к ритейлеру, ритейлер предоставляет песочницу, команда интегрирует шлюз, инженерные и QA-тесты кассы, затем обе стороны координируют выпуск производства.
Эта модель работала в пяти-семи ритейлерах и провалилась по мере роста сети. Ритейлеры использовали разные комбинации Shopify, Magento, BigCommerce и кастомных платформ, разные кассы, разные платёжные процессоры, а также разные процедуры песочницы и релиза, поэтому каждая интеграция становилась постоянной реализацией и жизненным циклом поддержки. Любое обновление платформы ритейлера или изменение оформления заказа может заставить клиента перестроить интеграцию, повторить регрессионное тестирование и запланировать новый совместный релиз. Примерно через шесть месяцев программа поддерживала около 15 ритейлеров с 60–70 сотрудниками, а план был заключаться в 200+ ритейлерах на следующий год: линейное расширение подразумевало сотни, возможно, почти тысячу человек. Настоящая проблема заключалась не в возможностях развития. Архитектура делала каждого нового ритейлера новой внешней зависимой, поэтому клиенту нужна была модель, при которой рост ритейлера больше не требует пропорционального роста в инженерии и поддержке.
02 Роль и ограничения
В AI Product Manager я владел сквозным решением: продуктовой стратегией, определением проблем, проектированием пути клиента, определением сценариев использования ИИ, архитектурой решений, стратегией поддержки ритейлеров, требованиями к данным продукта и маркировке, инженерной и координацией AI/ML, требованиям API и бэкенда, интеграцией виртуальных карт, опытом мобильных и браузерных расширений, координацией безопасности и соответствия, аналитике и требованиям к производительности моделей, планированием внедрения и управлением заинтересованными сторонами. Одним из самых важных вопросов было определение того, где ИИ следует и не следует использовать: модель отвечала только на вопрос, подходит ли продукт по политике арендуемых продуктов. Он не определял кредитоспособность, не устанавливал кредитные лимиты, не подтверждал личность, не определял условия погашения, не проводил верификацию SSN и не утверждал счета — всё это оставалось в существующих системах одобрения, идентификации и соглашений клиента.
Ограничения были конкретными. Устраните зависимость от реализации со стороны ритейлера: ни один ритейлер не должен добавлять способ оплаты, предоставлять доступ в песочницу, менять оформление заказа, открывать пользовательские API, назначать разработчиков или запускать совместный QA. Поддерживайте право на участие на уровне товара, поскольку розничный торговец мог продавать как арендуемые, так и неарендуемые товары, поэтому система классифицировала отдельные товары из корзин, а не целые розничные продавцы, и обрабатывала смешанные карты, финансируя только допустимую часть. Работайте с разными технологиями ритейлеров и управляйте изменениями в DOM, потому что расширение всё ещё читает страницы ритейлера, а обновления страниц могут менять структуру HTML, селекторы, карточки товаров, цены и поля оформления заказа. Сохраняйте приемлемую точность классификации, обычно 85–90 процентов при целевом уровне выше 90 и улучшайтесь к 95. Защищайте информацию о клиенте (имя, адрес, мобильный номер, SSN и OTP) с помощью шифрования, токенизации, контроля доступа и аудита. А позже поддерживать физическую розничную торговлю без интеграции в систему точек продаж каждого магазина.
03 Подход к продукту
Вместо того чтобы строить более эффективную команду по интеграции ритейлеров, мы изменили место интеграции. Оригинальная модель размещала финансовые возможности клиента внутри кассы продавца. Обновлённая модель разместила финансовый опыт внутри каналов, контролируемых клиентом: расширение Chrome для электронной коммерции и мобильное приложение клиента для физических магазинов. Это создало общую платформу, независимую от продавца, которая работала во многих ритейлерах без использования способа оплаты клиента.
В интернете продление Chrome определило продавца, сообщило, что клиенту доступно финансирование, прочитало корзину и общий сумм, отправило данные продукта на бэкэнд, классифицировало каждый товар как арендуемый или неарендуемый, исключил неподходящие товары, проверил допустимую сумму по лимиту клиента, поддержал регистрацию и проверку, представил соглашение, создал одноразовую или ограниченную виртуальную карту, и автоматически заполнил его на стандартную кассу магазина. Создание нового ритейлера стало внутренне управляемым процессом, а не шестимесячной двусторонней интеграцией: сбор публичных каталогов ритейлера, маркировка продуктов, подлежащих аренде или нельзящего по политике клиента, обучения или обновления классификатора на тысячах записей, проверки точности по известным этикеткам, настройке извлечения из DOM по названию продукта, цене, количеству, категории и общему объему корзины, Протестируйте сквозной поток, затем активируйте ритейлера — не требуется изменение кассы или развертывание шлюза.
В магазине мы расширили ту же возможность в мобильном приложении. Приложение обнаружило, что покупатель находится внутри геозоны магазина; На счетовой стойке клиент фотографировал детализированный счёт; OCR извлекали названия, количество и цены; Линии были нормализованы и переданы по той же модели допустимости; Приложение разделялось с неподходящими товарами, чтобы не подлежащие аренде продукты могли оплачиваться отдельно; допустимый итог был проверен по лимиту; клиент принял соглашение; Виртуальная карта была создана на соответствующую сумму и использовалась в рамках обычного процесса принятия карт в магазине. Если клиент покинул геозону до использования карты, она автоматически истекает. Геозонирование не обрабатывало транзакцию, оно служило триггером, позволяющим бэкенду изменить статус жизненного цикла карты.
Клиенту, похоже, нужна была большая команда интеграции. Настоящая проблема заключалась в том, что рост зависел от сотен внешних систем ритейлеров и графиков релиза. Перенос опыта в расширение, управляемое клиентом, и мобильное приложение, с виртуальными картами как слоем совместимости, изменило эту зависимость: данные о продуктах ритейлера заменили интеграцию с пользовательскими платежами, и каждый товар решался независимо.
Построенные объекты 04
Обнаружение поддерживаемых ритейлеров
Расширение распознаёт доступные сайты ритейлеров и сообщает, что клиенту доступно финансирование.
Извлечение картриджов на основе DOM
Логика DOM, специфичная для ритейлера, берёт информацию о продуктах и корзине со страницы.
Право на использование продукта ИИ
Каждый товар в тележке классифицируется как арендуемый или неарендуемый по общей модели.
Обращение с смешанными каржетами
Неподходящие товары исключаются, поэтому финансируется только подходящая часть.
Регистрация в расширении
Новые клиенты создают аккаунт, не покидая пути покупок.
Виртуальная карта + автозаполнение оформления заказа
В кассе продавца генерируется одноразовая или ограниченная карта, которая автоматически заполняется.
Путешествие в мобильном магазине
Существующее клиентское приложение было расширено для финансирования подходящих покупок в физических магазинах.
Геоограждение магазинов
Приложение определяет, когда клиент находится внутри заданной зоны поддерживаемого магазина.
Захват клюва + OCR
Клиент фотографирует детализированный счет; OCR извлекает строки из изображения.
Нормализация приёма
OCR выпуск преобразуется в структурированные записи о продуктах, количестве и цене.
Раздел между допустимыми и неподходящими
Приложение показывает, что можно профинансировать, а что нужно оплачивать отдельно.
Срок действия, вызванный геозоной,
Выход за пределы магазина до использования запускает автоматический срок действия карты.
Также поставляются: валидация с одобренным лимитом, верификация мобильного OTP, проверка SSN в реальном времени по существующим системам идентификации клиента, презентация и принятие соглашения (в расширении и в приложении), повторяемая поддержка ритейлера через обучение продукту и конфигурацию DOM, общая классификация продуктов, повторно используемая на обоих каналах, а также единый омниканальный бэкенд для соответствия требованиям, валидация клиентов, соглашения, виртуальные карты и аналитика.
05 Архитектура
Два клиентских канала сходились на одном сервере. Онлайн-канал — это экстракция Chrome extension plus ритейлера DOM; Внутримагазинный канал — это мобильное приложение, а также фотографирование счетов, OCR и геозонирование. Оба используют одни и те же основные сервисы для нормализации продуктов, классификации кредитных продуктов, проверки идентификации клиентов и кредитных лимитов, генерации соглашений, выпуска виртуальных карт, управления жизненным циклом карт, а также аналитики и аудита. Python бэкенд открывает REST API; внешний поставщик плат, совместимый с PCI DSS, выпускает одноразовые или ограниченные виртуальные карты.
Архитектура изменила направление расширения. Если ранее каждому ритейлеру требовался коммерческий договор, технические ресурсы, доступ к песочнице, интеграция платежей, совместное QA, скоординированный релиз и постоянная поддержка платформы, то новый онлайн-ритейлер теперь в первую очередь требует подготовку данных о продукте, маркировку, обучение или валидацию моделей, конфигурацию DOM, тестирование при оформлении заказа и активацию расширений. Новый физический ритейлер в первую очередь требует конфигурации магазина, покрытия данных товара, проверки формата чеков, тестирования OCR , тестирования на соответствие и валидации карты. Безопасность охватывает шифрование, токенизацию, ограниченный доступ, аудитское ведение, верификацию OTP, проверку SSN в реальном времени, контролируемое исполнение соглашений, одноразовые или ограниченные карты, срок действия по геолокации и провайдера, совместимого с PCI DSS. Надёжность отслеживается по поверхности: поломка DOM онлайн (отсутствующие продукты, некорректные селекторы, сбои автозаполнения), OCR изменчивости в магазине (плохое освещение, размытие событий, складки, сокращения, налоговые и дисконтные линии), ограничения геозоны (отклонённые разрешения, точность в помещении, дрейф GPS, задержки выхода, фоновые ограничения ОС) и результаты виртуальной карты (сбои при выдаче, тайм-ауты провайдера, активация, истечение, авторизация). Компромиссы очевидны: независимость ритейлера всё ещё зависит от его DOM; Независимость POS зависит от качества чека; одна общая модель охватывает два совершенно разных типа входов; Контроль местоположения ограничен точностью местоположения; а внешний поставщик карт снижает нагрузку на инфраструктуру, добавляя зависимость от поставщика.
06 Аналитика и наблюдаемость
Расширенная платформа требовала отдельного измерения для онлайн-оформления: OCR производительность, точность модели, поведение местоположения и результаты оплаты, поскольку одна неудача могла возникнуть в любой из них. OCR точность и точность классификации измерялись отдельно: ошибка классификации могла возникнуть из-за неправильного OCR текста, неправильного разбора чеков, недостаточного контекста продукта или реальной ошибки модели. И воронка электронной коммерции (ритейлер зафиксировал → расширение, открытое → корзину, извлечённую → классифицированной → допустимой сумме→ подтверждение соглашения → → карты → автозаполнение → покупки), так и вӑрӑ-воронка в магазине (магазин обнаружен → геозона, введённый → счет, сфотографированный → OCR → →товары строки, классифицированные → неарендуемые, разделённые → допустимых одобренных → соглашения → карты → оплаты или истечении срока годности) были полностью инструментированы. Профиль поддержки тоже изменился: от интеграции с ритейлерами, песочниц и дефектов шлюзов к выставлению счетов, соглашениям, погашению, OCR или чтению счетов, изменениям DOM, вопросам по разрешению местоположения и авторизации карт.
Метрики онлайн-ритейлеров
Обнаружение продавцов, извлечение корзины, ошибки DOM, автозаполнение и успешное оформление заказа, конвертация по согласованию в покупку.
Показатели классификации
Точность по ритейлеру, категориям и каналам, ложным ставкам по аренде и неарендуемым, а также распределение доверия.
OCR метрики
Успех захвата и обработки, сбор по линиям и ценам, полная сверка, возврат и ручная коррекция.
Метрики геозоны
Обнаружение входа, отказ в разрешении, события выхода, истекшие карты после выхода и время от генерации до оплаты.
Метрики виртуальных карт
Запрос на успех, задержку генерации, ошибки провайдера, активацию, результаты авторизации и процент неиспользованных карт.
07 Слой принятия решений ИИ
Модель ответила на один узко определённый вопрос, согласованный для обоих каналов: подходит ли этот продукт в соответствии с политикой клиента о продукте, подлежащем арендованию? Онлайн-данные объединяют название продукта, изображение, категорию, контекст продавца, описание там, где доступно, цену и объём, а также обучаемую этикетку для аренды/неарендованного обучающего. Входные данные в магазине включали OCRизвлеченные описания, текст строки чеков, количество, цену, контекст магазина и данные о предыдущих товарах ритейлера, которые часто были гораздо менее подробными, чем страница электронной коммерции, поэтому нормализация товара была наиболее важной в процессе внутри магазина. Конвейер собирал информацию о продукте из DOM или чека, нормализовал текст, специфичный для ритейлера, сопоставлял с известными категориями, оценивал арендуемость, возвращал результат, рассчитывал допустимую сумму и записывал результат и версию модели для мониторинга. Обучение использовало структурированные данные в виде таблиц (имя, изображение, категория, ритейлер, этикетка) с тысячами примеров для каждого ритейлера или группы ритейлеров, а также модель классификации продуктов под контролем. Сообщаемая точность составляла примерно 85–90 процентов с целью превысить 90 и улучшиться к 95; это была мера на уровне проекта клиента, без отдельной точности, отзыва, F1 или независимой аудитированной оценки.
ИИ отвечал только на вопрос права на продукт. Он никогда не определял кредитоспособность, не устанавливал кредитные лимиты, не подтверждал личность, не определял условия погашения, не проводил проверку SSN или не утверждал счета — все эти счета оставались в существующих системах клиента. Известные способы отказа (неарендуемый товар, оценённый для аренды, неправильно отклонённый в аренду, сокращённая строка чека, упакованный или совершенно новый продукт, изменённая таксономия ритейлера или плохой OCR) указывают на рекомендуемый следующий шаг: решение на основе доверия, которое продолжается автоматически при уверенности, применяет детерминированные правила категории при средней уверенности, требует от клиента вернуть доверительность при низкой уверенности, и исключает или предлагает маршруты для пересмотра, если вопрос не решен.
Статус и результат 08
Расширение Chrome поддерживало 100+ ритейлеров примерно в течение четырёх месяцев, тогда как 15 — примерно шесть месяцев по первоначальной модели, и в итоге позволило клиентам использовать финансовый продукт в 300+ онлайн-ритейлерах, что примерно в двадцать раз больше, чем у 15 ритейлеров. Новому ритейлеру больше не требовались технические ресурсы, доступ к песочнице, интеграция шлюзов, совместное контролирование качества, развертывание на стороне ритейлера или скоординированные релизы; его можно было включить через внутренне контролируемую подготовку, маркировку, обучение моделей, конфигурацию DOM, тестирование при оформлении и активацию. Первоначальная команда из 60–70 человек осталась в целом прежней, с добавлением примерно четырёх-пяти инженеров по искусственному интеллекту и машинному обучению для подготовки данных, обучения моделей и работы с точностью, поэтому организация избежала пропорционального увеличения штата, которое предполагала старая модель. Интеграция ритейлеров, индивидуальная разработка, песочница, совместное тестирование и поддержка платформенных платежей были удалены; Клиент сообщил о увеличении объема транзакций при оформлении заказа, поскольку всё больше мест приняли одобренный лимит (качественно указано, точная цифра не указана). Затем платформа расширилась на физический ритейл через мобильное приложение, доказав, что основная модель не ограничивалась веб-оформлением, а расходы, связанные с повторяющимися интеграциями, песочницами, разработкой шлюзов, совместным контролем качества, координацией релизов и ростом пропорциональной поддержки, улучшились, при этом провайдер виртуальных карт оставался основной внешней зависимостью.
300+
Поддерживаемые онлайн-ритейлеры
20×
Увеличение покрытия розничных продавцов
4 mo
Для 100+ ритейлеров (против 6 месяцев для 15)
85-90%
Отчетная точность модели
09 Размышления / Что дальше
Что сработало — это решение проблемы зависимости вместо проблемы с персоналом: одна возможность допуска обслуживала веб-страницы, корзины для покупок и OCRизвлекаемые счета, виртуальные карты позволяли клиенту работать через платежные потоки, которые уже поддерживали ритейлеры, а каждый канал добавлял свои собственные контроли (извлечение DOM и автозаполнение онлайн; OCR, геозонирование и истечение срока действия карты в магазине) на единой общей платформе. Что я бы улучшил дальше: формализовать возможность подключения ритейлеров как внутреннего операционного продукта (загрузка, маркировка, обучение, валидация, настройка DOM и магазина, одобрение релизов, мониторинг состояния); добавьте сверку квитанций таким образом, извлечённые суммы, скидки и налоговую сверку с окончательным счетом; ввести политику низкой доверия; усилить контроль геозоны с короткими сроками действия, лимитами по сумме и одной транзакции, а также немедленным закрытием после авторизации; создавать автоматическое обнаружение изменений DOM с помощью запланированных синтетических тестов; отдельные OCR и отчёты об ошибках ИИ на панелях управления; улучшить прослеживаемость управления моделью (версия канала, ритейлера, модели и обучающих данных, входные данные, OCR и уверенность классификации, версия согласования, результат карты); и аккуратно расширять на Android и iOS, учитывая их разные разрешения и поведение фоновых локаций. Долгосрочным результатом стала омниканальная платформа, где данные о продуктах ритейлеров заменили индивидуальную интеграцию платежей, ИИ определял право на участие, существующие системы управляли идентификацией и кредитом, виртуальные карты обеспечивали совместимость, а браузер и мобильные устройства предоставляли клиенту контроль над дистрибуцией, отделяя рост бизнеса от инженерных усилий.