Skip to main content
HjemBloggPrismodeller for Tracking API forklart: per kall vs. per forsendelse og hvordan du beregner den faktiske kostnaden din

Prismodeller for Tracking API forklart: per kall vs. per forsendelse og hvordan du beregner den faktiske kostnaden din

17TRACK

Prising per API-kall belaster fakturerbare forespørsler; prising per forsendelse belaster en definert sporingsenhet, for eksempel et registrert sporingsnummer. Ingen av dem er automatisk billigere. For å anslå den faktiske kostnaden din bør du sammenligne begge modellene mot samme forsendelsesvolum, oppdateringskrav, sporingsvarighet og faktureringsregler, og deretter legge til plattformavgifter, overforbruk og integrasjonskostnader.

Tracking API Pricing Models Explained Per Call vs Per Shipment

For utviklings-, drifts- og innkjøpsteam er den nyttige sammenligningen ikke bare pris per kall kontra pris per forsendelse. Det er den totale kostnaden ved å levere den forsendelsessynligheten virksomheten trenger. En lav forespørselsrate kan bli dyr ved hyppig polling, mens en lav forsendelsesrate kan være misvisende hvis sporingsvinduet eller de inkluderte tjenestene ikke passer arbeidsflyten.

Hva hver prismodell faktisk måler

Det første steget er å skille mellom tre ting: en API-forespørsel, registrering av en forsendelse og en sporingsoppdatering. Dette er forskjellige hendelser, og en avtale kan gi hver av dem ulik faktureringsbehandling.

SammenligningspunktPrising per kallPrising per forsendelse
FaktureringsgrunnlagForespørsler eller forespørselsenheter definert som fakturerbareForsendelsesenheter definert som fakturerbare
Viktigste kostnadsdriverHvor ofte applikasjonen foretar belastbare forespørslerHvor mange belastbare sporingsenheter som omfattes eller forblir innenfor avtalen
Faktureringsspørsmål som må avklaresHvilke endepunkter, svar og batch-elementer teller?Hva utgjør én forsendelse, og hvor lenge er sporing inkludert?
Mulig kostnadseksponeringGjentatt polling, nye forsøk og unødvendige oppslagDupliserte registreringer, flere pakker og begrensninger i sporingsvinduet
Beste betingede egnethetOppslag med lav frekvens og kontrollert forespørselsvolumLøpende overvåking når oppdateringer er inkludert i forsendelsesavgiften

Prising per kall betyr ikke nødvendigvis at alle HTTP-forespørsler koster det samme

Et pristilbud må identifisere de fakturerbare endepunktene og enhetene deres. Registrering av et sporingsnummer, henting av lagrede resultater, forespørsel om oppdatering og administrasjon av abonnementer kan behandles forskjellig. Ikke anta at en mislykket forespørsel er gratis, eller at en vellykket forespørsel alltid er belastbar.

Batching må også defineres uttrykkelig. Én forespørsel som inneholder 100 sporingsnumre, kan telle som én forespørsel, 100 sporingsenheter eller en annen kontraktsfestet mengde. Redusert nettverkstrafikk gir ikke i seg selv en besparelse på faktureringen med mindre målereglene støtter det.

Prising per forsendelse betyr ikke nødvendigvis per ordre

En e-handelsordre kan resultere i flere pakker. Hvis den belastbare enheten er et sporingsnummer, kan en delt ordre bruke flere enheter. Returer, erstatningsforsendelser og overleveringer mellom transportører må også behandles tydelig.

Spør om avgiften kjøper sporing for en bestemt periode, frem til en definert fullførelseshendelse eller under en annen begrensning. Avklar også om allerede registrerte forsendelser medfører nye kostnader i en senere faktureringsperiode. Disse detaljene er viktigere enn betegnelsen på prisplanen.

Beregn kostnaden ut fra arbeidsflyten, ikke bare ordreantallet

Bruk en representativ driftsperiode og lag en prognose basert på data på forsendelsesnivå. Ta med både nye forsendelser og eldre forsendelser som fortsatt krever overvåking. Hvis dataene dine er ufullstendige, bør du synliggjøre antakelsene i stedet for å presentere resultatet som et nøyaktig pristilbud.

  1. Tell sporbare pakker. Start med unike sporingsenheter for pakker, ikke utsjekkingsordrer. Hold utgående pakker, returer og erstatninger adskilt til faktureringsbehandlingen er bekreftet.
  2. Mål overvåkingsvarigheten. Beregn hvor lenge hver forsendelse trenger oppdateringer, inkludert perioder før transport og perioder med avvik der det er relevant.
  3. Definer nødvendig oppdateringsfrekvens. Angi hvor ofte applikasjonen trenger ny informasjon, og om dette varierer etter forsendelsesstatus.
  4. Kartlegg API-arbeidsflyten. List opp registreringer, resultatoppslag, oppdateringsforespørsler, korrigeringer, nye forsøk og eventuelle andre endepunkter integrasjonen skal bruke.
  5. Bruk faktureringsreglene. Konverter teknisk aktivitet til fakturerbare kall eller forsendelsesenheter ved hjelp av den foreslåtte avtalen.
  6. Legg til ikke-bruksbaserte kostnader. Inkluder relevant abonnement, minimumsforpliktelse, valgfrie tjenester samt implementerings- eller driftskostnader.

For en enkel polling-integrasjon med ett sporingsnummer per oppslag er det innledende anslaget:

Oppslagsforespørsler = overvåkede forsendelser × gjennomsnittlig antall overvåkede dager × oppslag per dag

Denne snarveien forutsetter at alle forsendelser følger samme gjennomsnittlige tidsplan. En mer nøyaktig modell summerer forespørslene for hver forsendelse eller forsendelseskohort, og legger deretter til registreringskall og annen fakturerbar aktivitet. Hvis forsendelser forblir aktive over månedsskiftet, skal forespørslene fordeles på faktureringsperiodene der forespørslene finner sted.

Et regneeksempel: når den billigste modellen endres

Følgende tall er oppdiktet utelukkende for å demonstrere beregningen. De er ikke 17TRACK-priser, leverandørtilbud eller markedsreferanser.

Anta at 10 000 pakker registreres og overvåkes fullt ut innenfor den samme modellerte perioden. Hver krever én registreringsforespørsel og tre oppslagsforespørsler per dag i åtte dager. Anta at hver forespørsel er fakturerbar, at hver forespørsel gjelder én pakke, og at det ikke finnes nye forsøk, batchrabatter, inkluderte kvoter eller faste avgifter.

  • Registreringsforespørsler: 10 000.
  • Oppslagsforespørsler: 10 000 × 8 × 3 = 240 000.
  • Totalt antall fakturerbare forespørsler: 250 000.
  • Illustrativ pris per kall: $0.002.
  • Illustrativ pris per forsendelse: $0.04, inkludert nødvendig overvåking.

Brukskostnaden per kall er 250 000 × $0.002 = $500. Brukskostnaden per forsendelse er 10 000 × $0.04 = $400. Under disse forutsetningene koster prising per forsendelse $100 mindre i bruk.

Endre nå bare oppslagsfrekvensen til én gang per dag. Antall forespørsler blir 10 000 registreringer pluss 80 000 oppslag, altså 90 000 kall. Brukskostnaden per kall synker til $180, mens den illustrerte brukskostnaden per forsendelse fortsatt er $400. Den foretrukne modellen endres fordi arbeidsmengden endres, ikke fordi en av prismodellene i seg selv er bedre.

Finn balansepunktet

Når ingen av planene har faste kostnader, inkluderte kvoter eller ekstragebyrer, bruker du:

Fakturerbare kall per forsendelse ved balansepunktet = forsendelsespris ÷ kallpris

I eksempelet er $0.04 ÷ $0.002 lik 20 fakturerbare kall per forsendelse. Over 20 kall er forsendelsesavgiften lavere; under 20 er kallavgiften lavere. Registreringskall teller med i denne terskelen under forutsetningene i eksempelet.

Denne snarveien er ikke tilstrekkelig for trinnvise planer, forhåndsbetalte kreditter, ulike endepunktpriser eller minimumsforpliktelser. For slike tilbud bør du beregne hele fakturaen ved hvert prognostiserte volum i stedet for å sammenligne oppgitte enhetspriser.

