Tracking API:n hinnoittelumallit selitettynä: kutsukohtainen vs. lähetyskohtainen ja kuinka arvioida todelliset kustannuksesi
Puhelukohtaisen seuranta-API:n hinnoittelu veloittaa laskutettavista pyynnöistä; lähetyskohtainen hinnoittelu veloittaa määritellystä seurannan yksiköstä, kuten rekisteröidystä seurantanumerosta. Kumpikaan ei ole automaattisesti edullisempi. Arvioi todelliset kustannuksesi vertaamalla molempia malleja samaa lähetysmäärää, päivitystarpeita, seurannan kestoa ja laskutussääntöjä vasten ja lisää sen jälkeen alustamaksut, ylitysmaksut ja integraatiokustannukset.
Tekniikan, operaatioiden ja hankinnan tiimeille hyödyllinen vertailu ei ole yksinkertaisesti hinta puhelua tai lähetystä kohden. Olennaista on niiden kokonaiskustannusten arviointi, joita yrityksesi tarvitsee lähetysnäkyvyyden tuottamiseen. Alhainen pyyntömäärä voi tulla kalliiksi tiheän kyselyn vuoksi, kun taas alhainen lähetysmäärä voi olla harhaanjohtava, jos seurantaikkuna tai palveluihin sisältyvät ominaisuudet eivät sovi työnkulkuusi.
Mitä kukin hinnoittelumalli todella mittaa
Ensimmäinen vaihe on erottaa kolme asiaa: API-pyyntö, lähetyksen rekisteröinti ja seurannan päivitys. Ne ovat eri tapahtumia, ja sopimuksessa voidaan määrittää kullekin erilainen laskutuskäsittely.
| Vertailukohta | Puhelukohtainen hinnoittelu | Lähetyskohtainen hinnoittelu |
|---|---|---|
| Laskutusperuste | Laskutettaviksi määritellyt pyynnöt tai pyyntöyksiköt | Laskutettaviksi määritellyt lähetysyksiköt |
| Pääasiallinen kustannustekijä | Kuinka usein sovellus tekee veloitettavia pyyntöjä | Kuinka monta veloitettavaa seurannan yksikköä kuuluu piiriin tai pysyy sen piirissä |
| Selvitettävä laskutuskysymys | Mitkä päätepisteet, vastaukset ja eräajon kohteet lasketaan? | Mikä muodostaa yhden lähetyksen ja kuinka kauan seuranta sisältyy hintaan? |
| Mahdollinen kustannusriski | Toistuvat kyselyt, uudelleenyritykset ja tarpeettomat haut | Kaksoisrekisteröinnit, useat paketit ja seurantaikkunan rajoitukset |
| Sopivin käyttötapa tietyin ehdoin | Harvatahtiset haut, joiden pyyntömäärää hallitaan | Jatkuva seuranta, kun päivitykset sisältyvät lähetysmaksuun |
Puhelukohtainen hinnoittelu ei välttämättä tarkoita, että jokainen HTTP-pyyntö maksaa saman verran
Tarjouksessa on yksilöitävä laskutettavat päätepisteet ja niiden yksiköt. Seurantanumeron rekisteröinti, tallennettujen tulosten hakeminen, päivityspyynnöt ja tilausten hallinta voidaan käsitellä eri tavoin. Älä oleta, että epäonnistunut pyyntö on maksuton tai että onnistunut pyyntö on aina veloitettava.
Myös eräajolle tarvitaan selkeä määritelmä. Yksi pyyntö, joka sisältää 100 seurantanumeroa, voidaan laskea yhdeksi pyynnöksi, 100 seurannan yksiköksi tai joksikin muuksi sopimuksessa määritellyksi määräksi. Verkkoliikenteen vähentäminen ei merkitse laskutussäästöä, elleivät mittaussäännöt tue sitä.
Lähetyskohtainen hinnoittelu ei välttämättä tarkoita tilaushintaista hinnoittelua
Verkkokauppatilaus voi tuottaa useita paketteja. Jos veloitettava yksikkö on seurantanumero, jaettu tilaus voi kuluttaa useita yksiköitä. Myös palautukset, korvaavat lähetykset ja kuljetusliikkeen vaihdokset on käsiteltävä selkeästi.
Selvitä, kattaako maksu seurannan tietyn ajanjakson ajan, tiettyyn päätöstapahtumaan asti vai jonkin muun rajoituksen puitteissa. Selvitä myös, aiheuttavatko jo rekisteröidyt lähetykset uusia maksuja myöhemmällä laskutuskaudella. Nämä yksityiskohdat ovat tärkeämpiä kuin hinnoittelusuunnitelman nimi.
Arvioi kustannukset työnkulkusi, ei vain tilaustesi määrän perusteella
Käytä edustavaa toimintajaksoa ja laadi ennuste lähetystason tietojen perusteella. Ota mukaan sekä uudet lähetykset että vanhemmat lähetykset, joita on edelleen seurattava. Jos tietosi ovat puutteelliset, tuo oletukset näkyviin sen sijaan, että esittäisit tuloksen tarkkana tarjouksena.
- Laske seurattavat paketit. Aloita yksilöllisistä pakettien seurantayksiköistä, älä kassavaiheen tilauksista. Pidä lähtevät paketit, palautukset ja korvaavat lähetykset erillään, kunnes niiden laskutuskäsittely on vahvistettu.
- Mittaa seurannan kesto. Arvioi, kuinka kauan kukin lähetys tarvitsee päivityksiä, mukaan lukien tarvittaessa kuljetusta edeltävät ja poikkeustilanteiden jaksot.
- Määritä tarvittava päivitystiheys. Määritä, kuinka usein sovelluksesi tarvitsee tuoreita tietoja ja muuttuuko tämä lähetyksen tilan mukaan.
- Kartoita API-työnkulku. Luettele rekisteröinnit, tulosten haut, päivityspyynnöt, korjaukset, uudelleenyritykset ja kaikki muut päätepisteet, joita integraatiosi käyttää.
- Sovella laskutussääntöjä. Muunna tekninen toiminta laskutettaviksi puheluiksi tai lähetysyksiköiksi ehdotetun sopimuksen mukaisesti.
- Lisää käyttöön liittymättömät maksut. Ota mukaan sovellettava tilausmaksu, vähimmäissitoumus, valinnaiset palvelut sekä käyttöönotto- ja käyttökustannukset.
Yksinkertaisessa kyselyintegraatiossa, jossa jokaisessa haussa on yksi seurantanumero, lähtöarvio on:
Hakupyynnöt = seurattavat lähetykset × seurannan keskimääräinen kesto päivinä × haut päivässä
Tämä oikopolku olettaa, että jokainen lähetys noudattaa samaa keskimääräistä aikataulua. Tarkempi malli summaa kunkin lähetyksen tai lähetysryhmän pyynnöt ja lisää sitten rekisteröintikutsut sekä muun laskutettavan toiminnan. Jos lähetykset pysyvät aktiivisina kuukauden vaihtuessa, kohdista niiden pyynnöt niille laskutuskausille, joiden aikana pyynnöt tehdään.
Laskentaesimerkki: milloin edullisempi malli vaihtuu
Seuraavat luvut on keksitty ainoastaan laskennan havainnollistamiseksi. Ne eivät ole 17TRACKin hintoja, toimittajien tarjouksia tai markkinavertailuarvoja.
Oletetaan, että 10 000 pakettia rekisteröidään ja seurataan kokonaan saman mallinnetun ajanjakson aikana. Jokainen vaatii yhden rekisteröintipyynnön ja kolme hakupyyntöä päivässä kahdeksan päivän ajan. Oletetaan, että jokainen pyyntö on laskutettava, jokainen pyyntö koskee yhtä pakettia eikä uudelleenyrityksiä, eräalennuksia, hyvityksiä tai kiinteitä maksuja ole.
- Rekisteröintipyynnöt: 10 000.
- Hakupyynnöt: 10 000 × 8 × 3 = 240 000.
- Laskutettavia pyyntöjä yhteensä: 250 000.
- Esimerkinomainen puhelukohtainen hinta: 0,002 $.
- Esimerkinomainen lähetyskohtainen hinta: 0,04 $, sisältäen vaaditun seurannan.
Puhelukohtainen käyttökustannus on 250 000 × 0,002 $ = 500 $. Lähetyskohtainen käyttökustannus on 10 000 × 0,04 $ = 400 $. Näillä oletuksilla lähetyskohtainen hinnoittelu maksaa käytöstä 100 $ vähemmän.
Muuta nyt ainoastaan hakutiheys yhteen kertaan päivässä. Pyyntömääräksi tulee 10 000 rekisteröintiä plus 80 000 hakua eli 90 000 puhelua. Puhelukohtainen käyttökustannus laskee 180 dollariin, kun taas esimerkinomainen lähetyskohtainen käyttökustannus pysyy 400 dollarissa. Suositeltava malli vaihtuu, koska työmäärä muuttuu, ei siksi, että jompikumpi hinnoittelurakenne olisi luonnostaan parempi.
Etsi kannattavuusraja
Kun kummassakaan suunnitelmassa ei ole kiinteitä maksuja, hyvityksiä tai lisämaksuja, käytä kaavaa:
Laskutettavien puheluiden kannattavuusraja lähetystä kohden = lähetyshinta ÷ puheluhinta
Esimerkissä 0,04 $ ÷ 0,002 $ on 20 laskutettavaa puhelua lähetystä kohden. Yli 20 puhelulla lähetysmaksu on edullisempi; alle 20 puhelulla puhelumaksu on edullisempi. Esimerkin oletusten mukaan rekisteröintipuhelut lasketaan mukaan tähän rajaan.
Tämä oikopolku ei riitä porrastettuihin suunnitelmiin, ennakkoon maksettuihin krediitteihin, eri päätepisteiden hintoihin tai vähimmäissitoumuksiin. Laske tällöin koko lasku jokaisella ennustetulla käyttömäärällä sen sijaan, että vertaisit otsikkotason yksikköhintoja.
Webhookit voivat vähentää kyselyä, mutta laskutus on silti varmistettava
Kysely tarkoittaa, että sovelluksesi pyytää seurantatietoja toistuvasti. Webhookin avulla palvelu voi lähettää tapahtuman sovelluksellesi, mikä vähentää toistuvien hakujen tarvetta, kun tapahtumavirta vastaa tarpeitasi.
Harvemmat hakupyynnöt eivät kuitenkaan automaattisesti tarkoita pienempää laskua. Varmista, sisältyykö webhookien toimitus hintaan, mitataanko toimituksia tai uudelleenyrityksiä ja tarvitaanko täsmäytyshakuja edelleen. Sovelluksesi on myös käsiteltävä päällekkäiset tai väärässä järjestyksessä tulevat tapahtumat turvallisesti ja palaututtava toimitusvirheistä.
On tärkeää erottaa myös seuraavat asiat: tietojen pyytäminen useammin ei takaa, että taustalla oleva kuljetusliike on tuottanut uuden skannauksen. Selvitä ennen maksamista, mitä haku palauttaa ja miten tietojen päivitys toimii, jotta et maksa kyselytiheydestä, joka tuottaa vain vähän operatiivista hyötyä.
Kustannukset, jotka otsikkotason hinta voi peittää
Sisältyvät hyvitykset, vähimmäismaksut ja ennakkomaksut
Erota vähimmäislasku tilauksesta, joka sisältää käyttöä. Vähimmäislasku voi määrittää vähimmäisveloituksen; hyvitys voi kattaa tietyn määrän ennen ylitysmaksujen soveltamista. Ennakkoon maksetut krediitit tuovat erillisiä kysymyksiä vanhenemisesta, hyvityksistä ja käyttämättömistä saldoista.
Suunnitelmassa, jossa hyvitys vähennetään ennen ylityksiä, hyödyllinen rakenne on:
API-lasku = kiinteä suunnitelmamaksu + laskutettava ylitys + sovellettavat lisäpalvelut
Käytä tätä kaavaa vain, jos se vastaa sopimusta. Älä lisää samaa sisältyvää käyttömäärää kahdesti tai oleta, että kaikki suunnitelmat soveltavat marginaalihinnoittelua samalla tavalla.
Pitkäkestoiset lähetykset ja toistuvat rekisteröinnit
Pitkät seuranta-ajat lisäävät kyselymallissa hakujen määrää. Lähetyskohtaisessa hinnoittelussa olennainen kysymys on, kattaako alkuperäinen maksu kyseisen keston. Testaa poikkeukset ja viivästyneet lähetykset, ei ainoastaan nopeasti päättyviä toimituksia.
Varmista myös, mitä tapahtuu, kun sama seurantanumero lähetetään kahdesti, korjataan, poistetaan ja lisätään uudelleen tai yhdistetään eri kuljetusliikkeeseen. Ota käyttöön kaksoiskappaleiden esto tarvittaessa, mutta älä oleta, että sovellustason kaksoiskappaleiden poisto vastaa täydellisesti toimittajan laskutuksessa käyttämää identiteettiä.
Taajuusrajat ja huippukapasiteetti
Edullinen kuukausittainen hyvitys ei takaa, että integraatio pystyy käsittelemään suurta tuontia tai liikennepiikkiä. Tarkista pyyntötaajuuden rajat, erärajat, samanaikaisuuden rajoitukset ja odotettu toiminta rajojen saavuttamisen jälkeen. Suunnitelma, joka täyttää kuukausittaisen määrän mutta ei tue vaadittua työnkulkua, ei ole aidosti vertailukelpoinen vaihtoehto.
Tekniikan ja käytön kustannukset
Pidä API-lasku erillään kokonaisomistuskustannuksista. Sisäisiin kuluihin voivat kuulua integraation kehitys, webhookien isännöinti, jonot, valvonta, häiriötilanteiden hallinta, tietojen tallennus ja ylläpito.
Käytä omia työ- ja infrastruktuuriarvioitasi. Kalliimpi tilaus voi silti olla taloudellinen, jos se todistetusti vähentää operatiivista työtä, mutta säästö on testattava eikä sitä pidä olettaa.
Tarjousten vertailu ja ehdokkaiden validointi
Pyydä jokaista toimittajaa hinnoittelemaan sama työkuvaus: pakettimäärä, lähetysvalikoima, seurannan kesto, päivitystarpeet, päätepisteet, huippukuormitus ja tarvittavat palvelut. Pyydä kirjallinen selvitys laskutusyksiköstä ja esimerkkilaskelma laskusta.
17TRACKia harkitseville tiimeille virallinen Tracking API -sivu ja API-dokumentaatio ovat olennaiset lähtökohdat tuotteen ja integraation arviointiin. Vahvista sovellettavat hinnat ja laskutusmääritelmät suoraan ennen mallin määrittämistä ennusteeseen. Tässä artikkelissa ei esitetä eikä luokitella nykyistä 17TRACK-suunnitelmaa.
Suorita ennen sitoutumista hallittu pilotti edustavilla lähetyksillä. Ota mukaan jaetut tilaukset, kaksoislähetykset, viivästyneet paketit, rajat ylittävät kuljetukset ja lähetykset, jotka ylittävät laskutusrajan. Testaa vika- tai uudelleenyrityskäyttäytymistä vain palvelun sallimilla tavoilla.
- Vertaa pyyntölokejasi toimittajan käyttötietoihin.
- Täsmäytä rekisteröidyt seurannan yksiköt laskutettuihin lähetysyksiköihin.
- Tarkista, saavutetaanko vaadittu päivitystiheys käytännössä.
- Mittaa huippukysyntä erikseen kuukausikulutuksesta.
- Selvitä selittämättömät erot ennen kustannusten ekstrapolointia.
Laadi vähintään kolme ennustetta: normaali toiminta, kausihuippu ja pitkittynyt kuljetus. Muuta taustalla olevia tekijöitä sen sijaan, että lisäisit laskuun mielivaltaisen prosenttiosuuden. Mallinna esimerkiksi suurempi pakettimäärä huippua varten ja pidempi seurannan kesto viivästystilannetta varten.
Kumpi malli kannattaa valita?
Suosi puhelukohtaista hinnoittelua, kun haut ovat harvinaisia, pyyntötarve on mitattavissa ja ennuste pysyy kannattavuusrajan alapuolella, kun rekisteröinnit ja muu laskutettava toiminta on otettu mukaan. Se on vähemmän houkutteleva, kun tiheä kysely tai ennakoimaton seurannan kesto aiheuttaa merkittävän pyyntöriskin.
Suosi lähetyskohtaista hinnoittelua, kun jatkuvaa seurantaa tarvitaan ja tarjottu lähetysmaksu sisältää tarvitsemasi päivitystiheyden, seurannan keston ja toimitustavan. Se on vähemmän houkutteleva, kun maksat seurannasta, jota käytät harvoin, tai kun lähetyksen määritelmä tuottaa odottamattomia lisäyksiköitä.
Lopullisen päätöksen tulisi perustua operatiivisen paketin kokonaiskustannukseen: API-lasku ja kohdistettavat käyttökustannukset jaettuna niiden yksilöllisten pakettien määrällä, joita yrityksesi tarvitsee seurata. Pidä tämä sisäinen pakettimääritelmä samana kaikissa tarjouksissa, vaikka toimittajat käyttäisivät eri laskutusyksiköitä.
UKK
Ovatko epäonnistuneet API-pyynnöt laskutettavia?
Älä oleta kumpaakaan vaihtoehtoa. Kysy validointivirheiden, todennusvirheiden, taajuusrajavastausten, palvelinvirheiden ja aikakatkaisujen käsittelystä. Aikakatkaisu voi myös aiheuttaa epävarmuutta siitä, käsiteltiinkö pyyntö ennen kuin sovelluksesi yritti uudelleen.
Lasketaanko yksi tilaus aina yhdeksi lähetykseksi?
Ei. Tilaus voi sisältää useita erikseen seurattavia paketteja. Budjetointia varten yhdistä tilaukset seurantayksiköihin ja sovella sen jälkeen toimittajan määritelmää. Vahvista, miten palautukset, korvaavat lähetykset ja kuljetusliikkeen vaihdokset lasketaan.
Vähentävätkö eräpyynnöt laskuani?
Vain jos laskutussäännöt suosivat eräajoa. Eräajot voivat vähentää verkkopyyntöjä ilman, että laskutettavien seurannan yksiköiden määrä vähenee. Tarkista eräraja ja se, sovelletaanko laskutusta pyyntöä, kohdetta vai painotettua yksikköä kohden.
Voivatko webhookit poistaa kaikki hakupyynnöt?
Ne voivat poistaa suuren osan rutiininomaisesta kyselystä, mutta suunnittelusi saattaa silti tarvita alkuperäisen haun, palautumisen väliin jääneistä tapahtumista tai säännöllisen täsmäytyksen. Ota nämä kutsut mukaan arvioon ja vahvista webhookien toimitukseen liittyvät maksut.
Miten budjetoin ensi kuussa edelleen aktiiviset lähetykset?
Puhelukohtaisessa hinnoittelussa ennusta pyynnöt, joita kyseiset lähetykset tuottavat seuraavalla kaudella. Lähetyskohtaisessa hinnoittelussa vahvista, pysyykö seuranta katettuna vai aiheuttaako se uuden maksun. Älä laske jatkuvaa työmäärää arvioidessasi vain uusia lähetyksiä.
Lähteet
Edellä esitetyissä laskelmissa käytetään nimenomaisesti hypoteettisia syötteitä, ei julkaistuja toimittajahintoja. Käytä 17TRACK-arviointiin näitä virallisia viitesivuja ja vahvista kaupalliset ehdot suoraan:
