Pojasnjeni cenovni modeli API-ja za sledenje: cena na klic v primerjavi s ceno na pošiljko in kako oceniti svoje dejanske stroške
Cene API-ja za sledenje na klic se zaračunavajo za obračunljive zahteve; cene na pošiljko se zaračunavajo za določeno sledilno enoto, kot je registrirana sledilna številka. Nobena možnost ni samodejno cenejša. Za oceno dejanskih stroškov primerjajte oba modela glede na enak obseg pošiljk, zahteve po posodobitvah, trajanje sledenja in pravila obračunavanja, nato pa dodajte še pristojbine platforme, prekoračitve in stroške integracije.
Za ekipe za razvoj, operacije in nabavo uporabna primerjava ni preprosto cena na klic v primerjavi s ceno na pošiljko. Gre za skupne stroške zagotavljanja vidljivosti pošiljk, ki jo vaše podjetje potrebuje. Nizko število zahtev lahko zaradi pogostega preverjanja postane drago, medtem ko je nizko število pošiljk lahko zavajajoče, če obdobje sledenja ali vključene storitve ne ustrezajo vašemu delovnemu procesu.
Kaj posamezni model cen dejansko meri
Prvi korak je ločiti tri stvari: zahtevo API-ja, registracijo pošiljke in posodobitev sledenja. To so različni dogodki, pogodba pa lahko vsakemu določi drugačno obračunsko obravnavo.
| Primerjalna točka | Cene na klic | Cene na pošiljko |
|---|---|---|
| Osnova obračunavanja | Zahteve ali enote zahtev, opredeljene kot obračunljive | Enote pošiljk, opredeljene kot obračunljive |
| Glavno gonilo stroškov | Kako pogosto aplikacija pošilja obračunljive zahteve | Koliko obračunljivih sledilnih enot vstopi v obseg ali ostane v njem |
| Vprašanje glede obračunavanja, ki ga je treba razrešiti | Katere končne točke, odgovori in elementi paketnih zahtev se štejejo? | Kaj predstavlja eno pošiljko in kako dolgo je sledenje vključeno? |
| Možna izpostavljenost stroškom | Ponavljajoče se preverjanje, ponovni poskusi in nepotrebna iskanja | Podvojene registracije, več paketov in omejitve obdobja sledenja |
| Najprimernejša pogojna uporaba | Redka iskanja z nadzorovanim obsegom zahtev | Stalno spremljanje, kadar so posodobitve vključene v pristojbino za pošiljko |
Cena na klic ne pomeni nujno, da vsaka zahteva HTTP stane enako
V ponudbi morajo biti navedene obračunljive končne točke in njihove enote. Registracija sledilne številke, pridobivanje shranjenih rezultatov, zahteva za osvežitev in upravljanje naročnin so lahko obravnavani različno. Ne predpostavljajte, da je neuspešna zahteva brezplačna ali da je uspešna zahteva vedno obračunljiva.
Tudi paketne zahteve morajo biti izrecno opredeljene. Ena zahteva, ki vsebuje 100 sledilnih številk, se lahko šteje kot ena zahteva, 100 sledilnih enot ali druga pogodbena količina. Zmanjšanje omrežnega prometa ne pomeni prihranka pri obračunavanju, razen če ga podpirajo pravila merjenja.
Cena na pošiljko ne pomeni nujno cene na naročilo
Eno naročilo v e-trgovini lahko ustvari več paketov. Če je obračunljiva enota sledilna številka, lahko razdeljeno naročilo porabi več enot. Tudi vračila, nadomestne pošiljke in predaje med prevozniki morajo biti jasno opredeljeni.
Vprašajte, ali pristojbina zagotavlja sledenje za določeno obdobje, do opredeljenega dogodka zaključka ali pod drugo omejitvijo. Prav tako ugotovite, ali registrirane pošiljke v poznejšem obračunskem obdobju povzročijo nove stroške. Te podrobnosti so pomembnejše od oznake cenovnega načrta.
Ocenite stroške na podlagi delovnega procesa, ne le števila naročil
Uporabite reprezentativno operativno obdobje in pripravite napoved na podlagi podatkov na ravni pošiljk. Vključite nove pošiljke in starejše pošiljke, ki jih je še treba spremljati. Če so vaši podatki nepopolni, jasno navedite predpostavke, namesto da rezultat predstavite kot natančno ponudbo.
- Preštejte sledljive pakete. Začnite z edinstvenimi sledilnimi enotami paketov, ne z naročili na blagajni. Odhodne pakete, vračila in nadomestne pošiljke obravnavajte ločeno, dokler ni potrjena njihova obračunska obravnava.
- Izmerite trajanje spremljanja. Ocenite, kako dolgo vsaka pošiljka potrebuje posodobitve, po potrebi vključno z obdobji pred prevozom in obdobji izjem.
- Določite zahtevano pogostost posodobitev. Navedite, kako pogosto aplikacija potrebuje sveže informacije in ali se to spreminja glede na status pošiljke.
- Preslikajte potek dela API-ja. Naštejte registracije, iskanja rezultatov, zahteve za osvežitev, popravke, ponovne poskuse in vse druge končne točke, ki jih bo uporabljala vaša integracija.
- Uporabite obračunska pravila. Tehnično dejavnost pretvorite v obračunljive klice ali enote pošiljk v skladu s predlagano pogodbo.
- Dodajte stroške, ki niso povezani z uporabo. Vključite ustrezno naročnino, minimalno obveznost, izbirne storitve ter stroške uvedbe ali delovanja.
Pri preprosti integraciji s preverjanjem, pri kateri se pri vsakem iskanju uporablja ena sledilna številka, je začetna ocena:
Zahteve za iskanje = spremljane pošiljke × povprečno število spremljanih dni × število iskanj na dan
Ta bližnjica predpostavlja, da vsaka pošiljka sledi enakemu povprečnemu urniku. Natančnejši model sešteje zahteve za vsako pošiljko ali skupino pošiljk, nato pa doda registracijske klice in drugo obračunljivo dejavnost. Če pošiljke ostanejo aktivne čez konec meseca, njihove zahteve razporedite v obračunska obdobja, v katerih so bile te zahteve izvedene.
Primer izračuna: kdaj se cenejši model spremeni
Naslednje številke so izmišljene izključno za prikaz izračuna. Ne predstavljajo cen 17TRACK, ponudb dobaviteljev ali tržnih meril.
Predpostavimo, da je v istem modeliranem obdobju registriranih in v celoti spremljanih 10.000 paketov. Vsak zahteva eno registracijsko zahtevo in tri zahteve za iskanje na dan v osmih dneh. Predpostavimo, da je vsaka zahteva obračunljiva, da se vsaka zahteva nanaša na en paket ter da ni ponovnih poskusov, popustov za paketne zahteve, vključenih količin ali stalnih pristojbin.
- Registracijske zahteve: 10.000.
- Zahteve za iskanje: 10.000 × 8 × 3 = 240.000.
- Skupaj obračunljive zahteve: 250.000.
- Prikazana cena na klic: $0.002.
- Prikazana cena na pošiljko: $0.04, vključno z zahtevanim spremljanjem.
Strošek uporabe po ceni na klic je 250.000 × $0.002 = $500. Strošek uporabe po ceni na pošiljko je 10.000 × $0.04 = $400. V skladu s temi predpostavkami je cena na pošiljko za $100 nižja.
Zdaj spremenimo samo pogostost iskanja na enkrat dnevno. Število zahtev postane 10.000 registracij in 80.000 iskanj oziroma 90.000 klicev. Strošek uporabe po ceni na klic pade na $180, medtem ko prikazani strošek uporabe po ceni na pošiljko ostane $400. Prednostni model se spremeni, ker se spremeni obremenitev, ne zato, ker bi bila ena cenovna struktura sama po sebi boljša.
Poiščite točko preloma
Če noben od obeh načrtov nima stalnih stroškov, vključenih količin ali dodatnih pristojbin, uporabite:
Obračunljivi klici na pošiljko pri točki preloma = cena pošiljke ÷ cena klica
V tem primeru je $0.04 ÷ $0.002 enako 20 obračunljivim klicem na pošiljko. Nad 20 klici je pristojbina za pošiljko nižja; pod 20 klici je nižja pristojbina za klic. Registracijski klici se v skladu s predpostavkami primera vštevajo v ta prag.
Ta bližnjica ne zadostuje za stopenjske načrte, predplačniške kredite, različne cene končnih točk ali minimalne obveznosti. Pri teh ponudbah izračunajte celoten račun pri vsaki napovedani količini, namesto da primerjate objavljene cene na enoto.
Spletne kljuke lahko zmanjšajo preverjanje, vendar je treba obračun še vedno preveriti
Preverjanje pomeni, da aplikacija večkrat zapored zahteva informacije o sledenju. Spletna kljuka omogoča storitvi, da aplikaciji pošlje dogodek, s čimer se zmanjša potreba po ponavljajočih se iskanjih, kadar tok dogodkov izpolnjuje vaše zahteve.
Vendar manjše število zahtev za iskanje samodejno ne pomeni nižjega računa. Potrdite, ali je dostava prek spletnih kljuk vključena, ali se dostave ali ponovni poskusi merijo in ali so še vedno potrebna usklajevalna iskanja. Aplikacija mora tudi varno obravnavati podvojene dogodke ali dogodke v napačnem vrstnem redu ter se obnoviti po neuspešnih dostavah.
Obstaja še ena pomembna razlika: pogostejše zahtevanje informacij ne zagotavlja, da je osnovni prevoznik ustvaril novo skeniranje. Preden plačate pogostost preverjanja, ki ima lahko malo operativne vrednosti, vprašajte, kaj vrne iskanje in kako deluje osveževanje podatkov.
Stroški, ki jih lahko objavljena cena skrije
Vključene količine, minimumi in predplačniška stanja
Ločite minimalni račun od naročnine z vključeno uporabo. Minimalni račun lahko določa najnižji znesek porabe; vključena količina lahko pokriva določeno količino, preden se začnejo zaračunavati prekoračitve. Predplačniški krediti odpirajo ločena vprašanja glede poteka veljavnosti, vračil in neporabljenih sredstev.
Za načrt, pri katerem se vključena količina odšteje pred prekoračitvami, je uporabna naslednja struktura:
Račun API-ja = stalna pristojbina načrta + obračunljiva prekoračitev + veljavne dodatne storitve
To formulo uporabite le, če ustreza pogodbi. Iste vključene uporabe ne prištevajte dvakrat in ne predpostavljajte, da vsi načrti uporabljajo mejne cene na enak način.
Dolgotrajne pošiljke in ponovne registracije
Dolga obdobja spremljanja povečajo število iskanj pri zasnovi s preverjanjem. Pri cenah na pošiljko je pomembno vprašanje, ali prvotna pristojbina pokriva to trajanje. Preizkusite izjeme in zamujene pošiljke, ne le dostav, ki se hitro zaključijo.
Prav tako potrdite, kaj se zgodi, ko je ista sledilna številka poslana dvakrat, popravljena, izbrisana in znova dodana ali povezana z drugim prevoznikom. Kjer je primerno, preprečite podvajanje, vendar ne predpostavljajte, da se deduplikacija na ravni aplikacije popolnoma ujema z identiteto, ki jo za obračun uporablja dobavitelj.
Omejitve hitrosti in največja zmogljivost
Cenovno ugodna mesečna vključena količina ne zagotavlja, da integracija zmore velik uvoz ali skok prometa. Preverite omejitve hitrosti zahtev, omejitve paketnih zahtev, omejitve sočasnosti in pričakovano vedenje ob doseganju omejitev. Načrt, ki ustreza mesečnemu obsegu, vendar ne podpira zahtevanega delovnega procesa, ni primerljiva alternativa.
Stroški razvoja in delovanja
Račun API-ja ločite od skupnih stroškov lastništva. Notranji stroški lahko vključujejo razvoj integracije, gostovanje spletnih kljuk, čakalne vrste, spremljanje, odziv na incidente, shranjevanje podatkov in vzdrževanje.
Uporabite lastne ocene dela in infrastrukture. Dražja naročnina je lahko še vedno ekonomična, če dokazljivo zmanjša operativno delo, vendar je treba ta prihranek preveriti, ne pa ga predpostaviti.
Kako primerjati ponudbe in potrditi ožji izbor
Vsakega dobavitelja prosite, naj oceni enako specifikacijo delovne obremenitve: obseg paketov, sestavo pošiljk, trajanje spremljanja, zahteve po posodobitvah, končne točke, največjo obremenitev in zahtevane storitve. Zahtevajte pisno razlago obračunske enote in primer izračuna računa.
Za ekipe, ki razmišljajo o 17TRACK, sta uradna stran Tracking API in dokumentacija API-ja ustrezni izhodišči za ocenjevanje izdelka in integracije. Preden v napovedi določite model, neposredno potrdite veljavne cene in definicije obračunavanja. Ta članek ne navaja ali razvršča trenutnega načrta 17TRACK.
Pred zavezo izvedite nadzorovan pilot z reprezentativnimi pošiljkami. Vključite razdeljena naročila, podvojene oddaje, zamujene pakete, čezmejna gibanja in pošiljke, ki prečkajo obračunsko mejo. Neuspešno vedenje ali vedenje pri ponovnih poskusih preizkušajte samo na načine, ki jih storitev dovoljuje.
- Primerjajte dnevnike zahtev s podatki dobavitelja o uporabi.
- Uskladite registrirane sledilne enote z obračunanimi enotami pošiljk.
- Preverite, ali je zahtevana pogostost posodobitev dejansko dosežena.
- Največje povpraševanje merite ločeno od mesečne porabe.
- Pred ekstrapolacijo stroškov raziščite nepojasnjene razlike.
Pripravite vsaj tri napovedi: običajno delovanje, sezonski vrh in podaljšan tranzit. Spreminjajte osnovna gonila, namesto da računu dodate poljuben odstotek. Na primer, pri vrhu modelirajte več paketov, pri scenariju zamude pa daljše trajanje spremljanja.
Kateri model izbrati?
Odločite se za cene na klic, kadar so iskanja redka, povpraševanje po zahtevah merljivo in napoved po vključitvi registracij ter druge obračunljive dejavnosti ostane pod točko preloma. Ta možnost je manj privlačna, kadar pogosto preverjanje ali nepredvidljivo trajanje spremljanja povzroča veliko število zahtev.
Odločite se za cene na pošiljko, kadar je potrebno neprekinjeno spremljanje in navedena cena pošiljke vključuje pogostost posodobitev, trajanje sledenja in način dostave, ki ga potrebujete. Ta možnost je manj privlačna, kadar plačujete za spremljanje, ki ga redko uporabljate, ali kadar definicija pošiljke ustvarja nepričakovane dodatne enote.
Končna odločitev mora temeljiti na skupnem strošku na operativni paket: računu API-ja skupaj s pripadajočimi operativnimi stroški, deljenim s številom edinstvenih paketov, ki jih mora vaše podjetje spremljati. To notranjo opredelitev paketa ohranite enako pri vseh ponudbah, tudi če dobavitelji uporabljajo različne obračunske enote.
Pogosta vprašanja
Ali se neuspešne zahteve API-ja obračunajo?
Ne predpostavljajte ne enega ne drugega. Vprašajte, kako se obravnavajo napake pri preverjanju, napake pri preverjanju pristnosti, odgovori zaradi omejitve hitrosti, napake strežnika in časovne prekoračitve. Časovna prekoračitev lahko povzroči tudi negotovost glede tega, ali je bila zahteva obdelana, preden jo je aplikacija znova poslala.
Ali eno naročilo vedno šteje kot ena pošiljka?
Ne. Naročilo lahko vsebuje več ločeno spremljanih paketov. Za pripravo proračuna naročila preslikajte v sledilne enote in nato uporabite dobaviteljevo definicijo. Potrdite, kako se štejejo vračila, nadomestne pošiljke in predaje med prevozniki.
Ali bodo paketne zahteve zmanjšale moj račun?
Samo če pravila obračunavanja nagrajujejo paketne zahteve. Paketi lahko zmanjšajo število omrežnih zahtev, ne da bi zmanjšali število obračunljivih sledilnih enot. Preverite omejitev paketov in ali se obračun izvaja na zahtevo, na element ali prek utežene enote.
Ali lahko spletne kljuke odpravijo vse zahteve za iskanje?
Morda odstranijo velik del rutinskega preverjanja, vendar lahko zasnova še vedno potrebuje začetno pridobivanje, obnovitev po zgrešenih dogodkih ali občasno usklajevanje. Te klice vključite v oceno in potrdite morebitne stroške dostave prek spletnih kljuk.
Kako naj v proračun vključim pošiljke, ki bodo aktivne tudi naslednji mesec?
Pri cenah na klic napovejte zahteve, ki jih bodo te pošiljke ustvarile v naslednjem obdobju. Pri cenah na pošiljko potrdite, ali spremljanje ostane vključeno ali sproži nov strošek. Pri ocenjevanju stalne obremenitve ne štejte samo na novo ustvarjenih pošiljk.
Viri
Pri zgornjih izračunih so uporabljeni izrecno hipotetični vnosi, ne objavljene cene dobaviteljev. Za ocenjevanje 17TRACK uporabite te uradne referenčne strani in neposredno potrdite komercialne pogoje:
