Siuntų sekimo API kainodaros modeliai paaiškinti: mokestis už iškvietimą ir už siuntą bei kaip įvertinti tikrąją kainą
Stebėjimo API kainodara pagal iškvietimą taiko mokestį už apmokestinamas užklausas; kainodara pagal siuntą taiko mokestį už apibrėžtą stebėjimo vienetą, pavyzdžiui, užregistruotą sekimo numerį. Nė vienas modelis nėra automatiškai pigesnis. Norėdami įvertinti tikrąją kainą, palyginkite abu modelius pagal tą patį siuntų kiekį, atnaujinimų reikalavimus, stebėjimo trukmę ir atsiskaitymo taisykles, tada pridėkite platformos mokesčius, viršijimo mokesčius ir integracijos išlaidas.
Inžinerijos, operacijų ir pirkimų komandoms naudingas palyginimas nėra tiesiog kainos už iškvietimą ir už siuntą palyginimas. Tai yra bendra siuntų matomumo, kurio reikia jūsų verslui, suteikimo kaina. Mažas užklausų dažnis gali tapti brangus dėl dažno apklausimo, o maža siuntų kaina gali būti klaidinanti, jei jos stebėjimo laikotarpis ar įtrauktos paslaugos neatitinka jūsų darbo eigos.
Ką iš tikrųjų matuoja kiekvienas kainodaros modelis
Pirmasis žingsnis – atskirti tris dalykus: API užklausą, siuntos registraciją ir stebėjimo atnaujinimą. Tai skirtingi įvykiai, o sutartyje kiekvienam iš jų gali būti nustatytas skirtingas atsiskaitymas.
| Palyginimo aspektas | Kainodara pagal iškvietimą | Kainodara pagal siuntą |
|---|---|---|
| Atsiskaitymo pagrindas | Užklausos arba apmokestinamomis laikomos užklausų vienetų apimtys | Apmokestinamais laikomi siuntų vienetai |
| Pagrindinis kainą lemiantis veiksnys | Kaip dažnai programa pateikia apmokestinamas užklausas | Kiek apmokestinamų stebėjimo vienetų patenka į taikymo sritį arba joje lieka |
| Klausimas, kurį reikia išspręsti dėl atsiskaitymo | Kurie galiniai taškai, atsakymai ir paketinių užklausų elementai įskaičiuojami? | Kas laikoma viena siunta ir kiek laiko įtrauktas stebėjimas? |
| Galimos išlaidos | Pakartotinis apklausimas, pakartotiniai bandymai ir nereikalingos paieškos | Pasikartojančios registracijos, keli paketai ir stebėjimo laikotarpio ribos |
| Tinkamiausias sąlyginis pritaikymas | Retos paieškos ir kontroliuojamas užklausų kiekis | Nuolatinis stebėjimas, kai atnaujinimai įtraukti į siuntos mokestį |
Kainodara pagal iškvietimą nebūtinai reiškia, kad kiekviena HTTP užklausa kainuoja vienodai
Pasiūlyme turi būti nurodyti apmokestinami galiniai taškai ir jų vienetai. Sekimo numerio registravimui, išsaugotų rezultatų gavimui, atnaujinimo užklausai ir prenumeratų valdymui gali būti taikomos skirtingos taisyklės. Nemanykite, kad nesėkminga užklausa yra nemokama arba kad sėkminga užklausa visada apmokestinama.
Taip pat reikia aiškiai apibrėžti paketines užklausas. Viena užklausa, kurioje yra 100 sekimo numerių, gali būti laikoma viena užklausa, 100 stebėjimo vienetų arba kitu sutartyje nustatytu kiekiu. Tinklo srauto sumažinimas savaime nereiškia sutaupymo, jei matavimo taisyklės to nepatvirtina.
Kainodara pagal siuntą nebūtinai reiškia kainodarą pagal užsakymą
Elektroninės prekybos užsakymas gali sukurti kelis paketus. Jei apmokestinamas vienetas yra sekimo numeris, padalytam užsakymui gali būti sunaudoti keli vienetai. Taip pat reikia aiškiai apibrėžti grąžinamas siuntas, pakeičiamąsias siuntas ir siuntėjo perdavimus vežėjui.
Paklauskite, ar mokestis suteikia stebėjimą nustatytą laikotarpį, iki apibrėžto užbaigimo įvykio ar taikant kitą ribą. Taip pat išsiaiškinkite, ar jau užregistruotos siuntos vėlesniu atsiskaitymo laikotarpiu apmokestinamos iš naujo. Šios detalės yra svarbesnės už kainodaros plano pavadinimą.
Vertinkite kainą pagal darbo eigą, o ne vien pagal užsakymų skaičių
Pasirinkite tipinį veiklos laikotarpį ir parenkite prognozę pagal siuntų lygio duomenis. Įtraukite naujas siuntas ir senesnes siuntas, kurias vis dar reikia stebėti. Jei jūsų duomenys neišsamūs, aiškiai nurodykite prielaidas, o ne pateikite rezultatą kaip tikslų pasiūlymą.
- Suskaičiuokite stebimus paketus. Pradėkite nuo unikalių paketų stebėjimo vienetų, o ne nuo atsiskaitymo užsakymų. Kol nepatvirtintas jų apmokestinimas, atskirai laikykite išsiunčiamus paketus, grąžinamas ir pakeičiamąsias siuntas.
- Įvertinkite stebėjimo trukmę. Apskaičiuokite, kiek laiko kiekvienai siuntai reikės atnaujinimų, prireikus įtraukdami laikotarpius iki tranzito pradžios ir išimčių laikotarpius.
- Apibrėžkite reikiamą atnaujinimų dažnį. Nurodykite, kaip dažnai programai reikia naujausios informacijos ir ar tai keičiasi priklausomai nuo siuntos būsenos.
- Susiekite API darbo eigą. Išvardykite registracijas, rezultatų paieškas, atnaujinimo užklausas, pataisymus, pakartotinius bandymus ir kitus galinius taškus, kuriuos naudos integracija.
- Pritaikykite atsiskaitymo taisykles. Techninę veiklą paverskite apmokestinamais iškvietimais arba siuntų vienetais pagal siūlomą sutartį.
- Pridėkite su naudojimu nesusijusius mokesčius. Įtraukite taikomą prenumeratą, minimalų įsipareigojimą, pasirenkamas paslaugas ir diegimo arba veiklos išlaidas.
Paprastos apklausimu pagrįstos integracijos, kai kiekvienai paieškai naudojamas vienas sekimo numeris, pradinė sąmata yra:
Paieškos užklausos = stebimos siuntos × vidutinis stebėjimo dienų skaičius × paieškos per dieną
Ši santrumpa daro prielaidą, kad kiekviena siunta laikosi tokio paties vidutinio grafiko. Tikslesnis modelis susumuoja kiekvienos siuntos arba siuntų grupės užklausas, tada prideda registracijos iškvietimus ir kitą apmokestinamą veiklą. Jei siuntos išlieka aktyvios per mėnesio pabaigą, paskirstykite jų užklausas tiems atsiskaitymo laikotarpiams, kuriais šios užklausos pateikiamos.
Praktinis pavyzdys: kada pigesnis modelis pasikeičia
Toliau pateikti skaičiai išgalvoti vien tam, kad būtų pademonstruotas skaičiavimas. Tai nėra 17TRACK kainos, tiekėjų pasiūlymai ar rinkos lyginamieji rodikliai.
Tarkime, kad per tą patį modeliuojamą laikotarpį užregistruojama ir visiškai stebima 10 000 paketų. Kiekvienam reikia vienos registracijos užklausos ir trijų paieškos užklausų per dieną aštuonias dienas. Tarkime, kad kiekviena užklausa apmokestinama, kiekviena užklausa susijusi su vienu paketu ir nėra pakartotinių bandymų, paketinių nuolaidų, lengvatų ar fiksuotų mokesčių.
- Registracijos užklausos: 10 000.
- Paieškos užklausos: 10 000 × 8 × 3 = 240 000.
- Visos apmokestinamos užklausos: 250 000.
- Orientacinis tarifas pagal iškvietimą: $0.002.
- Orientacinis tarifas pagal siuntą: $0.04, įskaitant reikiamą stebėjimą.
Naudojimo kaina pagal iškvietimą yra 250 000 × $0.002 = $500. Naudojimo kaina pagal siuntą yra 10 000 × $0.04 = $400. Pagal šias prielaidas kainodara pagal siuntą naudojimui kainuoja $100 mažiau.
Dabar pakeiskime tik paieškos dažnį į kartą per dieną. Užklausų skaičius tampa 10 000 registracijų ir 80 000 paieškų, arba 90 000 iškvietimų. Naudojimo kaina pagal iškvietimą sumažėja iki $180, o orientacinė naudojimo kaina pagal siuntą lieka $400. Pageidaujamas modelis pasikeičia todėl, kad pasikeičia darbo krūvis, o ne todėl, kad kuri nors kainodaros struktūra iš esmės yra geresnė.
Raskite lūžio tašką
Kai abu planai neturi fiksuotų mokesčių, lengvatų ar papildomų mokesčių, naudokite:
Apmokestinamų iškvietimų lūžio taškas vienai siuntai = siuntos tarifas ÷ iškvietimo tarifas
Pavyzdyje $0.04 ÷ $0.002 yra 20 apmokestinamų iškvietimų vienai siuntai. Viršijus 20 iškvietimų, siuntos mokestis yra mažesnis; nesiekus 20, mažesnis yra iškvietimo mokestis. Pagal pavyzdžio prielaidas registracijos iškvietimai įskaičiuojami į šią ribą.
Šios santrumpos nepakanka pakopiniams planams, iš anksto apmokėtiems kreditams, skirtingiems galinių taškų tarifams ar minimaliems įsipareigojimams. Tokiems pasiūlymams apskaičiuokite visą sąskaitą pagal kiekvieną prognozuojamą apimtį, o ne lyginkite tik nurodytus vieneto tarifus.
Žiniatinklio kabliukai gali sumažinti apklausimą, tačiau atsiskaitymą vis tiek reikia patikrinti
Apklausimas reiškia, kad programa pakartotinai prašo stebėjimo informacijos. Žiniatinklio kabliukas leidžia paslaugai išsiųsti įvykį jūsų programai ir sumažinti pakartotinių paieškų poreikį, kai įvykių srautas atitinka jūsų reikalavimus.
Tačiau mažesnis paieškos užklausų skaičius automatiškai nereiškia mažesnės sąskaitos. Patvirtinkite, ar žiniatinklio kabliuko pranešimai įtraukti, ar pranešimai ir pakartotiniai bandymai matuojami, ir ar vis dar reikalingos suderinimo paieškos. Programa taip pat turi saugiai tvarkyti pasikartojančius arba ne eilės tvarka gaunamus įvykius ir atsigauti po pristatymo klaidų.
Verta atskirti dar vieną dalyką: dažnesnis informacijos prašymas negarantuoja, kad vežėjas jau sukūrė naują nuskaitymą. Prieš mokėdami už apklausimo dažnį, kuris gali suteikti mažai papildomos veiklos vertės, paklauskite, ką grąžina paieška ir kaip atnaujinami duomenys.
Išlaidos, kurias gali paslėpti nurodytas tarifas
Įtrauktos lengvatos, minimumai ir iš anksto apmokėti likučiai
Atskirkite minimalią sąskaitą nuo prenumeratos su įtrauktu naudojimu. Minimali sąskaita gali nustatyti mažiausią išlaidų ribą; lengvata gali apimti nustatytą kiekį, iki pradedami taikyti viršijimo mokesčiai. Iš anksto apmokėti kreditai kelia atskirus klausimus dėl galiojimo pabaigos, grąžinimo ir nepanaudotų likučių.
Planuose, kuriuose lengvata išskaičiuojama prieš taikant viršijimo mokesčius, naudinga tokia struktūra:
API sąskaita = fiksuotas plano mokestis + apmokestinamas viršijimas + taikomi papildomi priedai
Naudokite šią formulę tik tuo atveju, jei ji atitinka sutartį. Nepridėkite to paties įtraukto naudojimo du kartus ir nemanykite, kad visi planai vienodai taiko ribinę kainodarą.
Ilgai trunkančios siuntos ir pakartotinės registracijos
Ilgi stebėjimo laikotarpiai didina paieškų kiekį apklausimu pagrįstame modelyje. Kainodaros pagal siuntą atveju svarbu, ar pradinis mokestis apima tą laikotarpį. Išbandykite išimtis ir vėluojančias siuntas, o ne tik greitai pristatomas siuntas.
Taip pat patvirtinkite, kas nutinka, kai tas pats sekimo numeris pateikiamas du kartus, pataisomas, ištrinamas ir vėl pridedamas arba susiejamas su kitu vežėju. Jei reikia, įdiekite pasikartojimų prevenciją, tačiau nemanykite, kad programos lygmens pasikartojimų šalinimas tiksliai sutampa su tiekėjo atsiskaitymo tapatybe.
Užklausų dažnio ribos ir pikinis pajėgumas
Įperkama mėnesio lengvata negarantuoja, kad integracija galės apdoroti didelį importą ar srauto šuolį. Patikrinkite užklausų dažnio ribas, paketinių užklausų ribas, lygiagretaus vykdymo apribojimus ir numatomą elgesį pasiekus ribas. Planas, atitinkantis mėnesio apimtį, bet nepalaikantis reikiamos darbo eigos, nėra lygiavertė alternatyva.
Inžinerijos ir veiklos išlaidos
API sąskaitą laikykite atskirai nuo bendrų nuosavybės išlaidų. Vidaus išlaidos gali apimti integracijos kūrimą, žiniatinklio kabliukų talpinimą, eiles, stebėjimą, reagavimą į incidentus, duomenų saugojimą ir priežiūrą.
Naudokite savo darbo ir infrastruktūros sąmatas. Brangesnė prenumerata vis tiek gali būti ekonomiška, jei ji akivaizdžiai sumažina veiklos darbą, tačiau šį sutaupymą reikia patikrinti, o ne laikyti savaime suprantamu.
Kaip palyginti pasiūlymus ir patikrinti trumpąjį sąrašą
Paprašykite kiekvieno tiekėjo įkainoti tą pačią darbo krūvio specifikaciją: paketų kiekį, siuntų derinį, stebėjimo trukmę, atnaujinimų reikalavimus, galinius taškus, pikines apkrovas ir reikiamas paslaugas. Paprašykite raštu paaiškinti atsiskaitymo vienetą ir pateikti pavyzdinį sąskaitos skaičiavimą.
Komandoms, svarstančioms 17TRACK, oficialus Tracking API puslapis ir API dokumentacija yra tinkami pradiniai taškai produkto ir integracijos vertinimui. Prieš priskirdami modelį savo prognozei, tiesiogiai patvirtinkite taikomą kainodarą ir atsiskaitymo apibrėžtis. Šiame straipsnyje nepateikiamas ir neklasifikuojamas dabartinis 17TRACK planas.
Prieš įsipareigodami atlikite kontroliuojamą bandymą su tipinėmis siuntomis. Įtraukite padalytus užsakymus, pasikartojančius pateikimus, vėluojančius paketus, tarpvalstybinius pervežimus ir siuntas, kurios pereina atsiskaitymo ribą. Nesėkmių ar pakartotinių bandymų elgseną tikrinkite tik paslaugos leidžiamais būdais.
- Palyginkite savo užklausų žurnalus su tiekėjo naudojimo įrašais.
- Suderinkite užregistruotus sekimo vienetus su apmokestintais siuntų vienetais.
- Patikrinkite, ar iš tikrųjų pasiekiamas reikiamas atnaujinimų dažnis.
- Pikinę paklausą vertinkite atskirai nuo mėnesio suvartojimo.
- Ištirkite nepaaiškinamus skirtumus prieš ekstrapoliuodami išlaidas.
Parenkite bent tris prognozes: įprastos veiklos, sezoninio piko ir užsitęsusio tranzito. Keiskite pagrindinius veiksnius, o ne pridėkite savavališką procentą prie sąskaitos. Pavyzdžiui, piko scenarijuje modeliuokite daugiau paketų, o vėlavimo scenarijuje – ilgesnę stebėjimo trukmę.
Kurį modelį turėtumėte pasirinkti?
Rinkitės kainodarą pagal iškvietimą, kai paieškos atliekamos retai, užklausų poreikis yra išmatuojamas, o prognozė, įskaičiavus registracijas ir kitą apmokestinamą veiklą, lieka žemiau lūžio taško. Ji mažiau patraukli, kai dažnas apklausimas arba nenuspėjama stebėjimo trukmė sukuria didelę užklausų apimtį.
Rinkitės kainodarą pagal siuntą, kai reikalingas nuolatinis stebėjimas ir nurodytas siuntos mokestis apima jums reikalingą atnaujinimų dažnį, stebėjimo trukmę bei pristatymo mechanizmą. Ji mažiau patraukli, kai mokate už retai naudojamą stebėjimą arba kai dėl siuntos apibrėžimo atsiranda netikėtų papildomų vienetų.
Galutinis sprendimas turėtų būti grindžiamas bendra vieno veiklos paketo kaina: API sąskaita ir priskirtos veiklos išlaidos, padalytos iš unikalių paketų, kuriuos jūsų verslui reikia stebėti, skaičiaus. Šį vidinį paketo apibrėžimą išlaikykite nuoseklų visuose pasiūlymuose, net jei tiekėjai naudoja skirtingus atsiskaitymo vienetus.
DUK
Ar nesėkmingos API užklausos apmokestinamos?
Nenumatykite nei vieno, nei kito varianto. Paklauskite, kaip vertinamos tikrinimo klaidos, autentifikavimo nesėkmės, dažnio ribojimo atsakymai, serverio klaidos ir skirtojo laiko pabaigos. Skirtojo laiko pabaiga taip pat gali sukelti neaiškumą, ar užklausa buvo apdorota prieš programai ją pakartojant.
Ar vienas užsakymas visada laikomas viena siunta?
Ne. Užsakyme gali būti keli atskirai stebimi paketai. Biudžetui sudarykite užsakymų ir stebėjimo vienetų atitikmenį, tada pritaikykite tiekėjo apibrėžimą. Patvirtinkite, kaip skaičiuojamos grąžinamos, pakeičiamosios siuntos ir siuntų perdavimai vežėjui.
Ar paketinės užklausos sumažins mano sąskaitą?
Tik jei atsiskaitymo taisyklės skatina paketinių užklausų naudojimą. Paketai gali sumažinti tinklo užklausų skaičių, bet nesumažinti apmokestinamų stebėjimo vienetų. Patikrinkite paketo ribą ir tai, ar atsiskaitoma už užklausą, elementą ar svertinį vienetą.
Ar žiniatinklio kabliukai gali panaikinti visas paieškos užklausas?
Jie gali pašalinti didžiąją dalį įprasto apklausimo, tačiau jūsų sistemai vis tiek gali reikėti pradinio gavimo, atkūrimo po praleistų įvykių ar periodinio suderinimo. Įtraukite šiuos iškvietimus į sąmatą ir patvirtinkite visus žiniatinklio kabliukų pranešimų mokesčius.
Kaip turėčiau planuoti kitą mėnesį vis dar aktyvias siuntas?
Kainodaros pagal iškvietimą atveju prognozuokite užklausas, kurias šios siuntos sugeneruos kitu laikotarpiu. Kainodaros pagal siuntą atveju patvirtinkite, ar stebėjimas ir toliau įtrauktas, ar bus taikomas papildomas mokestis. Vertindami tęstinį darbo krūvį, neskaičiuokite tik naujai sukurtų siuntų.
Šaltiniai
Pirmiau pateiktuose skaičiavimuose naudojami aiškiai hipotetiniai duomenys, o ne paskelbtos tiekėjų kainos. Vertindami 17TRACK, naudokite šiuos oficialius informacijos puslapius ir tiesiogiai patvirtinkite komercines sąlygas:
