10 būtinų siuntos sekimo API funkcijų (pirkėjo kontrolinis sąrašas)
Pirkdami siuntų sekimo API, prieš vertindami valdymo skydus ar rinkodaros teiginius, pirmenybę teikite patikimiems sekimo įvykiams, plačiam vežėjų pasirinkimui, aiškiai dokumentacijai, nuspėjamam klaidų tvarkymui ir integracijos valdikliams. Tinkama API turėtų padėti jūsų komandai paversti vežėjų naujinius į tikslius klientų pranešimus, veiklos procesus ir atsakymus klientų aptarnavimo skyriui, nesukuriant antros sistemos, kurią nuolat reikėtų rankiniu būdu taisyti.
Šis kontrolinis sąrašas skirtas produktų savininkams, inžinerijos komandoms, logistikos vadybininkams ir el. prekybos operatoriams, vertinantiems sekimo API programai, užsakymų valdymo sistemai, pagalbos tarnybai ar klientų portalui. Naudokite jį tiekėjų paieškos, techninės peržiūros ir koncepcijos patikrinimo metu. Tiekėjas gali reklamuoti tam tikrą funkciją viešai neatskleisdamas visų įgyvendinimo detalių, todėl patvirtinkite aspektus, kurie turi įtakos jūsų siuntų tipams ir paslaugų lygio reikalavimams.
1. Platus ir aktualus vežėjų aprėpties diapazonas
Vežėjų aprėptis yra pradinis atskaitos taškas, tačiau didelis vežėjų skaičius nėra pakankamas. Svarbu išsiaiškinti, ar API gali sekti jūsų verslo naudojamus vežėjus, pašto operatorius, krovinių vežėjus ir regionines pristatymo tarnybas.
Paprašykite tiekėjų pateikti aktualų vežėjų katalogą ir palyginkite jį su realių siuntų pavyzdžiais. Peržiūrėkite jums svarbias šalis, paslaugų tipus ir sekimo numerių formatus. Vežėjas gali būti įtrauktas į sąrašą, tačiau palaikomos tik tam tikros paslaugos, paskirties vietos ar įvykių tipai. Taip pat paklauskite, kaip API tvarko perdavimą pašto operatoriams, paskutinės mylios partneriams ir siuntas, kurios juda tarp kelių logistikos paslaugų teikėjų.
Nepriimkite pirkimo sprendimo remdamiesi vienu aprėpties procentu, nebent tiekėjas paaiškina savo metodiką. Jūsų faktinių maršrutų aprėptis yra vertingesnė už bendrą apibendrintą rodiklį. Vertindami įtraukite vietines, tarptautines, grąžinamas, pakeičiamas siuntas ir rečiau pasitaikančias paskirties vietas.
2. Stabilus siuntų sekimo modelis
Skirtingi vežėjai panašiems etapams apibūdinti naudoja skirtingus žodžius ir įvykių struktūras. Vienas gali nurodyti, kad siunta išsiųsta, kitas – kad priimta, o trečias – kad juda per rūšiavimo centrą. Naudinga sekimo API normalizuoja šiuos naujinius į modelį, kurį jūsų programa gali nuosekliai interpretuoti, kartu prireikus išsaugodama originalų vežėjo pranešimą.
Patikrinkite, ar API pateikia stabilų siuntos identifikatorių, sekimo numerį, vežėjo tapatybę, būseną, įvykio laiką, vietą ir aprašomąjį pranešimą. Išsiaiškinkite, ar įvykiai pateikiami eilės tvarka, ar gali pasitaikyti pasikartojančių įvykių ir kaip pateikiami pataisymai arba vėluojantys įvykiai.
Jūsų komanda turėtų gebėti atskirti siuntą, kuri dar negavo pirmojo nuskaitymo, judančią siuntą, vėluojančią siuntą, atsiėmimui paruoštą siuntą ir pristatytą siuntą. Venkite kurti klientų pranešimus remdamiesi nedideliu skaičiumi neaiškių etikečių.
3. Realaus laiko arba įvykiais pagrįsti pranešimai
Vien tik apklausų naudojimas gali sukurti nereikalingą srautą ir atidėti klientams skirtus naujinius. Daugeliui programų webhook arba kiti įvykiais pagrįsti pranešimai yra svarbus pirkimo reikalavimas. Jie leidžia jūsų sistemai reaguoti, kai tampa prieinamas reikšmingas siuntos įvykis, užuot pakartotinai klaususi tos pačios būsenos.
Patvirtinkite, ar pranešimai galimi apie jums faktiškai reikalingus įvykius, pavyzdžiui, siuntą kelyje, bandymą pristatyti, pristatymo išimtį ir pristatymą. Paklauskite, kaip tiekėjas autentifikuoja užklausas, pasirašo duomenų rinkinius, pakartoja nepavykusius pristatymus ir tvarko laikiną jūsų sistemos neveikimą.
Jūsų pranešimus priimantis galinis taškas turėtų būti idempotentinis. Praktiškai tai reiškia, kad tą patį pranešimą apdorojus daugiau nei vieną kartą nebus siunčiami pasikartojantys el. laiškai, kuriami pasikartojantys bilietai ar pakartotinai inicijuojami sandėlio veiksmai. Taip pat nuspręskite, ar jūsų sistemai reikia originalaus įvykio laiko, pranešimo laiko, ar abiejų.
4. Aiški API dokumentacija ir pavyzdžiai
Dokumentacija yra produkto funkcija. Prieš pasirašydamas sutartį inžinierius turėtų gebėti suprasti autentifikavimą, užklausų formatus, atsakymo laukus, būsenos kodus, puslapiavimą, webhook veikimą ir dažniausius gedimų atvejus visiškai nepasikliaudamas pardavimų kontaktu.
Ieškokite išsamių pavyzdžių jūsų komandos naudojamomis programavimo kalbomis. Patikrinkite, ar dokumentacijoje paaiškinti privalomi ir pasirenkami parametrai, laukų tipai, datos formatai, regioniniai nustatymai ir skirtumas tarp netinkamai suformuotos užklausos bei tinkamos užklausos dėl nežinomos siuntos.
Gera dokumentacija taip pat turėtų paaiškinti versijų valdymą ir pakeitimų valdymą. Paklauskite, prieš kiek laiko tiekėjas praneša apie lauko pašalinimą, įvykio reikšmės pakeitimą ar naujos atsakymo struktūros įvedimą. Jei viešas dokumentas neišsamus, laikykite tai dalyku, kurį reikia išsiaiškinti, o ne manykite, kad tokia funkcija neegzistuoja.
5. Nuspėjamas autentifikavimas ir prieigos kontrolė
Sekimo API tvarkys veiklos duomenis, kurie gali būti susieti su klientų užsakymais. Todėl jai reikia jūsų architektūrai tinkamo saugumo modelio. Įvertinkite, kaip išduodami, keičiami, atšaukiami ir atskiriami kūrimo, testavimo bei gamybinės aplinkos prisijungimo duomenys.
Patvirtinkite, ar paslauga palaiko aplinkų atskyrimą, ribotos apimties prisijungimo duomenis, autentifikavimą serverio pusėje ir jūsų diegimui tinkamus apribojimus. Niekada nedėkite privačių API prisijungimo duomenų į naršyklės kodą ar mobiliąsias programas, nebent tiekėjas aiškiai dokumentuoja saugų tokio naudojimo būdą.
Paklauskite, kaip tiekėjas tvarko įtartiną srautą, prisijungimo duomenų atskleidimą ir paskyros lygio prieigą. Jei API apdoros asmeninę informaciją arba siuntų duomenis keliose rinkose, saugumo sąlygas turėtų peržiūrėti jūsų techninės ir teisinės komandos.
6. Užklausų dažnio ribos, kvotos ir naudojimo matomumas
Užklausų dažnio ribos turi įtakos ir architektūrai, ir kainai. Tiekėjas turėtų paaiškinti užklausų ribas, trumpalaikio srauto elgseną, kvotų laikotarpius, lygiagrečių užklausų apribojimus ir atsakymą, grąžinamą pasiekus ribą. Jei dokumentacijoje šios detalės nenurodytos, paprašykite raštiško patvirtinimo.
Naudojimo modelį kurkite remdamiesi faktiniu darbo procesu. Sistema, kuri kiekvieną užsakymą seka vieną kartą, gali generuoti visiškai kitokį srautą nei sistema, kuri dažnai atnaujina aktyvias siuntas, palaiko klientų savitarnos paiešką ir po importavimo vykdo istorinių duomenų papildymą. Įtraukite pardavimų pikus, masinius įkėlimus, vežėjų vėlavimus ir pakartotines užklausas.
Naudingi veiklos valdikliai apima naudojimo skydus, kvotų įspėjimus, užklausų identifikatorius ir rekomendacijas dėl spartinančiojo kaupimo arba apklausų intervalų. Nemanykite, kad planas, apibūdintas kaip neribotas, neturi sąžiningo naudojimo sąlygų ar techninių ribų. Prieš paleisdami gamybinę aplinką paklauskite, kaip tvarkomi viršijimai ir laikinas srauto ribojimas.
7. Patikimas klaidų tvarkymas ir stebimumas
Sekimo sistemos turi tvarkyti įprastus gedimus: netinkamus sekimo numerius, nepalaikomus vežėjus, laikinus vežėjų sutrikimus, tinklo klaidas, pasikartojančius pateikimus ir vėluojančius duomenis. Patikima API leidžia šiuos atvejus atskirti.
Peržiūrėkite HTTP būsenos kodus, klaidų objektus, klaidų pranešimus ir užklausų identifikatorius. Jūsų programa turėtų gebėti nuspręsti, ar taisyti naudotojo įvestį, bandyti dar kartą vėliau, nukreipti problemą pagalbos tarnybai ar pažymėti siuntą kaip laukiančią pirmojo nuskaitymo. Bendrinės klaidos, tokios kaip „užklausa nepavyko“, automatizuotoms operacijoms nepakanka.
Taip pat patikrinkite tiekėjo būsenos komunikaciją ir pagalbos procesą. API būsenos puslapis gali būti naudingas, tačiau jis nepakeičia programos lygio registravimo. Saugokite užklausos laiką, tiekėjo atsakymą, sekimo identifikatorių ir vidinį koreliacijos ID taip, kad būtų laikomasi jūsų duomenų saugojimo ir privatumo reikalavimų.
8. Duomenų naujumas ir įvykių istorija
Sekimo duomenys naudingi tik tada, kai naudotojai supranta, kiek jie aktualūs. Paklauskite, kaip dažnai paslauga gauna naujinius, ar skirtingi vežėjai atnaujinami skirtingais intervalais ir kaip API nurodo, kada įvykis gautas arba kada jis paskutinį kartą patikrintas.
Įvertinkite, ar atsakyme pateikiama visa įvykių istorija, ar tik naujausia būsena. Visa istorija yra vertinga klientų aptarnavimui, pristatymo tyrimams, pretenzijų procesams ir analizei. Ji taip pat gali atskleisti pasikartojančius, netinkama tvarka pateiktus ar pataisytus įvykius, todėl jūsų duomenų modelis neturėtų manyti, kad kiekvienas naujinys yra visiškai naujas etapas.
Koncepcijos patikrinimo metu palyginkite API atsakymus su vežėjų puslapiais arba vežėjų pateiktais duomenimis, naudodami reprezentatyvią imtį. Nesitikėkite, kad kiekvienas šaltinis atsinaujins tiksliai tuo pačiu metu. Tikslas – suprasti įprastą vėlavimą ir sąlygas, kuriomis duomenys gali būti neišsamūs.
9. Internacionalizacija ir tarptautinių siuntų kontekstas
Tarptautinėms siuntoms reikia daugiau nei išverstos būsenos etiketės. Pirkėjai turėtų galėti suprasti įvykius pageidaujama kalba ir laiko juostoje, o veiklos komandoms gali reikėti originalios vežėjo formuluotės tyrimui.
Patikrinkite lokalizuotų pranešimų, paskirties ir kilmės informacijos, laiko juostų tvarkymo, šalių kodų ir tarptautinių sekimo numerių palaikymą. Nustatykite, ar su muitine susiję įvykiai pateikiami atskirai nuo įprastų tranzito įvykių. Jei muitai, mokesčiai ar muitinės formalumų informacija nepatenka į API taikymo sritį, aiškiai apibrėžkite šią ribą savo produkto dizaine.
Išbandykite siuntas, kurios pakeičia vežėją arba keliauja per kelias šalis. Būsenos modelis, tinkamas vietiniam siuntiniui, gali klaidinti, kai siunta laukia muitinės procedūrų arba buvo perduota vietiniam pristatymo partneriui.
10. Integracijos tinkamumas ir komercinis skaidrumas
Paskutinė funkcija nėra vienas galinis taškas. Tai API tinkamumas sistemoms ir procesams, kuriuos jau naudojate. Susiekite integraciją su užsakymų valdymo sistema, sandėlio įrankiais, el. prekybos platforma, klientų aptarnavimo platforma, analitikos sprendimais ir pranešimų teikėju.
Ieškokite praktinio masinio sekimo, siuntų kūrimo ar registravimo, jei tai aktualu, webhook, testavimo, eksporto ir duomenų saugojimo palaikymo. Patvirtinkite, kurios funkcijos įtrauktos į svarstomą planą, užuot manę, kad kiekvienas dokumentuotas galinis taškas prieinamas kiekvienam klientui.
Kainą reikėtų vertinti atsižvelgiant į numatomą užklausų kiekį, aktyvias siuntas, vežėjų derinį, aplinkas, pagalbos reikalavimus ir augimo modelį. Paklauskite, ar sąskaitos išrašomos pagal užklausas, sekamas siuntas, įvykius ar kitą vienetą. Gaukite raštiškus atsakymus apie minimalius įsipareigojimus, viršijimų tvarkymą, atšaukimą ir plano ribų pakeitimus. Jei kainos viešai nenurodytos, pažymėkite jas tiesioginiam patvirtinimui, o ne bandykite jas apskaičiuoti.
Kaip praktiškai įvertinti sekimo API
- Apibrėžkite siuntų aibę. Išvardykite vežėjus, šalis, paslaugas, sekimo numerių formatus ir siuntų kiekius, kuriuos tikitės apdoroti.
- Parašykite priėmimo kriterijus. Nurodykite būsenas, įvykių laukus, naujumo lūkesčius, pranešimų elgseną ir klaidų atsakymus, kurių reikia jūsų programai.
- Saugiai naudokite realius pavyzdžius. Išbandykite pristatytas, kelyje esančias, vėluojančias, grąžintas, netinkamas, tarptautines ir naujai sukurtas siuntas. Pašalinkite nereikalingą asmeninę informaciją.
- Išbandykite visą gyvavimo ciklą. Siųskite užklausas, gaukite įvykius, pakartokite nepavykusias užklausas, apdorokite dublikatus ir patvirtinkite, kaip jūsų sistema elgiasi vėluojant vežėjo duomenims.
- Išmatuokite veiklos pastangas. Užregistruokite integracijos laiką, dokumentacijos spragas, pagalbos atsakymų kokybę, stebėjimo poreikius ir normalizavimo apimtį, kurią turi sukurti jūsų komanda.
- Patvirtinkite komercines sąlygas. Susiekite išbandytą darbo eigą su siūlomu planu ir paprašykite paaiškinti kiekvieną nepatvirtintą ribą ar funkciją.
Kur 17TRACK atitinka vertinimą
17TRACK teikia specializuotą Tracking API produktą ir skelbia API dokumentaciją kūrėjams. Todėl tai yra aktualus pasirinkimas, kurį verta įtraukti, kai reikia kelių vežėjų siuntų matomumo, o ne konkrečiam vežėjui skirtos integracijos. Peržiūrėkite oficialią API medžiagą kartu su savo vežėjų sąrašu, pavyzdiniais sekimo numeriais, įvykių reikalavimais ir numatomu srautu.
Teisinga pirkimo išvada turėtų būti grindžiama kontroliuojamu testu, o ne vien prekės ženklo žinomumu. Patikrinkite jūsų verslui svarbius vežėjus ir funkcijas, patvirtinkite taikomas paskyros sąlygas ir įvertinkite, kaip grąžinami duomenys dera su jūsų vidiniu būsenos modeliu. Tas pats kontrolinis sąrašas taikomas ir lyginant 17TRACK su kitais sekimo API teikėjais.
Pirkėjo sprendimo kontrolinis sąrašas
- Ar vežėjų katalogas atitinka jūsų faktinius siuntimo maršrutus?
- Ar API gali atskirti reikšmingas pristatymo būsenas ir išsaugoti vežėjo informaciją?
- Ar webhook, pakartotiniai bandymai, autentifikavimas ir dublikatų tvarkymas yra dokumentuoti?
- Ar jūsų komanda gali išbandyti API su realistiškais siuntų pavyzdžiais?
- Ar aiškios užklausų dažnio ribos, naudojimo vienetai, pagalbos sąlygos ir plano ribos?
- Ar galite stebėti klaidas ir paaiškinti klientams duomenų naujumą?
- Ar API tinkamai tvarko tarptautines ir kelių vežėjų keliones?
- Ar yra dokumentuotas perkėlimo ir versijų valdymo kelias?
DUK
Ar turėčiau rinktis API su didžiausiu vežėjų sąrašu?
Nebūtinai. Rinkitės tiekėją, kuris patikimai apima jūsų siuntų aibėje esančius vežėjus, paskirties vietas ir paslaugas. Mažesnė, bet aktuali aprėptis gali būti naudingesnė už didesnį sąrašą, kuris neatitinka jūsų maršrutų ar įvykių reikalavimų.
Ar webhook yra geresni už apklausas?
Jie sprendžia skirtingas problemas. Webhook gali sumažinti nereikalingas apklausas ir padėti jūsų programai greitai reaguoti į naujinius, o apklausos gali būti atsarginis arba periodinio suderinimo procesas. Patikimas sprendimas, priklausomai nuo dokumentuotos tiekėjo elgsenos, gali naudoti įvykių pranešimus kartu su kontroliuojamu suderinimu.
Ką turėčiau išbandyti koncepcijos patikrinimo metu?
Išbandykite įprastus ir sudėtingus atvejus: naują sekimo numerį, kelyje esantį siuntinį, pristatytą siuntą, vėlavimą, grąžinimą, netinkamą numerį, tarptautinę siuntą, pasikartojančius pranešimus ir laikiną API gedimą. Įvertinkite tiek duomenų kokybę, tiek inžinerines pastangas, reikalingas saugiam naudojimui.
Kaip dažnai sekimo API turėtų atnaujinti siuntų duomenis?
Nėra vieno intervalo, taikomo kiekvienam vežėjui ar paslaugai. Paklauskite, kaip apibrėžiamas naujumas, kada siunta buvo paskutinį kartą patikrinta ir kaip vežėjo vėlavimai veikia atsakymą. Klientų lūkesčius nustatykite remdamiesi duomenimis, kuriuos API iš tikrųjų pateikia.
Ar galiu pasikliauti vien API normalizuota būsena?
Naudokite normalizuotas būsenas nuosekliems procesams, tačiau, jei įmanoma, išsaugokite originalią įvykio informaciją. Vežėjo formuluotės, laiko žymos ir vietos gali būti svarbios pagalbos tarnybos tyrimams, išimčių tvarkymui ir ginčams.
