Göndəriş izləmə API-sini e-ticarət mağazanıza necə inteqrasiya etmək olar

Göndəriş izləmə API-sini e-ticarət mağazanıza inteqrasiya etmək üçün sifariş sisteminizi izləmə provayderinə qoşun, göndəriş və daşıyıcı məlumatlarını təhlükəsiz server tərəfli sorğu vasitəsilə göndərin, normallaşdırılmış izləmə hadisələrini yadda saxlayın və nəticədə yaranan statusu müştəri və dəstək interfeyslərində göstərin. Etibarlı tətbiq sadəcə izləmə nömrəsi sahəsi əlavə etməkdən daha çoxunu tələb edir: o, daşıyıcı seçimini, status yeniləmələrini, çatdırılma istisnalarını, təkrar cəhdləri, məxfiliyi və müştərilərin satınalmadan sonrakı məlumatlardan faktiki istifadə formasını idarə etməlidir.

Bu təlimat mağaza sahibləri, tərtibatçılar və əməliyyat komandaları üçün praktik inteqrasiya yanaşmasını izah edir. İstinad nöqtəsi kimi 17TRACK-in rəsmi Tracking API sənədlərindən istifadə edir, lakin eyni planlaşdırma prinsipləri başqa çoxdaşıyıcılı provayderi qiymətləndirərkən də tətbiq olunur.

İnteqrasiyanın nəyə nail olmalı olduğunu müəyyənləşdirin

API son nöqtəsindən deyil, biznes nəticəsindən başlayın. Əksər mağazalar “Sifarişim haradadır?” müraciətlərini azaltmaq, alıcılara aydın çatdırılma görünüşü təqdim etmək və müştəri şikayət etməzdən əvvəl əməliyyatlara gecikmiş göndərişləri müəyyənləşdirməyə kömək etmək istəyir. Bu məqsədlər fərqli məlumat və iş axınları tələb edir.

• Müştəri görünürlüğü: cari göndəriş statusunu, mövcud olduqda təxmini çatdırılma məlumatını, daşıyıcı məlumatlarını və son əhəmiyyətli hadisəni göstərin.
• Əməliyyat görünürlüğü: əməkdaşlara daşıyıcılar üzrə gecikmiş, dayanmış, qaytarılmış və ya istisna vəziyyətində olan göndərişləri tapmağa imkan verin.
• Avtomatlaşdırılmış kommunikasiya: göndəriş müəyyən edilmiş vəziyyətə çatdıqda təsdiqlənmiş e-poçt, SMS və ya digər bildirişləri işə salın.
• Məlumat ardıcıllığı: müxtəlif daşıyıcı hadisə etiketlərini mağazanızın etibarlı şəkildə istifadə edə biləcəyi daha az sayda statusa çevirin.

İcra üsulunu seçməzdən əvvəl bu nəticələri müəyyənləşdirin. İzləmə API-si göndəriş məlumatlarını təmin edə bilər, lakin hansı hadisələrin müştəri bildirişinə layiq olduğunu və ya mağazanızın ünvan problemi ilə necə davranmalı olduğunu avtomatik müəyyən etmir.

Düzgün inteqrasiya arxitekturasını seçin

Tipik arxitektura dörd təbəqədən ibarətdir: e-ticarət platforması, inteqrasiya xidməti, izləmə provayderi və müştəriyə yönəlmiş təcrübə. İnteqrasiya xidməti backend tətbiqi, sifarişlərin idarə edilməsi sistemi və ya serversiz iş axını ola bilər. Bu məntiqi serverdə saxlamaq adətən API məlumatlarını brauzer koduna yerləşdirməkdən daha təhlükəsizdir.

Əsas axın belə görünür:

1. Ödənilmiş sifariş icra olunur və izləmə nömrəsi ilə daşıyıcı əldə edir.
2. Backend-iniz göndəriş məlumatlarını izləmə provayderinə göndərir.
3. Provayder API dizaynına uyğun olaraq izləmə identifikatoru və ya izləmə məlumatlarını qaytarır.
4. Sisteminiz provayder istinadını yadda saxlayır və göndəriş hadisələrini daxili statuslara uyğunlaşdırır.
5. Planlaşdırılmış yeniləmə prosesi və ya dəstəklənən hadisə bildirişi göndərişi yeniləyir.
6. Mağazanızın vitrini, sifariş səhifəsi, dəstək alətləri və bildiriş xidməti öz normallaşdırılmış məlumatlarınızdan oxuyur.

Hər səhifə baxışında daşıyıcıya və ya izləmə API-sinə sorğu göndərməyin. Bu dizayn müştəri təcrübəsinin yavaşlamasına, təkrarlanan sorğulara, sürət limiti problemlərinə və uyğunsuz nəticələrə səbəb ola bilər. Son qəbul edilmiş izləmə vəziyyətini verilənlər bazanızda saxlayın və onu nəzarət olunan fon tapşırıqları və ya provayderin dəstəklənən yeniləmə mexanizmi vasitəsilə yeniləyin.

Kod yazmazdan əvvəl provayderin sənədlərini təsdiqləyin

Tətbiqdən əvvəl provayderin rəsmi API sənədlərini autentifikasiya, sorğu formatları, cavab sahələri, dəstəklənən daşıyıcılar, xəta davranışı, yeniləmə mexanizmləri və hesab tələbləri baxımından nəzərdən keçirin. 17TRACK xüsusi Tracking API məhsul səhifəsi və tərtibatçı sənədləri təqdim edir. Forumlardan və ya köhnə inteqrasiya təlimatlarından köçürülmüş nümunələrə etibar etmək əvəzinə, cari API davranışı üçün bu səhifələri əsas mənbə hesab edin.

Sənədlər əsasında qısa tələblər siyahısı hazırlayın:

• API məlumatları necə verilir, saxlanılır, yenilənir və ləğv edilir?
• Sorğu daşıyıcı kodu tələb edir, yoxsa xidmət daşıyıcını izləmə nömrəsindən müəyyən edə bilər?
• Hansı cavab sahələri göndərişi, statusu, yeri, vaxt nişanlarını və istisna mesajını müəyyən edir?
• Hesab onları dəstəkləyirsə, asinxron yeniləmələr necə çatdırılır?
• Sənədləşdirilmiş sorğu limitləri, ödəniş qaydaları, vaxt aşımı gözləntiləri və xəta kodları hansılardır?
• Təkrarlanan izləmə nömrələri, etibarsız nömrələr, naməlum daşıyıcılar və çatdırılmış göndərişlər necə idarə olunmalıdır?

Xüsusiyyəti məhsul adından çıxarmayın. Məsələn, “real-time” məhsulun mövqeləndirilməsini ifadə edə bilər, lakin bu, hər daşıyıcı hadisəsinin dərhal göründüyünə zəmanət vermir. Tətbiqiniz daşıyıcı skanlarının gecikə biləcəyini və API-nin daşıyıcının bildirmədiyi skanı yarada bilməyəcəyini izah etməlidir.

Sifariş və göndəriş məlumatlarını hazırlayın

İzləmənin yaradılması üçün ən uyğun vaxt adətən sifarişin yaradılması deyil, göndərişin icrasıdır. Sifariş ödənilmiş ola bilər, lakin hələ qablaşdırılmamışdır və izləmə nömrəsi bağlama daşıyıcı tərəfindən qəbul edilməzdən əvvəl yaradıla bilər. İcra iş axınınızda hansı hadisənin izləmə qeydini yaratmalı olduğunu müəyyənləşdirin.

Daxili göndəriş qeydiniz ən azı aşağıdakı dəyərləri fərqləndirməlidir:

• Daxili sifariş ID-si və icra ID-si
• İzləmə nömrəsi
• Daşıyıcının adı və ya daşıyıcı kodu
• Əməliyyat baxımından zəruri olduqda təyinat ölkəsi və ya regionu
• Qaytarılıbsa, provayder izləmə ID-si və ya abunə istinadı
• Cari normallaşdırılmış status
• Son hadisə vaxt nişanı və son sinxronizasiya vaxt nişanı
• Provayderin xam cavabı və ya nəzarət olunan audit istinadı

Sifariş və göndəriş məlumatlarını ayrı saxlayın. Bir sifarişdə bir neçə bağlama, bölünmüş göndəriş və ya müxtəlif daşıyıcılar ola bilər. Bir sifarişin yalnız bir izləmə nömrəsi ilə əlaqələndirilməsi fərziyyəsi anbar məhsulları ayrı-ayrılıqda göndərdikdə çox vaxt uğursuz olur.

İdemponent prosesdən istifadə edin. İcra sistemi eyni sorğunu təkrar göndərərsə, inteqrasiya təkrarlanan abunəliklər və ya müştəri mesajları yaratmaq əvəzinə mövcud göndərişi yeniləməlidir. Praktik idempotentlik açarı provayderin öz tələblərindən asılı olaraq daxili icra ID-si, daşıyıcı identifikatoru və izləmə nömrəsini birləşdirə bilər.

Müştərilər üçün daşıyıcı statuslarını normallaşdırın

Daşıyıcılar fərqli etiketlərdən və hadisə ardıcıllıqlarından istifadə edir. Mağazanız Məlumat alındı, Yoldadır, Çatdırılma üçün çıxarılıb, Çatdırıldı, İstisna və Qaytarıldı kimi kiçik daxili status modelini saxlamalıdır. Dəstək əməkdaşları üçün orijinal daşıyıcı hadisəsini qoruyun, lakin vitrin məntiqi üçün normallaşdırılmış statusdan istifadə edin.

Normallaşdırma qaydaları açıq olmalıdır. “Etiket yaradıldı” hadisəsi bağlamanın hərəkətdə olduğuna sübut kimi təqdim edilməməlidir. “Çatdırıldı” daşıyıcı tərəfindən bildirilmiş hadisə kimi qəbul edilməlidir, müştərinin bağlamanı fiziki olaraq tapdığına zəmanət kimi yox. Göndərişin sonradan davam edə biləcəyi ehtimalına görə istisna hadisəsi səssizcə “yoldadır” statusuna çevrilməməlidir.

Həmçinin status üstünlüyünü və geriləmə hallarının idarə edilməsini müəyyənləşdirin. Gecikmiş daşıyıcı məlumatı hadisələri ardıcıllıqdan kənar gətirə bilər. Mövcud olduqda hadisə vaxt nişanlarını müqayisə edin, xam hadisəni qeyd edin və daha yeni “çatdırıldı” vəziyyətini köhnə “yoldadır” vəziyyəti ilə əvəz etməyin. Vaxt nişanları yoxdursa və ya qeyri-müəyyəndirsə, ardıcıllıq uydurmaq əvəzinə ehtiyatlı yeniləmə üçün qeydi işarələyin.

Server tərəfli sorğu axınını qurun

Backend-iniz izləmə provayderinə müraciət etməzdən əvvəl daxil olan icra məlumatlarını yoxlamalıdır. İzləmə nömrəsinin mövcud olduğunu yoxlayın, təsadüfi boşluqları silin, uyğun olduqda gözlənilən formatı təsdiqləyin və daşıyıcı dəyərinin məqbul olduğunu yoxlayın. Qeyri-adi, lakin etibarlı izləmə nömrələrini yalnız dar yerli nümunəyə uyğun gəlmədikləri üçün rədd etməyin.

Provayderdən asılı olmayan sorğu axını belə göstərilə bilər:

icra hadisəsini qəbul et
sifariş və göndəriş sahələrini yoxla
mövcud idempotentlik açarını yoxla
də sənədləşdirilmiş izləmə sorğusunu serverdən göndər
provayderin cavabını və daxili göndəriş qeydini saxla
yeniləməni növbəyə əlavə et və ya dəstəklənən yeniləmə hadisəsini emal et
yalnız təsdiqlənmiş sahələri mağazanın vitrininə yayımla

Müvəqqəti xətalar üçün qısa vaxt aşımı, məhdud təkrar cəhdlər və eksponensial geriləmədən istifadə edin. Hər xətanı təkrar etməyin. Autentifikasiya xətası, etibarsız sorğu və ya dəstəklənməyən daşıyıcı adətən təkrar çağırışlardan çox düzəliş tələb edir. Korrelyasiya ID-sini, sorğunun nəticəsini və provayder xətasının kateqoriyasını qeyd edin, lakin API açarlarını, müştərinin tam ünvanlarını və lazımsız şəxsi məlumatları tətbiq jurnallarına yazmaqdan çəkinin.

Provayderin cavabını müştəriyə yönəlmiş modeldən ayrı saxlayın. Bu, provayderləri dəyişməyi, uyğunlaşdırma qaydasını düzəltməyi və açıq sifariş səhifəsi vasitəsilə nümayiş etdirilən məlumatları məhdudlaşdırmağı asanlaşdırır.

Müştəri izləmə təcrübəsini dizayn edin

İzləmə səhifəsi üç suala tez cavab verməlidir: cari vəziyyət nədir, ən son nə baş verib və müştəri bundan sonra nə etməlidir? Sifariş istinadını, məxfiliyə diqqət yetirilən formada göndəriş nömrəsini, daşıyıcının adını, son hadisənin vaxtını və istisnalar üçün aydın izahı göstərin.

Boş zaman xəttini texniki xəta kimi göstərməyin. İlk daşıyıcı skanından əvvəl göndəriş məlumatının alındığını və hərəkətin hələ görünməyə biləcəyini izah edin. İstisna halı üçün yalnız mənbə məlumatları bunu dəstəklədikdə sadə dildə izah verin. Daşıyıcı ünvan problemi barədə məlumat verirsə, biznesinizin həqiqətən təqdim edə biləcəyi dəstək prosesinə və ya müştəri xidməti tədbirinə keçid verin.

Shopify və ya başqa e-ticarət platformasında qurulmuş mağazalar üçün icra hadisələrinin, müştəri hesablarının, sifariş statusu səhifələrinin və bildiriş şablonlarının platforma tərəfindən necə təqdim edildiyini yoxlayın. Shopify-in rəsmi tərtibatçı sənədlərinə webhook-lar və icra məlumatları üçün resurslar daxildir. Platforma API-ləri və versiyalı sənədlər dəyişə bilər, buna görə istehsal işindən əvvəl tətbiqinizin istifadə etdiyi versiyanı təsdiqləyin.

Bildirişlərdən diqqətlə istifadə edin

Göndəriş hadisələri faydalı işə salıcılar olsa da, hər daşıyıcı skanı üçün mesaj göndərmək bildiriş yorğunluğu yarada bilər. Göndərişin yaradılması, əhəmiyyətli yolda irəliləyiş, çatdırılma üçün çıxarılma, çatdırılma və seçilmiş istisnalar zamanı bildiriş göndərmək kimi biznes qaydalarını müəyyənləşdirin. Təkrar bildirişləri susdurun və təkrarlanan gecikmə mesajları üçün minimum interval əlavə edin.

Əməliyyat xəbərdarlıqlarını müştəri bildirişlərindən ayırın. Dəstək komandası göndərişin bir neçə gün dəyişmədiyini bilməli ola bilər, müştəri isə yalnız daşıyıcı konkret istisna barədə məlumat verdikdə mesaj almalıdır. Vaxt həddi əməliyyat əsası olmayan universal rəqəmdən deyil, xidmət səviyyəsindən, təyinat yerindən, daşıyıcıdan və göndəriş üsulundan asılı olmalıdır.

Real çatdırılma ssenariləri ilə test edin

Bir izləmə nömrəsi üçün uğurlu cavab istehsala buraxılış üçün kifayət deyil. Bir neçə daşıyıcını, ölkəni, göndəriş növünü və hadisə vəziyyətini əhatə edən test matrisi yaradın. Ən azı bunları test edin:

• Daşıyıcı skanı olmayan yeni yaradılmış göndəriş
• Normal yolda olan göndəriş
• Çatdırılma üçün çıxarılmış göndəriş
• Çatdırılmış göndəriş
• İstisna və ya ünvanla bağlı hadisə
• Qaytarılmış göndəriş
• Etibarsız izləmə nömrəsi
• Təkrarlanan icra hadisəsi
• Gecikmiş provayder cavabı və ya vaxt aşımı
• Ardıcıllıqdan kənar hadisə

API əlçatanlığından daha çoxunu ölçün. Düzgün sifarişin yenilənib-yenilənmədiyini, müştərinin başa düşülən dil görüb-görmədiyini, təkrarlanan bildirişlərin susdurulub-susdurulmadığını və dəstək əməkdaşlarının orijinal daşıyıcı hadisəsini müəyyən edə bilib-bilmədiyini yoxlayın. Əvvəlcə məhdud tətbiq həyata keçirin, əməliyyat ehtiyat variantını saxlayın və buraxılışdan sonra xəta kateqoriyalarını izləyin.

Təhlükəsizlik, məxfilik və texniki xidmət

Məlumatları sirr idarəetmə sistemində və ya qorunan mühit dəyişənində saxlayın; onları tema kodunda, mobil kodda, mənbə nəzarətində və ya brauzer sorğularında saxlamayın. Göndəriş məlumatlarına girişi rollara görə məhdudlaşdırın, HTTPS-dən istifadə edin və xam cavabların və müştəri ilə bağlı sahələrin nə qədər müddət saxlanıldığını nəzərdən keçirin.

Provayderin sənədlərini və e-ticarət platformanızın API versiyasını müntəzəm nəzərdən keçirin. Daşıyıcı dəstəyi, hadisə adları, autentifikasiya tələbləri və platformanın webhook davranışı dəyişə bilər. Status uyğunlaşdırma qaydalarını konfiqurasiya edilə bilən saxlayın, onların arxasındakı fərziyyələri sənədləşdirin və müştəriyə başqa mesaj göndərmədən göndərişi yenidən emal və ya uzlaşdırma imkanını təmin edin.

Mağazanızın daşıyıcılar üzrə xüsusi izləmə inteqrasiyasına ehtiyacı olduqda 17TRACK API qiymətləndirilə biləcək uyğun seçimdir. Bununla belə, düzgün seçim istifadə etdiyiniz daşıyıcılardan, xidmət göstərdiyiniz ölkələrdən, hesabınız üçün sənədləşdirilmiş yeniləmə davranışından, gözlənilən sorğu həcmindən və komandanızın tələb etdiyi əməliyyat nəzarətlərindən asılıdır. İstehsal dizaynına qərar verməzdən əvvəl bu məqamları rəsmi sənədlərdə və nəzarət olunan konsepsiya sübutunda təsdiqləyin.

FAQ

İzləmə sifariş yerləşdirildikdə yaradılmalıdır?

Adətən yox. Daşıyıcı və izləmə nömrəsi olduqda icra iş axınınız göndəriş qeydini yaradın və ya aktivləşdirin. Onu ödəniş mərhələsində yaratmaq sonradan ləğv edilən, icra olunmayan və ya bölünən sifarişlər üçün qeydlərin yaranmasına səbəb ola bilər.

İzləmə API-si real vaxtda çatdırılma məlumatına zəmanət verə bilər?

Xeyr. Heç bir API hər daşıyıcı skanının dərhal görünəcəyinə zəmanət verə bilməz. Provayder daşıyıcı məlumatlarından asılıdır və daşıyıcı sistemləri hadisələri gecikmə və ya boşluqlarla bildirə bilər. Vaxt nişanlarını və status dilini dəqiq təqdim edin və müvafiq sənədlər və xidmət müqaviləsi bunu dəstəkləmədikcə dəqiq yenilənmə vaxtı vəd etməyin.

Brauzer birbaşa izləmə API-sinə müraciət etməlidir?

Əksər tətbiqlərdə yox. Məlumatların qorunması, cavabların normallaşdırılması, təkrar cəhdlərin idarə olunması və müştəriyə yönəlmiş məlumatların filtrlənməsi üçün server tərəfli inteqrasiyadan istifadə edin. Mağazanın vitrini adətən tətbiqinizdən təsdiqlənmiş göndəriş görünüşünü oxumalıdır.

Mağaza bir sifarişdə bir neçə bağlamanı necə idarə etməlidir?

Əsas sifariş ID-sini qorumaqla hər icranı və ya bağlamanı ayrıca göndəriş kimi modelləşdirin. Sifariş səhifəsi ümumi xülasəni və hər bağlama üçün ayrıca zaman xətlərini göstərə bilər. Bu, bir bağlama üçün “çatdırıldı” statusunun digər gecikmiş bağlamanı gizlətməsinin qarşısını alır.

İstehsalda izlənəcək ilk göstərici nədir?

İcranın yaradılmasından müştərinin düzgün görə bildiyi yeniləməyə qədər tam axını izləyin. Yalnız API uğuru kifayət deyil. Təkrarlanan qeydləri, köhnəlmiş göndərişləri, uyğunlaşdırılmamış hadisələri, bildiriş xətalarını və əl ilə düzəliş tələb edən göndərişlərin faizini izləyin.

Mənbələr

• 17TRACK Tracking API
• 17TRACK API Documentation
• Shopify Webhooks Documentation
• Shopify Fulfillment Object Documentation