Faqja kryesoreBlogMetrikat e vlerësimit të API-së së gjurmimit të dërgesave: 8 KPI për t'u matur në një provë koncepti

Metrikat e vlerësimit të API-së së gjurmimit të dërgesave: 8 KPI për t'u matur në një provë koncepti

17TRACK

Vlerësoni një provë koncepti të një API-je për gjurmimin e dërgesave duke përdorur tetë KPI: mbulimin e përdorshëm të gjurmimit, plotësinë e ngjarjeve, saktësinë e statusit, vonesën e përditësimeve, besueshmërinë e dorëzimit të webhook-eve, besueshmërinë e kërkesave të API-së, përpjekjen e integrimit dhe koston për dërgesë të gjurmuar në mënyrë të përdorshme. Matini ato kundrejt përzierjes suaj reale të dërgesave dhe të dhënave referuese të dakordësuara, jo vetëm kundrejt kërkesave të suksesshme të demonstrimit. Vendosni kriteret e pranimit përpara testimit, në mënyrë që rezultatet të mbështesin një vendim të qartë për lançim, korrigjim ose refuzim.

Metrikat e vlerësimit të API-së së gjurmimit të dërgesave: 8 KPI për t'u matur

Ky udhëzues u drejtohet drejtuesve të inxhinierisë, ekipeve të operacioneve logjistike dhe përgjegjësve të prokurimit që zgjedhin një API për një sistem të menaxhimit të porosive, platformë magazine, rrjedhë pune të mbështetjes së klientit ose përvojë gjurmimi. Formulat më poshtë janë metoda të propozuara vlerësimi, jo standarde të publikuara të industrisë. Pragjet tuaja duhet të pasqyrojnë pasojat e informacionit të munguar, të vonuar ose të pasaktë të gjurmimit.

Ndërtoni një test që përfaqëson prodhimin

Një provë koncepti duhet t'i përgjigjet një pyetjeje praktike: a mundet ky integrim të ofrojë informacion të besueshëm për dërgesat me një kosto të pranueshme operimi? Një sandbox mund të vërtetojë se kërkesat dhe përgjigjet funksionojnë, por nuk mund të demonstrojë vetë cilësinë e të dhënave të drejtpërdrejta të transportuesve.

Kombinoni dërgesat historike, aty ku të dhënat e përshtatshme mbeten të aksesueshme, me dërgesat drejtpërdrejt të vëzhguara gjatë testit. Rastet historike ndihmojnë në vërtetimin e interpretimit të statuseve dhe udhëtimeve të pazakonta. Rastet drejtpërdrejt janë të nevojshme për matjen e vonesave të përditësimeve dhe dorëzimit të njoftimeve.

  • Përfaqësoni përzierjen tuaj të dërgesave. Përfshini transportuesit kryesorë, kombinimet e origjinës dhe destinacionit, llojet e shërbimeve dhe dorëzimet ndërkufitare aty ku është e rëndësishme. Raportoni veçmas segmentet e rëndësishme, në vend që t'i fshihni brenda një mesatareje të vetme.
  • Përfshini udhëtime të vështira. Testoni dërgesat e vonuara, përpjekjet e pasuksesshme të dorëzimit, kthimet, identifikimin e paqartë të transportuesit dhe dërgesat që ende nuk kanë marrë një skanim fizik.
  • Ndani testet negative. Numrat e pavlefshëm të gjurmimit dhe kërkesat e pambështetura janë të dobishme për testimin e trajtimit të gabimeve, por nuk duhet të ulin në heshtje rezultatin e mbulimit për dërgesat e vlefshme.
  • Ruani provat referuese. Regjistroni informacionin e transportuesit, vulat kohore, zonën kohore të burimit, identifikuesit e gjurmimit dhe përgjigjet e API-së të përdorura në çdo vlerësim. Mbroni të dhënat personale dhe kredencialet në regjistra.
  • Rakordoni përgjegjësinë. Inxhinieria duhet të zotërojë instrumentimin teknik; operacionet logjistike duhet të vërtetojnë kuptimet e dërgesave; financa ose prokurimi duhet të vërtetojë modelin e kostos.

Përdorni një dritare të përbashkët vëzhgimi dhe përcaktoni çfarë quhet rezultat i përdorshëm përpara mbledhjes së pikëve. Nëse krahasoni disa zbatime, jepini secilit të njëjtin grup dërgesash dhe kushte të krahasueshme testimi. Regjistroni dallimet e konfigurimit që mund të ndikojnë në rezultat.

1. Mbulimi i përdorshëm i gjurmimit

Pyetje: A mund të kthejë API-ja informacion të dobishëm gjurmimi për dërgesat që biznesi juaj dërgon realisht?

Formula: Mbulimi i përdorshëm i gjurmimit = dërgesat e pranueshme të testit me rezultat të përdorshëm gjurmimi ÷ të gjitha dërgesat e pranueshme të testit × 100.

Përcaktoni pranueshmërinë në mënyrë të pavarur nga lista e transportuesve të mbështetur nga ofruesi. Për shembull, emëruesi juaj mund të përfshijë të gjitha dërgesat e vlefshme brenda fushës së synuar të lançimit që janë mjaftueshëm të vjetra për të pasur në mënyrë të arsyeshme informacion gjurmimi. Përndryshe, përjashtimi i dërgesave të pambështetura do të fshihte boshllëkun e mbulimit që po përpiqeni të matni.

Një rezultat i përdorshëm duhet të nënkuptojë më shumë se regjistrim të suksesshëm ose përgjigje të suksesshme HTTP. Përcaktoni informacionin minimal që i nevojitet rrjedhës suaj të punës, si një transportues i identifikuar saktë dhe një status kuptimplotë i dërgesës. Statusi i krijimit të etiketës mund të jetë i vlefshëm përpara dorëzimit fizik, por nuk duhet të llogaritet si provë e një ngjarjeje të mëvonshme lëvizjeje.

Ndajini rezultatet sipas transportuesit, itinerarit dhe shërbimit. Gjithashtu dalloni shërbimet e pambështetura, gabimet e identifikimit të transportuesit, dërgesat para skanimit dhe dështimet e përkohshme të marrjes. Një rezultat i përgjithshëm mund të duket i pranueshëm ndërsa një itinerar kritik për biznesin mbetet i papërdorshëm.

Rregulli i vendimit: Bëjeni mbulimin në segmentet e detyrueshme të dërgesave një kusht për lançimin. Një përqindje e lartë e përgjithshme nuk duhet të kompensojë një segment të pambuluar që kërkohet nga lançimi.

2. Plotësia e ngjarjeve të kërkuara

Pyetje: A kap API-ja momentet e dërgesës që u nevojiten operacioneve tuaja?

Formula: Plotësia e ngjarjeve të kërkuara = ngjarjet referuese të kërkuara të përputhura ÷ të gjitha ngjarjet referuese të kërkuara të vëzhguara gjatë testit × 100.

Ndërtoni një grup ngjarjesh referuese nga të dhënat e ruajtura të transportuesit ose nga një burim tjetër i dakordësuar i së vërtetës. Përcaktoni rregullat e përputhjes për përshkrimet, vulat kohore, vendndodhjet dhe llojet e ngjarjeve. Mos kërkoni tekst identik kur dy përshkrime përfaqësojnë të njëjtën ngjarje dhe mos prisni që çdo transportues të publikojë të njëjtën sekuencë momentesh.

Për shumë ekipe, momentet e dobishme përfshijnë pranimin fizik, lëvizjen, përpjekjet e dorëzimit, përjashtimet dhe dorëzimin përfundimtar. Lista e saktë duhet të ndjekë rrjedhën e punës. Një ekip mbështetjeje mund të ketë nevojë për një ngjarje përpjekjeje dorëzimi që nuk i nevojitet një paneli analitik.

Përputhni ngjarje të veçanta në vend që të numëroni rreshta të papërpunuar. Skanimet e dyfishta nuk duhet të përmirësojnë plotësinë. Në të kundërt, një ofrues mund të kombinojë ngjarje të tepërta pa humbur informacionin që i nevojitet aplikacionit tuaj.

Mbajini veçmas të dhënat referuese të paarritshme nga ngjarjet e konfirmuara që mungojnë. Nëse burimi referues nuk mund të përcaktojë nëse një ngjarje ka ekzistuar, shënojeni rastin si të pazgjidhur në vend që ta trajtoni si dështim ose sukses të ofruesit.

Rregulli i vendimit: Vlerësoni veçmas momentet kritike. Mungesa e një përditësimi opsional të vendndodhjes nuk është e barabartë me mungesën e një përpjekjeje të dështuar dorëzimi që duhet të shkaktojë veprim nga klienti.

3. Saktësia e statusit të normalizuar

Pyetje: A i përkthen API-ja ngjarjet e transportuesit në kuptimin e duhur operacional?

Formula: Saktësia e statusit = vëzhgimet e vlerësuara të statusit të klasifikuara saktë ÷ të gjitha vëzhgimet e vlerësuara të statusit × 100.

Lejoni që operacionet logjistike të përcaktojnë klasifikimet e pritshme përpara shqyrtimit të rezultateve të API-së. Një histori e saktë ngjarjesh mund të prodhojë ende një status aktual çorientues nëse integrimi e interpreton një përpjekje dorëzimi si dorëzim ose e trajton një lëvizje kthimi si tranzit të zakonshëm në dalje.

Vlerësoni si hartëzimet individuale të ngjarjeve, ashtu edhe statusin në nivel dërgese. Ruani përshkrimin origjinal të transportuesit së bashku me vlerën e normalizuar kur është e disponueshme, në mënyrë që shqyrtuesit të mund të hetojnë mospërputhjet.

Përdorni një matricë konfuzioni për të treguar cilat statuse ngatërrohen me cilat të tjera. Raportoni veçmas klasifikimet e rreme si të dorëzuara, sepse një sinjal i pasaktë për përfundimin mund të ndikojë në mesazhet e klientëve, rrjedhat e punës së mbështetjes dhe trajtimin pasues të porosive.

Përfshini një kategori të qartë të panjohur. Një rezultat i kujdesshëm i panjohur mund të jetë më i sigurt se një status përfundimtar i pajustifikuar, por gjithsesi ka nevojë për një rregull trajtimi operacional. Mos i hiqni rastet e panjohura nga emëruesi vetëm për të përmirësuar saktësinë.

Rregulli i vendimit: Vendosni kushte më të rrepta pranimi për gabimet që shkaktojnë veprime të pakthyeshme ose të dukshme për klientin. Saktësia e përgjithshme nuk mjafton kur një lloj gabimi mbart rrezik disproporcional.

4. Vonesa e përditësimit

Pyetje: Sa kohë duhet që një ngjarje e re e transportuesit të bëhet e përdorshme në sistemin tuaj?

Matja kryesore: Vonesa e vëzhguar e përditësimit = koha kur sistemi juaj regjistron në mënyrë të qëndrueshme përditësimin e përdorshëm − koha kur ngjarja u vëzhgua për herë të parë në burimin referues të dakordësuar.

Regjistroni vula kohore të veçanta për ngjarjen e transportuesit, vëzhgimin tuaj referues, marrjen e webhook-ut dhe përpunimin e brendshëm të suksesshëm. Këto vula kohore u përgjigjen pyetjeve të ndryshme. Koha e ngjarjes së skanimit mund të paraprijë momentin kur transportuesi e publikon atë, prandaj zbritja vetëm e kohës së skanimit nuk izolon vonesën e ofruesit të gjurmimit.

Kontrollet referuese sjellin pasiguri matjeje. Nëse kontrolloni një burim transportuesi në intervale, dini kur e patë për herë të parë një ngjarje, jo kohën e saktë të publikimit të saj. Dokumentoni atë interval dhe përshkruajeni rezultatin si vonesë të vëzhguar, jo si kohë të saktë përpunimi nga ofruesi.

Raportoni medianën dhe një përqindje të skajit, si p95, sipas segmenteve të rëndësishme kur kampioni e mbështet këtë. Përfshini madhësitë e kampioneve. Një medianë e shpejtë mund të fshehë vonesa të gjata që prekin një grup më të vogël, por operacionalisht të rëndësishëm, dërgesash.

Rregulli i vendimit: Lidhini objektivat e vonesës me veprimin. Një rrjedhë pune raportimi ditor dhe një njoftim i ndjeshëm ndaj kohës për përjashtime nuk duhet të kenë automatikisht të njëjtin prag. Përditësimet e munguara duhet të mbeten të dukshme në raportimin e plotësisë dhe të mos zhduken nga rezultatet e vonesës.

5. Besueshmëria e dorëzimit të webhook-eve

Pyetje: A arrijnë përditësimet e pritshme në aplikacionin tuaj marrës, edhe kur dorëzimi dështon përkohësisht?

Formula: Besueshmëria e dorëzimit të webhook-eve = njoftimet e veçanta të pritshme të pranuara në mënyrë të qëndrueshme brenda dritares së dakordësuar ÷ të gjitha njoftimet e pritshme × 100.

Përcaktoni grupin e pritshëm të njoftimeve nga rregullat e dokumentuara të abonimit, ndryshimet e vëzhguara të burimit dhe testet e kontrolluara. Mos supozoni se çdo skanim i papërpunuar i transportuesit duhet të gjenerojë një njoftim më vete. Nëse grupi i pritshëm nuk mund të përcaktohet në mënyrë të pavarur, raportojeni rezultatin si të pjesshëm në vend që të pretendoni besueshmëri të plotë të dorëzimit.

Testoni gabimet e përkohshme të serverit, ndërprerjet e lidhjes, mesazhet e dyfishta, konfirmimet e vonuara dhe rikuperimin. Konfirmoni sjelljen e dokumentuar të riprovimeve dhe atë që ndodh pasi riprovimet ndalojnë. Përdorni dërgesa joprodhuese ose një mjedis të izoluar për testet ndërhyrëse.

Numëroni njoftimet e veçanta, jo përpjekjet HTTP. Përpjekjet e përsëritura të dorëzimit nuk duhet të fryjnë numëruesin. Endpoint-i juaj duhet të konfirmojë marrjen vetëm pasi ta ketë regjistruar ose vendosur në radhë në mënyrë të sigurt mesazhin, sipas dizajnit të aplikacionit tuaj.

Raportoni veçmas dorëzimin nga ofruesi dhe përpunimin e brendshëm. Një webhook mund të arrijë me sukses ndërsa aplikacioni juaj dështon të përditësojë porosinë. Testoni trajtimin idempotent në mënyrë që mesazhet e dyfishta të mos krijojnë njoftime të dyfishta për klientët.

Rregulli i vendimit: Kërkoni një rrugë të demonstruar rikuperimi për përditësimet e humbura, jo vetëm dorëzim të suksesshëm në kushte normale.

6. Besueshmëria e kërkesave të API-së

Pyetje: A përgjigjet API-ja me sukses nën ngarkesën e pritshme?

Formula: Besueshmëria e kërkesave të API-së = kërkesat e vlefshme që kthejnë një përgjigje të pritshme dhe të analizueshme brenda afatit tuaj kohor ÷ të gjitha kërkesat e vlefshme të provuara × 100.

Përcaktoni një kërkesë të vlefshme duke përdorur autentikimin, ngarkesën dhe kufijtë e kontraktuar të kërkesave të dokumentuara. Ndiqni veçmas kërkesat e keqformuara si defekte integrimi. Raportoni gjithashtu veçmas kufizimin e ritmit, gabimet e autentikimit, afatet e tejkaluara dhe gabimet e serverit, në mënyrë që rezultati i përgjithshëm të mbetet i interpretueshëm.

Testoni regjistrimin e dërgesave, marrjen e të dhënave dhe endpoint-et e tjera që përdor realisht zbatimi juaj. Një test i suksesshëm vetëm për lexim nuk vërteton se regjistrimi masiv do të sillet në mënyrë të pranueshme.

Matni përqindjet e kohës së përgjigjes së bashku me besueshmërinë. Ndani suksesin në përpjekjen e parë nga suksesi përfundimtar pas riprovimeve: riprovimet mund të rikuperojnë një operacion, por duke shtuar vonesë, trafik dhe punë përpunimi.

