Как унифицировать отслеживание отправлений в Австралии и Новой Зеландии с помощью одного API

Чтобы унифицировать отслеживание отправлений в Австралии и Новой Зеландии с помощью одного API, подключите систему заказов или выполнения заказов к службе отслеживания с поддержкой нескольких перевозчиков, регистрируйте каждое отправление с правильным идентификатором перевозчика и преобразуйте входящие обновления отслеживания в согласованную внутреннюю модель событий. Интеграция должна сохранять сведения, специфичные для перевозчика, и одновременно предоставлять операционной команде и клиентам единый опыт отслеживания внутренних и транс-тасманских доставок.

Для разработчиков, операторов электронной коммерции и логистических команд главная проблема заключается не в выполнении первого API-запроса. Она состоит в том, чтобы сохранять согласованность идентификаторов отправлений, статусов доставки, передачи между перевозчиками и уведомлений клиентов, когда разные перевозчики по-разному описывают один и тот же путь. В этом руководстве объясняется, как спроектировать такую интеграцию, оценить API отслеживания и протестировать его до использования в рабочей среде.

17TRACK API — Упростите глобальное отслеживание посылок с обновлениями по отправлениям от более чем 3500 перевозчиков. Подробнее → Связанная статья: Лучшее программное обеспечение для отслеживания отправлений для команд электронной коммерции и логистики

Определите, что именно должен унифицировать единый API

Общий API предоставляет вашему приложению единую точку интеграции. Он не заставляет всех перевозчиков публиковать идентичную информацию или сканировать посылки с одинаковой частотой. Ваша архитектура должна различать согласованный интерфейс и полную видимость.

Начните с реестра отправлений, основанного на фактической активности по выполнению заказов, а не на общем списке перевозчиков, работающих в любой из двух стран. Включите внутренние отправления по Австралии, внутренние отправления по Новой Зеландии и трансграничные перемещения в обоих направлениях. Добавьте другие международные направления отправки, если они входят в сферу вашего бизнеса.

• Перевозчик и услуга: Зафиксируйте перевозчика, использованную услугу и любого известного партнёра по доставке.
• Маршрут: Различайте пункт отправления и пункт назначения отправления и местоположение последнего сканирования.
• Идентификаторы: Сохраняйте ссылку на заказ, ссылку на выполнение заказа, номер отслеживания, а также любой заменяющий номер или номер партнёра.
• Операционная цель: Укажите, предназначены ли обновления для отслеживания клиентами, управления исключениями, подтверждения доставки или всех трёх целей.
• Необходимые сведения: Определите, достаточно ли общего статуса доставки или сотрудникам также нужны описания сканирований, местоположения и временные метки.

Этот реестр становится вашим контрольным списком приёмки. Общий охват перевозчиков провайдера полезен для предварительного отбора, но решение должно основываться на том, возвращают ли фактически используемые вами сочетания перевозчиков и услуг пригодную для использования информацию об отслеживании.

Решение для брендированного отслеживания заказов — Улучшайте клиентский опыт и увеличивайте количество повторных покупок с помощью брендированного отслеживания и автоматических уведомлений. Попробовать бесплатно →

Оцените API отслеживания с учётом структуры ваших отправлений

17TRACK предлагает Tracking API, поэтому его стоит рассмотреть для интеграции с несколькими перевозчиками. Используйте его официальную документацию API, чтобы проверить текущие требования к интеграции. Рассматривайте поддержку перевозчиков, поля событий, поведение обновлений, ограничения аккаунта и коммерческие условия как параметры, которые необходимо проверить для вашей реализации, а не как предположения, сделанные на основе категории продукта.

Продолжить чтение: Отслеживание несколькими перевозчиками: что это такое, преимущества и принцип работы

Задавайте каждому рассматриваемому API одни и те же практические вопросы:

• Может ли он идентифицировать и отслеживать перевозчиков и услуги из вашего реестра отправлений?
• Если определить перевозчика однозначно невозможно, можете ли вы передать явный идентификатор перевозчика?
• Как ваше приложение получает обновления и какой механизм восстановления доступен, если обновление пропущено?
• Какие исходные сведения о перевозчике сохраняются вместе с нормализованными статусами?
• Что происходит, если номер отслеживания недействителен, ещё не распознан или связан более чем с одним возможным перевозчиком?
• Как для вашего аккаунта определяются использование, тарификация, продолжительность отслеживания и ограничения доступа?

Рекомендуемое правило принятия решения: выбирайте решение на основе успешного тестирования ваших реальных сценариев доставки, а не на основании самого большого заявленного количества перевозчиков. Интеграция подходит, если предоставляет достаточно информации для поддержки ваших операционных решений и достаточно ясно показывает сбои, чтобы их можно было устранить.

Создайте внутреннюю модель, устойчивую к различиям между перевозчиками

Разделяйте заказы, отправления и этапы отслеживания

Не используйте номер отслеживания как первичный ключ заказа. Один заказ может содержать несколько посылок, а путь посылки может включать более одного идентификатора отслеживания. Вместо этого создайте внутренний ID отправления и привяжите к нему записи отслеживания.

Практическая модель имеет три уровня: заказ клиента, его физические отправления и этапы отслеживания, связанные с каждым отправлением. Для внутренней посылки может быть достаточно одного этапа отслеживания. Для трансграничной посылки могут потребоваться связанные записи, если становится актуальным другой перевозчик или идентификатор.

Дополнительное чтение: Как улучшить отслеживание отправлений для трансграничных заказов

Определяйте запись отслеживания не только по номеру отслеживания, но и по перевозчику, сохраняя её связь с ID отправления. Если появляется новый номер партнёра по доставке, добавьте его как связанный идентификатор, а не перезаписывайте исходный. Это сохраняет историю, необходимую сотрудникам поддержки при расследовании передачи отправления.

Храните исходное событие и нормализованное событие

Используйте небольшой внутренний словарь статусов, на основании которого ваш бизнес может действовать. Например, можно определить статусы «до отправки», «в пути», «готовится к доставке», «доступно для получения», «доставлено», «исключение» и «неизвестно». Это рекомендуемые внутренние категории, а не утверждение о схеме статусов конкретного провайдера.

Храните исходное описание перевозчика вместе с сопоставленным статусом. Событие в пункте выдачи и проблема с адресом могут требовать действий клиента, но не должны порождать одинаковое сообщение. Аналогично, создание этикетки не должно автоматически считаться доказательством того, что перевозчик физически получил посылку.

Документируйте решения по сопоставлению в конфигурации с контролем версий. Если появляется новое описание события, помещайте его в очередь на проверку, когда его значение неясно. Явное состояние «неизвестно» безопаснее, чем уверенное назначение неправильного результата доставки.

Различайте время события и время получения

Храните время возникновения события отдельно от времени его получения вашей системой. Более старое сканирование может поступить после более нового, особенно если обновления задерживаются или исторические события передаются вместе.

Для Австралии и Новой Зеландии не применяйте один фиксированный часовой сдвиг ко всем отправлениям. Сохраняйте исходные временные метки и смещения, если они предоставлены. Используйте подходящий именованный часовой пояс для отображения, когда у вас есть надёжный контекст местоположения, и учитывайте переходы на летнее время. Если исходный часовой пояс отсутствует, сохраняйте эту неопределённость, а не выдумывайте точное преобразование в UTC.

Реализуйте надёжный процесс получения данных

1. Сначала создайте внутреннее отправление. До регистрации в службе отслеживания сохраните его связь с заказом, маршрут, выбранного перевозчика и идентификатор отслеживания.
2. Отправьте регистрацию отслеживания. Используйте задокументированный формат запроса провайдера. Сохраните ответ и различайте успешную регистрацию и последующую доступность событий перевозчика.
3. Классифицируйте сбои. Отделяйте недействительные входные данные и проблемы аутентификации от временных сбоев службы. Повторяйте запрос только в случаях, когда повтор действительно может помочь.
4. Получайте или извлекайте обновления. Реализуйте механизм доставки, поддерживаемый выбранным API. При использовании вебхуков проверяйте входящие запросы задокументированным провайдером способом и обрабатывайте принятые события через надёжную очередь.
5. Удаляйте дубликаты до применения изменений. Используйте идентификатор события провайдера, если он доступен, либо тщательно спроектированный составной ключ. Повторная доставка не должна запускать повторные уведомления клиентов.
6. Пересчитывайте состояние отправления. Оценивайте значение и хронологию событий, а не заменяйте текущий статус тем обновлением, которое пришло последним.
7. Сверяйте неполные записи. Если API поддерживает получение данных, используйте его для расследования пропущенных обновлений или устаревших записей в пределах применимых лимитов использования.

Храните специфичные для провайдера данные аутентификации, имена полей и обработку ошибок внутри адаптера. Ваша система управления заказами должна использовать внутреннюю модель отправления, а не напрямую зависеть от каждой детали ответа провайдера. Такое разделение также упрощает тестирование последующих изменений API.

Обрабатывайте транс-тасманские маршруты без выдуманной уверенности

Для трансграничного отслеживания требуется больше контекста, чем последовательность меток статуса. Ваше приложение должно различать событие экспорта, событие, связанное с таможней, передачу перевозчику и событие финальной доставки, если исходные данные позволяют провести такие различия.

Не делайте вывод о таможенном оформлении на основании общего сканирования «в пути». Аналогично, отсутствие недавнего сканирования не доказывает, что посылка находится на таможне. Полезное сообщение клиенту указывает последнее подтверждённое событие и его время, а затем объясняет возможное следующее действие, которое ваша команда действительно может поддержать.

Храните пункт отправления и пункт назначения отдельно от местоположения сканирования. Отправление, следующее из Австралии в Новую Зеландию, не становится внутренним отправлением Новой Зеландии только потому, что получило сканирование прибытия. Это различие важно для отчётности по маршрутам и определения ответственного за исключение.

Если к доставке подключается партнёр, связывайте его запись отслеживания только тогда, когда связь подтверждается данными отправления, службой отслеживания или операционно проверенной записью. Не объединяйте посылки только потому, что их идентификаторы выглядят похожими.

Превращайте события отслеживания в полезные обновления для клиентов

Страница для клиентов должна отвечать на четыре вопроса: каков последний подтверждённый статус, когда это произошло, где это было зафиксировано, если известно, и требуется ли действие со стороны клиента?

Отделяйте правила уведомлений от получения событий. Не каждое сканирование заслуживает электронного письма или текстового сообщения. Определите значимые переходы, например первое подтверждённое перемещение, попытку доставки, необходимость получения или событие доставки, и подавляйте повторные уведомления об одном и том же переходе.

• Устаревшее отслеживание: Указывайте время последнего обновления, не считая отсутствие сообщений доказательством потери.
• Оценки доставки: Различайте оценку перевозчика и обещание продавца. Не придумывайте дату, если ни одного из них нет.
• Исключения: Указывайте конкретный следующий шаг, если он известен, вместо необъяснимой метки ошибки.
• Споры о доставке: Сохраняйте исходное событие и направляйте случай в службу поддержки; одного статуса «доставлено» недостаточно для разрешения каждого спора клиента.

Защищайте страницы отслеживания так же, как учётные данные API. Не раскрывайте ненужные адресные или контактные данные, храните учётные данные службы на сервере и применяйте средства контроля доступа, соответствующие отображаемой информации.

Проведите пилот по маршрутам до запуска

Протестируйте внутренние отправления по Австралии, внутренние отправления по Новой Зеландии, отправления из Австралии в Новую Зеландию и из Новой Зеландии в Австралию, если эти маршруты актуальны для вашего бизнеса. Включите обычные доставки и операционные крайние случаи: разделённые заказы, нераспознанные номера, передачи, попытки доставки, события получения, возвраты и сканирования, поступающие с задержкой.

17RETURNS — решение для возвратов и обменов — Сокращайте расходы на поддержку и сохраняйте больше выручки с помощью автоматизированных возвратов и обменов, дополненных интеллектуальными инструментами удержания. Попробовать бесплатно →

Используйте реальные записи отправлений с соответствующими разрешениями для проверки перевозчиков. Используйте синтетические события для проверки устойчивости собственного приложения, но не рассматривайте синтетические результаты как доказательство фактического охвата перевозчиков.

• Проверка идентичности: Каждое обновление поступает к правильному отправлению и заказу.
• Проверка хронологии: События, поступившие не по порядку, не приводят к неправильному откату прогресса доставки.
• Проверка восстановления: Временные сбои и дублирующиеся обновления не приводят к потере данных или повторным уведомлениям.
• Проверка поддержки: Сотрудники могут просмотреть исходное событие и понять статус, отображаемый клиенту.
• Коммерческая проверка: Ожидаемое использование соответствует подтверждённой модели тарификации и ограничениям аккаунта.

Установите пороговые значения приёмки до оценки пилота. Измеряйте результаты регистрации, несопоставленные события, задержки обработки, дубли уведомлений и неразрешённые устаревшие отправления. Отделяйте задержки в данных перевозчика от задержек в вашем приложении, чтобы исправление направлялось ответственному владельцу.

Реализация готова, когда ваша команда может объяснить неполное отслеживание и восстановиться после него, а не просто отображать успешные доставки. Один API упрощает подключение; именно модель отправления, правила событий и операционные процедуры делают это подключение надёжным.

Дополнительное чтение: Как выбрать API отслеживания отправлений для электронной коммерции?

Часто задаваемые вопросы

Заменяет ли один API отслеживания интеграции с перевозчиками?

Не обязательно. Отслеживание, создание этикеток, бронирование забора, расчёт тарифов и таможенная документация — это отдельные функции. Проверьте область действия выбранного продукта и сохраните другие интеграции там, где они необходимы вашему процессу выполнения заказов.

Вам также может понравиться: Интеграции доставки Bigcommerce: варианты тарифов, этикеток и отслеживания

Можно ли зарегистрировать номер отслеживания до первого сканирования перевозчиком?

Проверьте правила регистрации API. Спроектируйте приложение так, чтобы оно различало принятую регистрацию отслеживания и подтверждённое физическое перемещение. Запись без событий не должна автоматически отображаться как находящаяся в пути.

Будет ли единый API предоставлять обновления в реальном времени для каждого перевозчика?

Не следует так считать. Актуальность на всём пути зависит от того, когда перевозчик публикует данные, когда служба отслеживания получает их и когда ваше приложение обрабатывает их. Подтвердите поведение обновлений для используемых вами сочетаний перевозчиков и услуг.

Что должно происходить при изменении номера отслеживания?

Сохраните исходный идентификатор и привяжите подтверждённый заменяющий идентификатор или идентификатор партнёра к тому же внутреннему отправлению. Сохраняйте обе истории и не допускайте, чтобы дублирующиеся записи создавали противоречивые уведомления.

Актуален ли 17TRACK для этой интеграции?

Да. Его Tracking API подходит для описанной здесь интеграции с несколькими перевозчиками. Оцените его на примерах отправлений по Австралии и Новой Зеландии, а перед развёртыванием подтвердите поддержку перевозчиков, техническое поведение и условия аккаунта с помощью официальных ресурсов API.

Источники

• 17TRACK Tracking API — официальный ресурс продукта для рассматриваемого в руководстве варианта API.
• Документация 17TRACK API — официальный технический справочник для проверки форматов запросов, требований к интеграции и поддерживаемого поведения.