PagrindinisTinklaraštisSiuntų sekimo API vertinimo metrikos: 8 KPI, kuriuos reikia išmatuoti atliekant koncepcijos patikrą

Siuntų sekimo API vertinimo metrikos: 8 KPI, kuriuos reikia išmatuoti atliekant koncepcijos patikrą

17TRACK

Įvertinkite siuntų sekimo API koncepcijos patikrinimą pagal aštuonis KPI: tinkamo sekimo aprėptį, įvykių išsamumą, būsenos tikslumą, atnaujinimo delsą, žiniatinklio kablių pristatymo patikimumą, API užklausų patikimumą, integravimo pastangas ir vienos tinkamai sekamos siuntos kainą. Vertinkite juos pagal faktinį jūsų siuntų derinį ir suderintus etaloninius duomenis, o ne tik pagal sėkmingas demonstracines užklausas. Prieš testavimą nustatykite priėmimo kriterijus, kad rezultatai padėtų priimti aiškų sprendimą dėl diegimo, trūkumų šalinimo arba atmetimo.

Siuntų sekimo API vertinimo metrikos: 8 KPI, kuriuos reikia įvertinti

Šis vadovas skirtas inžinerijos vadovams, logistikos operacijų komandoms ir pirkimų vadovams, kurie renkasi API užsakymų valdymo sistemai, sandėlio platformai, klientų aptarnavimo procesui arba sekimo funkcijai. Toliau pateiktos formulės yra siūlomi vertinimo metodai, o ne paskelbti pramonės standartai. Jūsų ribinės reikšmės turėtų atspindėti trūkstamos, vėluojančios ar netikslios sekimo informacijos pasekmes.

Sukurkite gamybą atspindintį testą

Koncepcijos patikrinimas turėtų atsakyti į praktinį klausimą: ar ši integracija gali užtikrinti patikimą informaciją apie siuntas už priimtiną eksploatavimo kainą? Smėlio dėžė gali parodyti, kad užklausos ir atsakymai veikia, tačiau pati savaime negali įrodyti tiesioginių vežėjų duomenų kokybės.

Derinkite istorines siuntas, kai tinkami įrašai išlieka pasiekiami, su tiesioginėmis siuntomis, stebimomis testo metu. Istoriniai atvejai padeda patikrinti būsenų interpretavimą ir neįprastus maršrutus. Tiesioginiai atvejai būtini atnaujinimo vėlavimams ir pranešimų pristatymui matuoti.

  • Atspindėkite savo siuntų derinį. Įtraukite pagrindinius vežėjus, kilmės ir paskirties vietų derinius, paslaugų tipus ir, kai aktualu, tarpvalstybinius perdavimus. Svarbius segmentus pateikite atskirai, o ne paslėpkite viename vidurkyje.
  • Įtraukite sudėtingus maršrutus. Testuokite vėluojančias siuntas, nepavykusius pristatymo bandymus, grąžinimus, neaiškų vežėjo identifikavimą ir siuntas, kurios dar nebuvo fiziškai nuskenuotos.
  • Neigiamus testus atskirkite. Negaliojantys sekimo numeriai ir nepalaikomos užklausos yra naudingos klaidų tvarkymui tikrinti, tačiau neturėtų nepastebimai mažinti galiojančių siuntų aprėpties balo.
  • Išsaugokite etaloninius įrodymus. Kiekvienam vertinimui užfiksuokite vežėjo informaciją, laiko žymas, šaltinio laiko juostą, sekimo identifikatorius ir naudotus API atsakymus. Žurnaluose apsaugokite asmens duomenis ir prisijungimo duomenis.
  • Sutarkite dėl atsakomybės. Inžinerijos komanda turėtų būti atsakinga už techninę instrumentaciją; logistikos operacijos – už siuntų reikšmių patvirtinimą; finansų arba pirkimų komanda – už išlaidų modelio patvirtinimą.

