Skip to main content
HomeBlogGidsenPrijsmodellen voor de Tracking API uitgelegd: per aanroep versus per zending en hoe u uw werkelijke kosten kunt inschatten

Prijsmodellen voor de Tracking API uitgelegd: per aanroep versus per zending en hoe u uw werkelijke kosten kunt inschatten

17TRACK

De prijsstelling van de tracking-API per aanroep brengt kosten in rekening voor factureerbare verzoeken; prijsstelling per zending brengt kosten in rekening voor een gedefinieerde trackingeenheid, zoals een geregistreerd trackingnummer. Geen van beide is automatisch goedkoper. Om uw werkelijke kosten te schatten, vergelijkt u beide modellen op basis van hetzelfde verzendvolume, dezelfde updatevereisten, trackingduur en factureringsregels, en voegt u platformkosten, overschrijdingen en integratiekosten toe.

Prijsmodellen voor tracking-API's uitgelegd: per aanroep versus per zending

Voor engineering-, operationele en inkoopteams is de nuttige vergelijking niet simpelweg de prijs per aanroep versus de prijs per zending. Het gaat om de totale kosten voor het leveren van de verzendzichtbaarheid die uw bedrijf nodig heeft. Een laag aantal verzoeken kan duur worden door frequent pollen, terwijl een laag aantal zendingen misleidend kan zijn als het trackingvenster of de inbegrepen diensten niet aansluiten op uw workflow.

Wat elk prijsmodel daadwerkelijk meet

De eerste stap is het scheiden van drie zaken: een API-verzoek, een zendingregistratie en een trackingupdate. Dit zijn verschillende gebeurtenissen en een contract kan aan elk ervan een verschillende factureringsbehandeling toekennen.

VergelijkingspuntPrijsstelling per aanroepPrijsstelling per zending
FactureringsbasisVerzoeken of als factureerbaar gedefinieerde verzoekeenhedenAls factureerbaar gedefinieerde zendingseenheden
Belangrijkste kostenfactorHoe vaak de applicatie kostenplichtige verzoeken doetHoeveel kostenplichtige trackingeenheden binnen de scope vallen of blijven
Te beantwoorden factureringsvraagWelke endpoints, antwoorden en batchitems tellen mee?Wat vormt één zending en hoe lang is tracking inbegrepen?
Mogelijke kostenblootstellingHerhaald pollen, nieuwe pogingen en onnodige zoekopdrachtenDubbele registraties, meerdere pakketten en beperkingen van het trackingvenster
Sterkste voorwaardelijke geschiktheidZoekopdrachten met lage frequentie en gecontroleerd verzoekvolumeDoorlopende monitoring wanneer updates bij de verzendkosten zijn inbegrepen

Per aanroep betekent niet noodzakelijk dat elk HTTP-verzoek hetzelfde kost

Een offerte moet de factureerbare endpoints en hun eenheden identificeren. Het registreren van een trackingnummer, het ophalen van opgeslagen resultaten, het aanvragen van een vernieuwing en het beheren van abonnementen kunnen verschillend worden behandeld. Ga er niet van uit dat een mislukt verzoek gratis is of dat een geslaagd verzoek altijd factureerbaar is.

Ook voor batching is een expliciete definitie nodig. Eén verzoek met 100 trackingnummers kan tellen als één verzoek, 100 trackingeenheden of een andere contractueel bepaalde hoeveelheid. Het verminderen van netwerkverkeer levert geen factureringsbesparing op tenzij de meetregels dit ondersteunen.

Per zending betekent niet noodzakelijk per bestelling

Een e-commercebestelling kan meerdere pakketten opleveren. Als de factureerbare eenheid een trackingnummer is, kan een gesplitste bestelling meerdere eenheden verbruiken. Retourzendingen, vervangende zendingen en overdrachten tussen vervoerders moeten ook duidelijk worden behandeld.

Vraag of de vergoeding tracking omvat gedurende een bepaalde periode, tot een gedefinieerde voltooiingsgebeurtenis of onder een andere limiet. Stel ook vast of reeds geregistreerde zendingen in een latere factureringsperiode opnieuw kosten veroorzaken. Deze details zijn belangrijker dan het label op het prijsplan.

Schat de kosten op basis van uw workflow, niet alleen van uw aantal bestellingen

Gebruik een representatieve operationele periode en maak een prognose op basis van gegevens op zendingniveau. Neem zowel nieuwe zendingen als oudere zendingen op die nog monitoring vereisen. Als uw gegevens onvolledig zijn, maak de aannames zichtbaar in plaats van het resultaat als een precieze offerte te presenteren.

  1. Tel traceerbare pakketten. Begin met unieke trackingeenheden van pakketten, niet met checkoutbestellingen. Houd uitgaande pakketten, retouren en vervangingen apart totdat hun factureringsbehandeling is bevestigd.
  2. Meet de monitoringduur. Schat hoe lang elke zending updates nodig heeft, inclusief pre-transit- en uitzonderingsperioden waar relevant.
  3. Definieer de vereiste updatefrequentie. Geef aan hoe vaak uw applicatie nieuwe informatie nodig heeft en of dit per verzendstatus verandert.
  4. Breng de API-workflow in kaart. Noteer registraties, resultaatopvragingen, vernieuwingsverzoeken, correcties, nieuwe pogingen en alle andere endpoints die uw integratie gebruikt.
  5. Pas de factureringsregels toe. Zet technische activiteit met behulp van het voorgestelde contract om in factureerbare aanroepen of zendingseenheden.
  6. Voeg niet-gebruiksgebonden kosten toe. Neem het toepasselijke abonnement, de minimale afname, optionele diensten en implementatie- of operationele kosten op.

Voor een eenvoudige pollingintegratie met één trackingnummer per zoekopdracht is de eerste schatting:

Zoekopdrachten = gemonitorde zendingen × gemiddeld aantal gemonitorde dagen × zoekopdrachten per dag

Deze vereenvoudiging gaat ervan uit dat elke zending hetzelfde gemiddelde schema volgt. Een nauwkeuriger model telt de verzoeken voor elke zending of elk zendingcohort op en voegt vervolgens registratieaanroepen en andere factureerbare activiteiten toe. Als zendingen aan het einde van de maand nog actief zijn, wijs hun verzoeken toe aan de factureringsperioden waarin die verzoeken plaatsvinden.

Een uitgewerkt voorbeeld: wanneer het goedkopere model verandert

De volgende cijfers zijn uitsluitend ter illustratie van de berekening verzonnen. Het zijn geen 17TRACK-prijzen, leveranciersoffertes of marktbenchmarks.

Ga ervan uit dat 10.000 pakketten binnen dezelfde gemodelleerde periode worden geregistreerd en volledig gemonitord. Elk pakket vereist één registratieverzoek en drie zoekopdrachten per dag gedurende acht dagen. Ga ervan uit dat elk verzoek factureerbaar is, elk verzoek betrekking heeft op één pakket en er geen nieuwe pogingen, batchkortingen, vrijstellingen of vaste kosten zijn.

  • Registratieverzoeken: 10.000.
  • Zoekopdrachten: 10.000 × 8 × 3 = 240.000.
  • Totaal aantal factureerbare verzoeken: 250.000.
  • Illustratief tarief per aanroep: $0.002.
  • Illustratief tarief per zending: $0.04, inclusief de vereiste monitoring.

De gebruikskosten per aanroep bedragen 250.000 × $0.002 = $500. De gebruikskosten per zending bedragen 10.000 × $0.04 = $400. Onder deze aannames kost prijsstelling per zending $100 minder voor het gebruik.

Wijzig nu alleen de zoekfrequentie naar eenmaal per dag. Het aantal verzoeken wordt 10.000 registraties plus 80.000 zoekopdrachten, oftewel 90.000 aanroepen. De gebruikskosten per aanroep dalen naar $180, terwijl de illustratieve gebruikskosten per zending $400 blijven. Het voorkeursmodel verandert omdat de werklast verandert, niet omdat een van beide prijsstructuren van nature beter is.

Bepaal het omslagpunt

Wanneer beide plannen geen vaste kosten, vrijstellingen of extra vergoedingen hebben, gebruikt u:

Factureerbare aanroepen per zending bij omslagpunt = tarief per zending ÷ tarief per aanroep

In het voorbeeld is $0.04 ÷ $0.002 gelijk aan 20 factureerbare aanroepen per zending. Boven 20 aanroepen is de verzendvergoeding lager; onder 20 is de vergoeding per aanroep lager. Registratieaanroepen tellen onder de aannames van het voorbeeld mee voor die drempel.

Deze snelberekening volstaat niet voor getrapte plannen, vooruitbetaalde credits, verschillende endpointtarieven of minimale afnames. Bereken voor die aanbiedingen de volledige factuur bij elk voorspeld volume in plaats van de nominale eenheidstarieven te vergelijken.

Webhooks kunnen polling verminderen, maar facturering moet nog steeds worden gecontroleerd

Bij polling vraagt uw applicatie herhaaldelijk om trackinginformatie. Met een webhook kan een dienst een gebeurtenis naar uw applicatie sturen, waardoor minder herhaalde zoekopdrachten nodig zijn wanneer de gebeurtenissenstroom aan uw vereisten voldoet.

Minder zoekopdrachten betekenen echter niet automatisch een lagere factuur. Controleer of webhooklevering inbegrepen is, of leveringen of nieuwe pogingen worden gemeten en of zoekopdrachten voor reconciliatie nodig blijven. Uw applicatie moet ook dubbele of niet-volgordelijke gebeurtenissen veilig kunnen verwerken en zich kunnen herstellen van leveringsfouten.

Er is nog een onderscheid dat u moet bewaken: vaker informatie opvragen garandeert niet dat de onderliggende vervoerder een nieuwe scan heeft geproduceerd. Vraag wat een zoekopdracht oplevert en hoe gegevens worden vernieuwd voordat u betaalt voor een pollingfrequentie die mogelijk weinig operationele waarde toevoegt.

Kosten die een nominaal tarief kan verbergen

Inbegrepen vrijstellingen, minima en vooruitbetaalde saldi

Maak onderscheid tussen een minimumbedrag op de factuur en een abonnement met inbegrepen gebruik. Een minimumbedrag kan een bestedingsvloer instellen; een vrijstelling kan een bepaalde hoeveelheid dekken voordat overschrijdingskosten worden toegepast. Vooruitbetaalde credits roepen afzonderlijke vragen op over vervaldatum, terugbetalingen en ongebruikte saldi.

Voor een plan waarbij de vrijstelling vóór overschrijdingen wordt afgetrokken, is een nuttige structuur:

API-factuur = vaste plankosten + factureerbare overschrijding + toepasselijke add-ons

Gebruik deze formule alleen als deze overeenkomt met het contract. Tel hetzelfde inbegrepen gebruik niet twee keer op en ga er niet van uit dat alle plannen marginale prijzen op dezelfde manier toepassen.

Langlopende zendingen en herhaalde registraties

Lange monitoringperioden verhogen het aantal zoekopdrachten in een pollingontwerp. Bij prijsstelling per zending is de relevante vraag of de oorspronkelijke vergoeding die duur dekt. Test uitzonderingen en vertraagde zendingen, niet alleen leveringen die snel worden voltooid.

Bevestig ook wat er gebeurt wanneer hetzelfde trackingnummer twee keer wordt ingediend, gecorrigeerd, verwijderd en opnieuw toegevoegd, of aan een andere vervoerder wordt gekoppeld. Implementeer waar passend preventie van dubbele registraties, maar ga er niet van uit dat deduplicatie op applicatieniveau perfect overeenkomt met de factureringsidentiteit van de leverancier.

Snelheidslimieten en piekcapaciteit

Een betaalbare maandelijkse vrijstelling betekent niet dat een integratie een grote import of verkeerspiek aankan. Controleer verzoeksnelheidslimieten, batchlimieten, beperkingen op gelijktijdigheid en het verwachte gedrag wanneer limieten worden bereikt. Een plan dat aan het maandvolume voldoet maar de vereiste workflow niet kan ondersteunen, is geen gelijkwaardig alternatief.

Engineering- en operationele kosten

Houd de API-factuur gescheiden van de totale eigendomskosten. Interne kosten kunnen integratieontwikkeling, webhookhosting, wachtrijen, monitoring, incidentrespons, gegevensopslag en onderhoud omvatten.

Gebruik uw eigen schattingen van arbeid en infrastructuur. Een duurder abonnement kan nog steeds economisch zijn als het de operationele werkzaamheden aantoonbaar vermindert, maar die besparing moet worden getest en niet verondersteld.

Offertes vergelijken en een shortlist valideren

Vraag elke leverancier om dezelfde werklastspecificatie te prijzen: pakketvolume, verzendmix, monitoringduur, updatevereisten, endpoints, piekbelasting en vereiste diensten. Vraag om een schriftelijke uitleg van de factureringseenheid en een voorbeeldberekening van de factuur.

Voor teams die 17TRACK overwegen, zijn de officiële Tracking API-pagina en de API-documentatie relevante uitgangspunten voor product- en integratie-evaluatie. Bevestig de toepasselijke prijs- en factureringsdefinities rechtstreeks voordat u in uw prognose een model toewijst. Dit artikel vermeldt of classificeert geen actueel 17TRACK-plan.

Voer vóór uw toezegging een gecontroleerde pilot uit met representatieve zendingen. Neem gesplitste bestellingen, dubbele indieningen, vertraagde pakketten, grensoverschrijdende bewegingen en zendingen die een factureringsgrens overschrijden op. Test fout- of nieuwepogingsgedrag alleen op manieren die door de dienst zijn toegestaan.

  • Vergelijk uw verzoeklogs met de gebruiksgegevens van de leverancier.
  • Stem geregistreerde trackingeenheden af op gefactureerde zendingseenheden.
  • Controleer of de vereiste updatefrequentie daadwerkelijk wordt bereikt.
  • Meet piekvraag afzonderlijk van maandelijks verbruik.
  • Onderzoek onverklaarde verschillen voordat u kosten extrapoleert.

Maak ten minste drie prognoses: normale bedrijfsvoering, seizoenspiek en langdurig transport. Wijzig de onderliggende factoren in plaats van een willekeurig percentage aan de factuur toe te voegen. Modelleer bijvoorbeeld meer pakketten voor een piek en langere monitoringduur voor een vertragingsscenario.

Welk model moet u kiezen?

Geef de voorkeur aan prijsstelling per aanroep wanneer zoekopdrachten weinig voorkomen, de vraag naar verzoeken meetbaar is en de prognose onder het omslagpunt blijft nadat registraties en andere factureerbare activiteiten zijn opgenomen. Het model is minder aantrekkelijk wanneer frequent pollen of een onvoorspelbare monitoringduur een aanzienlijke blootstelling aan verzoekkosten veroorzaakt.

Geef de voorkeur aan prijsstelling per zending wanneer doorlopende monitoring vereist is en de opgegeven verzendvergoeding de updatefrequentie, trackingduur en leveringsmethode omvat die u nodig hebt. Het model is minder aantrekkelijk wanneer u betaalt voor monitoring die u zelden gebruikt of wanneer de definitie van een zending onverwachte extra eenheden creëert.

De uiteindelijke beslissing moet gebruikmaken van de totale kosten per operationeel pakket: de API-factuur plus toerekenbare operationele kosten, gedeeld door de unieke pakketten die uw bedrijf moet monitoren. Houd die interne pakketdefinitie consistent tussen offertes, ook wanneer leveranciers verschillende factureringseenheden gebruiken.

Veelgestelde vragen

Zijn mislukte API-verzoeken factureerbaar?

Ga niet uit van een van beide uitkomsten. Vraag hoe validatiefouten, authenticatiefouten, antwoorden wegens snelheidslimieten, serverfouten en time-outs worden behandeld. Een time-out kan ook onzekerheid veroorzaken over de vraag of een verzoek is verwerkt voordat uw applicatie het opnieuw probeerde.

Telt één bestelling altijd als één zending?

Nee. Een bestelling kan meerdere afzonderlijk gevolgde pakketten bevatten. Breng voor budgettering bestellingen in kaart naar trackingeenheden en pas vervolgens de definitie van de leverancier toe. Bevestig hoe retouren, vervangingen en overdrachten tussen vervoerders worden geteld.

Verlagen batchverzoeken mijn factuur?

Alleen als de factureringsregels batching belonen. Batches kunnen het aantal netwerkverzoeken verminderen zonder het aantal factureerbare trackingeenheden te verminderen. Controleer de batchlimiet en of facturering per verzoek, per item of via een gewogen eenheid plaatsvindt.

Kunnen webhooks alle zoekopdrachten elimineren?

Ze kunnen veel routinematig pollen wegnemen, maar uw ontwerp kan nog steeds initiële gegevensopvraging, herstel na gemiste gebeurtenissen of periodieke reconciliatie vereisen. Neem die aanroepen op in de schatting en bevestig eventuele kosten voor webhooklevering.

Hoe moet ik budgetteren voor zendingen die volgende maand nog actief zijn?

Voor prijsstelling per aanroep voorspelt u de verzoeken die deze zendingen in de volgende periode zullen genereren. Voor prijsstelling per zending bevestigt u of monitoring gedekt blijft of een nieuwe vergoeding activeert. Tel bij het schatten van de doorlopende werklast niet alleen nieuw aangemaakte zendingen.

Bronnen

De bovenstaande berekeningen gebruiken expliciet hypothetische invoer, geen gepubliceerde leveranciersprijzen. Gebruik voor een 17TRACK-evaluatie deze officiële referentiepagina's en bevestig de commerciële voorwaarden rechtstreeks:

Loading