Prismodeller för Tracking API förklarade: per anrop kontra per försändelse och hur du uppskattar din faktiska kostnad
Prissättning för spårnings-API per anrop tar betalt för debiterbara förfrågningar; prissättning per försändelse tar betalt för en definierad spårningsenhet, till exempel ett registrerat spårningsnummer. Ingen av modellerna är automatiskt billigare. För att uppskatta din verkliga kostnad bör du jämföra båda modellerna utifrån samma försändelsevolym, uppdateringskrav, spårningsperiod och debiteringsregler och sedan lägga till plattformsavgifter, överskridna volymer och integrationskostnader.
För teknik-, drift- och inköpsteam är den användbara jämförelsen inte bara pris per anrop kontra pris per försändelse. Det handlar om den totala kostnaden för att leverera den försändelsesynlighet som verksamheten behöver. En låg förfrågningsfrekvens kan bli dyr vid frekvent polling, medan en låg försändelseavgift kan vara missvisande om spårningsperioden eller de inkluderade tjänsterna inte passar ert arbetsflöde.
Vad varje prismodell faktiskt mäter
Det första steget är att skilja mellan tre saker: en API-förfrågan, en försändelseregistrering och en spårningsuppdatering. De är olika händelser, och ett avtal kan tillämpa olika debiteringsregler för var och en.
| Jämförelsepunkt | Prissättning per anrop | Prissättning per försändelse |
|---|---|---|
| Debiteringsgrund | Förfrågningar eller förfrågningsenheter som definieras som debiterbara | Försändelseenheter som definieras som debiterbara |
| Huvudsaklig kostnadsdrivare | Hur ofta applikationen gör debiterbara förfrågningar | Hur många debiterbara spårningsenheter som tillkommer eller förblir omfattade |
| Debiteringsfråga som måste klargöras | Vilka endpoints, svar och batchobjekt räknas? | Vad utgör en försändelse och hur länge ingår spårningen? |
| Möjlig kostnadsexponering | Upprepad polling, omförsök och onödiga uppslag | Dubbla registreringar, flera kollin och begränsningar i spårningsperioden |
| Bästa villkorade användningsområde | Uppslag med låg frekvens och kontrollerad förfrågningsvolym | Löpande övervakning när uppdateringar ingår i försändelseavgiften |
Per anrop betyder inte nödvändigtvis att varje HTTP-förfrågan kostar lika mycket
En offert behöver ange vilka endpoints och enheter som är debiterbara. Registrering av ett spårningsnummer, hämtning av lagrade resultat, begäran om en uppdatering och hantering av prenumerationer kan behandlas olika. Anta inte att en misslyckad förfrågan är kostnadsfri eller att en lyckad förfrågan alltid är debiterbar.
Även batchhantering behöver en uttrycklig definition. En förfrågan som innehåller 100 spårningsnummer kan räknas som en förfrågan, 100 spårningsenheter eller någon annan avtalsenlig mängd. Minskad nätverkstrafik innebär inte automatiskt en debiteringsbesparing om inte mätreglerna stödjer det.
Per försändelse betyder inte nödvändigtvis per order
En e-handelsorder kan resultera i flera kollin. Om den debiterbara enheten är ett spårningsnummer kan en delad order förbruka flera enheter. Returer, ersättningsförsändelser och överlämningar mellan transportörer behöver också behandlas tydligt.
Fråga om avgiften gäller spårning under en angiven period, fram till en definierad sluthändelse eller enligt någon annan begränsning. Klargör också om redan registrerade försändelser medför nya avgifter under en senare debiteringsperiod. Dessa detaljer är viktigare än namnet på prisplanen.
Uppskatta kostnaden utifrån ert arbetsflöde, inte bara antalet ordrar
Använd en representativ driftsperiod och gör en prognos utifrån data på försändelsenivå. Ta med både nya försändelser och äldre försändelser som fortfarande behöver övervakas. Om era data är ofullständiga bör ni synliggöra antagandena i stället för att presentera resultatet som en exakt offert.
- Räkna spårningsbara kollin. Börja med unika spårningsenheter för kollin, inte kassabeställningar. Håll utgående kollin, returer och ersättningar åtskilda tills deras debiteringsregler har bekräftats.
- Mät övervakningens varaktighet. Uppskatta hur länge varje försändelse behöver uppdateringar, inklusive perioder före transport och perioder med avvikelser där det är relevant.
- Definiera den nödvändiga uppdateringsfrekvensen. Ange hur ofta applikationen behöver färsk information och om detta varierar beroende på försändelsestatus.
- Kartlägg API-arbetsflödet. Lista registreringar, resultatuppslag, uppdateringsförfrågningar, korrigeringar, omförsök och alla andra endpoints som integrationen kommer att använda.
- Tillämpa debiteringsreglerna. Omvandla teknisk aktivitet till debiterbara anrop eller försändelseenheter enligt det föreslagna avtalet.
- Lägg till icke-användningsbaserade avgifter. Inkludera tillämplig abonnemangsavgift, minimiåtagande, valfria tjänster samt implementerings- eller driftskostnader.
För en enkel pollingintegration med ett spårningsnummer per uppslag är den initiala uppskattningen:
Uppslagsförfrågningar = övervakade försändelser × genomsnittligt antal övervakade dagar × uppslag per dag
Denna förenkling förutsätter att varje försändelse följer samma genomsnittliga schema. En mer exakt modell summerar förfrågningarna för varje försändelse eller försändelsekohort och lägger sedan till registreringsanrop och annan debiterbar aktivitet. Om försändelser förblir aktiva över ett månadsskifte ska deras förfrågningar fördelas till de debiteringsperioder då förfrågningarna faktiskt görs.
Ett räkneexempel: när den billigare modellen ändras
Följande siffror är påhittade enbart för att demonstrera beräkningen. De är inte 17TRACK-priser, leverantörsofferter eller marknadsjämförelser.
Anta att 10 000 kollin registreras och övervakas fullt ut under samma modellerade period. Varje kolli kräver ett registreringsanrop och tre uppslagsförfrågningar per dag under åtta dagar. Anta att varje förfrågan är debiterbar, att varje förfrågan gäller ett kolli och att det inte finns några omförsök, batchrabatter, inkluderade volymer eller fasta avgifter.
- Registreringsförfrågningar: 10 000.
- Uppslagsförfrågningar: 10 000 × 8 × 3 = 240 000.
- Totalt antal debiterbara förfrågningar: 250 000.
- Illustrativt pris per anrop: $0.002.
- Illustrativt pris per försändelse: $0.04, inklusive den nödvändiga övervakningen.
Användningskostnaden per anrop är 250 000 × $0.002 = $500. Användningskostnaden per försändelse är 10 000 × $0.04 = $400. Med dessa antaganden kostar prissättning per försändelse $100 mindre för användningen.
Ändra nu endast uppslagsfrekvensen till en gång per dag. Antalet förfrågningar blir 10 000 registreringar plus 80 000 uppslag, det vill säga 90 000 anrop. Användningskostnaden per anrop sjunker till $180, medan den illustrativa kostnaden per försändelse fortfarande är $400. Den föredragna modellen ändras eftersom arbetsbelastningen ändras, inte för att någon av prismodellerna i sig är bättre.
Hitta brytpunkten
När båda planerna saknar fasta avgifter, inkluderade volymer och extra avgifter kan du använda:
Debiterbara anrop per försändelse vid brytpunkten = försändelsepris ÷ anropspris
I exemplet är $0.04 ÷ $0.002 lika med 20 debiterbara anrop per försändelse. Över 20 anrop är försändelseavgiften lägre; under 20 är anropsavgiften lägre. Registreringsanrop räknas in i denna tröskel enligt antagandena i exemplet.
Denna förenkling räcker inte för trappstegsbaserade planer, förbetalda krediter, olika priser per endpoint eller minimiåtaganden. För sådana erbjudanden bör du beräkna hela fakturan för varje prognostiserad volym i stället för att jämföra angivna enhetspriser.
Webhooks kan minska polling, men debiteringen måste fortfarande verifieras
Polling innebär att applikationen upprepade gånger frågar efter spårningsinformation. En webhook gör det möjligt för en tjänst att skicka en händelse till applikationen, vilket minskar behovet av upprepade uppslag när händelseströmmen uppfyller era krav.
Färre uppslagsförfrågningar innebär dock inte automatiskt en lägre faktura. Bekräfta om webhook-leverans ingår, om leveranser eller omförsök mäts och debiteras samt om avstämningsuppslag fortfarande behövs. Applikationen måste också kunna hantera dubbla eller felordnade händelser på ett säkert sätt och återhämta sig från leveransfel.
Det finns ytterligare en skillnad som är viktig att beakta: tätare informationsförfrågningar garanterar inte att den underliggande transportören har registrerat en ny scanning. Fråga vad ett uppslag returnerar och hur datauppdateringen fungerar innan ni betalar för en pollingfrekvens som kanske ger liten operativ nytta.
Kostnader som ett angivet pris kan dölja
Inkluderade volymer, minimiavgifter och förbetalda saldon
Skilj mellan en minimiavgift och ett abonnemang med inkluderad användning. En minimiavgift kan ange en lägsta kostnadsnivå; en inkluderad volym kan täcka en definierad mängd innan överskridandeavgifter tillkommer. Förbetalda krediter medför separata frågor om giltighetstid, återbetalningar och outnyttjade saldon.
För en plan där den inkluderade volymen dras av innan överskridandeavgifter tas ut är en användbar struktur:
API-faktura = fast planavgift + debiterbart överskridande + tillämpliga tillägg
Använd endast denna formel om den överensstämmer med avtalet. Lägg inte till samma inkluderade användning två gånger och anta inte att alla planer tillämpar marginalprissättning på samma sätt.
Långvariga försändelser och upprepade registreringar
Långa övervakningsperioder ökar uppslagsvolymen i en pollinglösning. Vid prissättning per försändelse är den relevanta frågan om den ursprungliga avgiften täcker denna varaktighet. Testa undantag och försenade försändelser, inte bara leveranser som slutförs snabbt.
Bekräfta också vad som händer när samma spårningsnummer skickas in två gånger, korrigeras, tas bort och läggs till igen eller kopplas till en annan transportör. Implementera förebyggande av dubbletter när det är lämpligt, men anta inte att deduplicering på applikationsnivå exakt motsvarar leverantörens debiteringsidentitet.
Hastighetsbegränsningar och kapacitet vid toppar
En prisvärd månadsvolym innebär inte att en integration kan hantera en stor import eller en trafikökning. Kontrollera begränsningar för förfrågningshastighet, batchstorlek och samtidighet samt det förväntade beteendet när gränserna nås. En plan som klarar månadsvolymen men inte stöder det nödvändiga arbetsflödet är inte ett jämförbart alternativ.
Tekniska kostnader och driftskostnader
Håll API-fakturan åtskild från den totala ägandekostnaden. Interna kostnader kan omfatta integrationsutveckling, webhook-hosting, köer, övervakning, incidenthantering, datalagring och underhåll.
Använd era egna uppskattningar av arbetskraft och infrastruktur. Ett dyrare abonnemang kan fortfarande vara ekonomiskt om det tydligt minskar det operativa arbetet, men besparingen bör testas och inte antas.
Så jämför du offerter och validerar en kortlista
Be varje leverantör prissätta samma arbetsbelastningsspecifikation: kollivolym, försändelsemix, övervakningsperiod, uppdateringskrav, endpoints, toppbelastning och nödvändiga tjänster. Begär en skriftlig förklaring av debiteringsenheten och ett exempel på en fakturaberäkning.
För team som överväger 17TRACK är den officiella sidan för Tracking API och API-dokumentationen relevanta utgångspunkter för produkt- och integrationsutvärdering. Bekräfta tillämpliga priser och debiteringsdefinitioner direkt innan ni tilldelar en modell i prognosen. Denna artikel anger eller klassificerar inte någon aktuell 17TRACK-plan.
Innan ni fattar beslut bör ni genomföra ett kontrollerat pilotprojekt med representativa försändelser. Ta med delade ordrar, dubbla inskickningar, försenade kollin, gränsöverskridande transporter och försändelser som passerar en debiteringsgräns. Testa endast fel- eller omförsöksbeteende på sätt som tjänsten tillåter.
- Jämför era förfrågningsloggar med leverantörens användningsregister.
- Stäm av registrerade spårningsenheter mot debiterade försändelseenheter.
- Kontrollera om den nödvändiga uppdateringstakten faktiskt uppnås.
- Mät toppbelastning separat från månadsförbrukning.
- Utred oförklarade skillnader innan kostnader extrapoleras.
Ta fram minst tre prognoser: normal drift, säsongstopp och förlängd transport. Ändra de underliggande drivarna i stället för att lägga till en godtycklig procentsats på fakturan. Modellera till exempel fler kollin vid en topp och längre övervakningsperioder i ett scenario med förseningar.
Vilken modell bör du välja?
Välj prissättning per anrop när uppslag görs sällan, efterfrågan på förfrågningar kan mätas och prognosen ligger under brytpunkten efter att registreringar och annan debiterbar aktivitet har räknats med. Modellen är mindre attraktiv när frekvent polling eller oförutsägbar övervakningsperiod skapar en betydande mängd förfrågningar.
Välj prissättning per försändelse när kontinuerlig övervakning krävs och det angivna försändelsepriset inkluderar den uppdateringsfrekvens, spårningsperiod och leveransmekanism ni behöver. Modellen är mindre attraktiv när ni betalar för övervakning som sällan används eller när definitionen av försändelse skapar oväntade extra enheter.
Det slutliga beslutet bör baseras på total kostnad per operativt kolli: API-fakturan plus hänförliga driftskostnader, dividerat med de unika kollin som verksamheten behöver övervaka. Håll den interna kollidefinitionen konsekvent mellan offerter, även när leverantörerna använder olika debiteringsenheter.
Vanliga frågor
Är misslyckade API-förfrågningar debiterbara?
Anta inte något av alternativen. Fråga hur valideringsfel, autentiseringsfel, svar vid hastighetsbegränsning, serverfel och timeouts hanteras. En timeout kan också skapa osäkerhet kring om en förfrågan behandlades innan applikationen försökte igen.
Räknas en order alltid som en försändelse?
Nej. En order kan innehålla flera separat spårade kollin. För budgetering bör du koppla ordrar till spårningsenheter och sedan tillämpa leverantörens definition. Bekräfta hur returer, ersättningar och överlämningar mellan transportörer räknas.
Kommer batchförfrågningar att minska min faktura?
Endast om debiteringsreglerna premierar batchhantering. Batchar kan minska antalet nätverksförfrågningar utan att minska antalet debiterbara spårningsenheter. Kontrollera batchgränsen och om debiteringen sker per förfrågan, per objekt eller genom en viktad enhet.
Kan webhooks eliminera alla uppslagsförfrågningar?
De kan ta bort mycket rutinmässig polling, men designen kan fortfarande behöva initial hämtning, återställning efter missade händelser eller periodisk avstämning. Ta med dessa anrop i uppskattningen och bekräfta eventuella avgifter för webhook-leverans.
Hur bör jag budgetera för försändelser som fortfarande är aktiva nästa månad?
Vid prissättning per anrop bör du prognostisera de förfrågningar som dessa försändelser kommer att generera under nästa period. Vid prissättning per försändelse bör du bekräfta om övervakningen fortfarande täcks eller utlöser en ny avgift. Räkna inte bara nyregistrerade försändelser när du uppskattar den löpande arbetsbelastningen.
Källor
Beräkningarna ovan använder uttryckligen hypotetiska indata, inte publicerade leverantörspriser. För en utvärdering av 17TRACK bör du använda dessa officiella referenssidor och bekräfta kommersiella villkor direkt:
