Обновление продукта: улучшенный UX массовой проверки, более честный прогресс асинхронных операций и современная модель подключения MCP

За последний цикл выпуска мы внесли набор изменений, которые все указывают в одном направлении: сделать BillionVerify более надежным для доверия, более удобным для мониторинга и более простым для интеграции.

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

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

И некоторые из этих изменений напрямую влияют на разработчиков. BillionVerify MCP полностью отошел от более старой установки ?api_key= и перешел в размещенную удаленную модель MCP, построенную на основе OAuth, защищенного обнаружения ресурсов и современной совместимости клиентов. Мы обновили продукт, документацию, маркетинговые страницы и поверхности аутентификации, чтобы соответствовать этой реальности.

Этот пост объединяет эти обновления в один повествование, чтобы клиенты, разработчики и внутренние команды могли увидеть, как они соответствуют друг другу.

Если вы хотите краткую версию, вот она:

Массовая проверка теперь имеет более чистый поток после загрузки.
Мониторинг асинхронных заданий более информативен и более честен.
Интерфейс статуса бэкенда лучше структурирован для распределенной работы.
BillionVerify MCP теперь имеет более четкую долгосрочную форму: удаленная конечная точка плюс OAuth, а не встроенные в URL ключи API.

Если вы хотите полную историю, продолжайте читать.

Быстрые ссылки

Почему эти обновления идут вместе

На первый взгляд, этот релиз выглядит как несколько отдельных потоков работы:

очистка фронтенда на странице массовой верификации
более информативный экран истории детализации
обновление бэкенд контракта статуса
очистка аутентификации и документации MCP

Но основная тема одна и та же для всех них: устранить двусмысленность.

Двусмысленность проявляется по-разному в программных продуктах.

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

Иногда это выглядит как прогресс-бар, который говорит "29% завершено", в то время как окружающие числа не объясняют, что представляет собой этот процент. Это 29% обработанных писем? 29% завершённых задач рабочего? 29% объединённых результатов? Большинство пользователей не хотят разбираться в архитектуре очередей только чтобы отследить задачу.

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

Этот релиз — наш ответ на эти проблемы.

Мы улучшили пользовательский опыт продукта вокруг того, что пользователи действительно должны знать. Мы упростили бэкенд интерфейсы вокруг того, что клиентам действительно нужно отобразить. И мы улучшили историю MCP для разработчиков вокруг того, как платформа фактически работает сегодня.

1. Bulk Verify теперь имеет более чистый интерфейс после загрузки

Первая часть этого релиза была сосредоточена на моменте сразу после отправки файла.

Этот момент имеет большее значение, чем кажется.

Когда кто-то загружает большой CSV для проверки, они не закончили. Они только что перешли из состояния ввода в состояние мониторинга. Интерфейс должен помочь им ответить на несколько непосредственных вопросов:

Мой файл успешно отправлен?
Уже началась обработка?
Где я могу отслеживать эту конкретную задачу?
Могу ли я доверять, что система уведомит меня при завершении?

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

Мы это очистили.

Что изменилось на странице

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

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

Основной CTA после отправки также изменился важным образом. Вместо отправки пользователей на универсальный индекс истории, основное действие теперь связывает непосредственно с точной страницей деталей задачи. Это звучит как небольшое изменение, но оно устраняет ненужный переход и делает рабочий процесс более преднамеренным.

Мы также удалили элементы, которые были технически функциональными, но не особенно полезными:

дублирующийся текст состояния в области загрузки
дополнительную кнопку "Загрузить другой файл" в карточке успеха

Пользователи все еще могут загрузить другой файл с основной поверхности загрузки. Разница в том, что интерфейс больше не конкурирует сам с собой.

Почему это важно на практике

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

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

Это снижает количество сканирования экрана, необходимого сразу после отправки.
Это делает следующий шаг очевидным.
Это сохраняет UI в соответствии с ментальной моделью пользователя: "Мой файл загружен. Теперь я хочу отследить эту задачу."

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

Пример: новый путь после отправки

Вот предполагаемый путь пользователя сейчас:

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

Это более простой путь, чем:

Загрузить файл.
Разобрать дублирующиеся области состояния.
Нажать на универсальную историю.
Найти нужную строку.
Заново открыть целевую задачу.

Сокращение усилий небольшое в одной сессии и значительное при повторном использовании.

2. История проверки теперь работает как настоящая поверхность мониторинга

Второе крупное улучшение коснулось страницы истории асинхронной проверки.

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

Это несоответствие для долгосрочного задания верификации.

Когда клиент открывает страницу деталей истории во время обработки файла, он ищет не просто число процентов. Он пытается понять:

к какому файлу относится это задание
насколько большой объем работы
сколько работы уже выполнено
как выглядит ранний набор результатов
сколько времени займет задание

Мы переработали страницу с учетом этой реальности.

Стабильные метаданные теперь отображаются первыми

Обновленная страница истории теперь начинается со стабильной сводной карточки. Эта карточка объединяет наиболее важные метаданные задания:

исходное имя файла
всего строк
количество уникальных email-адресов
расчетное время обработки
время начала

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

Когда пользователи попадают на страницу, они могут сразу ориентироваться вместо ожидания ответа о живом статусе.

Область живого прогресса намного богаче

Под сводкой интерфейс выполняющегося состояния теперь материально лучше.

Вместо голой полосы прогресса с ограниченным контекстом, страница теперь отображает:

обработанный объем
оставшийся объем
распределение результатов по статусам
семантику языка и ETA, соответствующую основному потоку массовой верификации

Не менее важно, что она удаляет внутренние метрики, которые должны оставаться внутренними. Мы намеренно перестали выставлять счета рабочих задач и количество чанков на пользовательской поверхности. Эти значения могут быть операционно полезны, но они не то, что клиенты пытаются измерить, когда спрашивают: «Как далеко продвинулось мое задание?»

Правильный вопрос почти всегда ориентирован на email, а не на очередь.

Инструменты завершенного состояния остаются неизменными

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

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

Это означает, что страница теперь лучше работает в обоих случаях:

во время обработки она работает как поверхность мониторинга
после завершения она все еще работает как поверхность анализа и экспорта

Пример: что пользователи теперь могут понять с первого взгляда

Страница запущенного задания теперь быстро отвечает на все эти вопросы:

«Это файл из 19 293 строк, который я загрузил ранее.»
«В нем 19 010 уникальных email-адресов.»
«Система оценивает примерно 33 минуты.»
«Уже проверено 499 email-адресов.»
«Большинство завершенного набора до сих пор корректны, с меньшей долей некорректных и неизвестных.»

Это гораздо более полезная ментальная модель, чем одно число процентов с неясной семантикой.

3. Семантика прогресса теперь более честная

Один из самых важных уроков в асинхронных продуктах — что "прогресс" — это не единая концепция.

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

рабочие задачи могут завершиться
фрагменты могут объединиться
результаты на уровне письма могут накапливаться
финальные файлы могут стать доступны для скачивания

Если клиент получает только одно общее поле progress, ему приходится угадывать, какое из этих значений несёт число. Именно так вы получаете UI-состояния, которые технически согласованы, но в опыте пользователя запутанны.

Мы хотели это исправить на уровне контракта.

Основной сдвиг

Обновленный интерфейс позволяет различить:

email_progress
chunk_progress
progress_source

Это различие даёт клиентам намного более прочную основу для отображения прогресса так, как это соответствует намерениям пользователя.

Например:

большая пользовательская панель прогресса может теперь приоритизировать email_progress
операционные или диагностические представления всё ещё могут использовать chunk_progress
если требуется резервный вариант, progress_source может сделать это явным

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

Пример полезной нагрузки

Вот какой формат это позволяет:

{
  "task_id": "36f68e67-ddcb-441a-a407-22f826e72443",
  "status": "processing",
  "total_emails": 19010,
  "processed_emails": 499,
  "valid_emails": 496,
  "invalid_emails": 2,
  "unknown_emails": 1,
  "catchall_emails": 0,
  "risky_emails": 0,
  "role_emails": 0,
  "disposable_emails": 0,
  "email_progress": 3,
  "chunk_progress": 7,
  "progress_source": "email_progress"
}

