Shpjegimi i modeleve të çmimeve të Tracking API: për thirrje kundrejt për dërgesë dhe si të vlerësoni koston tuaj reale
Çmimi i API-së së gjurmimit për thirrje tarifon kërkesat e faturueshme; çmimi për dërgesë tarifon njësi të përcaktuar gjurmimi, si një numër gjurmimi të regjistruar. Asnjëra nuk është automatikisht më e lirë. Për të vlerësuar koston reale, krahasoni të dyja modelet kundrejt të njëjtit vëllim dërgesash, kërkesave për përditësime, kohëzgjatjes së gjurmimit dhe rregullave të faturimit, më pas shtoni tarifat e platformës, tejkalimet dhe kostot e integrimit.
Për ekipet e inxhinierisë, operacioneve dhe prokurimit, krahasimi i dobishëm nuk është thjesht çmimi për thirrje kundrejt çmimit për dërgesë. Është kostoja totale e ofrimit të dukshmërisë së dërgesave që i nevojitet biznesit tuaj. Një normë e ulët kërkesash mund të bëhet e shtrenjtë me sondime të shpeshta, ndërsa një normë e ulët dërgesash mund të jetë çorientuese nëse dritarja e gjurmimit ose shërbimet e përfshira nuk përshtaten me rrjedhën tuaj të punës.
Çfarë mat në të vërtetë secili model çmimi
Hapi i parë është të ndahen tri gjëra: një kërkesë API, një regjistrim dërgese dhe një përditësim gjurmimi. Ato janë ngjarje të ndryshme dhe një kontratë mund t'u caktojë trajtim të ndryshëm faturimi.
| Pika e krahasimit | Çmimi për thirrje | Çmimi për dërgesë |
|---|---|---|
| Baza e faturimit | Kërkesa ose njësi kërkesash të përcaktuara si të faturueshme | Njësi dërgesash të përcaktuara si të faturueshme |
| Faktori kryesor i kostos | Sa shpesh aplikacioni bën kërkesa të tarifueshme | Sa njësi gjurmimi të tarifueshme hyjnë ose mbeten në fushëveprim |
| Pyetja e faturimit që duhet zgjidhur | Cilat endpoint-e, përgjigje dhe artikuj grupi numërohen? | Çfarë përbën një dërgesë dhe për sa kohë përfshihet gjurmimi? |
| Ekspozimi i mundshëm ndaj kostos | Sondime të përsëritura, riprovime dhe kërkime të panevojshme | Regjistrime të dyfishta, paketa të shumta dhe kufizime të dritares së gjurmimit |
| Përshtatja më e fortë kushtore | Kërkime me frekuencë të ulët dhe vëllim të kontrolluar kërkesash | Monitorim i vazhdueshëm kur përditësimet përfshihen në tarifën e dërgesës |
Çmimi për thirrje nuk do të thotë domosdoshmërisht se çdo kërkesë HTTP kushton njësoj
Një ofertë duhet të identifikojë endpoint-et e faturueshme dhe njësitë e tyre. Regjistrimi i një numri gjurmimi, marrja e rezultateve të ruajtura, kërkesa për rifreskim dhe menaxhimi i abonimeve mund të trajtohen ndryshe. Mos supozoni se një kërkesë e dështuar është falas ose se një kërkesë e suksesshme është gjithmonë e tarifueshme.
Grupimi gjithashtu kërkon një përkufizim të qartë. Një kërkesë që përmban 100 numra gjurmimi mund të llogaritet si një kërkesë, 100 njësi gjurmimi ose një sasi tjetër kontraktuale. Ulja e trafikut të rrjetit nuk krijon kursim faturimi nëse rregullat e matjes nuk e mbështesin atë.
Çmimi për dërgesë nuk do të thotë domosdoshmërisht për porosi
Një porosi e tregtisë elektronike mund të prodhojë disa paketa. Nëse njësia e tarifueshme është numri i gjurmimit, një porosi e ndarë mund të konsumojë disa njësi. Kthimet, dërgesat zëvendësuese dhe kalimet ndërmjet transportuesve gjithashtu kërkojnë trajtim të qartë.
Pyetni nëse tarifa blen gjurmim për një periudhë të caktuar, deri në një ngjarje të përcaktuar përfundimi apo nën një kufizim tjetër. Gjithashtu përcaktoni nëse dërgesat e regjistruara më parë shkaktojnë tarifa të reja në një periudhë të mëvonshme faturimi. Këto hollësi kanë më shumë rëndësi se emërtimi i planit të çmimeve.
Vlerësoni koston nga rrjedha juaj e punës, jo vetëm nga numri i porosive
Përdorni një periudhë përfaqësuese funksionimi dhe ndërtoni një parashikim nga të dhënat në nivel dërgese. Përfshini si dërgesat e reja, ashtu edhe dërgesat më të vjetra që ende kërkojnë monitorim. Nëse të dhënat tuaja janë të paplota, bëjini të dukshme supozimet në vend që ta paraqisni rezultatin si një ofertë të saktë.
- Numëroni paketat që mund të gjurmohen. Filloni me njësitë unike të gjurmimit të paketave, jo me porositë e arkës. Mbajini të ndara paketat dalëse, kthimet dhe zëvendësimet derisa të konfirmohet trajtimi i tyre në faturim.
- Matni kohëzgjatjen e monitorimit. Vlerësoni për sa kohë çdo dërgesë ka nevojë për përditësime, duke përfshirë periudhat para tranzitit dhe të përjashtimeve, kur është e rëndësishme.
- Përcaktoni frekuencën e kërkuar të përditësimeve. Specifikoni sa shpesh aplikacioni juaj ka nevojë për informacion të freskët dhe nëse kjo ndryshon sipas statusit të dërgesës.
- Përshkruani rrjedhën e punës së API-së. Listoni regjistrimet, kërkimet e rezultateve, kërkesat për rifreskim, korrigjimet, riprovimet dhe çdo endpoint tjetër që do të përdorë integrimi juaj.
- Zbatoni rregullat e faturimit. Shndërroni aktivitetin teknik në thirrje ose njësi dërgesash të faturueshme duke përdorur kontratën e propozuar.
- Shtoni tarifat që nuk lidhen me përdorimin. Përfshini abonimin e zbatueshëm, angazhimin minimal, shërbimet opsionale dhe kostot e zbatimit ose funksionimit.
Për një integrim të thjeshtë me sondim dhe një numër gjurmimi për kërkim, vlerësimi fillestar është:
Kërkesa kërkimi = dërgesat e monitoruara × ditët mesatare të monitorimit × kërkimet në ditë
Kjo shkurtore supozon se çdo dërgesë ndjek të njëjtin plan mesatar. Një model më i saktë mbledh kërkesat për çdo dërgesë ose grup dërgesash, pastaj shton thirrjet e regjistrimit dhe aktivitetet e tjera të faturueshme. Nëse dërgesat mbeten aktive gjatë ndërrimit të muajit, caktojini kërkesat e tyre periudhave të faturimit në të cilat ndodhin ato kërkesa.
Një shembull i përllogaritur: kur ndryshon modeli më i lirë
Numrat e mëposhtëm janë të sajuar vetëm për të demonstruar përllogaritjen. Ata nuk janë çmime të 17TRACK, oferta të furnitorëve ose tregues tregu.
Supozoni se regjistrohen dhe monitorohen plotësisht 10,000 paketa brenda së njëjtës periudhë të modeluar. Secila kërkon një kërkesë regjistrimi dhe tri kërkesa kërkimi në ditë për tetë ditë. Supozoni se çdo kërkesë është e faturueshme, çdo kërkesë lidhet me një paketë dhe nuk ka riprovime, zbritje për grupe, lehtësime ose tarifa fikse.
- Kërkesat e regjistrimit: 10,000.
- Kërkesat e kërkimit: 10,000 × 8 × 3 = 240,000.
- Kërkesat totale të faturueshme: 250,000.
- Norma ilustruese për thirrje: $0.002.
- Norma ilustruese për dërgesë: $0.04, duke përfshirë monitorimin e kërkuar.
Kostoja e përdorimit për thirrje është 250,000 × $0.002 = $500. Kostoja e përdorimit për dërgesë është 10,000 × $0.04 = $400. Sipas këtyre supozimeve, çmimi për dërgesë kushton $100 më pak për përdorim.
Tani ndryshoni vetëm frekuencën e kërkimit në një herë në ditë. Numri i kërkesave bëhet 10,000 regjistrime plus 80,000 kërkime, ose 90,000 thirrje. Përdorimi për thirrje bie në $180, ndërsa përdorimi ilustrues për dërgesë mbetet $400. Modeli i preferuar ndryshon sepse ndryshon ngarkesa e punës, jo sepse njëra strukturë çmimi është në thelb më e mirë.
Gjeni pikën e barazimit
Kur të dyja planet nuk kanë tarifa fikse, lehtësime ose tarifa shtesë, përdorni:
Thirrjet e faturueshme të barazimit për dërgesë = norma për dërgesë ÷ norma për thirrje
Në shembull, $0.04 ÷ $0.002 është e barabartë me 20 thirrje të faturueshme për dërgesë. Mbi 20 thirrje, tarifa e dërgesës është më e ulët; nën 20, tarifa e thirrjes është më e ulët. Kërkesat e regjistrimit llogariten në këtë prag sipas supozimeve të shembullit.
Kjo shkurtore nuk mjafton për planet me nivele, kreditë e parapaguara, norma të ndryshme endpoint-esh ose angazhime minimale. Për këto oferta, llogaritni faturën e plotë në çdo vëllim të parashikuar në vend që të krahasoni normat kryesore për njësi.
Webhook-et mund të zvogëlojnë sondimin, por faturimi ende duhet verifikuar
Sondimi do të thotë që aplikacioni juaj kërkon vazhdimisht informacion gjurmimi. Një webhook lejon që një shërbim t'i dërgojë një ngjarje aplikacionit tuaj, duke zvogëluar nevojën për kërkime të përsëritura kur rrjedha e ngjarjeve përmbush kërkesat tuaja.
Megjithatë, më pak kërkesa kërkimi nuk do të thotë automatikisht një faturë më të ulët. Konfirmoni nëse dërgimi i webhook-eve përfshihet, nëse dërgesat ose riprovimet maten dhe nëse kërkimet e rakordimit mbeten të nevojshme. Aplikacioni juaj gjithashtu duhet të trajtojë në mënyrë të sigurt ngjarjet e dyfishta ose jashtë rendit dhe të rikuperohet nga dështimet e dërgimit.
Ekziston edhe një dallim tjetër që duhet ruajtur: kërkimi i informacionit më shpesh nuk garanton që transportuesi bazë ka prodhuar një skanim të ri. Pyetni se çfarë kthen një kërkim dhe si funksionon rifreskimi i të dhënave përpara se të paguani për një frekuencë sondimi që mund të sjellë pak vlerë operacionale.
Kostot që mund të fshihen pas një norme kryesore
Lehtësimet e përfshira, minimumet dhe balancat e parapaguara
Ndani një faturë minimale nga një abonim me përdorim të përfshirë. Një faturë minimale mund të përcaktojë një prag shpenzimi; një lehtësim mund të mbulojë një sasi të caktuar përpara se të zbatohen tarifat e tejkalimit. Kreditë e parapaguara sjellin pyetje të veçanta për skadimin, rimbursimet dhe balancat e papërdorura.
Për një plan ku lehtësimi zbritet përpara tejkalimeve, një strukturë e dobishme është:
Fatura e API-së = tarifa fikse e planit + tejkalimi i tarifueshëm + shtesat e zbatueshme
Përdoreni këtë formulë vetëm nëse përputhet me kontratën. Mos e shtoni të njëjtin përdorim të përfshirë dy herë dhe mos supozoni se të gjitha planet zbatojnë çmimin margjinal në të njëjtën mënyrë.
Dërgesat afatgjata dhe regjistrimet e përsëritura
Periudhat e gjata të monitorimit rrisin vëllimin e kërkimeve në një model me sondim. Sipas çmimit për dërgesë, pyetja përkatëse është nëse tarifa fillestare mbulon këtë kohëzgjatje. Testoni përjashtimet dhe dërgesat e vonuara, jo vetëm dërgesat që përfundojnë shpejt.
Gjithashtu konfirmoni se çfarë ndodh kur i njëjti numër gjurmimi dërgohet dy herë, korrigjohet, fshihet dhe shtohet përsëri ose lidhet me një transportues tjetër. Zbatoni parandalimin e dublikatave kur është e përshtatshme, por mos supozoni se deduplikimi në nivel aplikacioni përputhet në mënyrë të përsosur me identitetin e faturimit të furnitorit.
Kufijtë e normës dhe kapaciteti maksimal
Një lehtësim mujor i përballueshëm nuk përcakton se një integrim mund të përballojë një import të madh ose një rritje të menjëhershme të trafikut. Kontrolloni kufijtë e normës së kërkesave, kufijtë e grupeve, kufizimet e njëkohshmërisë dhe sjelljen e pritshme kur arrihen kufijtë. Një plan që përmbush vëllimin mujor, por nuk mbështet rrjedhën e kërkuar të punës, nuk është alternativë e krahasueshme.
Kostot e inxhinierisë dhe funksionimit
Mbajeni faturën e API-së të ndarë nga kostoja totale e zotërimit. Shpenzimet e brendshme mund të përfshijnë zhvillimin e integrimit, hostimin e webhook-eve, radhët, monitorimin, përgjigjen ndaj incidenteve, ruajtjen e të dhënave dhe mirëmbajtjen.
Përdorni vlerësimet tuaja për punën dhe infrastrukturën. Një abonim më i shtrenjtë mund të jetë ende ekonomik nëse redukton në mënyrë të dukshme punën operacionale, por ky kursim duhet testuar dhe jo supozuar.
Si të krahasoni ofertat dhe të vërtetoni një listë të shkurtër
Kërkojini çdo furnitori të çmojë të njëjtin specifikim ngarkese pune: vëllimin e paketave, përzierjen e dërgesave, kohëzgjatjen e monitorimit, kërkesat për përditësime, endpoint-et, ngarkesën maksimale dhe shërbimet e kërkuara. Kërkoni një shpjegim me shkrim të njësisë së faturimit dhe një shembull të llogaritjes së faturës.
Për ekipet që po shqyrtojnë 17TRACK, faqja zyrtare e Tracking API dhe dokumentacioni i API-së janë pikat përkatëse të nisjes për vlerësimin e produktit dhe integrimit. Konfirmoni drejtpërdrejt çmimet dhe përkufizimet e faturimit të zbatueshme përpara se të caktoni një model në parashikimin tuaj. Ky artikull nuk citon ose klasifikon një plan aktual të 17TRACK.
Përpara angazhimit, zhvilloni një pilot të kontrolluar duke përdorur dërgesa përfaqësuese. Përfshini porosi të ndara, dërgime të dyfishta, paketa të vonuara, lëvizje ndërkufitare dhe dërgesa që kalojnë një kufi faturimi. Testoni sjelljen ndaj dështimeve ose riprovimeve vetëm në mënyrat e lejuara nga shërbimi.
- Krahasoni regjistrat e kërkesave tuaja me të dhënat e përdorimit të furnitorit.
- Rakordoni njësitë e regjistruara të gjurmimit me njësitë e faturuara të dërgesave.
- Kontrolloni nëse ritmi i kërkuar i përditësimeve arrihet realisht.
- Matni veçmas kërkesën maksimale nga konsumi mujor.
- Hettoni ndryshimet e pashpjeguara përpara se të ekstrapoloni kostot.
Ndërtoni të paktën tri parashikime: funksionim normal, kulm sezonal dhe tranzit të zgjatur. Ndryshoni faktorët bazë në vend që të shtoni një përqindje arbitrare në faturë. Për shembull, modeloni më shumë paketa për një kulm dhe kohëzgjatje më të gjata monitorimi për një skenar vonese.
Cilin model duhet të zgjidhni?
Preferoni çmimin për thirrje kur kërkimet janë të rralla, kërkesa për thirrje është e matshme dhe parashikimi mbetet nën pikën e barazimit pasi përfshihen regjistrimet dhe aktivitetet e tjera të faturueshme. Ai është më pak tërheqës kur sondimi i shpeshtë ose kohëzgjatja e paparashikueshme e monitorimit krijon ekspozim të konsiderueshëm ndaj kërkesave.
Preferoni çmimin për dërgesë kur kërkohet monitorim i vazhdueshëm dhe tarifa e kuotuar për dërgesë përfshin frekuencën e përditësimeve, kohëzgjatjen e gjurmimit dhe mekanizmin e dërgimit që ju nevojitet. Ai është më pak tërheqës kur paguani për monitorim që e përdorni rrallë ose kur përkufizimi i dërgesës krijon njësi shtesë të papritura.
Vendimi përfundimtar duhet të përdorë koston totale për paketë operacionale: faturën e API-së plus kostot operative të atribuueshme, pjesëtuar me paketat unike që biznesi juaj duhet të monitorojë. Mbajeni të njëjtë përkufizimin e brendshëm të paketës në të gjitha ofertat, edhe kur furnitorët përdorin njësi të ndryshme faturimi.
FAQ
A janë të faturueshme kërkesat e pasuksesshme API?
Mos supozoni asnjërin rezultat. Pyetni për trajtimin e gabimeve të validimit, dështimeve të autentikimit, përgjigjeve të kufizimit të normës, gabimeve të serverit dhe skadimeve të kohës. Një skadim kohe mund të krijojë gjithashtu pasiguri nëse një kërkesë u përpunua përpara se aplikacioni juaj ta riprovonte.
A llogaritet gjithmonë një porosi si një dërgesë?
Jo. Një porosi mund të përmbajë disa paketa të gjurmuara veçmas. Për buxhetim, lidhini porositë me njësitë e gjurmimit dhe më pas zbatoni përkufizimin e furnitorit. Konfirmoni se si numërohen kthimet, zëvendësimet dhe kalimet ndërmjet transportuesve.
A do ta ulin faturën time kërkesat në grup?
Vetëm nëse rregullat e faturimit shpërblejnë grupimin. Grupet mund të ulin kërkesat e rrjetit pa ulur njësitë e faturueshme të gjurmimit. Verifikoni kufirin e grupit dhe nëse faturimi zbatohet për kërkesë, për artikull ose përmes një njësie të ponderuar.
A mund të eliminojnë webhook-et të gjitha kërkesat e kërkimit?
Ato mund të heqin pjesën më të madhe të sondimit rutinë, por dizajni juaj mund të ketë ende nevojë për marrje fillestare, rikuperim pas ngjarjeve të humbura ose rakordim periodik. Përfshini këto thirrje në vlerësim dhe konfirmoni çdo tarifë për dërgimin e webhook-eve.
Si duhet të buxhetoj për dërgesat që janë ende aktive muajin e ardhshëm?
Për çmimin për thirrje, parashikoni kërkesat që këto dërgesa do të gjenerojnë në periudhën e ardhshme. Për çmimin për dërgesë, konfirmoni nëse monitorimi mbetet i mbuluar ose shkakton një tarifë tjetër. Mos numëroni vetëm dërgesat e krijuara rishtazi kur vlerësoni ngarkesën e vazhdueshme të punës.
Burimet
Përllogaritjet e mësipërme përdorin të dhëna hyrëse shprehimisht hipotetike, jo çmime të publikuara të furnitorëve. Për një vlerësim të 17TRACK, përdorni këto faqe zyrtare referimi dhe konfirmoni drejtpërdrejt kushtet tregtare:
