Объяснение моделей ценообразования Tracking API: оплата за вызов vs. оплата за отправление и как оценить ваши реальные затраты
Ценообразование Tracking API за вызов взимает плату за оплачиваемые запросы; ценообразование за отправление взимает плату за определённую единицу отслеживания, например зарегистрированный трек-номер. Ни один из вариантов автоматически не является более дешёвым. Чтобы оценить реальные затраты, сравните обе модели при одинаковом объёме отправлений, требованиях к обновлениям, продолжительности отслеживания и правилах выставления счетов, затем добавьте платформенные сборы, плату за превышение лимитов и затраты на интеграцию.
Для инженерных, операционных и закупочных команд полезное сравнение — это не просто цена за вызов и цена за отправление. Важно учитывать общую стоимость обеспечения необходимой вашему бизнесу видимости отправлений. Низкая частота запросов может стать дорогой при частом опросе, а низкая ставка за отправление может вводить в заблуждение, если окно отслеживания или включённые услуги не соответствуют вашему рабочему процессу.
Что на самом деле измеряет каждая модель ценообразования
Первый шаг — разделить три понятия: API-запрос, регистрация отправления и обновление данных отслеживания. Это разные события, и договор может предусматривать для каждого из них разные правила тарификации.
| Параметр сравнения | Ценообразование за вызов | Ценообразование за отправление |
|---|---|---|
| Основа тарификации | Запросы или определённые как оплачиваемые единицы запросов | Определённые как оплачиваемые единицы отправлений |
| Основной фактор затрат | Частота выполнения приложением платных запросов | Количество платных единиц отслеживания, которые входят в охват или остаются в нём |
| Вопрос по тарификации, требующий уточнения | Какие конечные точки, ответы и элементы пакетных запросов учитываются? | Что считается одним отправлением и как долго включено отслеживание? |
| Потенциальные источники затрат | Повторный опрос, повторы запросов и ненужные обращения | Повторная регистрация, несколько посылок и ограничения окна отслеживания |
| Наиболее подходящий условный сценарий | Редкие обращения при контролируемом объёме запросов | Постоянный мониторинг, когда обновления включены в стоимость отправления |
Ценообразование за вызов не обязательно означает одинаковую стоимость каждого HTTP-запроса
В коммерческом предложении должны быть указаны оплачиваемые конечные точки и их единицы тарификации. Регистрация трек-номера, получение сохранённых результатов, запрос обновления и управление подписками могут тарифицироваться по-разному. Не следует предполагать, что неудачный запрос бесплатен или что успешный запрос всегда оплачивается.
Пакетная обработка также требует явного определения. Один запрос, содержащий 100 трек-номеров, может считаться одним запросом, 100 единицами отслеживания или другим количеством, установленным договором. Снижение сетевого трафика не означает экономии на тарификации, если правила учёта этого не предусматривают.
Ценообразование за отправление не обязательно означает оплату за заказ
Один заказ в электронной торговле может включать несколько посылок. Если оплачиваемой единицей является трек-номер, разделённый заказ может потребить несколько единиц. Возвраты, повторные отправления и передача отправления между перевозчиками также требуют чёткого определения.
Уточните, оплачивает ли сбор отслеживание в течение установленного периода, до определённого события завершения или в пределах другого ограничения. Также выясните, взимается ли новая плата за уже зарегистрированные отправления в следующем расчётном периоде. Эти детали важнее, чем название тарифного плана.
Оценивайте стоимость исходя из рабочего процесса, а не только количества заказов
Используйте репрезентативный рабочий период и составляйте прогноз на основе данных об отдельных отправлениях. Включайте как новые отправления, так и более старые отправления, которые всё ещё требуют мониторинга. Если ваши данные неполны, явно указывайте допущения, а не представляйте результат как точное коммерческое предложение.
- Подсчитайте отслеживаемые посылки. Начинайте с уникальных единиц отслеживания посылок, а не с заказов на оплату. Пока правила тарификации не подтверждены, учитывайте исходящие посылки, возвраты и повторные отправления отдельно.
- Измерьте продолжительность мониторинга. Оцените, как долго каждой отправлению требуются обновления, включая периоды до отправки и периоды исключений, если они актуальны.
- Определите необходимую частоту обновлений. Укажите, как часто приложению нужна свежая информация и меняется ли эта частота в зависимости от статуса отправления.
- Сопоставьте рабочий процесс с API. Перечислите регистрации, запросы результатов, запросы обновлений, исправления, повторы и любые другие конечные точки, которые будет использовать интеграция.
- Примените правила тарификации. Преобразуйте техническую активность в оплачиваемые вызовы или единицы отправлений согласно предлагаемому договору.
- Добавьте непотребительские сборы. Включите применимую абонентскую плату, минимальные обязательства, дополнительные услуги и затраты на внедрение или эксплуатацию.
Для простой интеграции с опросом и одним трек-номером на один запрос начальная оценка выглядит так:
Запросы на получение данных = отслеживаемые отправления × среднее число дней мониторинга × запросы в день
Эта упрощённая формула предполагает, что каждое отправление следует одному и тому же среднему графику. Более точная модель суммирует запросы для каждого отправления или группы отправлений, а затем добавляет вызовы регистрации и прочую оплачиваемую активность. Если отправления остаются активными после окончания месяца, распределяйте их запросы по расчётным периодам, в которых эти запросы выполняются.
Пример расчёта: когда более дешёвая модель меняется
Следующие числа выдуманы исключительно для демонстрации расчёта. Это не цены 17TRACK, коммерческие предложения поставщиков и не рыночные ориентиры.
Предположим, что 10 000 посылок зарегистрированы и полностью отслеживаются в течение одного и того же моделируемого периода. Для каждой требуется один запрос регистрации и три запроса получения данных в день в течение восьми дней. Предположим, что каждый запрос оплачивается, каждый запрос относится к одной посылке, а повторов, скидок за пакетную обработку, включённых лимитов и фиксированных сборов нет.
- Запросы регистрации: 10 000.
- Запросы получения данных: 10 000 × 8 × 3 = 240 000.
- Всего оплачиваемых запросов: 250 000.
- Иллюстративная ставка за вызов: $0.002.
- Иллюстративная ставка за отправление: $0.04, включая необходимый мониторинг.
Стоимость использования по модели за вызов составляет 250 000 × $0.002 = $500. Стоимость использования по модели за отправление составляет 10 000 × $0.04 = $400. При этих допущениях ценообразование за отправление обходится на $100 дешевле.
Теперь изменим только частоту запросов получения данных на один раз в день. Количество запросов составит 10 000 регистраций плюс 80 000 запросов получения данных, то есть 90 000 вызовов. Стоимость использования по модели за вызов снизится до $180, а иллюстративная стоимость по модели за отправление останется равной $400. Предпочтительная модель меняется из-за изменения рабочей нагрузки, а не потому, что одна структура ценообразования изначально лучше другой.
Определите точку безубыточности
Если у обоих планов нет фиксированных сборов, включённых лимитов и дополнительных платежей, используйте формулу:
Точка безубыточности: оплачиваемые вызовы на отправление = ставка за отправление ÷ ставка за вызов
В данном примере $0.04 ÷ $0.002 равно 20 оплачиваемым вызовам на отправление. При более чем 20 вызовах плата за отправление ниже; при менее чем 20 вызовах ниже плата за вызов. Согласно допущениям примера, запросы регистрации также учитываются в этом пороге.
Эта упрощённая формула недостаточна для тарифов с уровнями, предоплаченными кредитами, разными ставками для конечных точек или минимальными обязательствами. Для таких предложений рассчитывайте полный счёт при каждом прогнозируемом объёме, а не сравнивайте только заявленные цены за единицу.
Вебхуки могут сократить количество опросов, но тарификацию всё равно нужно проверить
При опросе приложение многократно запрашивает информацию об отслеживании. Вебхук позволяет сервису отправлять событие в приложение, снижая необходимость в повторных запросах, если поток событий соответствует вашим требованиям.
Однако меньшее количество запросов получения данных не означает автоматически меньший счёт. Уточните, включена ли доставка вебхуков, тарифицируются ли доставки или повторы и остаются ли необходимыми запросы для сверки. Приложение также должно безопасно обрабатывать дублирующиеся события или события, поступившие не по порядку, и восстанавливаться после сбоев доставки.
Есть и ещё одно важное различие: более частый запрос информации не гарантирует, что соответствующий перевозчик создал новое сканирование. Прежде чем платить за частоту опроса, которая может дать мало операционной ценности, выясните, что возвращает запрос и как обновляются данные.
Затраты, которые может скрывать заявленная ставка
Включённые лимиты, минимальные платежи и предоплаченные балансы
Различайте минимальный счёт и подписку с включённым использованием. Минимальный счёт может устанавливать нижний порог расходов; включённый лимит может покрывать определённое количество операций до применения платы за превышение. Предоплаченные кредиты порождают отдельные вопросы о сроке действия, возвратах и неиспользованных остатках.
Для плана, в котором включённый лимит вычитается до начисления платы за превышение, полезна следующая структура:
Счёт за API = фиксированная плата за план + оплачиваемое превышение + применимые дополнительные услуги
Используйте эту формулу только в том случае, если она соответствует договору. Не учитывайте один и тот же включённый объём дважды и не предполагайте, что все планы применяют предельное ценообразование одинаковым образом.
Длительные отправления и повторная регистрация
Длительные периоды мониторинга увеличивают объём запросов при использовании опроса. При ценообразовании за отправление важно выяснить, покрывает ли первоначальная плата такую продолжительность. Проверяйте исключения и задержанные отправления, а не только быстро доставленные посылки.
Также уточните, что происходит, если один и тот же трек-номер отправляется дважды, исправляется, удаляется и добавляется снова или связывается с другим перевозчиком. При необходимости реализуйте защиту от дубликатов, но не предполагайте, что дедупликация на уровне приложения идеально совпадает с идентификацией отправлений поставщиком для целей тарификации.
Ограничения скорости и пиковая нагрузка
Доступный месячный лимит не гарантирует, что интеграция сможет обработать крупный импорт или резкий всплеск трафика. Проверьте ограничения частоты запросов, лимиты пакетных запросов, ограничения параллельности и ожидаемое поведение при достижении лимитов. План, соответствующий месячному объёму, но не поддерживающий необходимый рабочий процесс, не является сопоставимой альтернативой.
Затраты на разработку и эксплуатацию
Отделяйте счёт за API от общей стоимости владения. Внутренние расходы могут включать разработку интеграции, размещение вебхуков, очереди, мониторинг, реагирование на инциденты, хранение данных и обслуживание.
Используйте собственные оценки трудозатрат и инфраструктуры. Более дорогая подписка всё же может быть экономичной, если она явно снижает операционную нагрузку, но такую экономию следует проверить, а не принимать на веру.
Как сравнивать коммерческие предложения и проверять отобранные варианты
Попросите каждого поставщика оценить одну и ту же спецификацию рабочей нагрузки: объём посылок, состав отправлений, продолжительность мониторинга, требования к обновлениям, конечные точки, пиковую нагрузку и необходимые услуги. Запросите письменное объяснение единицы тарификации и пример расчёта счёта.
Для команд, рассматривающих 17TRACK, официальная страница Tracking API и документация API являются отправными точками для оценки продукта и интеграции. Перед назначением модели в прогнозе подтвердите применимые цены и определения тарификации непосредственно у поставщика. В этой статье не приводится и не классифицируется текущий тарифный план 17TRACK.
Перед принятием обязательств проведите контролируемое пилотное тестирование с репрезентативными отправлениями. Включите разделённые заказы, повторные отправления, задержанные посылки, трансграничные перемещения и отправления, пересекающие расчётную границу. Тестируйте сбои или повторы только способами, разрешёнными сервисом.
- Сравните журналы запросов с данными об использовании у поставщика.
- Сопоставьте зарегистрированные единицы отслеживания с оплачиваемыми единицами отправлений.
- Проверьте, действительно ли достигается необходимая периодичность обновлений.
- Измеряйте пиковый спрос отдельно от месячного потребления.
- Изучите необъяснимые расхождения, прежде чем экстраполировать затраты.
Составьте как минимум три прогноза: обычная работа, сезонный пик и длительный транзит. Изменяйте основные факторы, а не добавляйте к счёту произвольный процент. Например, для пикового периода моделируйте больше посылок, а для сценария задержки — более длительную продолжительность мониторинга.
Какую модель выбрать?
Выбирайте ценообразование за вызов, если запросы выполняются редко, спрос на запросы измерим, а прогноз остаётся ниже точки безубыточности после учёта регистраций и прочей оплачиваемой активности. Этот вариант менее привлекателен, когда частый опрос или непредсказуемая продолжительность мониторинга создают значительный объём запросов.
Выбирайте ценообразование за отправление, если требуется постоянный мониторинг и заявленная плата за отправление включает необходимую частоту обновлений, продолжительность отслеживания и механизм доставки. Этот вариант менее привлекателен, если вы платите за редко используемый мониторинг или если определение отправления приводит к неожиданным дополнительным единицам.
Окончательное решение следует принимать на основе общей стоимости на одну операционную посылку: счёт за API плюс относимые операционные затраты, разделённые на количество уникальных посылок, которые необходимо отслеживать вашему бизнесу. Сохраняйте единое внутреннее определение посылки при сравнении предложений, даже если поставщики используют разные единицы тарификации.
Часто задаваемые вопросы
Тарифицируются ли неуспешные API-запросы?
Не следует предполагать ни один из вариантов. Уточните правила для ошибок валидации, сбоев аутентификации, ответов об ограничении скорости, ошибок сервера и тайм-аутов. Тайм-аут также может создавать неопределённость относительно того, был ли запрос обработан до того, как приложение повторило его.
Всегда ли один заказ считается одним отправлением?
Нет. Заказ может содержать несколько посылок, отслеживаемых отдельно. Для бюджетирования сопоставьте заказы с единицами отслеживания, а затем примените определение поставщика. Уточните, как учитываются возвраты, повторные отправления и передача отправлений между перевозчиками.
Снизят ли пакетные запросы мой счёт?
Только если правила тарификации поощряют пакетную обработку. Пакеты могут сократить количество сетевых запросов, не уменьшая число оплачиваемых единиц отслеживания. Проверьте лимит пакета и выясните, применяется ли тарификация за запрос, за элемент или через взвешенную единицу.
Могут ли вебхуки полностью устранить запросы получения данных?
Они могут устранить большую часть регулярного опроса, но вашей системе всё ещё могут потребоваться первоначальное получение данных, восстановление после пропущенных событий или периодическая сверка. Включите эти вызовы в оценку и уточните возможные сборы за доставку вебхуков.
Как планировать бюджет для отправлений, которые всё ещё активны в следующем месяце?
При ценообразовании за вызов прогнозируйте запросы, которые эти отправления создадут в следующем периоде. При ценообразовании за отправление уточните, остаётся ли мониторинг включённым или вызывает дополнительную плату. При оценке текущей рабочей нагрузки не учитывайте только недавно созданные отправления.
Источники
В приведённых выше расчётах используются явно гипотетические исходные данные, а не опубликованные цены поставщиков. Для оценки 17TRACK используйте следующие официальные справочные страницы и подтверждайте коммерческие условия непосредственно у поставщика:
