Nerandamas DHL arba DPD siuntos sekimas? Kaip 17TRACK API naudoja dirbtinį intelektą, kad pagerintų sekimo sėkmės rodiklius

Kodėl tas pats sekimo numeris vienoje platformoje nerodo rezultatų, o kitoje pateikia visą sekimo istoriją?

Kai įmonės susiduria su tokiomis problemomis kaip DHL Tracking Not Found arba DPD Tracking Not Found, jos dažnai mano, kad sekimo numeris yra neteisingas arba vežėjas dar neatnaujino savo įrašų.

Praktiškai sekimo numerio pateikimas API negarantuoja, kad bus grąžinti sekimo įvykiai.

Sekimo informacijos gavimas pirmiausia priklauso nuo teisingo vežėjo nustatymo ir užklausos išsiuntimo į tinkamą duomenų šaltinį. Jei vežėjas nustatomas neteisingai, užklausa gali grąžinti Not Found, net jei siunta juda įprastai.

Problema tampa dar akivaizdesnė dideliu mastu. Pavyzdžiui, įmonė, naudojanti ir DHL Tracking API, ir DPD Tracking API, pirmiausia turi nustatyti, kuriai API turi būti siunčiamas kiekvienas sekimo numeris.

17TRACK API sujungia vidinį AI identifikavimo modelį, taisyklėmis pagrįstą atitikmenų nustatymą ir nuolatinę stebėseną, kad padėtų įmonėms sumažinti išvengiamus vežėjų neatitikimus ir pagerinti sekimo sėkmės rodiklius.

1. Kodėl sekimo numeris gali negrąžinti jokių sekimo įvykių?

Nėra universalaus sekimo numerio formato. Kiekvienas vežėjas naudoja savo numeravimo taisykles, o vien sekimo numeryje gali nepakakti informacijos vežėjui nustatyti.

1.1 Dėl panašių sekimo numerių formatų vežėjus sunkiau nustatyti

Skirtingi vežėjai gali naudoti tokio pat ilgio sekimo numerius su panašiais priešdėliais arba raidžių ir skaitmenų deriniais.

Vienas sekimo numeris gali atitikti kelių vežėjų numeravimo formatus. Tradicinis taisyklėmis pagrįstas atitikmenų nustatymas vertina ilgį, priešdėlius ir simbolių derinius. Kai šios taisyklės sutampa, vien formato gali nepakakti tinkamam vežėjui nustatyti.

Vežėjas, kurio formatas sutampa su numeriu, yra tik vienas iš galimų kandidatų. Iš tikrųjų siuntą gali tvarkyti kitas vežėjas.

Neatitikimas gali nukreipti užklausą į netinkamą duomenų šaltinį ir sukelti atsaką Not Found.

1.2 Pateikta vežėjo informacija gali būti netiksli

Įmonės dažnai pateikia siuntų informaciją per ERP, WMS, OMS ar kitas užsakymų valdymo sistemas.

Šios sistemos gali nurodyti tą patį vežėją oficialiu pavadinimu, santrumpa arba vidiniu kodu. Įraše taip pat gali būti galiojantis sekimo numeris, tačiau neteisingai nurodytas vežėjas.

Jei sekimo sistema visiškai pasikliauja pateikta vežėjo informacija, ji gali toliau teikti užklausas netinkamam šaltiniui.

Todėl sekimo sistema turi nustatyti vežėjus, patikrinti atitikmenis ir ištaisyti neatitikimus.

1.3 Tarpvalstybinių siuntų duomenys gali būti paskirstyti tarp kelių vežėjų

Tarpvalstybinis siuntimas paprastai apima paėmimą, pagrindinį transportavimą, muitinės formalumus ir pristatymą paskutinėje mylioje.

Siuntą iš eilės gali tvarkyti keli vežėjai, o pakeliui gali būti suteiktas susietas paskutinės mylios sekimo numeris.

Pateikus užklausą tik vienam iš šių vežėjų, gali būti grąžinta dalinė istorija, todėl siuntos kelionėje lieka spragų.

Be plataus vežėjų aprėpties, sistemai reikia nustatyti tinkamus šaltinius ir sujungti sekimo duomenis.

Sekimo sėkmė priklauso nuo API prieinamumo, sekimo numerio kokybės, vežėjo nustatymo, duomenų šaltinio prieinamumo ir nuo to, ar buvo sugeneruoti sekimo įvykiai.

2. Kaip 17TRACK API naudoja AI, kad pagerintų vežėjo nustatymo tikslumą?

Fiksuotos taisyklės gali lemti neteisingus atitikmenis, kai numerių formatai sutampa arba pateikta vežėjo informacija yra netiksli.

AI gali padėti išspręsti šiuos dviprasmiškus atitikmenis.

17TRACK derina savo vidinį AI modelį su tradiciniu taisyklėmis pagrįstu atitikmenų nustatymu. Remdamasi daugelio metų logistikos duomenimis, sistema nustato labiausiai tikėtiną vežėją ir sumažina užklausų, kurios nepavyksta dėl pasirinkto netinkamo šaltinio, skaičių.

2.1 Fiksuotų taisyklių derinimas su AI padedamu nustatymu

Tradicinis vežėjo nustatymas daugiausia remiasi iš anksto nustatytomis taisyklėmis, pagal kurias galimi vežėjai lyginami pagal numerio ilgį, priešdėlius ir simbolių derinius.

Šis metodas gerai veikia, kai numeravimo taisyklės yra aiškiai skirtingos. Panašios skirtingų vežėjų taisyklės arba neišsami sekimo numerio informacija gali lemti dviprasmiškus rezultatus.

17TRACK derina AI identifikavimą ir taisyklėmis pagrįstą atitikmenų nustatymą, naudodama tiek sekimo numerio ypatybes, tiek prieinamą informaciją apie vežėją, kad nustatytų tikėtiną šaltinį.

Kai sistemos nustatytas vežėjas skiriasi nuo įmonės pateikto vežėjo, atitikmuo gali būti patikrintas papildomai.

Pavyzdžiui:

• Įmonė nurodo DHL kaip vežėją.
• Sistema pagal sekimo numerio šabloną nustato kitą galimą kandidatą.
• Sistema gali patikrinti abu atitikmenis ir taip sumažinti nesėkmingos užklausos riziką dėl neteisingai nurodyto vežėjo.

Tai sumažina priklausomybę nuo rankinio vežėjo pasirinkimo ir sutrumpina pakartotinių patikrų laiką apdorojant dideles sekimo numerių partijas.

2.2 Vidinis AI modelis, sukurtas remiantis daugelio metų logistikos duomenimis

AI identifikavimo našumas priklauso nuo mokymo duomenų, juose pateiktų pavyzdžių įvairovės ir nuo to, kaip modelis tobulinamas.

17TRACK daugiausia dėmesio pasauliniam siuntų sekimui skiria nuo 2010 m. Dabar sistema apima daugiau nei 3 500 vežėjų ir kas mėnesį sukaupia didelius logistikos duomenų kiekius.

Naudodama šiuos duomenis, 17TRACK moko ir tobulina savo identifikavimo modelį. Nuolatinis mokymas ir derinimas padeda modeliui išmokti konkretiems vežėjams būdingus sekimo numerių šablonus ir pagerinti identifikavimą sudėtingais atvejais.

AI gali suteikti papildomų signalų, kai vežėjai naudoja panašias numeravimo taisykles ir juos sunku atskirti įprastais atitikmenų nustatymo būdais.

Šis metodas sumažina rankinio fiksuotų taisyklių palaikymo poreikį ir suteikia lankstesnes galimybes nustatyti naujai pridėtus vežėjus bei sudėtingus siuntimo scenarijus.

2.3 AI identifikavimo derinimas su dviguba registracija, siekiant sumažinti neatitikimus

17TRACK taip pat siūlo būdą pagerinti sekimo sėkmę nustačius galimą vežėją.

Jei sistema nustato kitą vežėją nei pateiktas, įmonės, kuriose įjungta dviguba registracija, taip pat gali pateikti užklausą AI nustatytam vežėjui.

Pavyzdžiui:

Įmonė pateikia siuntą, pažymėtą kaip DHL, tačiau sistema nustato, kad kitas vežėjas yra labiau tikėtinas atitikmuo.

Įjungus dvigubą registraciją, sistema gali bandyti gauti sekimo įvykius iš nustatyto vežėjo, kartu atlikdama ir pradinę užklausą.

Tai suteikia įmonei galimybę gauti teisingus sekimo duomenis net tuo atveju, jei iš pradžių ji nurodė netinkamą vežėją.

Kartu šios funkcijos padeda sumažinti išvengiamas užklausų nesėkmes, kurias sukelia vežėjų neatitikimai.

3. Not Found rezultatų priežasčių tyrimas

Net ir teisingai nustačius vežėją, kai kurios užklausos iš pradžių gali negrąžinti jokių sekimo įvykių.

Sekimo numeris galėjo būti ką tik sukurtas, o vežėjas dar gali laukti, kol gaus siuntą. Vežėjo sekimo paslauga taip pat gali būti laikinai nepasiekiama. Bet kuri iš šių situacijų gali lemti rezultatą Not Found.

Vien rezultato Not Found nepakanka išvadai, kad siunta dar neišsiųsta arba prarasta.

Norint pagerinti sekimo sėkmės rodiklius, reikia nustatyti priežastį ir imtis tinkamų veiksmų.

3.1 Priežasties nustatymas, siekiant išvengti nereikalingų užklausų

Dažniausios Not Found rezultatų arba nesėkmingų užklausų priežastys:

Problemos tipas	Galima priežastis	Rekomenduojamas veiksmas
Neteisingas vežėjo atitikmuo	Tikrasis vežėjas nesutampa su pasirinktu vežėju.	Iš naujo nustatykite ir patikrinkite vežėją.
Neteisinga sekimo informacija	Neteisingas sekimo numeris arba trūksta privalomų parametrų.	Patikrinkite sekimo numerį ir užklausos parametrus.
Nėra sekimo atnaujinimų	Sekimo numeris sugeneruotas, tačiau vežėjas dar nepateikė pirmojo sekimo įvykio.	Palaukite, kol vežėjas atnaujins sekimo informaciją.
Duomenų šaltinio klaida	Vežėjo API gedimas, paslaugų apribojimai ar kitos problemos.	Stebėkite vežėjo API būseną ir ištirkite išimtis.

Kiekvienai priežasčiai reikia skirtingo sprendimo.

Jei vežėjas neatitinka, problemą galima išspręsti iš naujo nustačius vežėją ir patikrinus duomenų šaltinį. Jei vežėjas dar nesugeneravo pirmojo sekimo įvykio, pakartotinės užklausos vis tiek gali negrąžinti jokios naujos informacijos.

Šių scenarijų atskyrimas sumažina nereikalingų užklausų ir pakartotinio trikčių šalinimo poreikį.

3.2 Vežėjo duomenų stebėjimas siekiant anksti aptikti problemas

Be atskirų nesėkmingų užklausų, įmonės turi stebėti problemas, turinčias įtakos siuntų grupėms.

Jei vežėjas paprastai grąžina sekimo įvykius, tačiau didelė dalis siuntų staiga rodo Not Found, kitas žingsnis – patikrinti vežėjo API, svetainės sekimo paslaugą arba duomenų gavimo procesą.

17TRACK nuolat stebi vežėjų duomenų našumą. Aptikusi našumo sumažėjimą arba neįprastus svyravimus, sistema siunčia įspėjimus ir informuoja klientus.

Tai suteikia įmonėms galimybę anksčiau pastebėti vežėjo pusėje kylančias problemas ir pakoreguoti užklausų bei tvarkymo procedūras, kol nesusikaupė klientų skundų.

Vežėjo nustatymas, trikčių šalinimas ir šaltinio stebėjimas suteikia komandoms galimybę tirti Not Found rezultatus ir imtis tolesnių veiksmų.

4. Klientų pavyzdžiai, kai pagerėjo sekimo sėkmės rodikliai

Sekimo rezultatai realiose operacijose parodo AI identifikavimo ir Not Found valdymo poveikį.

Sekimo sėkmės rodikliai skiriasi priklausomai nuo kliento ir priklauso nuo tokių veiksnių kaip vežėjų aprėptis, sekimo numerių kokybė, užklausų strategija ir duomenų šaltinio prieinamumas.

Du 17TRACK klientų pavyzdžiai:

1 atvejis: pirmaujanti pasaulinė greitosios mados platforma

• Mastelis: vidutiniškai per dieną seka dešimčių milijonų užsakymų siuntas.
• Sekimo sėkmės rodiklis: padidėjo nuo 44,25 % iki 93,29 %.

2 atvejis: JAV elektroninės prekybos platforma, teikianti apsaugą po pirkimo

• Mastelis: aptarnauja daugiau nei 5 000 pirmaujančių prekių ženklų visame pasaulyje.
• Sekimo sėkmės rodiklis: padidėjo nuo 85 % iki 95 %.

Šie rezultatai atspindi visų klientų sekimo operacijų pagerėjimą. Jų negalima priskirti vien AI arba laikyti konkrečių DHL ar DPD vežėjų sėkmės rodikliais.

Įmonėms, apdorojančioms didelius tarpvalstybinių užsakymų kiekius, didesni sekimo sėkmės rodikliai reiškia daugiau panaudojamų siuntų duomenų užsakymų valdymui, klientų aptarnavimui ir veiklai po pirkimo.

Didesnė tikimybė gauti tinkamus sekimo įvykius kiekvienam galiojančiam numeriui

Sekimo užklausa gali atrodyti tokia paprasta kaip numerio įvedimas. Tačiau užkulisiuose ji apima vežėjo nustatymą, duomenų šaltinio parinkimą, duomenų gavimą ir nuolatinę stebėseną.

Persidengiantys numerių formatai, neišsami informacija apie vežėją ir siuntų perdavimas tarp vežėjų gali turėti įtakos rezultatui, ypač siunčiant tarpvalstybines siuntas.

17TRACK API sujungia AI pagrįstą vežėjo nustatymą, vidinį logistikos duomenų modelį, dvigubą registraciją ir nuolatinį Not Found valdymą, kad padėtų įmonėms sumažinti išvengiamus duomenų šaltinių neatitikimus ir efektyviau gauti sekimo duomenis.