Udhëzuesi i Google për Site Reliability Engineering identifikon vonesën, trafikun, gabimet dhe ngopjen si sinjale të dobishme monitorimi. Zbatojeni këtë kuadër në provën e konceptit duke regjistruar volumin e kërkesave dhe konkurencën së bashku me dështimet. Dakordësoni kufijtë e testit të ngarkesës përpara gjenerimit të trafikut.

Rregulli i vendimit: Trajtojeni një rezultat të shkurtër të provës së konceptit si dëshmi për ngarkesën dhe periudhën e testuar, jo si provë të disponueshmërisë afatgjatë ose zëvendësim të angazhimeve kontraktuale.

7. Përpjekja e integrimit dhe rikuperimit

Pyetje: Sa punë inxhinierike nevojitet për ta bërë integrimin të sigurt për operim?

Matja kryesore: Përpjekja e integrimit = orët e regjistruara të inxhinierisë të nevojshme për të përfunduar një listë kontrolli të dakordësuar për gatishmërinë në prodhim.

Përdorni të njëjtën listë kontrolli për çdo zbatim. Përfshini autentikimin, regjistrimin, marrjen e webhook-eve, hartëzimin e statuseve, eliminimin e dublimeve, rakordimin, monitorimin, trajtimin e kredencialeve, vendosjen në prodhim dhe dokumentacionin operacional. Regjistroni veçmas kohën kalendarike të kaluar nga koha e punës praktike inxhinierike.

Matni punën përtej kërkesës së parë të suksesshme. Një demonstrim i shpejtë mund të lërë pas punë të konsiderueshme në trajtimin e gabimeve, rikuperimin historik dhe mjetet e mbështetjes.

Kryeni një ushtrim rikuperimi: ndërprisni konsumatorin tuaj, rikthejeni atë dhe përcaktoni nëse gjendjet e prekura të dërgesave mund të rakordohen. Regjistroni kohën e rikuperimit, ndërhyrjet manuale dhe të dhënat e pazgjidhura. Shënoni cilat probleme lindin nga aplikacioni juaj dhe cilat kërkojnë ndihmën e ofruesit.

Rregulli i vendimit: Krahasoni përpjekjen vetëm në nivele ekuivalente gatishmërie. Një prototip pa monitorim nuk duhet të duket më i lehtë për t'u integruar se një zbatim i gatshëm për prodhim me rikuperim të testuar.

8. Kostoja për dërgesë të gjurmuar në mënyrë të përdorshme

Pyetje: Sa do të kushtojë marrja e informacionit për dërgesat që plotëson kërkesat tuaja?

Formula: Kostoja për dërgesë të gjurmuar në mënyrë të përdorshme = kostoja totale e atribuueshme e operimit për periudhën ÷ dërgesat e veçanta që plotësojnë kriteret e dakordësuara të përdorshmërisë gjatë asaj periudhe.

Përdorni një ofertë me shkrim ose kushtet tregtare të zbatueshme, në vend që të supozoni mënyrën e faturimit. Konfirmoni trajtimin e përpjekjeve të regjistrimit, dërgimeve të dyfishta, rigjurmimit, tejkalimeve, aksesit historik dhe çdo shërbimi të tarifuar veçmas. Këto janë pyetje për t'u verifikuar, jo tarifa që duhen supozuar.

Përfshini infrastrukturën dhe punën e përsëritur operacionale kur llogaritni koston totale të brendshme. Tregojeni veçmas koston e zbatimit një herë ose bëni të ditur periudhën gjatë së cilës amortizohet.

Modeloni volumet e pritshme dhe kulmore të dërgesave duke përdorur të njëjtën përzierje dërgesash të testuar në provën e konceptit. Etiketoni projeksionet si vlerësime. Nëse nuk janë të disponueshme të dhëna të besueshme për kostot operative, raportoni një metrikë më të ngushtë të tarifës së ofruesit dhe identifikoni kostot e përjashtuara.

Rregulli i vendimit: Krahasoni kostot vetëm pasi të plotësohen kërkesat minimale të cilësisë. Një kosto e ulët për numër gjurmimi të regjistruar nuk është domosdoshmërisht një kosto e ulët për rezultat të dobishëm.

Shndërroni rezultatet në një vendim për lançimin

Krijoni një tabelë vlerësimi që përmban përkufizimin e çdo KPI-je, pragun e pranimit, rezultatin e vëzhguar, madhësinë e kampionit, ndarjen sipas segmenteve, rastet e pazgjidhura dhe përgjegjësin. Vendosni pragjet përpara shqyrtimit të rezultateve. Nuk ka një përqindje universale kalimi që i përshtatet çdo operacioni dërgesash.

Përdorni porta të detyrueshme për mbulimin kritik, gabimet e rrezikshme të statusit, aftësinë e rikuperimit dhe kërkesat e tjera të panegociueshme. Aplikoni vlerësimin e ponderuar vetëm pasi këto porta të kalohen. Përndryshe, një çmim i ulët ose kohë e shpejtë përgjigjeje mund të fshehë matematikisht një dështim serioz operacional.

Zgjidhni një nga tre rezultatet: miratoni një lançim me fushë të kufizuar, zgjatni provën e konceptit për të zgjidhur pasiguritë e emërtuara ose refuzoni konfigurimin e testuar. Një zgjatje duhet të specifikojë provat që mungojnë dhe kushtin që do ta mbyllë atë. Gjatë lançimit, vazhdoni të monitoroni të njëjtat përkufizime në mënyrë që performanca në prodhim të mbetet e krahasueshme.

Nëse 17TRACK është në listën tuaj të ngushtë, përdorni faqen e Tracking API dhe dokumentacionin zyrtar të API-së si pika fillestare për konfirmimin e kërkesave të integrimit të rëndësishme për testin tuaj. Aplikoni të njëjtën tabelë vlerësimi dhe të njëjtat kontrolle me dërgesa drejtpërdrejt; shqyrtimi i dokumentacionit nuk zëvendëson rezultatet e matura.

Pyetje të shpeshta

Sa dërgesa duhet të përfshijë një provë koncepti e API-së së gjurmimit?

Nuk ka madhësi universale kampioni. Përfshini mjaftueshëm vëzhgime për të vlerësuar çdo segment kritik për biznesin dhe përjashtimet që kanë rëndësi për rrjedhat tuaja të punës. Tregoni numërimet dhe pasigurinë në nivel segmenti. Një kampion i madh i përqendruar te një transportues nuk mund të vërtetojë besueshmërinë te transportuesit ose itineraret e patestuara.

A mund ta zëvendësojë sandbox-i testimin me dërgesa reale?

Një sandbox mund të vërtetojë ndërtimin e kërkesave, analizimin dhe sjelljen e aplikacionit. Nuk mund të përcaktojë vetë plotësinë e ngjarjeve reale, vonesat e publikimit nga transportuesit ose performancën e njoftimeve në prodhim. Përdoreni së bashku me testimin drejtpërdrejt, jo si zëvendësim.

Çfarë ndodh nëse faqja e internetit e transportuesit dhe API-ja nuk përputhen?

Ruajini të dyja regjistrimet me kohët e vëzhgimit. Kontrolloni konvertimin e zonës kohore, identitetin e dërgesës, kohën e publikimit dhe interpretimin e statusit përpara se të caktoni fajin. Nëse asnjë burim nuk e zgjidh mospërputhjen, shënojeni si të pazgjidhur dhe hetojeni, në vend që ta detyroni etiketën e suksesit ose dështimit.

A duhet të llogariten ngjarjet e munguara si përditësime të ngadalta?

Mbajini matjet të ndara. Një ngjarje që nuk arrin kurrë është dështim i plotësisë ose rast i pazgjidhur, në varësi të provave. Vonesa mat ngjarjet që arrijnë. Raportojini të dyja së bashku në mënyrë që ngjarjet e munguara të mos e bëjnë performancën e vonesës të duket artificialisht e mirë.

Çfarë duhet të ndodhë pasi prova e konceptit të kalojë?

Lançoni në një fushë të kontrolluar, ruani procedurat e rakordimit dhe rikthimit dhe vazhdoni të monitoroni të njëjtat KPI. Zgjerojeni vetëm kur rezultatet në prodhim e mbështesin këtë. Rivlerësoni kur ndryshojnë përzierja e transportuesve, volumi i dërgesave, konfigurimi i integrimit ose kushtet tregtare.

Burimet

Loading