Vysvetlenie cenových modelov Tracking API: za volanie vs. za zásielku a ako odhadnúť svoje skutočné náklady
Ceny rozhrania API na sledovanie účtované za volanie sa účtujú za fakturovateľné požiadavky; ceny za zásielku sa účtujú za definovanú sledovaciu jednotku, napríklad registrované sledovacie číslo. Ani jeden model nie je automaticky lacnejší. Ak chcete odhadnúť svoje skutočné náklady, porovnajte oba modely pri rovnakom objeme zásielok, požiadavkách na aktualizácie, dĺžke sledovania a fakturačných pravidlách a potom pripočítajte poplatky za platformu, nadlimitné využitie a náklady na integráciu.
Pre tímy zodpovedné za vývoj, prevádzku a obstarávanie nie je užitočné porovnanie jednoducho cena za volanie oproti cene za zásielku. Ide o celkové náklady na zabezpečenie viditeľnosti zásielok, ktorú vaša firma potrebuje. Nízka frekvencia požiadaviek sa môže pri častom dopytovaní predražiť, zatiaľ čo nízka sadzba za zásielku môže byť zavádzajúca, ak obdobie sledovania alebo zahrnuté služby nezodpovedajú vášmu pracovnému postupu.
Čo jednotlivé cenové modely skutočne merajú
Prvým krokom je oddeliť tri veci: požiadavku API, registráciu zásielky a aktualizáciu sledovania. Ide o odlišné udalosti a zmluva môže každej z nich priradiť odlišný spôsob účtovania.
| Bod porovnania | Cena za volanie | Cena za zásielku |
|---|---|---|
| Základ účtovania | Požiadavky alebo jednotky požiadaviek definované ako fakturovateľné | Jednotky zásielok definované ako fakturovateľné |
| Hlavný faktor nákladov | Ako často aplikácia odosiela spoplatnené požiadavky | Koľko spoplatnených sledovacích jednotiek vstupuje do rozsahu alebo v ňom zostáva |
| Fakturačná otázka, ktorú treba vyriešiť | Ktoré endpointy, odpovede a položky dávok sa započítavajú? | Čo predstavuje jednu zásielku a ako dlho je sledovanie zahrnuté? |
| Možné vystavenie nákladom | Opakované dopytovanie, opakovanie požiadaviek a nepotrebné vyhľadávania | Duplicitné registrácie, viacero balíkov a limity obdobia sledovania |
| Najvhodnejšie podmienené použitie | Vyhľadávania s nízkou frekvenciou a kontrolovaným objemom požiadaviek | Priebežné monitorovanie, keď sú aktualizácie zahrnuté v poplatku za zásielku |
Cena za volanie nemusí znamenať, že každá HTTP požiadavka stojí rovnako
Cenová ponuka musí identifikovať fakturovateľné endpointy a ich jednotky. Registrácia sledovacieho čísla, načítanie uložených výsledkov, vyžiadanie obnovenia a správa odberov môžu podliehať odlišnému účtovaniu. Nepredpokladajte, že neúspešná požiadavka je bezplatná alebo že úspešná požiadavka je vždy spoplatnená.
Aj dávkové spracovanie si vyžaduje výslovnú definíciu. Jedna požiadavka obsahujúca 100 sledovacích čísel sa môže počítať ako jedna požiadavka, 100 sledovacích jednotiek alebo iné zmluvne stanovené množstvo. Zníženie sieťovej prevádzky neznamená úsporu na faktúre, pokiaľ to pravidlá merania nepodporujú.
Cena za zásielku nemusí znamenať cenu za objednávku
Jedna e-commerce objednávka môže vytvoriť niekoľko balíkov. Ak je spoplatnenou jednotkou sledovacie číslo, rozdelená objednávka môže spotrebovať viacero jednotiek. Jasne treba upraviť aj vratky, náhradné zásielky a odovzdanie medzi dopravcami.
Zistite, či poplatok zahŕňa sledovanie počas určeného obdobia, až do definovanej udalosti dokončenia alebo podlieha inému limitu. Takisto stanovte, či už registrované zásielky spôsobia nové poplatky v neskoršom fakturačnom období. Tieto podrobnosti sú dôležitejšie než označenie cenového plánu.
Odhadujte náklady podľa pracovného postupu, nielen podľa počtu objednávok
Použite reprezentatívne prevádzkové obdobie a vytvorte prognózu z údajov na úrovni zásielok. Zahrňte nové zásielky aj staršie zásielky, ktoré si stále vyžadujú monitorovanie. Ak sú vaše údaje neúplné, uveďte predpoklady namiesto prezentovania výsledku ako presnej cenovej ponuky.
- Spočítajte sledovateľné balíky. Začnite jedinečnými sledovacími jednotkami balíkov, nie objednávkami pri pokladni. Odchádzajúce balíky, vratky a náhrady ponechajte oddelené, kým nebude potvrdené ich fakturačné zaobchádzanie.
- Zmerajte trvanie monitorovania. Odhadnite, ako dlho každá zásielka potrebuje aktualizácie, v relevantných prípadoch vrátane období pred prepravou a období výnimiek.
- Definujte požadovanú frekvenciu aktualizácií. Určite, ako často vaša aplikácia potrebuje aktuálne informácie a či sa to mení podľa stavu zásielky.
- Zmapujte pracovný postup API. Spíšte registrácie, vyhľadávania výsledkov, požiadavky na obnovenie, opravy, opakovania a všetky ďalšie endpointy, ktoré bude vaša integrácia používať.
- Uplatnite fakturačné pravidlá. Preveďte technickú aktivitu na fakturovateľné volania alebo jednotky zásielok podľa navrhovanej zmluvy.
- Pripočítajte poplatky nesúvisiace s využitím. Zahrňte príslušné predplatné, minimálny záväzok, voliteľné služby a náklady na implementáciu alebo prevádzku.
Pri jednoduchej integrácii s dopytovaním a jedným sledovacím číslom na jedno vyhľadanie je počiatočný odhad:
Požiadavky na vyhľadávanie = monitorované zásielky × priemerný počet monitorovaných dní × vyhľadávania za deň
Tento skrátený výpočet predpokladá, že každá zásielka sa riadi rovnakým priemerným harmonogramom. Presnejší model sčíta požiadavky pre každú zásielku alebo skupinu zásielok a potom pripočíta registračné volania a ďalšiu fakturovateľnú aktivitu. Ak zásielky zostávajú aktívne aj po skončení mesiaca, priraďte ich požiadavky k fakturačným obdobiam, v ktorých sa tieto požiadavky uskutočnia.
Príklad výpočtu: keď sa lacnejší model zmení
Nasledujúce čísla sú vymyslené výlučne na demonštráciu výpočtu. Nejde o ceny 17TRACK, cenové ponuky dodávateľov ani trhové referenčné hodnoty.
Predpokladajme, že v rovnakom modelovanom období je zaregistrovaných a úplne monitorovaných 10 000 balíkov. Každý vyžaduje jednu registračnú požiadavku a tri požiadavky na vyhľadávanie denne počas ôsmich dní. Predpokladajme, že každá požiadavka je fakturovateľná, každá požiadavka sa týka jedného balíka a neexistujú žiadne opakovania, zľavy za dávky, povolené limity ani fixné poplatky.
- Registračné požiadavky: 10 000.
- Požiadavky na vyhľadávanie: 10 000 × 8 × 3 = 240 000.
- Celkový počet fakturovateľných požiadaviek: 250 000.
- Ilustračná sadzba za volanie: $0.002.
- Ilustračná sadzba za zásielku: $0.04 vrátane požadovaného monitorovania.
Náklady na využitie pri cene za volanie sú 250 000 × $0.002 = $500. Náklady na využitie pri cene za zásielku sú 10 000 × $0.04 = $400. Za týchto predpokladov stojí cena za zásielku pri využití o $100 menej.
Teraz zmeňme iba frekvenciu vyhľadávania na raz denne. Počet požiadaviek bude 10 000 registrácií plus 80 000 vyhľadávaní, teda 90 000 volaní. Náklady na využitie pri cene za volanie klesnú na $180, zatiaľ čo ilustračné náklady na využitie pri cene za zásielku zostanú $400. Preferovaný model sa zmení preto, že sa zmení pracovné zaťaženie, nie preto, že by niektorá cenová štruktúra bola vo svojej podstate lepšia.
Nájdite bod zvratu
Ak oba plány nemajú fixné poplatky, povolené limity ani dodatočné poplatky, použite:
Fakturovateľné volania na zásielku v bode zvratu = sadzba za zásielku ÷ sadzba za volanie
V tomto príklade sa $0.04 ÷ $0.002 rovná 20 fakturovateľným volaniam na zásielku. Pri viac ako 20 volaniach je poplatok za zásielku nižší; pri menej ako 20 volaniach je nižší poplatok za volanie. Registračné volania sa podľa predpokladov príkladu započítavajú do tejto hranice.
Tento skrátený výpočet nestačí pri stupňovitých plánoch, predplatených kreditoch, odlišných sadzbách endpointov alebo minimálnych záväzkoch. Pri takýchto ponukách vypočítajte úplnú faktúru pre každý prognózovaný objem namiesto porovnávania hlavných jednotkových sadzieb.
Webhooky môžu znížiť dopytovanie, no fakturáciu treba stále overiť
Dopytovanie znamená, že vaša aplikácia opakovane žiada informácie o sledovaní. Webhook umožňuje službe odoslať udalosť do vašej aplikácie, čím znižuje potrebu opakovaných vyhľadávaní, keď tok udalostí spĺňa vaše požiadavky.
Menej požiadaviek na vyhľadávanie však automaticky neznamená nižšiu faktúru. Overte, či je doručovanie webhookov zahrnuté, či sa doručenia alebo opakovania merajú a či sú stále potrebné vyhľadávania na zosúladenie. Vaša aplikácia musí tiež bezpečne spracovať duplicitné alebo neusporiadané udalosti a zotaviť sa z chýb doručenia.
Existuje ešte jedno rozlíšenie, ktoré treba zachovať: častejšie vyžadovanie informácií nezaručuje, že príslušný dopravca vytvoril nové skenovanie. Pred platením za frekvenciu dopytovania, ktorá môže mať malú prevádzkovú hodnotu, sa opýtajte, čo vyhľadávanie vracia a ako funguje obnovovanie údajov.
Náklady, ktoré môže hlavná sadzba skrývať
Zahrnuté limity, minimá a predplatené zostatky
Rozlišujte medzi minimálnou faktúrou a predplatným so zahrnutým využitím. Minimálna faktúra môže stanoviť minimálnu úroveň výdavkov; limit môže pokrývať určené množstvo pred uplatnením poplatkov za prekročenie. Predplatené kredity prinášajú samostatné otázky týkajúce sa platnosti, vrátenia peňazí a nevyužitých zostatkov.
Pri pláne, ktorého limit sa odpočítava pred účtovaním nadlimitného využitia, je užitočná táto štruktúra:
Faktúra API = fixný poplatok za plán + spoplatnené nadlimitné využitie + príslušné doplnky
Tento vzorec používajte iba vtedy, ak zodpovedá zmluve. Nepripočítavajte rovnaké zahrnuté využitie dvakrát ani nepredpokladajte, že všetky plány uplatňujú marginálne ceny rovnakým spôsobom.
Dlhodobo aktívne zásielky a opakované registrácie
Dlhé obdobia monitorovania zvyšujú objem vyhľadávaní pri návrhu založenom na dopytovaní. Pri cene za zásielku je dôležitou otázkou, či pôvodný poplatok pokrýva toto trvanie. Testujte výnimky a oneskorené zásielky, nielen doručenia, ktoré sa dokončia rýchlo.
Takisto potvrďte, čo sa stane, keď sa rovnaké sledovacie číslo odošle dvakrát, opraví, odstráni a znovu pridá alebo priradí inému dopravcovi. Vhodným spôsobom zabráňte duplicitám, ale nepredpokladajte, že deduplikácia na úrovni aplikácie dokonale zodpovedá fakturačnej identite dodávateľa.
Limity frekvencie požiadaviek a špičková kapacita
Dostupný mesačný limit neznamená, že integrácia zvládne veľký import alebo špičku návštevnosti. Skontrolujte limity frekvencie požiadaviek, limity dávok, obmedzenia súbežnosti a očakávané správanie po dosiahnutí limitov. Plán, ktorý spĺňa mesačný objem, ale nepodporuje požadovaný pracovný postup, nie je porovnateľnou alternatívou.
Náklady na vývoj a prevádzku
Faktúru za API oddeľte od celkových nákladov vlastníctva. Interné výdavky môžu zahŕňať vývoj integrácie, hosting webhookov, fronty, monitorovanie, reakciu na incidenty, ukladanie údajov a údržbu.
Použite vlastné odhady práce a infraštruktúry. Drahšie predplatné môže byť stále ekonomické, ak preukázateľne znižuje prevádzkovú prácu, ale túto úsporu treba otestovať, nie predpokladať.
Ako porovnávať cenové ponuky a overiť užší výber
Požiadajte každého dodávateľa, aby ocenil rovnakú špecifikáciu pracovného zaťaženia: objem balíkov, zloženie zásielok, trvanie monitorovania, požiadavky na aktualizácie, endpointy, špičkové zaťaženie a požadované služby. Vyžiadajte si písomné vysvetlenie fakturačnej jednotky a vzorový výpočet faktúry.
Pre tímy zvažujúce 17TRACK sú oficiálna stránka Tracking API a dokumentácia API relevantnými východiskami na hodnotenie produktu a integrácie. Pred priradením modelu vo svojej prognóze si priamo overte príslušné ceny a definície účtovania. Tento článok neuvádza ani neklasifikuje aktuálny plán 17TRACK.
Pred záväzkom vykonajte kontrolovaný pilot s reprezentatívnymi zásielkami. Zahrňte rozdelené objednávky, duplicitné odoslania, oneskorené balíky, cezhraničné pohyby a zásielky, ktoré prekračujú fakturačnú hranicu. Správanie pri zlyhaní alebo opakovaní testujte iba spôsobmi povolenými službou.
- Porovnajte svoje protokoly požiadaviek so záznamami využitia dodávateľa.
- zosúlaďte registrované sledovacie jednotky s fakturovanými jednotkami zásielok.
- Skontrolujte, či sa požadovaná frekvencia aktualizácií skutočne dosahuje.
- Merajte špičkový dopyt oddelene od mesačnej spotreby.
- Pred extrapoláciou nákladov preskúmajte nevysvetlené rozdiely.
Vytvorte aspoň tri prognózy: bežnú prevádzku, sezónnu špičku a predĺženú prepravu. Meňte základné faktory, nie ľubovoľné percento pridané k faktúre. Napríklad pri špičke modelujte viac balíkov a pri scenári oneskorenia dlhšie trvanie monitorovania.
Ktorý model by ste si mali vybrať?
Uprednostnite cenu za volanie, keď sú vyhľadávania nepravidelné, dopyt po požiadavkách je merateľný a prognóza zostáva pod bodom zvratu po zahrnutí registrácií a ďalšej fakturovateľnej aktivity. Je menej atraktívna, keď časté dopytovanie alebo nepredvídateľné trvanie monitorovania vytvára výrazné vystavenie požiadavkám.
Uprednostnite cenu za zásielku, keď je potrebné nepretržité monitorovanie a uvedený poplatok za zásielku zahŕňa frekvenciu aktualizácií, trvanie sledovania a mechanizmus doručovania, ktoré potrebujete. Je menej atraktívna, keď platíte za monitorovanie, ktoré využívate len zriedka, alebo keď definícia zásielky vytvára neočakávané dodatočné jednotky.
Konečné rozhodnutie by malo používať celkové náklady na jednu prevádzkovú zásielku: faktúru za API plus priraditeľné prevádzkové náklady vydelené jedinečnými balíkmi, ktoré vaša firma potrebuje monitorovať. Túto internú definíciu balíka zachovajte pri všetkých ponukách konzistentnú, aj keď dodávatelia používajú odlišné fakturačné jednotky.
Často kladené otázky
Účtujú sa neúspešné požiadavky API?
Nepredpokladajte ani jeden výsledok. Opýtajte sa na spracovanie validačných chýb, zlyhaní overenia, odpovedí pri prekročení limitu frekvencie, chýb servera a časových limitov. Časový limit môže tiež vytvoriť neistotu, či bola požiadavka spracovaná predtým, ako ju aplikácia zopakovala.
Počíta sa jedna objednávka vždy ako jedna zásielka?
Nie. Objednávka môže obsahovať niekoľko samostatne sledovaných balíkov. Pri rozpočtovaní priraďte objednávky k sledovacím jednotkám a potom uplatnite definíciu dodávateľa. Potvrďte, ako sa započítavajú vratky, náhrady a odovzdanie medzi dopravcami.
Znížia dávkové požiadavky moju faktúru?
Iba ak pravidlá účtovania zvýhodňujú dávkové spracovanie. Dávky môžu znížiť počet sieťových požiadaviek bez zníženia počtu spoplatnených sledovacích jednotiek. Overte limit dávky a to, či sa účtuje za požiadavku, položku alebo váženú jednotku.
Môžu webhooky odstrániť všetky požiadavky na vyhľadávanie?
Môžu odstrániť veľkú časť bežného dopytovania, no váš návrh môže stále vyžadovať úvodné načítanie, obnovu po zmeškaných udalostiach alebo pravidelné zosúladenie. Zahrňte tieto volania do odhadu a potvrďte prípadné poplatky za doručovanie webhookov.
Ako mám rozpočtovať zásielky, ktoré budú aktívne aj budúci mesiac?
Pri cene za volanie prognózujte požiadavky, ktoré tieto zásielky vytvoria v nasledujúcom období. Pri cene za zásielku potvrďte, či zostáva monitorovanie pokryté alebo vyvolá ďalší poplatok. Pri odhade priebežného pracovného zaťaženia nepočítajte iba novo vytvorené zásielky.
Zdroje
Vyššie uvedené výpočty používajú výslovne hypotetické vstupy, nie zverejnené ceny dodávateľov. Pri hodnotení 17TRACK použite tieto oficiálne referenčné stránky a obchodné podmienky si priamo overte:
