Обяснение на моделите за ценообразуване на Tracking API: на извикване срещу на пратка и как да изчислите реалната си цена
Ценообразуването на 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 използвайте тези официални справочни страници и потвърдете директно търговските условия:
