Kaip pasirinkti siuntų sekimo API pristatymams į kelias Pietryčių Azijos šalis
Pasirinkite siuntų sekimo API Pietryčių Azijai, išbandydami savo faktinius siuntimo maršrutus, vežėjų perdavimus ir išimčių valdymo procesus, o ne lygindami viešai nurodomą vežėjų skaičių. Tinkamas API turėtų sujungti siuntos įvykius tarptautinio ir vietinio pristatymo etapuose, išsaugoti naudingą informaciją apie vežėją ir pateikti atnaujinimus, kuriuos jūsų sistemos gali patikimai apdoroti. Sprendimą grįskite maršrutų lygio našumu, integracijos atsparumu ir bendra veiklos kaina.
Šis vadovas skirtas elektroninės prekybos operacijų komandoms ir jas palaikantiems kūrėjams. Praktinis tikslas – paversti vežėjų sekimo duomenis patikimais klientų atnaujinimais ir įgyvendinamomis pristatymo išimtimis, nekuriant atskiros integracijos kiekvienam siuntimo partneriui.
Pradėkite nuo siuntimo maršrutų, o ne nuo teiginio apie regiono aprėptį
Teiginys, kad API palaiko Pietryčių Aziją, yra per daug bendras pirkimui. Jūsų poreikis yra konkretesnis: tam tikra siuntimo paslauga, teikiama tarp konkrečių šalių, kai už kiekvieną etapą atsakingi konkretūs partneriai.
Pavyzdžiui, siuntos, į Malaiziją patenkančios per tarptautinį logistikos partnerį, sekimo kelias gali skirtis nuo vietinės Malaizijos siuntos. Laikykite jas atskirais testavimo atvejais, net jei galutinė pristatymo įmonė yra ta pati. Taip pat sėkmingas sekimas vienu maršrutu nepatvirtina visų to vežėjo siūlomų paslaugų aprėpties.
Prieš prašydami demonstracijos, sudarykite maršrutų sąrašą. Įtraukite dabartinę veiklą ir realistiškus plėtros planus, o ne kiekvieną šalį, kurioje galbūt kada nors teiksite paslaugas.
| Reikalavimas | Ką registruoti | Kodėl tai svarbu |
|---|---|---|
| Siuntimo maršrutas | Kilmės šalis, paskirties vieta, paslauga ir siuntimo partneris | Vien šalių lygio aprėptis nepatvirtina jūsų naudojamos paslaugos. |
| Pristatymo grandinė | Žinomi tarptautiniai, pašto ir paskutinės mylios partneriai | Matomumą būtina išbandyti per perdavimo etapus. |
| Identifikatoriai | Pradinis numeris, pakaitinis numeris ir užsakymo nuoroda | Jūsų sistema turi susieti atnaujinimus su tinkamu siuntiniu. |
| Veiklos poreikis | Klientų atnaujinimai, išimčių eilės arba pristatymo suderinimas | Skirtingiems procesams reikia skirtingo įvykių detalumo ir laiko. |
Pažymėkite maršrutus kaip kritinius verslui arba pasirinktinius. Platus tinklas neturėtų kompensuoti neįvykdyto reikalavimo maršrute, kuriuo siunčiama reikšminga jūsų užsakymų dalis.
Patikrinkite, ar matomumas išlieka perdavimo metu
Tarptautinis siuntimas sukuria skirtumą tarp sekimo numerio atpažinimo ir siuntos sekimo iki pristatymo. Vertindami paslaugą, paprašykite teikėjo pademonstruoti visą tipinių siuntų įvykių istoriją, įskaitant perdavimą paskirties vietos pristatymo partneriui.
Vežėjo identifikavimas ir sekimo numerio pakeitimai
Paklauskite, kaip nustatomas vežėjas, kai numeris gali priklausyti daugiau nei vienam vežėjui. Ar jūsų integracija gali pateikti vežėjo identifikatorių? Ar neteisingą priskyrimą galima ištaisyti? Kas nutinka, jei siuntimo partneris išduoda antrą sekimo numerį?
Nelaikykite savaiminio aptikimo visų atvejų sprendimu. Kai įmanoma, išsaugokite vežėjo ir paslaugos informaciją iš savo siuntimo sistemos. Taip pat patvirtinkite, ar susiję sekimo numeriai susiejami automatiškai, grąžinami atskiruose laukuose, ar juos turite susieti savo duomenų bazėje.
Įvykių reikšmė ir pradinė išsami informacija
Normalizuota būsena naudinga vykdant bendrą procesą su skirtingais vežėjais. Tačiau plati etiketė, pavyzdžiui, „išimtis“, nėra pakankama nuspręsti, ar pagalba turėtų susisiekti su klientu, paprašyti vežėjo atnaujinimo, ar palaukti muitinės procedūrų.
Vertinkite ir normalizuotą būseną, ir pagrindinį įvykį. Jei įmanoma, išsaugokite pradinį aprašą, vietą, vežėjo tapatybę, įvykio laiko žymą ir laiko juostos informaciją. Patikrinkite, ar jūsų programa gali atskirti nepavykusį pristatymo bandymą nuo grąžinimo arba su muitine susijusio sulaikymo.
Vertimas gali padėti agentams suprasti įvykį, tačiau jis neturėtų pakeisti pradinio teksto audito žurnale. Paklauskite, kaip generuojami išversti aprašai ir kaip tvarkomi dviprasmiški pranešimai.
Siuntos tapatybė ir užsakymo tapatybė
Viename užsakyme gali būti keli siuntiniai. Užsakymo būseną laikykite atskirai nuo siuntinio būsenos ir apibrėžkite, kada užsakymas laikomas visiškai pristatytu. Priešingu atveju vienas pristatytas siuntinys gali sukelti klaidinantį pranešimą, kol kitas siuntinys dar gabenamas.
Matuokite atnaujinimų šviežumą, nepainiokite jo su pristatymo greičiu
Sekimo API pateikia informaciją apie siuntą, tačiau nepadaro siuntos greitesnės. Vėluojantis atnaujinimas gali atsirasti dar prieš API gaunant įvykį, o pats API taip pat gali sukelti papildomą apdorojimo ar pristatymo vėlavimą. Atliekant testą reikia atskirti šias galimybes.
Jei įmanoma, užfiksuokite tris laiko žymas:
- Vežėjo įvykio laikas: kada užfiksuota, kad pagrindinis siuntos įvykis įvyko.
- Teikėjo apdorojimo laikas: kada sekimo teikėjas gauna arba apdoroja tą įvykį, jei ši informacija atskleidžiama.
- Programos gavimo laikas: kada jūsų sistema gauna pranešimą arba gavimo atsakymą.
Registruokite laiko juostų poslinkius ir atskirkite įvykio laiką nuo gavimo laiko. Jei apdorojimo laiko žymos neprieinamos, matavimą apibūdinkite kaip viso ciklo stebėjimo vėlavimą, o ne priskirkite jį vien API.
Apibrėžkite priimtiną atnaujinimų šviežumą pagal procesą. Klientams skirtam sekimo puslapiui ir išimčių valdymo komandai gali būti taikomi skirtingi reikalavimai. Paklauskite, ar atnaujinimo elgsena skiriasi pagal vežėją, siuntos būseną ar paslaugų planą, ir patvirtinkite šias sąlygas prieš pasikliaudami žadėtu atnaujinimo intervalu.
Vertinkite integraciją sutrikimų, o ne tik įprastomis sąlygomis
Sėkmingas pavyzdinis atsakymas mažai ką įrodo apie patikimumą gamybinėje aplinkoje. Jūsų inžinerijos komanda turėtų išbandyti registravimą, atnaujinimus, pakartotinius bandymus, suderinimą ir atkūrimą.
- Siuntos registravimas: Patikrinkite tikrinimo klaidas, pasikartojančius pateikimus, paketų ribas ir tai, ar vienas netinkamas įrašas paveikia likusią paketo dalį.
- Webhook veikimas: Patvirtinkite galimus autentifikavimo ar tikrinimo būdus, patvirtinimo reikalavimus, pakartotinių bandymų taisykles ir atkūrimo galimybes po sutrikimo.
- Pasikartojantys ir ne eilės tvarka gaunami įvykiai: Įsitikinkite, kad pakartotiniai pranešimai nesiunčia pakartotinių klientų pranešimų ir neteisingai negrąžina siuntos į ankstesnę būseną.
- Suderinimas: Nustatykite, ar gavimo galiniai taškai arba kitas palaikomas procesas gali atkurti atnaujinimus, kuriuos praleido jūsų webhook gaviklis.
- Užklausų dažnio ribos: Išbandykite numatomus pikus, atsitraukimo elgseną ir dokumentuotas registravimo bei gavimo ribų skirtis.
- Schemų pakeitimai: Paklauskite apie versijavimą, pranešimus apie atsisakymą ir tai, kaip jūsų programa turėtų tvarkyti neatpažįstamas būsenų reikšmes ar papildomus laukus.
Praktiškas gaviklio projektas – patikrinti užklausą, patikimai ją priimti, greitai patvirtinti gavimą ir apdoroti asinchroniškai. Kai įmanoma, dubliavimui šalinti naudokite teikėjo dokumentuotą įvykio identifikatorių. Priešingu atveju sukurkite ir išbandykite dubliavimo šalinimo taisyklę, pagrįstą stabiliais įvykio laukais, o ne manykite, kad kiekvienas pranešimas yra unikalus.
Neatmeskite senesnio įvykio vien todėl, kad jis atkeliavo vėlai. Išsaugokite jį istorijoje, o dabartinę siuntos būseną apskaičiuokite pagal aiškias taisykles. Vėluojanti istorija ir tikras grąžinimas turi būti tvarkomi skirtingai.
Kurkite API stebėseną pagal verslo simptomus
HTTP sėkmės rodikliai yra būtini, bet nepakankami. Techniškai sėkminga užklausa vis tiek gali grąžinti tuščią istoriją, netikėtą vežėjo priskyrimą arba įvykį, kuris negali valdyti jūsų proceso.
Stebėkite techninius ir veiklos rodiklius kartu:
- Registravimo klaidas ir neišspręstus sekimo numerius, suskirstytus pagal maršrutą ir vežėją.
- Webhook gavimo klaidas, apdorojimo atsilikimą ir pasikartojančių įvykių dažnį.
- Laiką nuo paskutinio gauto atnaujinimo, vertinamą pagal siuntos etapą ir paslaugos lūkesčius.
- Pristatytas siuntas, kurios niekada nepasiekia jūsų užsakymų valdymo sistemos.
- Išimtis, kuriose trūksta pakankamai informacijos, kad agentas galėtų pasirinkti kitą veiksmą.
Neaktyvi siunta nebūtinai yra prarasta siunta. Nustatykite eskalavimo taisykles pagal vežėjo rekomendacijas, paslaugų įsipareigojimus ir savo veiklos istoriją. Netaikykite vienos neveiklumo ribos visoms šalims ir paslaugoms.
Palyginkite apmokestinamą vienetą ir veiklos naštą
Nelyginkite pasiūlymų, kol nesuprasite, ką skaičiuoja kiekvienas pasiūlymas. Paklauskite, ar mokesčiai priklauso nuo registruotų siuntų, užklausų, aktyvių sekimo įrašų, pranešimų ar kito vieneto. Tai yra pirkimo klausimai, o ne prielaidos apie kurio nors teikėjo kainodarą.
Prašykite raštiško paaiškinimo dėl pasikartojančio registravimo, pakartotinio sekimo, ilgesnių gabenimo laikotarpių, saugojimo, testavimo leidimų, viršijimų ir pagalbos. Taip pat paklauskite, kurios funkcijos įtrauktos į siūlomą planą, užuot manę, kad dokumentacijoje nurodyta galimybė įtraukta į kiekvieną sutartį.
Įvertinkite bendrą kainą pagal įprastą darbo krūvį ir piko scenarijų. Be teikėjo mokesčių įtraukite inžinerinės priežiūros ir rankinio tyrimo laiką. Mažesnė prenumeratos kaina nebūtinai reiškia mažesnę bendrą kainą, jei darbuotojai turi nuolat atkurti trūkstamus perdavimus.
Tuo pačiu metu peržiūrėkite duomenų tvarkymą. Siųskite tik integracijai reikalingą informaciją ir patikrinkite, ar konkretiems vežėjams ar paslaugoms būtini gavėjo duomenys. Paklauskite apie saugojimą, prieigos kontrolę, ištrynimo procedūras, subrangovus ir sutartines duomenų tvarkymo sąlygas. Įtraukite privatumo ar teisės komandą į reikalavimus jurisdikcijose, kuriose vykdote veiklą.
17TRACK vieta vertinimo procese
17TRACK Tracking API yra tinkamas variantas, kurį verta įvertinti kelių vežėjų integracijai. Pradėkite nuo oficialaus Tracking API puslapio ir kūrėjams skirtos dokumentacijos, tada palyginkite pirmiau nurodytus reikalavimus su planuojamu įgyvendinimu ir komercinėmis sąlygomis.
Prašykite patvirtinti jūsų nurodytus vežėjus, paslaugų tipus, perdavimo scenarijus, pranešimų reikalavimus ir numatomą apimtį. Patikrinkite atsakymus naudodami tipines siuntas, o ne laikykite produkto apžvalgą visų maršrutų įrodymu.
Aiškiai apibrėžkite taikymo sritį: šis sprendimas susijęs su API, tiekiančiu duomenis jūsų sistemoms. Vartotojams skirtas sekimo puslapis ar parduotuvės programa nepakeičia API veikimo, integracijos valdiklių ir sutartinių reikalavimų patikros. Taip pat vien sekimo duomenų nepakanka, kai tikrasis poreikis yra siuntų užsakymas, etikečių kūrimas ar muitinės deklaracijų tvarkymas; šiuos procesus patikrinkite atskirai.
Atlikite koncepcijos patikrą su aiškiais priėmimo kriterijais
Naudokite istorines siuntas įvykių interpretacijai patikrinti, o gyvas siuntas – atnaujinimų pateikimui įvertinti. Įtraukite įprastus pristatymus, tačiau sąmoningai pridėkite sudėtingus atvejus: neaiškų vežėją, pakeistą sekimo numerį, pristatymo bandymą, su muitine susijusį įvykį, grąžinimą ir padalytą užsakymą.
- Nustatykite reikalavimus prieš testavimą. Nurodykite privalomus maršrutus, būtinus laukus, priimtiną atnaujinimo vėlavimą ir atkūrimo lūkesčius. Tai yra jūsų priėmimo kriterijai, o ne universalūs pramonės standartai.
- Sukurkite atskaitos įrašą. Kiekvienai siuntai išsaugokite siuntimo sistemos duomenis ir svarbią vežėjo sekimo istoriją. Pažymėkite, kada užfiksavote kiekvieną stebėjimą.
- Patikrinkite visą procesą. Užregistruokite siuntą, gaukite atnaujinimus, parodykite sekimo informaciją, atidarykite išimtis ir suderinkite pristatymą užsakymų valdymo sistemoje.
- Sukelkite kontroliuojamus sutrikimus. Testavimo aplinkoje nutraukite gaviklio veikimą, pateikite dublikatus ir patikrinkite netinkamus identifikatorius. Įsitikinkite, kad atkūrimui nereikės rankinio atkūrimo.
- Peržiūrėkite neatitikimus pagal priežastį. Atskirskite trūkstamus ankstesnės grandies įvykius, vežėjų susiejimo klaidas, teikėjo apdorojimo problemas ir savo integracijos defektus.
- Dokumentuokite sprendimą. Kiekvieną reikalavimą pažymėkite kaip įvykdytą, neįvykdytą arba laukiantį patvirtinimo, nurodydami įrodymus ir atsakingą asmenį.
Prieš taikydami svertinį balą naudokite privalomus vartus. Kritinis privatumo reikalavimas ar nepalaikomas pagrindinis maršrutas neturėtų pranykti palankiame vidurkyje. Tarp šiuos vartus įveikusių teikėjų pirmenybę teikite tinkamų naudoti įvykių duomenų, patikimo atkūrimo ir tvarios veiklos kainos deriniui.
Operacijų vadovas turėtų būti atsakingas už išimčių naudingumą, inžinerijos komanda – už integracijos atsparumą, o pirkimų ir teisės komandos turėtų patvirtinti komercines bei duomenų sąlygas. Diegimą patvirtinkite tik tada, kai šie atsakingi asmenys sutaria ir dėl galimybių, ir dėl likusių apribojimų.
DUK
Ar man reikia atskiro sekimo API kiekvienai Pietryčių Azijos šaliai?
Nebūtinai. Kelių vežėjų API gali patenkinti jūsų poreikius keliose šalyse, tačiau patikrinkite kiekvieną naudojamą vežėją, paslaugą ir maršrutą. Atskirą integraciją pridėkite tik tada, kai dokumentuotas trūkumas ar specialus reikalavimas pateisina priežiūros kainą.
Ar vežėjo palaikymas garantuoja matomumą iki galutinio pristatymo?
Ne. Vežėjo įtraukimas į sąrašą nepatvirtina kiekvienos paslaugos ar partnerio perdavimo rezultato. Išbandykite visą siuntos istoriją, įskaitant antrinį identifikatorių ir pristatymo paskirties vietoje įvykius.
Ar turėčiau naudoti webhook ar apklausas?
Jei palaikomi, webhook gali sumažinti pasikartojančių gavimo užklausų skaičių. Suderinimo procesas gali padėti atkurti praleistus atnaujinimus. Pasirinkite derinį, kurį leidžia teikėjo dokumentuotos ribos ir atkūrimo mechanizmai, ir išbandykite jį sutrikimo metu.
Kiek laiko turėtų trukti sekimo API bandymas?
Vykdykite jį pakankamai ilgai, kad stebėtumėte jūsų siuntoms aktualų gyvavimo ciklą ir svarbius išimčių atvejus. Nustatytas kalendorinis laikotarpis yra mažiau naudingas nei būtinų scenarijų užbaigimas. Istoriniai įrašai gali papildyti gyvą bandymą, tačiau negali patvirtinti tiesioginių pranešimų patikimumo.
Ar API gali tiksliai pasakyti klientams, kada siunta atvyks?
Numatomą pristatymo datą naudokite tik tada, kai pasirinkta paslauga pateikia jūsų procesui tinkamą datą. Patvirtinkite jos šaltinį, reikšmę ir atnaujinimo elgseną. Nepaverskite neseno sekimo įvykio nepagrįstu pristatymo pažadu.
Šaltiniai
Toliau pateikti oficialūs ištekliai yra pradiniai punktai, skirti šiame vadove aptartiems 17TRACK produkto ir diegimo patikrinimams. Maršrutų lygio priėmimo kriterijai, stebėsenos rekomendacijos ir koncepcijos patikros procedūros yra redakcinės gairės, o ne pateikti produkto našumo rezultatai.
- 17TRACK Tracking API — oficiali produkto informacija, skirta API tinkamumui vertinti.
- 17TRACK API dokumentacija — oficiali techninė informacija, kurią reikia peržiūrėti patvirtinant integracijos reikalavimus ir palaikomą elgseną.
