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