Webhooks kan redusere polling, men faktureringen må fortsatt bekreftes

Polling betyr at applikasjonen gjentatte ganger ber om sporingsinformasjon. En webhook gjør det mulig for en tjeneste å sende en hendelse til applikasjonen, slik at behovet for gjentatte oppslag reduseres når hendelsesstrømmen oppfyller kravene dine.

Færre oppslagsforespørsler betyr imidlertid ikke automatisk en lavere faktura. Bekreft om webhook-levering er inkludert, om leveringer eller nye forsøk måles, og om det fortsatt er nødvendig med avstemmingsoppslag. Applikasjonen må også håndtere dupliserte eller feilrekkefølgebaserte hendelser på en sikker måte og kunne gjenopprette etter leveringsfeil.

Det finnes et annet skille som er viktig å opprettholde: Hyppigere informasjonsforespørsler garanterer ikke at den underliggende transportøren har produsert en ny skanning. Spør hva et oppslag returnerer og hvordan dataoppdatering fungerer før du betaler for en pollingfrekvens som kan gi liten operasjonell verdi.

Kostnader som en oppgitt pris kan skjule

Inkluderte kvoter, minimumsbeløp og forhåndsbetalte saldoer

Skill mellom en minimumsfaktura og et abonnement med inkludert bruk. En minimumsfaktura kan fastsette et minimumsnivå for kostnadene; en kvote kan dekke en bestemt mengde før overforbruksgebyrer gjelder. Forhåndsbetalte kreditter medfører separate spørsmål om utløp, refusjoner og ubrukte saldoer.

For en plan der kvoten trekkes fra før overforbruk faktureres, er en nyttig struktur:

API-faktura = fast planavgift + fakturerbart overforbruk + gjeldende tillegg

Bruk bare denne formelen hvis den samsvarer med avtalen. Ikke legg til samme inkluderte bruk to ganger, og ikke anta at alle planer bruker marginalprising på samme måte.

Langvarige forsendelser og gjentatte registreringer

Lange overvåkingsperioder øker oppslagsvolumet i en pollingmodell. Ved prising per forsendelse er det relevante spørsmålet om den opprinnelige avgiften dekker denne varigheten. Test avvik og forsinkede forsendelser, ikke bare leveranser som fullføres raskt.

Bekreft også hva som skjer når det samme sporingsnummeret sendes inn to ganger, korrigeres, slettes og legges til på nytt eller knyttes til en annen transportør. Implementer forebygging av duplikater der det er hensiktsmessig, men ikke anta at deduplisering på applikasjonsnivå samsvarer perfekt med leverandørens faktureringsidentitet.

Frekvensbegrensninger og kapasitetstopper

En rimelig månedlig kvote betyr ikke at en integrasjon kan håndtere en stor import eller en trafikktopp. Kontroller begrensninger for forespørselsrate, batchgrenser, samtidighetsbegrensninger og forventet atferd når grensene nås. En plan som dekker månedlig volum, men ikke støtter den nødvendige arbeidsflyten, er ikke et reelt alternativ på like vilkår.

Utviklings- og driftskostnader

Hold API-fakturaen adskilt fra de totale eierkostnadene. Interne utgifter kan omfatte integrasjonsutvikling, webhook-hosting, køer, overvåking, hendelseshåndtering, datalagring og vedlikehold.

Bruk egne estimater for arbeid og infrastruktur. Et dyrere abonnement kan fortsatt være økonomisk hvis det påviselig reduserer driftsarbeidet, men besparelsen bør testes og ikke antas.

Slik sammenligner du tilbud og validerer en kortliste

Be hver leverandør prise den samme arbeidsspesifikasjonen: pakkevolum, forsendelsesblanding, overvåkingsvarighet, oppdateringskrav, endepunkter, maksimal belastning og nødvendige tjenester. Be om en skriftlig forklaring av faktureringsenheten og et eksempel på fakturaberegning.

For team som vurderer 17TRACK, er den offisielle Tracking API-siden og API-dokumentasjonen relevante utgangspunkter for produkt- og integrasjonsevaluering. Bekreft gjeldende priser og faktureringsdefinisjoner direkte før du tilordner en modell i prognosen. Denne artikkelen oppgir eller klassifiserer ikke en aktuell 17TRACK-plan.

Før du inngår avtale, bør du gjennomføre en kontrollert pilot med representative forsendelser. Ta med delte ordrer, dupliserte innsendinger, forsinkede pakker, grensekryssende transporter og forsendelser som krysser en faktureringsgrense. Test bare feil- eller forsøksatferd på måter som er tillatt av tjenesten.

  • Sammenlign forespørselsloggene dine med leverandørens bruksregistre.
  • Avstem registrerte sporingsenheter mot fakturerte forsendelsesenheter.
  • Kontroller om den nødvendige oppdateringsfrekvensen faktisk oppnås.
  • Mål maksimal etterspørsel separat fra månedlig forbruk.
  • Undersøk uforklarte forskjeller før du projiserer kostnadene videre.

Lag minst tre prognoser: normal drift, sesongmessig topp og forlenget transport. Endre de underliggende driverne i stedet for å legge en vilkårlig prosentandel til fakturaen. Modellér for eksempel flere pakker for en topp og lengre overvåkingsvarighet i et scenario med forsinkelser.

Hvilken modell bør du velge?

Velg prising per kall når oppslagene er sjeldne, forespørselsbehovet kan måles og prognosen forblir under balansepunktet etter at registreringer og annen fakturerbar aktivitet er inkludert. Den er mindre attraktiv når hyppig polling eller uforutsigbar overvåkingsvarighet skaper betydelig forespørselseksponering.

Velg prising per forsendelse når kontinuerlig overvåking kreves og den oppgitte forsendelsesavgiften inkluderer oppdateringsfrekvensen, sporingsvarigheten og leveringsmekanismen du trenger. Den er mindre attraktiv når du betaler for overvåking du sjelden bruker, eller når forsendelsesdefinisjonen skaper uventede tilleggsenheter.

Den endelige beslutningen bør bruke totalkostnad per operasjonell pakke: API-fakturaen pluss henførbare driftskostnader, delt på de unike pakkene virksomheten trenger å overvåke. Hold den interne pakkedefinisjonen konsekvent på tvers av tilbud, selv når leverandørene bruker ulike faktureringsenheter.

Vanlige spørsmål

Er mislykkede API-forespørsler fakturerbare?

Ikke anta noen av delene. Spør hvordan valideringsfeil, autentiseringsfeil, svar på frekvensbegrensninger, serverfeil og tidsavbrudd behandles. Et tidsavbrudd kan også skape usikkerhet om hvorvidt en forespørsel ble behandlet før applikasjonen forsøkte på nytt.

Teller én ordre alltid som én forsendelse?

Nei. En ordre kan inneholde flere separat sporede pakker. For budsjettering bør du kartlegge ordrer til sporingsenheter og deretter bruke leverandørens definisjon. Bekreft hvordan returer, erstatninger og overleveringer mellom transportører telles.

Vil batchforespørsler redusere fakturaen min?

Bare hvis faktureringsreglene belønner batching. Batcher kan redusere antall nettverksforespørsler uten å redusere fakturerbare sporingsenheter. Bekreft batchgrensen og om faktureringen gjelder per forespørsel, per element eller gjennom en vektet enhet.

Kan webhooks eliminere alle oppslagsforespørsler?

De kan fjerne mye rutinemessig polling, men utformingen din kan fortsatt trenge innledende henting, gjenoppretting etter tapte hendelser eller periodisk avstemming. Ta med disse kallene i estimatet og bekreft eventuelle gebyrer for webhook-levering.

Hvordan bør jeg budsjettere for forsendelser som fortsatt er aktive neste måned?

Ved prising per kall bør du prognostisere forespørslene disse forsendelsene vil generere i neste periode. Ved prising per forsendelse bør du bekrefte om overvåkingen fortsatt er dekket eller utløser en ny kostnad. Ikke tell bare nylig opprettede forsendelser når du estimerer den løpende arbeidsmengden.

Kilder

Beregningene ovenfor bruker uttrykkelig hypotetiske inndata, ikke publiserte leverandørpriser. Ved evaluering av 17TRACK bør du bruke disse offisielle referansesidene og bekrefte kommersielle vilkår direkte:

Loading