Kaip pasirinkti JAV siuntų sekimo API: aprėptis, atnaujinimai ir integracija

Pasirinkite JAV siuntų sekimo API išbandydami savo faktinį vežėjų derinį, įvertindami, kaip greitai tinkami naudoti sekimo įvykiai pasiekia jūsų sistemą, ir patikrindami, kaip integracija veikia, kai užklausos ar pranešimai nepavyksta. Ilgo vežėjų sąrašo nepakanka. Tinkamas API turi palaikyti jūsų naudojamas siuntimo paslaugas, išsaugoti reikšmingą siuntos informaciją ir atitikti jūsų inžinerijos, klientų aptarnavimo bei el. prekybos operacijų komandų darbo eigą.

Tik JAV veikiančiai įmonei tai gali reikšti patikimą vietinių siuntų paslaugų matomumą. Tarpvalstybiniam pardavėjui, siunčiančiam į Jungtines Valstijas, tai taip pat reiškia siuntos stebėjimą nuo transportavimo kilmės šalyje, su muitine susijusių įvykių ir perdavimo paskutinės mylios vežėjams. Šiuos maršrutus vertinkite atskirai, o ne manykite, kad vežėjo pavadinimo palaikymas garantuoja išsamų sekimą.

Pradėkite nuo siuntimo darbo eigų, o ne nuo tiekėjų sąrašo

API dažnai renkasi inžinerijos vadovas arba operacijų vadovas, tačiau nuo rezultato priklauso kelios komandos. Klientų aptarnavimui reikia suprantamų pristatymo išimčių. Operacijoms reikia rasti siuntas, kurioms reikia įsikišimo. Kūrėjams reikia nuspėjamų duomenų paketų ir atkuriamų klaidų. Finansams reikia atsiskaitymo modelio, atitinkančio faktinį naudojimą.

Prieš vertindami tiekėjus, parenkite trumpą reikalavimų dokumentą naudodami naujausius siuntų įrašus. Įtraukite vežėją, paslaugą, kilmės ir paskirties šalis, sekimo identifikatorių, siuntos sukūrimo datą ir pristatymo rezultatą. Pašalinkite vertinimui nereikalingą klientų informaciją.

• Apibrėžkite siuntų apimtį: vietinės JAV siuntos, įvežamos tarptautinės siuntos, išvežamos siuntos arba jų derinys.
• Nustatykite sistemas, kurios naudos duomenis: užsakymų valdymo sistema, klientų aptarnavimo platforma, sandėlio programa, klientų sekimo puslapis arba vidinė išimčių skydinė.
• Nurodykite sprendimus: kada informuoti klientą, sukurti klientų aptarnavimo užduotį, ištirti užstrigusią siuntą arba pažymėti užsakymą kaip pristatytą.
• Atskirkite privalomus reikalavimus nuo pageidavimų: būtina vežėjo paslauga turėtų būti svarbesnė už patogią skydinės funkciją.

Paskirkite galutinio priėmimo sprendimo savininką ir įtraukite inžinerijos bei operacijų komandas į testą. Integracija gali veikti techniškai, tačiau vis tiek generuoti būsenas, kurių klientų aptarnavimo agentai negali panaudoti.

Patikrinkite aprėptį paslaugos ir siuntos lygiu

Vežėjų aprėptį laikykite patikrinamu reikalavimu, o ne reklaminiu skaičiumi. Paklauskite, ar tiekėjas palaiko kiekvieną aktualią paslaugą, siuntos kryptį ir identifikatoriaus formatą. Taip pat patvirtinkite, ar siuntai užregistruoti arba identifikuoti reikia papildomos informacijos, pavyzdžiui, aiškiai pasirinkti vežėją ar nurodyti kitą siuntos atributą.

Testų rinkinį sudarykite pagal jūsų verslui svarbias siuntas. Įtraukite didžiausios apimties maršrutus, mažesnės apimties, bet operaciniu požiūriu svarbias paslaugas ir siuntas su išimtimis. Testuojant tik nesudėtingus pristatymus gali likti nepastebėti trūkumai, kurie greičiausiai sukels papildomo darbo klientų aptarnavimui.

Aprėpties sritis	Ką patikrinti	Kodėl tai svarbu
Vietinės JAV paslaugos	Sekimas veikia su konkrečiomis jūsų siuntų paslaugomis, o ne tik su vežėjo prekės ženklu.	Aprėpties teiginiai gali būti platesni nei jūsų veiklos reikalavimai.
Tarpvalstybiniai perdavimai	Įvykiai lieka susieti su siunta, kai pristatymą perima kitas vežėjas.	Priešingu atveju po perdavimo paskirties šalies etapas gali likti neaiškus.
Sekimo identifikavimas	Neaiškius identifikatorius galima išspręsti arba pateikti kartu su aiškiai nurodytu vežėju.	Neteisingas identifikavimas gali pateikti trūkstamus arba nesusijusius rezultatus.
Išimčių matomumas	Bandymai pristatyti, grąžinimo procesas ir kitos aktualios išimtys išlieka suprantamos.	Šie įvykiai lemia įsikišimą, o ne įprastus pranešimus.

Tarpvalstybiniam siuntimui tikrinkite visą maršrutą

Į JAV įvežama siunta gali apimti daugiau nei vieną logistikos operatorių. Paklauskite, kaip API pateikia papildomus sekimo numerius, vežėjų pasikeitimus ir skirtingų etapų įvykius. Ar jis atskleidžia ryšį tarp identifikatorių, ar jūsų programa turi valdyti šį ryšį? Ar klientų aptarnavimo agentai gali atskirti pradinį vežėją nuo pristatančio vežėjo?

Nelaikykite nuskaitymų nebuvimo įrodymu, kad siunta nustojo judėti. Jūsų programa turi atskirti nurodytą išimtį nuo naujos informacijos trūkumo. Šioms sąlygoms reikia skirtingų pranešimų klientams ir skirtingų operacinių veiksmų.

Matuokite naujinių aktualumą nepainiokite jo su matomumu realiuoju laiku

Sekimo aktualumą sudaro keli komponentai: kada įvyksta fizinis įvykis, kada vežėjas jį paskelbia, kada sekimo tiekėjas jį gauna ir kada jūsų programa jį apdoroja. Webhook gali perduoti naujai pasiekiamus duomenis jūsų sistemai, tačiau dėl to pagrindiniai vežėjo duomenys netampa momentiniai.

Pilotinio projekto metu registruokite laiko žymas, kurias iš tikrųjų galite stebėti. Išsaugokite vežėjo įvykio laiką, pirmąjį įvykio stebėjimą per API, webhook gavimo laiką ir vidinio apdorojimo pabaigą. Patvirtinkite laiko juostų tvarkymą ir, kai praktiška, išsaugokite pradinį laiko žymos formatą.

• Intervalas nuo įvykio iki gavimo: naudingas suprantant bendrą informacijos amžių, tačiau apima ankstesnius vėlavimus ir galimus laiko žymų neatitikimus.
• Pristatymo iš tiekėjo į programą intervalas: išmatuojamas tik tada, kai tiekėjas pateikia tinkamą laiko žymą su aiškiu apibrėžimu.
• Vidinio apdorojimo delsa: laikas, kurio jūsų sistemoms reikia gautam naujiniui paversti tinkama naudoti būsena arba veiksmu.

Palyginkite rezultatus pagal vežėją, paslaugą ir įvykio tipą. Vienas vidurkis gali paslėpti lėtus išimčių naujinius tarp daugybės įprastų tranzito įvykių. Pateikite pasiskirstymą ir ištirkite uždelstus atvejus, o ne remkitės tik greičiausia arba tipiškiausia siunta.

Paklauskite, kas nutinka, kai naujiniai sustoja

Patvirtinkite tiekėjo sekimo gyvavimo ciklą: kada pradedamas stebėjimas, kada jis baigiamas, ar neaktyvios siuntos nustoja galioti ir kaip stebėjimą galima atnaujinti. Paklauskite, kuo naujai užregistruota siunta be įvykių skiriasi nuo nepavykusios registracijos arba nepalaikomo sekimo identifikatoriaus.

Pasenusių siuntų taisykles nustatykite pagal paslaugos lūkesčius ir operacinį kontekstą. Tylus tarptautinis etapas ir praleistas bandymas pristatyti neturėtų automatiškai sukelti to paties įspėjimo. Jūsų komanda turi galėti koreguoti šias taisykles nekeisdama pagrindinių vežėjo įvykių reikšmės.

Įtraukite įvykių kokybę į integracijos vertinimą

Normalizuotos būsenos padeda programoms taikyti nuoseklias taisykles skirtingiems vežėjams. Pradinė įvykio informacija padeda žmonėms suprasti, kas įvyko. Ieškokite duomenų modelio, galinčio patenkinti abu poreikius, ir tikrinkite laukus tikruose atsakymuose, o ne manykite, kad kiekvienoje siuntoje bus ta pati informacija.

Išnagrinėkite, kaip API pateikia įvykių istoriją, vietas, laiko žymas, vežėjo pranešimus ir siuntos lygio būseną. Patikrinkite, kaip tvarkomi trūkstami laukai ir ar būsena gali pasikeisti po tariamai galutinio įvykio. Jei svarbūs pristatymo įverčiai arba pristatymo įrodymo informacija, patvirtinkite jos prieinamumą konkrečioms jūsų paslaugoms ir paskyros susitarimams; nemanykite, kad šie laukai visada užpildomi.

Aiškiai susiekite būsenas su verslo veiksmais. Bandymas pristatyti gali sukurti klientų aptarnavimo užduotį, o pristatymo įvykis gali uždaryti stebėjimo darbo eigą. Išsaugokite pradinį įvykį kartu su normalizuotu jo aiškinimu, kad agentas galėtų peržiūrėti automatizuoto veiksmo pagrindą.

Išbandykite klaidų tvarkymą prieš paleisdami į gamybą

Sėkmingas scenarijus yra tik viena API integracijos dalis. Jūsų programa taip pat turi tvarkyti skirtąjį laiką, netinkamus identifikatorius, dalinius paketinių užklausų gedimus, užklausų ribojimą, pasikartojančius pranešimus ir laikinus sutrikimus. Paprašykite dokumentuoto elgesio aprašo ir išbandykite atvejus, kuriuos tiekėjas leidžia imituoti.

1. Registracija: nustatykite, ar pakartotiniai pateikimai sukuria dublikatus, grąžina esamą įrašą ar sukelia klaidą. Išsaugokite ryšį tarp savo siuntos ID ir tiekėjo identifikatoriaus.
2. Webhook gavimas: patikrinkite galimą autentifikavimo metodą ir atsakymo reikalavimus. Suprojektuokite galinį tašką taip, kad jis greitai patvirtintų priimtus pranešimus, o darbus apdorotų per eilę.
3. Dublikatų tvarkymas: naudokite stabilius įvykių identifikatorius, kai jie prieinami, arba kruopščiai sukurtą dedublikavimo raktą. Pasikartojantys pranešimai neturėtų siųsti pasikartojančių el. laiškų klientams.
4. Eiliškumas: išbandykite vėluojančius istorinius įvykius. Nemanykite, kad gavimo tvarka visada sutampa su įvykių tvarka.
5. Atkūrimas: nustatykite, kaip po sutrikimo gauti dabartinę būseną arba įvykių istoriją, atsižvelgdami į tiekėjo prieinamus galinius taškus ir saugojimo taisykles.
6. Užklausų ribos: patvirtinkite užklausų ribas, paketų apribojimus, pakartotinio bandymo rekomendacijas ir elgesį viršijus ribą.

