A Tracking API árazási modelljei: hívásonkénti vagy szállítmányonkénti díjazás, és hogyan becsülheti meg tényleges költségét
A hívásonkénti nyomkövetési API-árazás a számlázható kérések után számít fel díjat; a küldeményenkénti árazás egy meghatározott nyomkövetési egység, például egy regisztrált nyomkövetési szám után számít fel díjat. Egyik sem automatikusan olcsóbb. A tényleges költség becsléséhez hasonlítsa össze mindkét modellt ugyanazon küldeménymennyiség, frissítési követelmények, nyomkövetési időtartam és számlázási szabályok alapján, majd adja hozzá a platformdíjakat, a túllépési díjakat és az integrációs költségeket.
A mérnöki, üzemeltetési és beszerzési csapatok számára a hasznos összehasonlítás nem egyszerűen a hívásonkénti és a küldeményenkénti ár összevetése. A lényeg a vállalkozás által igényelt küldeményláthatóság biztosításának teljes költsége. Az alacsony kérésgyakoriság gyakori lekérdezés esetén drágává válhat, míg az alacsony küldeményenkénti díj félrevezető lehet, ha a nyomkövetési időablak vagy a tartalmazott szolgáltatások nem illeszkednek a munkafolyamathoz.
Mit mér valójában az egyes árazási modellek?
Az első lépés három dolog elkülönítése: API-kérés, küldeményregisztráció és nyomkövetési frissítés. Ezek különböző események, és egy szerződés mindegyikhez eltérő számlázási kezelést rendelhet.
| Összehasonlítási szempont | Hívásonkénti árazás | Küldeményenkénti árazás |
|---|---|---|
| Számlázási alap | Számlázhatóként meghatározott kérések vagy kérési egységek | Számlázhatóként meghatározott küldeményegységek |
| Fő költségtényező | A díjköteles kérések alkalmazás általi gyakorisága | A hatókörbe belépő vagy abban maradó díjköteles nyomkövetési egységek száma |
| Megválaszolandó számlázási kérdés | Mely végpontok, válaszok és kötegelt elemek számítanak? | Mi minősül egy küldeménynek, és meddig tartalmazza az ár a nyomkövetést? |
| Lehetséges költségkitettség | Ismételt lekérdezések, újrapróbálkozások és szükségtelen keresések | Duplikált regisztrációk, több csomag és a nyomkövetési időablak korlátai |
| Leginkább megfelelő feltételes eset | Alacsony gyakoriságú lekérdezések szabályozott kérésmennyiséggel | Folyamatos megfigyelés, amikor a frissítéseket tartalmazza a küldeménydíj |
A hívásonkénti árazás nem feltétlenül jelenti azt, hogy minden HTTP-kérés ugyanannyiba kerül
Az árajánlatnak meg kell határoznia a számlázható végpontokat és azok egységeit. A nyomkövetési szám regisztrálása, a tárolt eredmények lekérése, a frissítés kérése és a feliratkozások kezelése eltérő elbírálás alá eshet. Ne feltételezze, hogy egy sikertelen kérés ingyenes, vagy hogy egy sikeres kérés mindig díjköteles.
A kötegelt feldolgozást is kifejezetten meg kell határozni. Egy 100 nyomkövetési számot tartalmazó kérés számíthat egy kérésnek, 100 nyomkövetési egységnek vagy más, szerződésben meghatározott mennyiségnek. A hálózati forgalom csökkentése nem jelent számlázási megtakarítást, hacsak a mérési szabályok ezt nem támasztják alá.
A küldeményenkénti árazás nem feltétlenül jelenti azt, hogy rendelésenkénti
Egy e-kereskedelmi rendelés több csomagot is eredményezhet. Ha a díjköteles egység egy nyomkövetési szám, egy megosztott rendelés több egységet is felhasználhat. A visszaküldéseket, csereküldeményeket és fuvarozói átadásokat szintén egyértelműen kezelni kell.
Kérdezze meg, hogy a díj meghatározott időszakra, egy meghatározott teljesítési eseményig vagy más korlátozás mellett biztosítja-e a nyomkövetést. Azt is tisztázza, hogy a már regisztrált küldemények után keletkezik-e új díj egy későbbi számlázási időszakban. Ezek a részletek fontosabbak, mint az árazási csomag elnevezése.
A költséget a munkafolyamat, ne csupán a rendelésszám alapján becsülje
Használjon reprezentatív működési időszakot, és készítsen előrejelzést küldeményszintű adatokból. Vegye figyelembe az új küldeményeket és azokat a régebbi küldeményeket is, amelyek továbbra is megfigyelést igényelnek. Ha az adatai hiányosak, tegye láthatóvá a feltételezéseket ahelyett, hogy az eredményt pontos árajánlatként mutatná be.
- Számolja meg a nyomon követhető csomagokat. Egyedi csomag-nyomkövetési egységekkel kezdjen, ne a pénztári rendelésekkel. A kimenő csomagokat, visszaküldéseket és csereküldeményeket tartsa külön, amíg a számlázási kezelésük meg nem erősítést nyer.
- Mérje meg a megfigyelés időtartamát. Becsülje meg, hogy az egyes küldeményeknek mennyi ideig van szükségük frissítésekre, beleértve az indulás előtti és a kivételes időszakokat is, ahol releváns.
- Határozza meg a szükséges frissítési gyakoriságot. Adja meg, milyen gyakran van szüksége az alkalmazásnak friss információra, és hogy ez változik-e a küldemény állapotától függően.
- Térképezze fel az API-munkafolyamatot. Sorolja fel a regisztrációkat, eredménylekéréseket, frissítési kéréseket, javításokat, újrapróbálkozásokat és minden egyéb, az integráció által használt végpontot.
- Alkalmazza a számlázási szabályokat. A javasolt szerződés alapján alakítsa át a technikai tevékenységet számlázható hívásokká vagy küldeményegységekké.
- Adja hozzá a használattól független díjakat. Tartalmazza az alkalmazandó előfizetési díjat, minimális vállalást, opcionális szolgáltatásokat, valamint a bevezetési vagy üzemeltetési költségeket.
Egy egyszerű, lekérdezésen alapuló integráció esetén, ahol minden lekérdezéshez egy nyomkövetési szám tartozik, a kiinduló becslés:
Lekérdezési kérések = megfigyelt küldemények × átlagos megfigyelési napok × napi lekérdezések
Ez a rövidítés azt feltételezi, hogy minden küldemény ugyanazt az átlagos ütemezést követi. A pontosabb modell összegzi az egyes küldeményekhez vagy küldeménycsoportokhoz tartozó kéréseket, majd hozzáadja a regisztrációs hívásokat és az egyéb számlázható tevékenységeket. Ha a küldemények hónap végén is aktívak maradnak, a kéréseiket azokhoz a számlázási időszakokhoz rendelje, amelyekben a kérések történnek.
Számítási példa: amikor az olcsóbb modell változik
Az alábbi számok kizárólag a számítás bemutatására kitalált adatok. Nem a 17TRACK árai, beszállítói árajánlatok vagy piaci referenciaértékek.
Tegyük fel, hogy 10 000 csomagot regisztrálnak és teljes körűen megfigyelnek ugyanabban a modellezett időszakban. Mindegyikhez egy regisztrációs kérés és napi három lekérdezési kérés szükséges nyolc napon át. Tegyük fel, hogy minden kérés számlázható, minden kérés egy csomagra vonatkozik, és nincs újrapróbálkozás, kötegelt kedvezmény, engedmény vagy fix díj.
- Regisztrációs kérések: 10 000.
- Lekérdezési kérések: 10 000 × 8 × 3 = 240 000.
- Összes számlázható kérés: 250 000.
- Szemléltető hívásonkénti díj: 0,002 USD.
- Szemléltető küldeményenkénti díj: 0,04 USD, beleértve a szükséges megfigyelést.
A hívásonkénti használati költség 250 000 × 0,002 USD = 500 USD. A küldeményenkénti használati költség 10 000 × 0,04 USD = 400 USD. Ezekkel a feltételezésekkel a küldeményenkénti árazás 100 USD-val alacsonyabb használati költséget eredményez.
Most csak a lekérdezési gyakoriságot változtassuk napi egy alkalomra. A kérések száma 10 000 regisztráció és 80 000 lekérdezés, azaz 90 000 hívás lesz. A hívásonkénti használati költség 180 USD-ra csökken, míg a szemléltető küldeményenkénti használati költség 400 USD marad. Az előnyben részesített modell azért változik, mert a munkaterhelés változik, nem azért, mert valamelyik árazási struktúra eleve jobb.
Keresse meg a megtérülési pontot
Ha egyik csomag sem tartalmaz fix díjakat, engedményeket vagy további költségeket, használja a következőt:
Fedezeti pont szerinti számlázható hívások küldeményenként = küldeményenkénti díj ÷ hívásonkénti díj
A példában 0,04 USD ÷ 0,002 USD = 20 számlázható hívás küldeményenként. 20 hívás felett a küldeménydíj alacsonyabb; 20 alatt a hívásonkénti díj alacsonyabb. A példában szereplő feltételezések szerint a regisztrációs hívások beleszámítanak ebbe a küszöbértékbe.
Ez a rövidítés nem elegendő többszintű csomagok, előre fizetett kreditek, eltérő végponti díjak vagy minimális vállalások esetén. Ilyen ajánlatoknál minden előre jelzett volumenhez számítsa ki a teljes számlát a kiemelt egységárak összehasonlítása helyett.
A webhookok csökkenthetik a lekérdezéseket, de a számlázást továbbra is ellenőrizni kell
A lekérdezés azt jelenti, hogy az alkalmazás ismételten nyomkövetési információkat kér. A webhook lehetővé teszi, hogy egy szolgáltatás eseményt küldjön az alkalmazásnak, így csökkenti az ismételt lekérdezések szükségességét, amikor az eseményfolyam megfelel a követelményeknek.
Azonban a kevesebb lekérdezési kérés nem jelenti automatikusan az alacsonyabb számlát. Ellenőrizze, hogy a webhook-kézbesítés tartalmazza-e az ár, mérik-e a kézbesítéseket vagy az újrapróbálkozásokat, illetve szükség van-e továbbra is egyeztető lekérdezésekre. Az alkalmazásnak biztonságosan kell kezelnie a duplikált vagy sorrenden kívül érkező eseményeket, és helyre kell állnia a kézbesítési hibákból.
Van egy másik különbség is, amelyet érdemes megőrizni: az információ gyakoribb lekérése nem garantálja, hogy az alapul szolgáló fuvarozó új szkennelést végzett. A lekérdezési gyakoriság kifizetése előtt kérdezze meg, mit ad vissza egy lekérdezés, és hogyan működik az adatok frissítése.
A kiemelt egységár által elrejthető költségek
Beépített engedmények, minimumok és előre fizetett egyenlegek
Különböztesse meg a minimális számlát a felhasználást tartalmazó előfizetéstől. A minimális számla kiadási alsó határt állapíthat meg; az engedmény meghatározott mennyiséget fedezhet, mielőtt túllépési díjak lépnek életbe. Az előre fizetett kreditek külön kérdéseket vetnek fel a lejárattal, a visszatérítésekkel és a fel nem használt egyenlegekkel kapcsolatban.
Olyan csomag esetén, amelynél az engedményeket a túllépések előtt vonják le, hasznos képlet:
API-számla = fix csomagdíj + díjköteles túllépés + alkalmazandó kiegészítők
Csak akkor használja ezt a képletet, ha megfelel a szerződésnek. Ne számolja kétszer ugyanazt a benne foglalt használatot, és ne feltételezze, hogy minden csomag ugyanúgy alkalmaz határköltség-alapú árazást.
Hosszú ideig futó küldemények és ismételt regisztrációk
A hosszú megfigyelési időszakok növelik a lekérdezések számát egy lekérdezésen alapuló kialakításban. Küldeményenkénti árazás esetén az a releváns kérdés, hogy az eredeti díj fedezi-e ezt az időtartamot. Ne csak a gyorsan célba érő küldeményeket vizsgálja, hanem a kivételeket és a késedelmes küldeményeket is.
Azt is erősítse meg, mi történik, ha ugyanazt a nyomkövetési számot kétszer küldik be, kijavítják, törlik és újra hozzáadják, vagy más fuvarozóhoz kapcsolják. Ahol megfelelő, valósítson meg duplikációmegelőzést, de ne feltételezze, hogy az alkalmazásszintű duplikációszűrés tökéletesen megfelel a szolgáltató számlázási identitásának.
Rate limitek és csúcskapacitás
A megfizethető havi engedmény nem garantálja, hogy az integráció képes kezelni egy nagy importot vagy forgalmi csúcsot. Ellenőrizze a kérési sebesség korlátait, a kötegkorlátokat, a párhuzamossági korlátozásokat és a korlátok elérésekor várható működést. Az a csomag, amely megfelel a havi volumennek, de nem támogatja a szükséges munkafolyamatot, nem valódi alternatíva.
Mérnöki és üzemeltetési költségek
Az API-számlát tartsa külön a teljes tulajdonlási költségtől. A belső kiadások magukban foglalhatják az integráció fejlesztését, a webhookok üzemeltetését, a sorokat, a megfigyelést, az incidenskezelést, az adattárolást és a karbantartást.
Használja saját munkaerő- és infrastruktúrabecsléseit. Egy drágább előfizetés is lehet gazdaságos, ha bizonyíthatóan csökkenti az üzemeltetési munkát, de ezt a megtakarítást tesztelni kell, nem pedig feltételezni.
Hogyan hasonlítsa össze az ajánlatokat és ellenőrizze a kiválasztott lehetőségeket?
Kérje meg minden szolgáltatót, hogy ugyanarra a munkaterhelési specifikációra adjon árat: csomagvolumen, küldeményösszetétel, megfigyelési időtartam, frissítési követelmények, végpontok, csúcsterhelés és szükséges szolgáltatások. Kérjen írásos magyarázatot a számlázási egységről és egy mintaszámlaszámítást.
A 17TRACK-et fontolgató csapatok számára a hivatalos Tracking API-oldal és az API-dokumentáció a megfelelő kiindulópont a termék- és integrációértékeléshez. A modell előrejelzésbe történő beillesztése előtt közvetlenül erősítse meg az alkalmazandó árakat és számlázási definíciókat. Ez a cikk nem közöl és nem minősít aktuális 17TRACK-csomagot.
Elköteleződés előtt végezzen ellenőrzött pilotot reprezentatív küldeményekkel. Tartalmazzon megosztott rendeléseket, duplikált beküldéseket, késedelmes csomagokat, határokon átnyúló mozgásokat és olyan küldeményeket, amelyek átlépnek egy számlázási határt. Sikertelen vagy újrapróbálkozási viselkedést csak a szolgáltatás által engedélyezett módon teszteljen.
- Hasonlítsa össze a kérési naplókat a szolgáltató használati nyilvántartásaival.
- Egyeztesse a regisztrált nyomkövetési egységeket a számlázott küldeményegységekkel.
- Ellenőrizze, hogy a szükséges frissítési ütemezés ténylegesen megvalósul-e.
- A csúcskeresletet a havi fogyasztástól külön mérje.
- Vizsgálja ki a megmagyarázhatatlan eltéréseket, mielőtt költségeket vetítene előre.
Készítsen legalább három előrejelzést: normál működésre, szezonális csúcsra és elhúzódó szállításra. Az alapul szolgáló tényezőket változtassa, ne önkényes százalékot adjon a számlához. Például a csúcsidőszakra modellezzen több csomagot, a késedelmi forgatókönyvre pedig hosszabb megfigyelési időtartamot.
Melyik modellt válassza?
Részesítse előnyben a hívásonkénti árazást, ha a lekérdezések ritkák, a kérésigény mérhető, és az előrejelzés a regisztrációk és egyéb számlázható tevékenységek figyelembevétele után a fedezeti pont alatt marad. Kevésbé vonzó, ha a gyakori lekérdezés vagy a kiszámíthatatlan megfigyelési időtartam jelentős kérési kitettséget hoz létre.
Részesítse előnyben a küldeményenkénti árazást, ha folyamatos megfigyelésre van szükség, és az ajánlott küldeménydíj tartalmazza a szükséges frissítési gyakoriságot, nyomkövetési időtartamot és kézbesítési módot. Kevésbé vonzó, ha olyan megfigyelésért fizet, amelyet ritkán használ, vagy ha a küldemény definíciója váratlan további egységeket hoz létre.
A végső döntésnek a működési csomagonkénti teljes költséget kell használnia: az API-számla és a hozzárendelhető üzemeltetési költségek összege osztva azzal az egyedi csomagszámmal, amelyet vállalkozásának figyelnie kell. Tartsa következetesen ugyanazt a belső csomagdefiníciót az ajánlatok között, még akkor is, ha a szolgáltatók eltérő számlázási egységeket használnak.
GYIK
Számlázhatók a sikertelen API-kérések?
Ne feltételezze egyik lehetőséget sem. Kérdezze meg, hogyan kezelik az ellenőrzési hibákat, hitelesítési hibákat, rate-limit válaszokat, szerverhibákat és időtúllépéseket. Egy időtúllépés azt is bizonytalanná teheti, hogy a kérés feldolgozása megtörtént-e, mielőtt az alkalmazás újrapróbálkozott.
Mindig egy küldeménynek számít egy rendelés?
Nem. Egy rendelés több, külön nyomon követett csomagot is tartalmazhat. Költségvetés készítésekor képezze le a rendeléseket nyomkövetési egységekre, majd alkalmazza a szolgáltató definícióját. Erősítse meg, hogyan számítják a visszaküldéseket, a csereküldeményeket és a fuvarozói átadásokat.
A kötegelt kérések csökkentik a számlámat?
Csak akkor, ha a számlázási szabályok jutalmazzák a kötegelt feldolgozást. A kötegek csökkenthetik a hálózati kérések számát anélkül, hogy csökkentenék a díjköteles nyomkövetési egységek számát. Ellenőrizze a kötegkorlátot, valamint hogy a számlázás kérésenként, elemenként vagy súlyozott egységen keresztül történik-e.
A webhookok megszüntethetik az összes lekérdezési kérést?
Jelentős mennyiségű rutinszerű lekérdezést eltávolíthatnak, de a kialakításnak továbbra is szüksége lehet kezdeti lekérésre, a kihagyott események utáni helyreállításra vagy időszakos egyeztetésre. Ezeket a hívásokat is vegye fel a becslésbe, és erősítse meg a webhook-kézbesítés esetleges díjait.
Hogyan tervezzek költségvetést a jövő hónapban is aktív küldeményekre?
Hívásonkénti árazás esetén jelezze előre, milyen kéréseket generálnak ezek a küldemények a következő időszakban. Küldeményenkénti árazásnál erősítse meg, hogy a megfigyelés továbbra is fedezett-e, vagy újabb díjat vált ki. A folyamatban lévő munkaterhelés becslésekor ne csak az újonnan létrehozott küldeményeket számolja.
Források
A fenti számítások kifejezetten hipotetikus bemeneti adatokon, nem pedig közzétett szolgáltatói árakon alapulnak. A 17TRACK értékeléséhez használja ezeket a hivatalos referenciaoldalakat, és közvetlenül erősítse meg a kereskedelmi feltételeket:
