Не знайдено дані відстеження DHL або DPD? Як API 17TRACK використовує ШІ для підвищення показників успішного відстеження
Чому один і той самий номер відстеження не повертає результатів на одній платформі, але показує повну історію відстеження на іншій?
Коли компанії стикаються з такими проблемами, як DHL Tracking Not Found або DPD Tracking Not Found, вони часто припускають, що номер відстеження недійсний або перевізник ще не оновив свої записи.
На практиці передавання номера відстеження до API не гарантує повернення подій відстеження.
Отримання інформації про відстеження насамперед залежить від правильного визначення перевізника та надсилання запиту до правильного джерела даних. Якщо перевізника визначено неправильно, запит може повернути Not Found, навіть коли відправлення рухається у звичайному режимі.
Проблема стає більш очевидною під час роботи у великих масштабах. Наприклад, компанія, яка використовує DHL Tracking API і DPD Tracking API, спочатку має визначити, який API повинен отримати кожен номер відстеження.
17TRACK API поєднує власну модель ідентифікації на основі AI, зіставлення на основі правил і постійний моніторинг, щоб допомогти компаніям зменшити кількість помилок зіставлення перевізників, яких можна уникнути, та підвищити показники успішного відстеження.
1. Чому номер відстеження може не повертати подій відстеження?
Універсального формату номерів відстеження не існує. Кожен перевізник використовує власні правила нумерації, і одного номера відстеження може бути недостатньо для визначення перевізника.
1.1 Подібні формати номерів відстеження ускладнюють визначення перевізника
Різні перевізники можуть використовувати номери відстеження однакової довжини з подібними префіксами або комбінаціями літер і цифр.
Один номер відстеження може відповідати форматам нумерації кількох перевізників. Традиційне зіставлення на основі правил враховує довжину, префікси та комбінації символів. Коли ці правила перетинаються, одного лише формату може бути недостатньо для визначення правильного перевізника.
Перевізник, формат якого відповідає номеру, є лише кандидатом. Фактично відправлення може обробляти інший перевізник.
Неправильне зіставлення може спрямувати запит до неправильного джерела даних і призвести до відповіді Not Found.
1.2 Надана інформація про перевізника може бути неточною
Компанії часто передають інформацію про відправлення через ERP, WMS, OMS або інші системи керування замовленнями.
Ці системи можуть позначати одного й того самого перевізника його офіційною назвою, скороченням або внутрішнім кодом. Запис також може містити дійсний номер відстеження, але неправильне поле перевізника.
Якщо система відстеження повністю покладається на надану інформацію про перевізника, вона може продовжувати надсилати запити до неправильного джерела.
Тому система відстеження повинна визначати перевізників, перевіряти відповідність і виправляти помилки зіставлення.
1.3 У транскордонних відправленнях дані можуть бути розподілені між перевізниками
Транскордонне перевезення зазвичай включає забір відправлення, магістральне транспортування, митне оформлення та доставку на останній милі.
Кілька перевізників можуть послідовно обробляти одне відправлення, а пов’язаний номер відстеження доставки на останній милі може бути призначений у процесі.
Запит лише до одного з цих перевізників може повернути неповну історію, залишивши прогалини в маршруті відправлення.
Окрім широкого охоплення перевізників, система повинна визначати правильні джерела та об’єднувати дані відстеження.
Успішність відстеження залежить від доступності API, якості номера відстеження, визначення перевізника, доступності джерела даних і того, чи були створені події відстеження.
2. Як 17TRACK API використовує AI для підвищення точності визначення перевізника?
Фіксовані правила можуть призводити до неправильних зіставлень, коли формати номерів перетинаються або надана інформація про перевізника є неточною.
AI може допомогти розв’язати такі неоднозначні випадки зіставлення.
17TRACK поєднує власну модель AI із традиційним зіставленням на основі правил. Вона використовує багаторічні логістичні дані, щоб визначити найбільш імовірного перевізника та зменшити кількість невдалих запитів через звернення до неправильного джерела.
2.1 Поєднання фіксованих правил із визначенням за допомогою AI
Традиційне визначення перевізника переважно спирається на заздалегідь задані правила для зіставлення кандидатів за довжиною номера, префіксами та комбінаціями символів.
Такий підхід добре працює, коли правила нумерації відрізняються. Подібні правила у різних перевізників або неповна інформація про номер відстеження можуть призвести до неоднозначних результатів.
17TRACK поєднує ідентифікацію за допомогою AI та зіставлення на основі правил, використовуючи характеристики номера відстеження й доступну інформацію про перевізника для визначення ймовірного джерела.
Якщо перевізник, визначений системою, відрізняється від перевізника, указаного компанією, відповідність можна перевірити додатково.
Наприклад:
- Компанія вказує DHL як перевізника.
- Система визначає іншого кандидата на основі шаблону номера відстеження.
- Система може перевірити обидва варіанти, щоб зменшити ризик невдалого запиту через неправильну інформацію про перевізника.
Це зменшує залежність від ручного вибору перевізника та скорочує кількість повторних перевірок у великих пакетах номерів відстеження.
2.2 Власна модель AI, створена на основі багаторічних логістичних даних
Ефективність ідентифікації за допомогою AI залежить від навчальних даних, діапазону охоплених ними прикладів і способу вдосконалення моделі.
17TRACK зосереджується на глобальному відстеженні відправлень із 2010 року. Наразі сервіс охоплює понад 3 500 перевізників і щомісяця накопичує значні обсяги логістичних даних.
Використовуючи ці дані, 17TRACK навчає та вдосконалює власну модель ідентифікації. Постійне навчання й налаштування допомагають моделі вивчати специфічні для перевізників шаблони номерів відстеження та підвищувати точність визначення у складних сценаріях.
AI може надавати додаткові сигнали, коли перевізники використовують подібні правила нумерації та їх складно розрізнити за допомогою традиційного зіставлення.
Такий підхід зменшує обсяг роботи з ручного підтримання фіксованих правил і забезпечує гнучкіше визначення для нових перевізників та складних сценаріїв доставки.
2.3 Поєднання ідентифікації AI із подвійною реєстрацією для зменшення помилок зіставлення
17TRACK також пропонує спосіб підвищити успішність відстеження після визначення перевізника-кандидата.
Якщо система визначає перевізника, відмінного від указаного, компанії з увімкненою подвійною реєстрацією також можуть надсилати запит до перевізника, визначеного AI.
Наприклад:
Компанія надсилає відправлення, позначене як DHL, але система визначає іншого перевізника як більш імовірний варіант.
Якщо подвійну реєстрацію ввімкнено, система може спробувати отримати події відстеження від визначеного перевізника на додаток до виконання початкового запиту.
Це дає компанії змогу отримати правильні дані відстеження, навіть якщо спочатку було вказано неправильного перевізника.
Разом ці можливості допомагають зменшити кількість невдалих запитів, яких можна уникнути та які спричинені помилками зіставлення перевізників.
3. Дослідження причин результатів Not Found
Навіть коли перевізника визначено правильно, деякі запити спочатку можуть не повертати подій відстеження.
Номер відстеження міг бути щойно створений, а перевізник може все ще очікувати на отримання відправлення. Сервіс відстеження перевізника також може бути тимчасово недоступним. Будь-яка з цих ситуацій може призвести до результату Not Found.
Сам по собі результат Not Found недостатній для висновку, що відправлення ще не було відправлено або його втрачено.
Для підвищення показників успішного відстеження потрібно визначити причину та вжити відповідних заходів.
3.1 Визначення причини для уникнення непотрібних запитів
Поширені причини результатів Not Found або невдалих запитів включають:
| Тип проблеми | Можлива причина | Рекомендована дія |
|---|---|---|
| Неправильне зіставлення перевізника | Фактичний перевізник не відповідає вибраному перевізнику. | Повторно визначити та перевірити перевізника. |
| Неправильна інформація про відстеження | Неправильний номер відстеження або відсутні обов’язкові параметри. | Перевірити номер відстеження та параметри запиту. |
| Оновлення відстеження недоступні | Номер відстеження створено, але перевізник ще не надав першої події відстеження. | Дочекатися оновлення інформації про відстеження перевізником. |
| Помилка джерела даних | Помилка API перевізника, обмеження сервісу або інші проблеми. | Відстежувати стан API перевізника та досліджувати винятки. |
Кожна причина потребує окремої реакції.
У разі помилки зіставлення перевізника повторне визначення перевізника та перевірка джерела даних можуть вирішити проблему. Якщо перевізник ще не створив першої події відстеження, повторні запити можуть і надалі не повертати нової інформації.
Розрізнення цих сценаріїв зменшує кількість непотрібних запитів і повторного усунення несправностей.
3.2 Моніторинг даних перевізників для раннього виявлення проблем
Окрім окремих невдалих запитів, компаніям потрібно стежити за проблемами, що впливають на групи відправлень.
Якщо перевізник зазвичай повертає події відстеження, але велика кількість відправлень раптово показує Not Found, наступним кроком слід перевірити API перевізника, сервіс відстеження на його вебсайті або процес отримання даних.
17TRACK постійно контролює ефективність даних перевізників. Коли система виявляє зниження ефективності або незвичні коливання, вона створює сповіщення та інформує клієнтів.
Це дає компаніям змогу раніше виявляти проблеми на боці перевізника, щоб вони могли скоригувати процедури запитів і обробки до того, як накопичаться скарги клієнтів.
Визначення перевізника, усунення несправностей і моніторинг джерел дають командам можливість досліджувати результати Not Found і працювати з ними.
4. Приклади клієнтів із підвищенням показників успішного відстеження
Ефективність відстеження у реальних операціях демонструє вплив ідентифікації за допомогою AI та роботи з результатами Not Found.
Показники успішного відстеження відрізняються залежно від клієнта та залежать від таких факторів, як охоплення перевізників, якість номерів відстеження, стратегія запитів і доступність джерела даних.
Два приклади клієнтів 17TRACK:
Приклад 1: Провідна глобальна платформа швидкої моди
- Масштаб: у середньому відстежує десятки мільйонів замовлень щодня.
- Показник успішного відстеження: зріс із 44,25% до 93,29%.
Приклад 2: Американська платформа захисту покупок після придбання в електронній комерції
- Масштаб: обслуговує понад 5 000 провідних брендів у всьому світі.
- Показник успішного відстеження: зріс із 85% до 95%.
Ці результати відображають покращення в загальних операціях клієнтів із відстеження. Їх не можна приписувати лише AI або використовувати як специфічні для перевізників показники успішності DHL чи DPD.
Для компаній, які обробляють великі обсяги транскордонних замовлень, вищі показники успішного відстеження означають більше придатних для використання даних про відправлення для керування замовленнями, підтримки клієнтів і операцій після придбання.
Підвищення ймовірності отримання правильних подій відстеження для кожного дійсного номера
Запит відстеження може здаватися таким простим, як введення номера. Але за лаштунками він включає визначення перевізника, зіставлення джерела даних, отримання даних і постійний моніторинг.
Перекриття форматів номерів, неповна інформація про перевізника та передавання відправлення між перевізниками можуть впливати на результат, особливо під час транскордонної доставки.
17TRACK API поєднує визначення перевізника на основі AI, власну модель логістичних даних, подвійну реєстрацію та постійне керування результатами Not Found, щоб допомогти компаніям зменшити кількість помилок зіставлення джерел даних, яких можна уникнути, і ефективніше отримувати дані відстеження.