Webhook laikykite atkuriamos darbo eigos įvestimi, o ne vienintele siuntos informacijos kopija. Jei palaikoma, saugomų siuntų ir dabartinių tiekėjo įrašų suderinimas gali padėti nustatyti praleistus naujinius. Koordinuokite šį procesą su užklausų ribomis ir atsiskaitymo taisyklėmis.

Stebėkite verslo nesėkmes, ne tik API klaidas

API stebėsena turėtų apimti užklausų nesėkmes, autentifikavimo klaidas, atsakymo delsą, pranešimų nesėkmes, eilės dydį ir apdorojimo delsas. Pridėkite operacines patikras dėl nepaaiškinamo įvykių apimties sumažėjimo, siuntų, užstrigusių be naujinių, ir neužregistruotų užsakymų.

Galinis taškas, grąžinantis sėkmingus atsakymus, negarantuoja naudingų sekimo duomenų. Įspėjimus suskirstykite pagal vežėją arba paslaugą, kad lokalizuota problema nedingtų bendrame sveikos sistemos sėkmės rodiklyje.

Palyginkite komercines sąlygas ir duomenų tvarkymą

Prieš lygindami kainas nustatykite, už ką taikomas mokestis. Paklauskite, ar mokesčiai susiję su užregistruotais sekimo numeriais, stebimomis siuntomis, užklausomis ar kitu vienetu. Išsiaiškinkite pasikartojančias registracijas, netinkamus pateikimus, pakartotinį sekimą, istorines užklausas, naudojimą viršijus plano ribas ir atskirus pagalbos susitarimus.

Įvertinkite išlaidas pagal numatomą siuntų derinį ir darbo eigą, įskaitant pakartotinius bandymus bei suderinimą, kai taikoma. Mažas reklamuojamas tarifas nepakankamas sąskaitai prognozuoti, o brangesnis planas automatiškai nėra patikimesnis. Rašytines sąlygas vertinkite kartu su išmatuotais pilotinio projekto rezultatais.

Tvarkydami duomenis nustatykite, kurie siuntos ir klientų laukai yra būtini. Peržiūrėkite prieigos kontrolę, prisijungimo duomenų keitimą, saugojimą, trynimo procesus, subrangovus ir sutartines atsakomybes. Nesaugokite paslapčių programos žurnaluose ir apribokite prieigą prie sekimo duomenų tik toms komandoms, kurioms jos reikia. Pagal jūsų organizacijos reikalavimus atlikite tinkamą teisinę arba saugumo peržiūrą.

17TRACK vieta vertinime

Komandoms, vertinančioms kelių vežėjų sekimo integraciją, 17TRACK Tracking API yra tinkamas kandidatas vertinimui. Techninę peržiūrą pradėkite nuo oficialios API dokumentacijos, tada pagal savo siuntų pavyzdį patvirtinkite reikiamus vežėjus, įvykių laukus, naujinių elgesį ir komercines sąlygas.

Vertindami sutelkite dėmesį į API ir nemanykite, kad vartotojų sekimo sąsajos ar kitos programos funkcijos įtrauktos į API susitarimą. Paprašykite patvirtinti reikalavimus, kurie nėra aiškiai nurodyti taikomoje dokumentacijoje ar sutartyje. Tinkamumas turėtų būti nustatomas pagal testų rezultatus, o ne bendrą teiginį apie vežėjų skaičių.

Vykdykite pilotinį projektą su rašytiniais priėmimo kriterijais

Priėmimo kriterijus nustatykite prieš prasidedant pilotiniam projektui. Naudokite istorines siuntas įvykių išsamumui tikrinti, o aktyvias siuntas – gaunamiems naujiniams vertinti. Įtraukite įprastus pristatymus, išimtis, aktualius tarpvalstybinius perdavimus ir kontroliuojamus integracijos gedimus.

• Aprėptis: reikiamos paslaugos pateikia tinkamus naudoti rezultatus, o visos spragos dokumentuojamos.
• Aktualumas: stebimas naujinių laikas atitinka darbo eigos poreikius, o ankstesni ir vidiniai vėlavimai, kai įmanoma, atskiriami.
• Duomenų kokybė: operacijų darbuotojai gali suprasti išimtis, nuolat neatkurdami maršruto kitose sistemose.
• Atsparumas: pasikartojantys įvykiai, nepavykusios užklausos ir praleisti pranešimai nesugadina siuntos būsenos ir nesukelia pasikartojančių veiksmų.
• Operacinė atsakomybė: stebėsena, eskalavimas, prisijungimo duomenų valdymas ir incidentų atkūrimas turi paskirtus atsakingus asmenis.
• Kaina: prognozuojamas atsiskaitymas atspindi faktinius registravimo ir gavimo modelius.

Pasirinkite API, atitinkantį privalomus reikalavimus ir keliančiam valdomą operacinę riziką. Jei jūsų siuntimo tinklas siauras ir stabilus, įvertinkite, ar pakanka tiesioginės integracijos su vežėju. Jei jūsų darbo eigos apima kelis vežėjus arba tarptautinius perdavimus, įvertinkite, ar bendra integracija sumažina priežiūrą neprarandant jums reikalingos informacijos. Nei vienas būdas neturėtų apeiti testavimo siuntos lygiu.

DUK

Ar sekimo API pateikia tiesioginę GPS vietą?

Nemanykite, kad taip. Siuntų sekimo įvykiai ir nuolatinė GPS vieta yra skirtingi duomenų produktai. Jei jūsų darbo eigai reikia tiesioginės vietos, patikrinkite tikslią paslaugą, duomenų šaltinį, naujinių elgesį ir prieigos sąlygas, o ne spręskite apie šią galimybę vien iš termino „sekimo API“.

Ar turėčiau naudoti webhook, ar apklausą?

Kai reikia įvykiais pagrįstų naujinių, naudokite palaikomus webhook, tačiau pasiruoškite nesėkmingam pristatymui ir pasikartojantiems pranešimams. Apklausą galima naudoti duomenims gauti arba suderinti, jei API tai leidžia. Tinkamas sprendimas priklauso nuo dokumentuotų galimybių, užklausų ribų, atsiskaitymo ir jūsų atkūrimo reikalavimų.

Ar galiu tą patį sekimo numerį naudoti kaip duomenų bazės raktą?

Vietoj to naudokite vidinį siuntos ID. Sekimo numerį, vežėją ir susijusį siuntos kontekstą saugokite kaip susietus laukus. Šis sprendimas yra saugesnis pakeitimų, kelių siuntų viename užsakyme, identifikatoriaus neaiškumo ir vėlesnio sekimo numerio pakartotinio naudojimo atvejais.

Ką daryti, kai API neturi naujinių, bet vežėjo puslapis juos turi?

Patvirtinkite, kad abu šaltiniai nurodo tą pačią siuntą ir vežėją, palyginkite įvykių laiko žymas bei patikrinkite registracijos ir stebėjimo būseną. Užregistruokite pavyzdžius tiekėjo pagalbos komandai. Ištirkite neatitikimą prieš keisdami klientams rodomą būseną arba nuspręsdami, kad paslauga nepalaikoma.

Ar pigiausias sekimo API yra geriausias pasirinkimas mažai parduotuvei?

Tik jei jis taip pat atitinka parduotuvės aprėpties ir darbo eigos poreikius. Sprendime įvertinkite integracijos priežiūrą, išimčių tvarkymą ir pagalbos sąnaudas. Maža įmonė pagrįstai gali teikti pirmenybę paprastesnei sąrankai, tačiau jai vis tiek reikia patikimos registracijos, suprantamų įvykių ir atkūrimo plano.

Šaltiniai

• 17TRACK Tracking API — oficiali šiame vadove aptariamo API kandidato produkto informacija.
• 17TRACK API dokumentacija — oficiali techninė informacija integracijos reikalavimams įvertinti ir taikomam API elgesiui patvirtinti.