Даже без знания о базовой системе очередей клиент может принимать хорошие решения из этого ответа.

Это важно, потому что API не просто возвращают данные. Они определяют значение.

Почему это лучше для клиентов

Клиентам не важно, завершил ли рабочий 7 из 96 внутренних задач, если на самом деле обработано только 499 из 19 010 писем. Раскрытие неправильной абстракции прогресса создаёт путаницу, а не уверенность.

Направляя основной UI на email_progress, продукт теперь отражает единицу работы, которая пользователям действительно важна.

Почему это лучше для команд фронтенда

UI больше не нужно выводить слишком много из одного двусмысленного поля процентов.

Это снижает целый класс ошибок продукта:

панели прогресса, которые выглядят слишком далеко впереди
блоки итогов, которые отстают от основного процента
неловкий текст статуса, который пытается объяснить пользователям детали реализации бэкенда

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

4. Контракт статуса бэкенда теперь лучше структурирован для распределённой работы

Изменения фронтенда не будут работать хорошо без улучшений контракта бэкенда.

Мы приняли два важных структурных решения.

Во-первых, мы разделили стабильные метаданные от живого статуса

Некоторые поля почти не меняются или вообще не меняются после создания задачи:

имя файла
время создания
общее количество строк
количество уникальных адресов электронной почты
примерное время обработки

Другие поля по своей природе динамичны:

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

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

Новая модель чище:

стабильные метаданные задачи рассматриваются как метаданные
живой статус задачи рассматривается как статус

Это звучит очевидно при простом написании, но это имеет значительные эффекты на качество реализации.

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

Во-вторых, мы расширили сам payload статуса

Интерфейс статуса в реальном времени теперь лучше подходит для распределённой асинхронной обработки, потому что он предоставляет более полную картину того, что произошло до сих пор.

Это включает счётчики, такие как:

обработано
действительно
недействительно
неизвестно
рискованно
catch-all
роль
одноразово
использовано кредитов

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

Пример: почему это имеет значение сверх пользовательского интерфейса

Представьте приложение, ориентированное на клиента и построенное поверх BillionVerify, которое хочет:

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

Все эти варианты использования становятся проще, когда контракт статуса бэкенда явен и достаточно богат.

Вот почему работа над интерфейсом бэкенда имеет значение даже когда первое видимое изменение — это «полоса прогресса выглядит лучше». Лучшая полоса прогресса часто является симптомом лучшего контракта.

5. MCP теперь полностью перешел в эру удаленного OAuth

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

BillionVerify MCP теперь представляется и документируется в той форме, в которой он должен быть для современных удаленных клиентов:

размещенная удаленная конечная точка
авторизация на основе OAuth
обнаружение защищенных ресурсов
стандартный доступ с маркером Bearer

Конечная точка:

https://mcp.billionverify.com/mcp

Это важно, потому что старые схемы настройки могут оставаться в открытых материалах задолго после того, как платформа уже внутренне перешла на новое. В нашем случае в некоторых документах и маркетинговых материалах по-прежнему подразумевалось, что MCP можно подключить через ключи API, встроенные в URL, и обертки curl --stdio.

Это больше не правильная форма для BillionVerify MCP.

Старая концептуальная модель

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

curl --stdio "https://mcp.billionverify.com/mcp?api_key=YOUR_API_KEY"

Эта модель объединяет несколько проблем в один неудобный шаг настройки:

транспорт
аутентификация
обработка секретов
локальное поведение обертки

Она также дает неправильный сигнал о том, как размещенный удаленный сервер MCP должен использоваться современными клиентами.

Новая концептуальная модель

Текущая модель чище.

Для Claude Code рекомендуемая настройка:

claude mcp add --transport http billionverify https://mcp.billionverify.com/mcp

Затем в Claude Code:

/mcp

После этого клиент завершает поток OAuth в браузере.

Для ChatGPT и других совместимых удаленных клиентов MCP правильная начальная точка — это просто сама конечная точка:

https://mcp.billionverify.com/mcp

Клиент обнаруживает метаданные защищенного ресурса, следует процессу авторизации и затем использует маркеры Bearer для аутентифицированных вызовов.

Самое важное различие: аутентификация MCP — это не аутентификация REST

Одна из причин, по которой старые документы нуждались в очистке, заключается в том, что ключи API по-прежнему важны в BillionVerify. Но они больше не являются частью истории загрузки MCP.

Четкое разделение:

REST API использует ключи API
удаленный MCP использует OAuth

Это различие теперь намного яснее по всей поверхности продукта.

Если разработчик использует:

ChatGPT
Claude Code
другой OAuth-совместимый удаленный клиент MCP

он должен использовать путь удаленного MCP.

Если он создает:

автоматизацию от бэкенда к бэкенду
скрипты, управляемые ключами API
клиентов, которые поддерживают только локальный stdio плюс ключи API

он должен использовать справочник API и поток REST вместо этого.

Это не косметическое различие. Это граница продукта, и документация должна это ясно показать.

6. Публичная документация и маркетинг теперь соответствуют продукту

Архитектурное обновление решает только часть проблемы, если публичные материалы рассказывают совсем другую историю.

Именно поэтому мы рассматривали обновление документации и маркетинга MCP как часть одного релиза.

Мы обновили:

публичную страницу MCP
руководство MCP
руководство Claude Code
точки входа в AI руководства
многоязычные варианты документации
локализованный FAQ маркетинга

Цель была простой: должен быть один чёткий ответ на вопрос «Как подключить BillionVerify MCP?»

Теперь он есть.

Почему это важно для разработчиков

Когда публичная документация отстаёт от реальности реализации, разработчики платят цену тремя способами:

Неудачные попытки настройки
Потеря доверия к платформе
Дополнительная нагрузка на поддержку, чтобы уточнить то, что должно было быть очевидным

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

Почему это важно для позиционирования платформы

Экосистема MCP развивается быстро. По мере того как всё больше команд оценивают инструменты через ChatGPT, Claude Code и других AI клиентов, качество первого опыта интеграции имеет всё большее значение.

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

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

7. Практический обзор «до и после» этого выпуска

Полезный способ понять выпуск — сравнить опыт пользователя и разработчика до и после.

До

Файл массовой проверки можно было успешно отправить, но состояние после отправки по-прежнему содержало дублирующийся UI и менее очевидные следующие шаги.
Страница истории показала активность, но еще не ощущалась как полная поверхность мониторинга.
Значение процента завершения могло существовать без четкого сообщения пользователям, представляет ли оно обработанные письма или завершение внутренних задач.
Публичные материалы MCP частично отражали устаревший сценарий ?api_key=.

После

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

Это не одна функция. Это значительный проход качества по всему рабочему процессу.

8. Что это означает для разных аудиторий

Для операционных и growth-команд

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

Для команд продукта и фронтенда

Теперь у вас есть более сильная семантика прогресса и чистое разделение между метаданными и текущим статусом, что упрощает построение экранов с интенсивным отслеживанием прогресса и упрощает объяснение.

Для команд бэкенда и платформы

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

Для разработчиков, интегрирующих MCP

Теперь у вас есть гораздо более четкий ответ на вопрос о настройке: используйте удаленный MCP плюс OAuth для MCP-клиентов и используйте API-ключи для REST API, где эта модель уместна.

9. С чего начать

Если вы хотите изучить обновленный опыт или пути интеграции, начните отсюда:

Узнайте больше о продукте: Проверка электронной почты
Запустите более крупные рабочие процессы: Массовая проверка электронной почты
Поймите основы: Что такое проверка электронной почты?
Подключите MCP от поддерживаемого клиента: Обзор MCP
Углубитесь в настройку: Руководство MCP
Настройте Claude Code специально: Руководство Claude Code
Используйте интеграцию на основе API-ключа: Справочник API

Завершение

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

Мы сделали путь массовой верификации чище. Мы сделали асинхронный мониторинг более полезным. Мы сделали отчёты о прогрессе более честными. И мы привели историю MCP в соответствие с платформой, которую мы на самом деле создаём.

Эти улучшения усиливают друг друга.

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

Это направление, в котором мы продолжаем развивать BillionVerify.

Если вы уже используете BillionVerify, эти изменения должны сделать вашу повседневную работу более прямолинейной и предсказуемой.

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