Naudokite bendrą stebėjimo laikotarpį ir prieš rinkdami balus apibrėžkite, kas laikoma tinkamu rezultatu. Jei lyginate kelias realizacijas, kiekvienai suteikite tą pačią siuntų grupę ir panašias testavimo sąlygas. Užfiksuokite konfigūracijos skirtumus, kurie galėtų paveikti rezultatą.

1. Tinkamo sekimo aprėptis

Klausimas: Ar API gali grąžinti naudingą sekimo informaciją apie siuntas, kurias jūsų įmonė iš tikrųjų siunčia?

Formulė: Tinkamo sekimo aprėptis = tinkamą sekimo rezultatą turinčios tinkamos testinės siuntos ÷ visos tinkamos testinės siuntos × 100.

Tinkamumą apibrėžkite nepriklausomai nuo teikėjo palaikomų vežėjų sąrašo. Pavyzdžiui, vardiklis gali apimti visas galiojančias siuntas, patenkančias į numatytą diegimo apimtį ir pakankamai senas, kad pagrįstai turėtų sekimo informaciją. Priešingu atveju, pašalinus nepalaikomas siuntas, būtų paslėpta aprėpties spraga, kurią bandote išmatuoti.

Tinkamas rezultatas turėtų reikšti daugiau nei sėkmingą registraciją arba sėkmingą HTTP atsakymą. Nurodykite minimalią informaciją, kurios reikia jūsų procesui, pavyzdžiui, teisingai identifikuotą vežėją ir prasmingą siuntos būseną. Etiketės sukūrimo būsena gali būti galiojanti prieš fizinį perdavimą, tačiau ji neturėtų būti laikoma vėlesnio judėjimo įvykio įrodymu.

Rezultatus suskirstykite pagal vežėją, maršrutą ir paslaugą. Taip pat atskirkite nepalaikomas paslaugas, vežėjo identifikavimo klaidas, prieš skenavimą esančias siuntas ir laikinus gavimo sutrikimus. Apibendrintas balas gali atrodyti priimtinas, nors verslui svarbus maršrutas lieka netinkamas naudoti.

Sprendimo taisyklė: Privalomų siuntų segmentų aprėptį paverskite diegimo sąlyga. Aukštas bendras procentas neturėtų kompensuoti neaptarnaujamo segmento, kurio reikia paleidimui.

2. Privalomų įvykių išsamumas

Klausimas: Ar API fiksuoja siuntų etapus, kurių reikia jūsų operacijoms?

Formulė: Privalomų įvykių išsamumas = sutapę privalomi etaloniniai įvykiai ÷ visi testo metu užfiksuoti privalomi etaloniniai įvykiai × 100.

Sukurkite etaloninių įvykių rinkinį pagal išsaugotus vežėjų įrašus arba kitą suderintą tiesos šaltinį. Apibrėžkite aprašymų, laiko žymų, vietų ir įvykių tipų atitikimo taisykles. Nereikalaukite identiško teksto, kai du aprašymai reiškia tą patį įvykį, ir nesitikėkite, kad kiekvienas vežėjas skelbs tokią pačią etapų seką.

Daugeliui komandų naudingi etapai apima fizinį priėmimą, judėjimą, pristatymo bandymus, išimtis ir galutinį pristatymą. Tikslus sąrašas turėtų atitikti procesą. Klientų aptarnavimo komandai gali reikėti nepavykusio pristatymo bandymo įvykio, kurio analitikos skydeliui nereikia.

Sutapatinkite atskirus įvykius, o ne skaičiuokite neapdorotas eilutes. Pasikartojantys skenavimai neturėtų gerinti išsamumo. Kita vertus, teikėjas gali sujungti perteklinius įvykius neprarasdamas jūsų programai reikalingos informacijos.

Nepasiekiamus etaloninius įrašus laikykite atskirai nuo patvirtintų trūkstamų įvykių. Jei etaloninis šaltinis negali nustatyti, ar įvykis egzistavo, pažymėkite atvejį kaip neišspręstą, o ne laikykite jį teikėjo nesėkme arba sėkme.

Sprendimo taisyklė: Kritinius etapus vertinkite atskirai. Trūkstamas pasirenkamas vietos atnaujinimas nėra lygiavertis trūkstamam nepavykusio pristatymo bandymui, kuris turėtų sukelti veiksmą klientui.

3. Normalizuotos būsenos tikslumas

Klausimas: Ar API teisingai išverčia vežėjo įvykius į operacinę reikšmę?

Formulė: Būsenos tikslumas = teisingai klasifikuoti įvertinti būsenos stebėjimai ÷ visi įvertinti būsenos stebėjimai × 100.

Prieš peržiūrėdami API išvestį, leiskite logistikos operacijų komandai apibrėžti tikėtinas klasifikacijas. Tiksli įvykių istorija vis tiek gali pateikti klaidinančią dabartinę būseną, jei integracija pristatymo bandymą interpretuoja kaip pristatymą arba grąžinimo judėjimą laiko įprastu siuntos judėjimu į paskirties vietą.

Vertinkite tiek atskirų įvykių susiejimus, tiek siuntos lygio būseną. Jei įmanoma, kartu su normalizuota reikšme išsaugokite pirminį vežėjo aprašymą, kad vertintojai galėtų nagrinėti nesutapimus.

Naudokite klaidų matricą, kad parodytumėte, kurios būsenos supainiojamos su kuriomis. Klaidingai priskirtas pristatymo būsenas pateikite atskirai, nes neteisingas užbaigimo signalas gali paveikti klientų pranešimus, aptarnavimo procesus ir tolesnį užsakymų tvarkymą.

Įtraukite aiškią nežinomos būsenos kategoriją. Atsargus nežinomas rezultatas gali būti saugesnis už nepagrįstą galutinę būseną, tačiau jam vis tiek reikia operacinės tvarkymo taisyklės. Nepašalinkite nežinomų atvejų iš vardiklio vien tam, kad pagerintumėte tikslumą.

Sprendimo taisyklė: Griežtesnes priėmimo sąlygas nustatykite klaidoms, kurios sukelia negrįžtamus arba klientams matomus veiksmus. Vien bendro tikslumo nepakanka, kai vieno tipo klaida kelia neproporcingai didelę riziką.

4. Atnaujinimo delsa

Klausimas: Kiek laiko praeina, kol naujas vežėjo įvykis tampa tinkamas naudoti jūsų sistemoje?

Pagrindinis matas: Stebėta atnaujinimo delsa = laikas, kai jūsų sistema patikimai įrašo tinkamą naudoti atnaujinimą − laikas, kai įvykis pirmą kartą pastebėtas suderintame etaloniniame šaltinyje.

Užfiksuokite atskiras vežėjo įvykio, jūsų etaloninio stebėjimo, žiniatinklio kablio gavimo ir sėkmingo vidinio apdorojimo laiko žymas. Šios laiko žymos atsako į skirtingus klausimus. Skenavimo įvykio laikas gali būti ankstesnis už momentą, kai vežėjas jį paskelbia, todėl vien skenavimo laiko atėmimas neatskiria sekimo teikėjo delsos.

Etaloniniai patikrinimai sukuria matavimo neapibrėžtumą. Jei vežėjo šaltinį tikrinate intervalais, žinote, kada pirmą kartą pamatėte įvykį, bet ne tikslų jo paskelbimo laiką. Dokumentuokite šį intervalą ir rezultatą apibūdinkite kaip stebėtą delsą, o ne tikslų teikėjo apdorojimo laiką.

Kai imtis tai leidžia, svarbiems segmentams pateikite medianą ir viršutinę procentilę, pavyzdžiui, p95. Įtraukite imčių dydžius. Greita mediana gali paslėpti ilgus vėlavimus, veikiančius mažesnę, bet operaciškai svarbią siuntų grupę.

Sprendimo taisyklė: Delsos tikslus susiekite su veiksmu. Kasdienio ataskaitų teikimo procesui ir laiko jautriam pranešimui apie išimtį neturėtų būti automatiškai taikoma ta pati riba. Trūkstami atnaujinimai turi likti matomi išsamumo ataskaitose, o ne išnykti iš delsos rezultatų.

5. Žiniatinklio kablių pristatymo patikimumas

Klausimas: Ar tikėtini atnaujinimai pasiekia jūsų priimančiąją programą, įskaitant atvejus, kai pristatymas laikinai nepavyksta?

Formulė: Žiniatinklio kablių pristatymo patikimumas = atskiri tikėtini pranešimai, patikimai priimti per suderintą laikotarpį ÷ visi tikėtini pranešimai × 100.

Tikėtinų pranešimų rinkinį sudarykite pagal dokumentuotas prenumeratos taisykles, stebėtus šaltinio pokyčius ir kontroliuojamus testus. Nemanykite, kad kiekvienas neapdorotas vežėjo skenavimas turi sukurti atskirą pranešimą. Jei tikėtino rinkinio negalima nustatyti nepriklausomai, pateikite rezultatą kaip dalinį, o ne teigkite, kad pristatymo patikimumas yra visiškas.

Testuokite laikiną serverio klaidą, ryšio pertrūkius, pasikartojančius pranešimus, pavėluotus patvirtinimus ir atkūrimą. Patvirtinkite dokumentuotą pakartotinių bandymų elgseną ir tai, kas vyksta pasibaigus pakartotiniams bandymams. Trikdžius sukeliančiam testavimui naudokite ne gamybines siuntas arba izoliuotą aplinką.

Skaičiuokite atskirus pranešimus, o ne HTTP bandymus. Pasikartojantys pristatymo bandymai neturi išpūsti skaitiklio. Jūsų galinis punktas turėtų patvirtinti gavimą tik tada, kai pagal programos dizainą saugiai įrašė arba į eilę įtraukė pranešimą.

Teikėjo pristatymą ir vidinį apdorojimą pateikite atskirai. Žiniatinklio kablys gali būti sėkmingai gautas, nors jūsų programa neatnaujina užsakymo. Testuokite idempotentinį apdorojimą, kad pasikartojantys pranešimai nesukurtų pasikartojančių pranešimų klientams.

Sprendimo taisyklė: Reikalaukite įrodyto praleistų atnaujinimų atkūrimo kelio, o ne tik sėkmingo pristatymo įprastomis sąlygomis.

6. API užklausų patikimumas

Klausimas: Ar API sėkmingai atsako esant numatomam darbo krūviui?

Formulė: API užklausų patikimumas = galiojančios užklausos, kurios per jūsų nustatytą skirtąjį laiką grąžina tikėtiną, išanalizuojamą atsakymą ÷ visos bandytos galiojančios užklausos × 100.

Galiojančią užklausą apibrėžkite pagal dokumentuotą autentifikavimą, naudingąją apkrovą ir sutartines užklausų ribas. Netinkamai suformuotas užklausas atskirai registruokite kaip integracijos trūkumus. Taip pat atskirai pateikite ribojimą, autentifikavimo klaidas, skirtuosius laikus ir serverio klaidas, kad bendras balas išliktų interpretuojamas.

Testuokite siuntų registravimą, gavimą ir kitus galinius punktus, kuriuos jūsų realizacija iš tikrųjų naudoja. Sėkmingas tik skaitymo testas neįrodo, kad masinis įtraukimas veiks priimtinai.

Kartu su patikimumu matuokite atsako laiko procentiles. Atskirai pateikite pirmojo bandymo sėkmę ir galutinę sėkmę po pakartotinių bandymų: pakartotiniai bandymai gali atkurti operaciją, tačiau padidina delsą, srautą ir apdorojimo darbą.

Google Site Reliability Engineering gairėse delsa, srautas, klaidos ir prisotinimas įvardijami kaip naudingi stebėjimo signalai. Pritaikykite šią sistemą koncepcijos patikrinimui, kartu su nesėkmėmis registruodami užklausų apimtį ir lygiagretumą. Prieš generuodami srautą suderinkite apkrovos testo ribas.

Sprendimo taisyklė: Trumpą koncepcijos patikrinimo rezultatą laikykite įrodymu apie testuotą darbo krūvį ir laikotarpį, o ne ilgalaikio pasiekiamumo įrodymu ar sutartinių įsipareigojimų pakaitalu.

7. Integravimo ir atkūrimo pastangos

Klausimas: Kiek inžinerinio darbo reikia, kad integracija būtų saugi eksploatuoti?

Pagrindinis matas: Integravimo pastangos = užregistruotos inžinerijos valandos, reikalingos suderintam pasirengimo gamybai kontroliniam sąrašui užbaigti.

Visoms realizacijoms naudokite tą patį kontrolinį sąrašą. Įtraukite autentifikavimą, registravimą, žiniatinklio kablių priėmimą, būsenų susiejimą, dublikatų pašalinimą, suderinimą, stebėjimą, prisijungimo duomenų tvarkymą, diegimą ir operacinę dokumentaciją. Praėjusį kalendorinį laiką atskirai nuo praktinio inžinerinio darbo laiko.

Matuokite darbą, reikalingą ne tik pirmajai sėkmingai užklausai. Greita demonstracija gali palikti daug darbo klaidų tvarkymo, istorinio atkūrimo ir aptarnavimo įrankių srityse.

Atlikite atkūrimo pratimą: nutraukite savo vartotojo veikimą, jį atkurkite ir nustatykite, ar paveiktas siuntų būsenas galima suderinti. Užregistruokite atkūrimo laiką, rankines intervencijas ir neišspręstus įrašus. Pažymėkite, kurios problemos kyla dėl jūsų programos, o kurioms reikia teikėjo pagalbos.

Sprendimo taisyklė: Pastangas lyginkite tik esant lygiaverčiam pasirengimo lygiui. Prototipas be stebėjimo neturėtų atrodyti lengviau integruojamas nei gamybai parengta realizacija su patikrintu atkūrimu.

8. Vienos tinkamai sekamos siuntos kaina

Klausimas: Kiek kainuos gauti jūsų reikalavimus atitinkančią informaciją apie siuntas?

Formulė: Vienos tinkamai sekamos siuntos kaina = visos priskirtinos veiklos išlaidos per laikotarpį ÷ atskiros siuntos, kurios tuo laikotarpiu atitinka suderintus tinkamumo kriterijus.

Naudokite rašytinį pasiūlymą arba taikomas komercines sąlygas, o ne darykite prielaidas apie atsiskaitymo tvarką. Patvirtinkite, kaip vertinami registravimo bandymai, pasikartojantys pateikimai, pakartotinis sekimas, viršijimai, istorinė prieiga ir atskirai apmokestinamos paslaugos. Tai klausimai, kuriuos reikia patikrinti, o ne numanomi mokesčiai.

Skaičiuodami bendrąsias vidines išlaidas įtraukite infrastruktūrą ir pasikartojantį operacinį darbą. Vienkartines diegimo išlaidas pateikite atskirai arba nurodykite laikotarpį, per kurį jos amortizuojamos.

Numatomas ir didžiausias siuntų apimtis modeliuokite naudodami tą patį siuntų derinį, kuris buvo testuotas atliekant koncepcijos patikrinimą. Prognozes pažymėkite kaip įverčius. Jei patikimų veiklos išlaidų duomenų nėra, pateikite siauresnę teikėjo mokesčių metriką ir nurodykite neįtrauktas išlaidas.

Sprendimo taisyklė: Išlaidas lyginkite tik įvykdžius minimalius kokybės reikalavimus. Maža vieno registruoto sekimo numerio kaina nebūtinai reiškia mažą vieno naudingo rezultato kainą.

Paverskite rezultatus sprendimu dėl diegimo

Sukurkite vertinimo kortelę, kurioje būtų kiekvieno KPI apibrėžimas, priėmimo riba, stebėtas rezultatas, imties dydis, segmentų išskaidymas, neišspręsti atvejai ir atsakingas asmuo. Ribines reikšmes nustatykite prieš peržiūrėdami rezultatus. Nėra universalaus praeinamumo procento, tinkamo kiekvienai siuntų operacijai.

Kritinei aprėpčiai, pavojingoms būsenos klaidoms, atkūrimo galimybei ir kitiems neprivalomiems reikalavimams naudokite privalomus vartus. Svertinį balų skaičiavimą taikykite tik tada, kai šie vartai įveikti. Priešingu atveju maža kaina arba greitas atsako laikas matematiškai galėtų paslėpti rimtą operacinę nesėkmę.

Pasirinkite vieną iš trijų rezultatų: patvirtinti ribotos apimties diegimą, pratęsti koncepcijos patikrinimą siekiant išspręsti įvardytus neaiškumus arba atmesti testuotą konfigūraciją. Pratęsime turėtų būti nurodyti trūkstami įrodymai ir sąlyga, kuri jį užbaigs. Diegimo metu toliau stebėkite tas pačias apibrėžtis, kad gamybiniai rezultatai išliktų palyginami.

Jei 17TRACK yra jūsų galutiniame kandidatų sąraše, naudokite jo Tracking API puslapį ir oficialią API dokumentaciją kaip pradžios taškus, kad patvirtintumėte jūsų testui aktualius integravimo reikalavimus. Taikykite tą pačią vertinimo kortelę ir tiesioginių siuntų patikras; dokumentacijos peržiūra nepakeičia išmatuotų rezultatų.

DUK

Kiek siuntų turėtų apimti sekimo API koncepcijos patikrinimas?

Nėra universalaus imties dydžio. Įtraukite pakankamai stebėjimų, kad galėtumėte įvertinti kiekvieną verslui kritinį segmentą ir jūsų procesams svarbias išimtis. Pateikite segmentų skaičius ir neapibrėžtumą. Didelė imtis, sutelkta į vieną vežėją, negali nustatyti nepatikrintų vežėjų ar maršrutų patikimumo.

Ar smėlio dėžė gali pakeisti tiesioginių siuntų testavimą?

Smėlio dėžė gali patvirtinti užklausų kūrimą, analizavimą ir programos elgseną. Pati savaime ji negali nustatyti tiesioginių įvykių išsamumo, vežėjo paskelbimo delsos ar gamybinių pranešimų našumo. Naudokite ją kartu su tiesioginiu testavimu, o ne vietoje jo.

Ką daryti, jei vežėjo svetainė ir API nesutampa?

Išsaugokite abu įrašus su stebėjimo laikais. Prieš priskirdami kaltę patikrinkite laiko juostos konvertavimą, siuntos tapatybę, paskelbimo laiką ir būsenos interpretavimą. Jei nė vienas šaltinis neatkuria neatitikimo priežasties, pažymėkite jį kaip neišspręstą ir ištirkite, o ne priverstinai priskirkite sėkmės arba nesėkmės žymą.

Ar trūkstami įvykiai turėtų būti laikomi lėtais atnaujinimais?

Šiuos matus laikykite atskirai. Niekada nepasiekiantis įvykis yra išsamumo nesėkmė arba neišspręstas atvejis, priklausomai nuo turimų įrodymų. Delsa matuoja įvykius, kurie pasiekia sistemą. Pateikite abu matus kartu, kad trūkstami įvykiai dirbtinai nepagerintų delsos rezultatų.

Kas turėtų vykti po to, kai koncepcijos patikrinimas sėkmingai baigiamas?

Diekite kontroliuojamoje apimtyje, išsaugokite suderinimo ir grįžimo procedūras bei toliau stebėkite tuos pačius KPI. Plėskite apimtį tik tada, kai gamybiniai rezultatai tai patvirtina. Iš naujo įvertinkite, kai pasikeičia jūsų vežėjų derinys, siuntų apimtis, integracijos konfigūracija arba komercinės sąlygos.

Šaltiniai

Loading