Објаснети моделите на цени за Tracking API: по повик наспроти по пратка и како да ги процените вашите реални трошоци
Цените на 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, надоместокот по повик е понизок. Повиците за регистрација се бројат во тој праг според претпоставките од примерот.
Ова поедноставување не е доволно за планови со различни нивоа, припејд кредити, различни стапки за крајни точки или минимални обврски. За таквите понуди, пресметајте ја целосната фактура при секој прогнозен обем наместо да ги споредувате само истакнатите единечни стапки.
Webhook-овите може да го намалат анкетирањето, но наплатата сепак треба да се провери
Анкетирањето значи дека вашата апликација постојано бара информации за следење. Webhook-от овозможува услугата да испрати настан до вашата апликација, со што се намалува потребата од повторени пребарувања кога текот на настани ги исполнува вашите барања.
Сепак, помалиот број барања за пребарување не значи автоматски пониска фактура. Потврдете дали испораката преку webhook е вклучена, дали испораките или повторните обиди се мерат и дали сè уште се потребни пребарувања за усогласување. Вашата апликација исто така треба безбедно да се справува со дупликатни или непоследователни настани и да се опоравува од неуспешни испораки.
Постои уште една разлика што треба да се има предвид: почестото барање информации не гарантира дека основниот превозник создал ново скенирање. Прашајте што враќа пребарувањето и како функционира освежувањето на податоците пред да платите за фреквенција на анкетирање што можеби носи мала оперативна вредност.
Трошоци што може да ги скрие истакнатата стапка
Вклучени квоти, минимални износи и припејд салда
Разликувајте минимална фактура од претплата со вклучена употреба. Минималната фактура може да постави минимален износ на трошење; квотата може да покрива одредена количина пред да се применат надоместоци за прекумерна употреба. Припејд кредитите отвораат одделни прашања за истекување, поврати и неискористени салда.
За план чија квота се одзема пред прекумерната употреба, корисна структура е:
API-фактура = фиксна цена на планот + наплатлива прекумерна употреба + применливи додатоци
Користете ја оваа формула само ако одговара на договорот. Не ја додавајте истата вклучена употреба двапати и не претпоставувајте дека сите планови применуваат маргинални цени на ист начин.
Пратки со долго траење и повторни регистрации
Долгите периоди на следење го зголемуваат обемот на пребарувања кај моделот со анкетирање. Кај цените по пратка, релевантното прашање е дали првичниот надоместок го покрива тоа времетраење. Тестирајте ги исклучоците и одложените пратки, а не само испораките што завршуваат брзо.
Исто така потврдете што се случува кога истиот број за следење се испрати двапати, се коригира, се избрише и повторно се додаде или се поврзе со друг превозник. Воведете спречување дупликати каде што е соодветно, но не претпоставувајте дека дедупликацијата на ниво на апликација совршено се совпаѓа со идентитетот за наплата на добавувачот.
Ограничувања на стапката и капацитет во шпиц
Достапната месечна квота не значи дека интеграцијата може да се справи со голем увоз или нагло зголемување на сообраќајот. Проверете ги ограничувањата на стапката на барања, ограничувањата за групни барања, ограничувањата на истовременоста и очекуваното однесување кога ќе се достигнат ограничувањата. План што го исполнува месечниот обем, но не може да го поддржи потребниот работен тек, не е споредлива алтернатива.
Трошоци за инженеринг и работење
Чувајте ја API-фактурата одделно од вкупниот трошок на сопственост. Внатрешните трошоци може да вклучуваат развој на интеграцијата, хостирање на webhook-ови, редици, мониторинг, одговор на инциденти, складирање податоци и одржување.
Користете ги сопствените проценки за труд и инфраструктура. Поскапата претплата сепак може да биде економична ако докажливо ја намалува оперативната работа, но таа заштеда треба да се тестира, а не да се претпостави.
Како да ги споредите понудите и да го потврдите потесниот избор
Побарајте од секој добавувач да го цени истиот опис на обемот на работа: обем на пакети, мешавина на пратки, времетраење на следењето, барања за ажурирање, крајни точки, врвно оптоварување и потребни услуги. Побарајте писмено објаснување на единицата за наплата и пример за пресметка на фактура.
За тимовите што го разгледуваат 17TRACK, официјалната страница на Tracking API и API-документацијата се релевантни почетни точки за процена на производот и интеграцијата. Потврдете ги применливите цени и дефинициите за наплата директно пред да доделите модел во вашата прогноза. Оваа статија не наведува или класифицира тековен план на 17TRACK.
Пред да се обврзете, спроведете контролиран пилот со репрезентативни пратки. Вклучете поделени нарачки, дупликатни поднесувања, одложени пакети, прекугранични движења и пратки што преминуваат граница на наплатен период. Тестирајте го однесувањето при неуспех или повторен обид само на начини дозволени од услугата.
- Споредете ги дневниците на вашите барања со записите за употреба на добавувачот.
- Усогласете ги регистрираните единици за следење со наплатените единици на пратки.
- Проверете дали навистина се постигнува потребната динамика на ажурирање.
- Измерете ја максималната побарувачка одделно од месечната потрошувачка.
- Испитајте ги необјаснетите разлики пред да ги екстраполирате трошоците.
Направете најмалку три прогнози: нормално работење, сезонски врв и продолжен транзит. Променете ги основните двигатели наместо да додавате произволен процент на сметката. На пример, моделирајте повеќе пакети за врвен период и подолги периоди на следење за сценарио со доцнење.
Кој модел треба да го изберете?
Одберете ги цените по повик кога пребарувањата се ретки, побарувачката за барања може да се измери и прогнозата останува под точката на рентабилност откако ќе се вклучат регистрациите и другата наплатлива активност. Овој модел е помалку привлечен кога честото анкетирање или непредвидливото времетраење на следењето создава значителна изложеност на барања.
Одберете ги цените по пратка кога е потребно континуирано следење и наведениот надоместок по пратка ја вклучува фреквенцијата на ажурирање, времетраењето на следењето и механизмот за испорака што ви се потребни. Овој модел е помалку привлечен кога плаќате за следење што ретко го користите или кога дефиницијата на пратката создава неочекувани дополнителни единици.
Конечната одлука треба да го користи вкупниот трошок по оперативен пакет: API-фактурата плус припишаните оперативни трошоци, поделено со уникатните пакети што вашиот бизнис треба да ги следи. Одржувајте ја истата интерна дефиниција за пакетот во сите понуди, дури и кога добавувачите користат различни единици за наплата.
ЧПП
Дали неуспешните API-барања се наплатуваат?
Не претпоставувајте ниту еден исход. Прашајте за третманот на грешките при валидација, неуспесите при автентикација, одговорите поради ограничување на стапката, грешките на серверот и истекувањата на времето. Истекувањето на времето исто така може да создаде неизвесност дали барањето било обработено пред апликацијата повторно да го испрати.
Дали една нарачка секогаш се брои како една пратка?
Не. Нарачката може да содржи неколку одделно следени пакети. За буџетирање, поврзете ги нарачките со единиците за следење и потоа применете ја дефиницијата на добавувачот. Потврдете како се бројат враќањата, замените и предавањата меѓу превозници.
Дали групните барања ќе ја намалат мојата сметка?
Само ако правилата за наплата го наградуваат групирањето. Групните барања може да ги намалат мрежните барања без да ги намалат наплатливите единици за следење. Потврдете го ограничувањето на групата и дали наплатата се применува по барање, по ставка или преку пондерирана единица.
Дали webhook-овите може да ги елиминираат сите барања за пребарување?
Тие може да отстранат голем дел од рутинското анкетирање, но вашиот дизајн можеби сè уште ќе има потреба од првично преземање, опоравување по пропуштени настани или периодично усогласување. Вклучете ги тие повици во проценката и потврдете ги евентуалните надоместоци за испорака преку webhook.
Како да буџетирам за пратки што сè уште се активни следниот месец?
Кај цените по повик, прогнозирајте ги барањата што тие пратки ќе ги создадат во следниот период. Кај цените по пратка, потврдете дали следењето останува покриено или активира нов надоместок. Не броете ги само новосоздадените пратки при процената на тековниот обем на работа.
Извори
Пресметките погоре користат експлицитно хипотетички влезни податоци, а не објавени цени на добавувачи. За процена на 17TRACK, користете ги овие официјални референтни страници и потврдете ги комерцијалните услови директно:
