10 pakollista ominaisuutta lähetysseuranta-API:ssa (ostajan tarkistuslista)
Kun ostat lähetysseuranta-API:n, aseta luotettavat seurantatapahtumat, kattava kuljetusyhtiöiden tuki, selkeä dokumentaatio, ennakoitava virheenkäsittely ja integraation hallintatoiminnot etusijalle ennen hallintapaneelien tai markkinointiväitteiden arviointia. Oikean API:n pitäisi auttaa tiimiäsi muuttamaan kuljetusyhtiöiden päivitykset tarkoiksi asiakasilmoituksiksi, operatiivisiksi työnkuluiksi ja tukivastauksiksi ilman, että syntyy toinen järjestelmä, joka vaatii jatkuvaa manuaalista korjaamista.
Tämä tarkistuslista on tarkoitettu tuotteen omistajille, suunnittelutiimeille, logistiikkapäälliköille ja verkkokauppaoperaattoreille, jotka arvioivat seuranta-API:a sovellukseen, tilaustenhallintajärjestelmään, help deskiin tai asiakasportaaliin. Käytä sitä toimittajien kartoituksessa, teknisessä arvioinnissa ja konseptitodistuksessa. Toimittaja voi mainostaa ominaisuutta paljastamatta kaikkia toteutuksen yksityiskohtia julkisesti, joten varmista omiin lähetysvolyymeihisi ja palvelutasovaatimuksiisi vaikuttavat kohdat.
1. Laaja ja tarkoituksenmukainen kuljetusyhtiöiden kattavuus
Kuljetusyhtiöiden kattavuus on lähtökohta, mutta suuri kuljetusyhtiöiden määrä ei yksin riitä. Hyödyllinen kysymys on, pystyykö API seuraamaan yrityksesi käyttämiä kuljetusyhtiöitä, postipalveluja, rahtipalveluntarjoajia ja alueellisia jakelupalveluja.
Pyydä toimittajilta ajantasainen kuljetusyhtiöhakemisto ja vertaa sitä todellisiin lähetysesimerkkeihin. Tarkista sinulle tärkeät maat, palvelutyypit ja seurantanumeromuodot. Kuljetusyhtiö voi olla luettelossa, vaikka vain tietyt palvelut, määränpäät tai tapahtumatyypit olisivat tuettuja. Kysy myös, miten API käsittelee postipalvelujen luovutuksia, viimeisen kilometrin kumppaneita ja lähetyksiä, jotka siirtyvät useiden logistiikkapalveluntarjoajien välillä.
Älä tee ostopäätöstä yhden kattavuusprosentin perusteella, ellei toimittaja selitä laskentamenetelmäänsä. Oman toimitusreittisi kattavuus on arvokkaampi kuin laaja koontiluku. Ota arviointiin mukaan kotimaan lähetykset, rajat ylittävät lähetykset, palautukset, korvaavat lähetykset ja harvinaisemmat määränpäät.
2. Vakaa lähetysten seurantamalli
Eri kuljetusyhtiöt käyttävät samanlaisista välivaiheista erilaisia termejä ja tapahtumarakenteita. Yksi voi ilmoittaa lähetyksen lähteneeksi, toinen vastaanotetuksi ja kolmas lajittelukeskuksen kautta kulkevaksi. Hyödyllinen seuranta-API normalisoi nämä päivitykset malliksi, jonka sovelluksesi voi tulkita johdonmukaisesti, säilyttäen tarvittaessa alkuperäisen kuljetusyhtiön viestin.
Tarkista, tarjoaako API vakaan lähetyskohtaisen tunnisteen, seurantanumeron, kuljetusyhtiön tiedot, tilan, tapahtuma-ajan, sijainnin ja kuvaavan viestin. Selvitä, ovatko tapahtumat järjestyksessä, voiko päällekkäisiä tapahtumia esiintyä ja miten korjaukset tai myöhässä saapuvat tapahtumat esitetään.
Tiimisi pitäisi pystyä erottamaan lähetys, joka ei ole vielä saanut ensimmäistä skannausta, kuljetuksessa oleva lähetys, viivästynyt lähetys, noudettavissa oleva lähetys ja toimitettu lähetys. Vältä rakentamasta asiakasviestintää pienen ja epäselvien tunnisteiden joukon ympärille.
3. Reaaliaikaiset tai tapahtumapohjaiset ilmoitukset
Pelkkä kysely voi aiheuttaa tarpeetonta liikennettä ja viivästyttää asiakkaille näkyviä päivityksiä. Monille sovelluksille webhookit tai muut tapahtumapohjaiset ilmoitukset ovat tärkeä hankintavaatimus. Niiden avulla järjestelmäsi voi reagoida, kun merkityksellinen lähetystapahtuma tulee saataville, sen sijaan että samaa tilaa kysyttäisiin toistuvasti.
Varmista, ovatko ilmoitukset saatavilla tarvitsemillesi tapahtumille, kuten kuljetuksessa olevalle lähetykselle, toimitusyritykselle, toimituspoikkeamalle ja toimitetulle lähetykselle. Kysy, miten toimittaja todentaa pyynnöt, allekirjoittaa hyötykuormat, yrittää epäonnistuneiden toimitusten lähettämistä uudelleen ja käsittelee oman järjestelmäsi tilapäiset käyttökatkot.
Vastaanottavan päätepisteesi tulisi olla idempotentti. Käytännössä tämä tarkoittaa, että saman ilmoituksen käsittely useammin kuin kerran ei lähetä päällekkäisiä sähköposteja, luo päällekkäisiä tikettejä tai käynnistä varastotoimia uudelleen. Päätä myös, tarvitseeko järjestelmäsi alkuperäisen tapahtuma-ajan, ilmoituksen aikaleiman vai molemmat.
4. Selkeä API-dokumentaatio ja esimerkit
Dokumentaatio on tuotteen ominaisuus. Ennen sopimuksen allekirjoittamista insinöörin pitäisi pystyä ymmärtämään todennus, pyyntömuodot, vastauskentät, tilakoodit, sivutus, webhookien toiminta ja yleiset vikatilanteet ilman, että hän on täysin riippuvainen myyntiyhteyshenkilöstä.
Etsi täydellisiä esimerkkejä tiimisi käyttämillä ohjelmointikielillä. Testaa, selittääkö dokumentaatio pakolliset ja valinnaiset parametrit, kenttätyypit, päivämäärämuodot, alueelliset asetukset sekä virheellisen pyynnön ja tuntematonta lähetystä koskevan kelvollisen pyynnön eron.
Hyvän dokumentaation pitäisi selittää myös versiointi ja muutosten hallinta. Kysy, kuinka paljon ennakkoilmoitusta toimittaja antaa ennen kentän poistamista, tapahtuma-arvon muuttamista tai uuden vastausrakenteen käyttöönottoa. Jos julkinen dokumentti on puutteellinen, käsittele asiaa selvitettävänä kohtana äläkä oleta, ettei ominaisuutta ole olemassa.
5. Ennakoitava todennus ja käyttöoikeuksien hallinta
Seuranta-API käsittelee operatiivisia tietoja, jotka voivat liittyä asiakastilauksiin. Siksi se tarvitsee arkkitehtuuriisi sopivan tietoturvamallin. Tarkista, miten tunnistetiedot myönnetään, vaihdetaan, peruutetaan ja erotetaan kehitys-, testi- ja tuotantoympäristöjen välillä.
Varmista, tukeeko palvelu ympäristöjen erottelua, rajattuja tunnistetietoja, palvelinpuolen todennusta ja käyttöönottoosi sopivia rajoituksia. Älä koskaan sijoita yksityisiä API-tunnistetietoja selainkoodiin tai mobiilisovelluksiin, ellei toimittaja nimenomaisesti dokumentoi turvallista toteutustapaa kyseiseen käyttötapaukseen.
Kysy, miten toimittaja käsittelee epäilyttävää liikennettä, tunnistetietojen paljastumista ja tilitason käyttöoikeuksia. Teknisten ja lakitiimien tulee tarkistaa tietoturvaehtoja, jos API käsittelee henkilötietoja tai lähetystietoja useilla markkinoilla.
6. Pyyntörajoitukset, kiintiöt ja käytön näkyvyys
Pyyntörajoitukset vaikuttavat sekä arkkitehtuuriin että kustannuksiin. Toimittajan tulisi selittää pyyntörajoitukset, purskekäyttäytyminen, kiintiöjaksot, samanaikaisuuden rajoitukset ja rajan saavuttamisen yhteydessä palautettava vastaus. Jos dokumentaatiossa ei ilmoiteta näitä tietoja, pyydä kirjallinen vahvistus.
Laadi käyttötapausmalli todellisen työnkulkusi perusteella. Järjestelmän, joka seuraa jokaista tilausta kerran, liikenne voi poiketa huomattavasti järjestelmästä, joka päivittää aktiivisia lähetyksiä usein, tukee asiakkaiden itsepalveluhakuja ja suorittaa tietojen täydennyksiä tuonnin jälkeen. Ota mukaan myynnin huippukaudet, joukkolataukset, kuljetusyhtiöiden viivästykset ja uudelleenyrityksistä syntyvä liikenne.
Hyödyllisiä operatiivisia hallintatoimintoja ovat käyttökoontinäytöt, kiintiöhälytykset, pyyntötunnisteet sekä välimuistin tai kyselyvälien käyttöä koskevat suositukset. Älä oleta, ettei rajattomaksi kuvattuun suunnitelmaan liity kohtuullisen käytön ehtoja tai teknisiä rajoituksia. Kysy, miten ylitykset ja tilapäinen rajoittaminen käsitellään ennen tuotantokäynnistystä.
7. Tehokas virheenkäsittely ja havainnointi
Seurantajärjestelmien on käsiteltävä tavallisia vikoja: virheellisiä seurantanumeroita, tukemattomia kuljetusyhtiöitä, tilapäisiä kuljetusyhtiöiden käyttökatkoja, verkkovirheitä, päällekkäisiä lähetyksiä ja viivästynyttä dataa. Luotettava API tekee näistä tapauksista erotettavia.
Tarkista HTTP-tilakoodit, virheobjektit, virheviestit ja pyyntötunnisteet. Sovelluksesi pitäisi pystyä päättämään, korjataanko käyttäjän syöte, yritetäänkö myöhemmin uudelleen, ohjataanko asia tukeen vai merkitäänkö lähetys ensimmäistä skannausta odottavaksi. Yleinen virhe, kuten “request failed”, ei riitä automatisoituihin toimintoihin.
Tarkista myös toimittajan tilaviestintä ja tukiprosessi. API:n tilasivu voi auttaa, mutta se ei korvaa sovellustason lokitusta. Säilytä pyyntöaika, toimittajan vastaus, seurantatunniste ja sisäinen korrelaatio-ID tavalla, joka noudattaa säilytys- ja tietosuojavaatimuksiasi.
8. Tietojen ajantasaisuus ja tapahtumahistoria
Seurantatiedot ovat hyödyllisiä vain, kun käyttäjät ymmärtävät, kuinka ajantasaisia ne ovat. Kysy, kuinka usein palvelu hankkii päivityksiä, päivittävätkö eri kuljetusyhtiöt eri aikavälein ja miten API ilmaisee tapahtuman vastaanottoajan tai viimeisimmän tarkistusajan.
Tarkista, sisältääkö vastaus täydellisen tapahtumahistorian vai ainoastaan viimeisimmän tilan. Täydellinen historia on arvokas asiakastuelle, toimitusten selvittämiseen, reklamaatioprosesseihin ja analytiikkaan. Se voi myös paljastaa päällekkäisiä, uudelleen järjestettyjä tai korjattuja tapahtumia, joten tietomallisi ei saa olettaa jokaisen päivityksen olevan täysin uusi välivaihe.
Vertaa konseptitodistuksen aikana API-vastauksia kuljetusyhtiöiden sivuihin tai kuljetusyhtiöiden toimittamiin tietoihin edustavalla otoksella. Älä odota kaikkien lähteiden päivittyvän täsmälleen samaan aikaan. Tavoitteena on ymmärtää normaali viive ja olosuhteet, joissa tiedot voivat olla puutteellisia.
9. Kansainvälistäminen ja rajat ylittävien lähetysten konteksti
Rajojen yli kulkevat lähetykset tarvitsevat enemmän kuin käännetyn tilatunnisteen. Ostajien pitäisi voida ymmärtää tapahtumat haluamallaan kielellä ja aikavyöhykkeellä, kun taas operatiiviset tiimit voivat tarvita alkuperäisen kuljetusyhtiön sanamuodon selvityksiä varten.
Tarkista lokalisoitujen viestien, määränpää- ja lähtötietojen, aikavyöhykkeiden käsittelyn, maakoodien ja kansainvälisten seurantanumeroiden tuki. Selvitä, esitetäänkö tulliin liittyvät tapahtumat erillään tavallisista kuljetustapahtumista. Jos tullit, verot tai tulliselvitystiedot eivät kuulu API:n piiriin, tee tämä rajaus selväksi tuotteen suunnittelussa.
Testaa lähetyksiä, jotka vaihtavat kuljetusyhtiötä tai kulkevat useiden maiden kautta. Kotimaan paketille toimiva tilamalli voi olla harhaanjohtava, kun lähetys odottaa tullikäsittelyä tai se on luovutettu paikalliselle jakelukumppanille.
10. Integraation sopivuus ja kaupallinen läpinäkyvyys
Viimeinen ominaisuus ei ole yksittäinen päätepiste. Kyse on siitä, miten API sopii jo käyttämiisi järjestelmiin ja prosesseihin. Kartoita integraatio tilaustenhallintajärjestelmääsi, varastotyökaluihin, verkkokauppa-alustaan, asiakaspalvelualustaan, analytiikkapinoon ja ilmoituspalveluntarjoajaan.
Etsi käytännöllinen tuki massaseurannalle, lähetysten luomiselle tai rekisteröinnille tarvittaessa, webhookeille, testaukselle, viennille ja tietojen säilytykselle. Varmista, mitkä toiminnot sisältyvät harkitsemaasi suunnitelmaan, äläkä oleta jokaisen dokumentoidun päätepisteen olevan kaikkien asiakkaiden käytettävissä.
Hinnoittelua tulisi arvioida suhteessa odotettuun pyyntömäärään, aktiivisiin lähetyksiin, kuljetusyhtiöiden yhdistelmään, ympäristöihin, tukivaatimuksiin ja kasvumalliin. Kysy, perustuuko laskutus pyyntöihin, seurattuihin lähetyksiin, tapahtumiin vai johonkin muuhun yksikköön. Pyydä kirjalliset vastaukset vähimmäissitoumuksista, ylitysten käsittelystä, peruutuksesta ja suunnitelmarajojen muutoksista. Jos hinnoittelua ei ilmoiteta julkisesti, merkitse se suoraan vahvistettavaksi äläkä arvioi sitä itse.
Näin toteutat käytännöllisen seuranta-API:n arvioinnin
- Määritä lähetysjoukko. Luettele kuljetusyhtiöt, maat, palvelut, seurantanumeromuodot ja käsiteltävät lähetysmäärät.
- Kirjoita hyväksymiskriteerit. Määritä sovelluksesi tarvitsemat tilat, tapahtumakentät, ajantasaisuusodotukset, ilmoituskäyttäytyminen ja virhevastaustyypit.
- Käytä todellisia näytteitä turvallisesti. Testaa toimitettuja, kuljetuksessa olevia, viivästyneitä, palautettuja, virheellisiä, rajat ylittäviä ja äskettäin luotuja lähetyksiä. Poista tarpeettomat henkilötiedot.
- Testaa koko elinkaari. Lähetä pyyntöjä, vastaanota tapahtumia, yritä epäonnistuneita toimintoja uudelleen, käsittele päällekkäisyyksiä ja varmista, miten järjestelmäsi toimii, kun kuljetusyhtiön tiedot saapuvat myöhässä.
- Mittaa operatiivinen työmäärä. Kirjaa integraatioon käytetty aika, dokumentaation puutteet, tuen vastausten laatu, valvontatarpeet ja normalisoinnin määrä, jonka tiimisi on rakennettava.
- Vahvista kaupalliset ehdot. Vertaa testattua työnkulkua ehdotettuun suunnitelmaan ja pyydä selvennys jokaisesta vahvistamattomasta rajoituksesta tai ominaisuudesta.
17TRACKin asema arvioinnissa
17TRACK tarjoaa erillisen Tracking API -tuotteen ja julkaisee API-dokumentaation kehittäjille. Siksi se on relevantti vaihtoehto, kun tarvitaan useiden kuljetusyhtiöiden lähetysten näkyvyyttä eikä kuljetusyhtiökohtaista integraatiota. Tarkista sen viralliset API-materiaalit oman kuljetusyhtiöluettelosi, esimerkkiseurantanumeroidesi, tapahtumavaatimustesi ja odotetun liikenteesi rinnalla.
Oikean ostopäätöksen tulisi perustua kontrolloituun testiin, ei pelkästään brändin tunnettuuteen. Varmista yrityksellesi tärkeät kuljetusyhtiöt ja toiminnot, vahvista sovellettavat tiliehdot ja arvioi, miten palautetut tiedot sopivat sisäiseen tilamalliisi. Sama tarkistuslista soveltuu myös 17TRACKin vertaamiseen muihin seuranta-API-palveluntarjoajiin.
Ostajan päätöksenteon tarkistuslista
- Vastaako kuljetusyhtiöhakemisto todellisia toimitusreittejäsi?
- Pystyykö API erottamaan merkitykselliset toimitustilat ja säilyttämään kuljetusyhtiön yksityiskohdat?
- Onko webhookien, uudelleenyritysten, todennuksen ja päällekkäisyyksien käsittely dokumentoitu?
- Voiko tiimisi testata API:a realistisilla lähetysesimerkeillä?
- Ovatko pyyntörajoitukset, käyttöyksiköt, tukiehdot ja suunnitelmien rajat selkeitä?
- Voitko valvoa vikoja ja selittää tietojen ajantasaisuuden asiakkaille?
- Käsitteleekö API rajat ylittävät ja usean kuljetusyhtiön kautta kulkevat lähetykset asianmukaisesti?
- Onko migraatiolle ja versioinnille dokumentoitu etenemistapa?
Usein kysytyt kysymykset
Pitäisikö minun valita API, jolla on suurin kuljetusyhtiöluettelo?
Ei välttämättä. Valitse palveluntarjoaja, joka kattaa luotettavasti lähetysvalikoimasi kuljetusyhtiöt, määränpäät ja palvelut. Pienempi mutta tarkoituksenmukainen kattavuus voi olla hyödyllisempi kuin suurempi luettelo, joka ei vastaa toimitusreittejäsi tai tapahtumavaatimuksiasi.
Ovatko webhookit parempia kuin kysely?
Ne ratkaisevat eri ongelmia. Webhookit voivat vähentää tarpeetonta kyselyä ja auttaa sovellustasi reagoimaan päivityksiin nopeasti, kun taas kysely voi toimia varamenetelmänä tai säännöllisenä täsmäytysprosessina. Kestävässä suunnittelussa voidaan käyttää tapahtumailmoituksia hallitun täsmäytyksen kanssa toimittajan dokumentoidun toiminnan mukaan.
Mitä minun pitäisi testata konseptitodistuksessa?
Testaa yleiset ja haastavat tapaukset: uusi seurantanumero, kuljetuksessa oleva paketti, toimitettu lähetys, viivästys, palautus, virheellinen numero, rajat ylittävä lähetys, päällekkäiset ilmoitukset ja tilapäinen API-virhe. Mittaa sekä tietojen laatu että niiden turvalliseen käyttöön tarvittava suunnittelutyö.
Kuinka usein seuranta-API:n pitäisi päivittää lähetystietoja?
Kaikkiin kuljetusyhtiöihin tai palveluihin soveltuvaa yhtä aikaväliä ei ole. Kysy, miten ajantasaisuus määritellään, milloin lähetys tarkistettiin viimeksi ja miten kuljetusyhtiöiden viivästykset vaikuttavat vastaukseen. Aseta asiakkaiden odotukset API:n tosiasiallisesti tarjoamien tietojen perusteella.
Voinko luottaa pelkästään API:n normalisoituun tilaan?
Käytä normalisoituja tiloja johdonmukaisissa työnkuluissa, mutta säilytä mahdollisuuksien mukaan alkuperäiset tapahtumatiedot. Kuljetusyhtiön sanamuoto, aikaleimat ja sijainnit voivat olla tärkeitä tukiselvityksissä, poikkeamien käsittelyssä ja riitatilanteissa.
