Tracking API vagy Shipping API: Melyikre van szüksége az e-kereskedelmi rendszerének (vagy mindkettőre)?

Használjon szállítási API-t, amikor az e-kereskedelmi rendszerének küldeményeket kell létrehoznia és szállítási címkéket kell generálnia. Használjon nyomkövetési API-t, amikor a feladást követően nyomon kell követnie a küldeményeket, és a fuvarozói frissítéseket hasznos operatív vagy ügyfeleknek szóló információkká kell alakítania. Mindkét képességre szüksége van, ha a szoftverének kezelnie kell a küldemények létrehozását és a vásárlás utáni láthatóságot, de ehhez nem feltétlenül van szüksége két szolgáltatóra vagy két külön integrációra.

A döntést annak kell meghoznia, aki a teljesítési architektúráért felelős: ez jellemzően egy e-kereskedelmi operációs vezető, aki egy mérnöki csapattal dolgozik együtt. Először azonosítsa, hogy az áruháza, raktára vagy teljesítési partnere mit kezel már. Egy újabb API hozzáadásának egy konkrét hiányosságot kell megszüntetnie, nem pedig egy már működő munkafolyamatot megkettőznie.

Mi a különbség a nyomkövetési API és a szállítási API között?

A különbség elsősorban az egyes API-k által végzett feladatban rejlik, nem pedig a termékkategóriák közötti merev határvonalban. Egy szállítási platform tartalmazhat nyomkövetési végpontokat, míg egy nyomkövetési szolgáltatás értesítési eszközöket és ügyfeleknek szóló kézbesítési frissítéseket is biztosíthat. A termék neve helyett a dokumentált végpontokat és az események működését értékelje.

A fuvarozói dokumentáció jól szemlélteti ezt a különválasztást. A FedEx a küldemények létrehozását a Ship API dokumentációjában, a nyomkövetési képességeket pedig a nyomkövetési API dokumentációjában ismerteti. Ezek a különböző technikai felelősségi körök példái, nem pedig egy adott fuvarozó kiválasztására vonatkozó ajánlás.

A küldemény létrehozása nem ugyanaz, mint a mozgásának megfigyelése

A sikeres küldeménylétrehozási válasz azt jelzi a szoftverének, hogy a szállítási kérést feldolgozták. Nem bizonyítja, hogy a fuvarozó fizikailag átvette a csomagot. Hasonlóképpen, nyomkövetési szám akkor is létezhet, amikor a mozgás még nem jelenik meg a nyomkövetési előzményekben.

Ezért a rendeléskezelő rendszerének különbséget kell tennie a címke létrehozása, a raktári átadás, a fuvarozói átvétel és a kézbesítés között. Ha mindezt egyetlen „feladva” eseményként kezeli, az idő előtti ügyfélüzenetekhez vezethet, és elrejtheti azokat a csomagokat, amelyek valójában még nem hagyták el a raktárt.

Olyan képességet válasszon, amely megszünteti jelenlegi szűk keresztmetszetét

Válasszon szállítási API-t, ha a feladás hiányzó elem

A szállítási API a megfelelő kiindulópont, ha saját alkalmazásának a rendelési adatokat küldeménnyé kell alakítania. Ilyen például, amikor a raktári csapat kézzel másolja be a címeket a fuvarozói portálokba, vagy amikor egy egyedi rendeléskezelő rendszer nem tud címkéket generálni.

Mielőtt integrációt választ, határozza meg a tényleges feladási munkafolyamatot. Csak küldeménylétrehozásra van szüksége, vagy díjak lekérésére, lemondásra, felvételi kérelmekre, vámügyi dokumentációra vagy napvégi folyamatokra is? Ezek a funkciók külön API-k lehetnek, függhetnek a fuvarozótól, vagy további fiókjogosultságokat igényelhetnek. Ne feltételezze, hogy a „szállítási API” címkével ellátott termék minden szállítási műveletet tartalmaz.

Önmagában nem ideális megoldás: olyan címkekészítési integráció, amely miatt az ügyfélszolgálati csapatnak továbbra is egyenként kell ellenőriznie a fuvarozók webhelyeit. Ez megoldhatja a feladást, miközben a kézbesítés láthatósága lényegében változatlan marad.

Válasszon nyomkövetési API-t, ha a küldeménylétrehozás már működik

A nyomkövetési API a közvetlenebb megoldás, ha a címkéket már a raktárkezelő rendszer, a teljesítési partner, a piactér vagy egy meglévő szállítási integráció hozza létre, de a kézbesítési információk széttagoltak.

Ebben a helyzetben a címkekészítési munkafolyamat lecserélése migrációs munkát eredményezhet anélkül, hogy megoldaná a központi problémát. Ehelyett kapcsolja össze a felfelé irányuló folyamatban létrehozott nyomkövetési számokat egy olyan láthatósági réteggel, amelyet a rendeléskezelő rendszer, a támogatási eszközök és az ügyfélkommunikáció is használhat.

Ebben a kategóriában a 17TRACK Tracking API releváns integrációs lehetőség. A hivatalos API-dokumentációja ismerteti a nyomkövetési számok regisztrációját és a nyomkövetési adatok munkafolyamatait, beleértve a push-értesítéseket is. Értékelje ezeket a munkafolyamatokat a szükséges fuvarozók, küldeménytípusok és alkalmazásarchitektúra alapján. Ez a nyomkövetési rétegre vonatkozó szempont, nem pedig annak bizonyítéka, hogy a szolgáltatás kiváltja a címkegeneráló integrációt.

Önmagában nem ideális megoldás: nyomkövetési API használata akkor, amikor a szoftverének továbbra sincs módja létrehozni azokat a küldeményeket, amelyek feladásáért felelős. A nyomkövetési láthatóság nem oldja meg a hiányzó szállítási végrehajtást.

Használja mindkettőt, ha alkalmazása a feladásért és a kézbesítés láthatóságáért is felelős

Mindkét képesség megfelelő, ha a rendszerének címkéket kell generálnia, majd megbízható képet kell fenntartania a küldemény előrehaladásáról. Ezek származhatnak egy platformról, különálló szolgáltatásokból, vagy fuvarozói integrációk és egy nyomkövetési réteg kombinációjából.

Részesítse előnyben az egyetlen integrációt, ha annak szállítási és nyomkövetési funkciói szükségtelen kompromisszumok nélkül megfelelnek a dokumentált követelményeinek. Külön integrációkat akkor érdemes fontolóra venni, ha egy meglévő szállítási munkafolyamatot meg akar őrizni, vagy ha a nyomkövetési követelmények lényegesen eltérnek attól, amit az adott munkafolyamat biztosít. Egy külön nyomkövetési szolgáltató nem automatikusan jobb; indokolnia kell a további integrációt, számlázást és operatív felelősséget.

Hogyan illeszkedik mindkét API egy e-kereskedelmi rendszerbe?

A praktikus kialakítás külön rekordként kezeli a rendelést, a küldeményt és a nyomkövetési eseményt. Egy rendelés több csomagot is eredményezhet, és minden csomagnak saját nyomkövetési előzményei lehetnek. Az ügyfeleknek megjelenő rendelési állapotot ezekből a küldeményrekordokból kell levezetni, nem pedig felülírni őket.

1. A rendelés teljesítésre kész állapotba kerül. Az áruház vagy a rendeléskezelő rendszer elküldi a szükséges teljesítési adatokat a felelős raktárnak.
2. A szállítási munkafolyamat létrehozza a küldeményt. Az alkalmazás eltárolja a visszaadott küldeményazonosítót, nyomkövetési számot, fuvarozót, szolgáltatást és címkehivatkozást.
3. A raktár befejezi az átadást. A raktári megerősítés és a fuvarozói átvétel továbbra is megkülönböztethető esemény marad.
4. Elindul a nyomkövetési munkafolyamat. Az alkalmazás regisztrálja vagy elküldi a nyomkövetési számot a kiválasztott integráció követelményeinek megfelelően.
5. A nyomkövetési frissítések eljutnak az alkalmazásba. A webhookok, a lekérdezés vagy ezek támogatott kombinációja frissíti a küldeményrekordot.
6. Az üzleti szabályok meghatározzák a következő lépést. A rendszer frissíti az ügyfeleknek megjelenő állapotot, operatív feladatot hoz létre, vagy üzenetet küld, amikor a releváns feltételek teljesülnek.

Például egy külső teljesítési raktárt használó kereskedőnek saját szoftverében csak a négyes–hatos lépésekre lehet szüksége. A küldemények létrehozásáért már a raktár felel. A saját raktárát üzemeltető kereskedőnek a teljes folyamatra szüksége lehet.

Jelöljön ki egy felelőst minden downstream művelethez

Ha mindkét integráció nyomkövetési frissítéseket biztosít, jelölje ki, hogy melyik rendszer kezeli az ügyfélértesítéseket és az áruházban megjelenő küldeményállapotot. Ellenkező esetben az ügyfelek ismétlődő üzeneteket kaphatnak, vagy egymásnak ellentmondó kézbesítési állapotokat láthatnak.

A másodlagos adatokat megtarthatja vizsgálati célokra anélkül, hogy minden forrás e-mailt küldhetne. Őrizze meg az eredeti fuvarozói eseményt a belső állapot-hozzárendelés mellett, hogy a támogatási munkatársak megérthessék, miért sorolta a rendszer a küldeményt egy adott kategóriába.

Az operatív illeszkedést hasonlítsa össze, ne a funkciócímkéket

Ellenőrizze a ténylegesen használt fuvarozókat és szolgáltatásokat

A fuvarozói támogatás nem egyszerű igen-nem kérdés. Egy szolgáltatás támogathatja egy fuvarozó nyomkövetését anélkül, hogy ugyanahhoz a fuvarozóhoz címkekészítést is támogatna. A címkekészítés függhet a feladás országától, a fuvarozói fiók beállításától vagy a szolgáltatásra való jogosultságtól is.

Állítson össze tesztlistát a tényleges szállítási útvonalai alapján. Tartalmazzon belföldi csomagokat, nemzetközi küldeményeket és a szállítási partnerek közötti minden átadást. Erősítse meg minden esetben a szükséges műveletet: küldemény létrehozását, nyomkövetést vagy mindkettőt. A széles körű lefedettségi állítás kevésbé hasznos, mint az üzletében fontos szolgáltatások sikeres tesztelése.

Vizsgálja meg az események jelentését és az adatok teljességét

Nyomkövetés esetén tesztelje, mi történik az első szkennelés előtt, kézbesítési kivétel során, sikertelen kézbesítési kísérlet után és kézbesítéskor. Ellenőrizze, hogy az időbélyegek tartalmaznak-e időzóna-információt, és hogy az eredeti fuvarozói leírások továbbra is elérhetők-e.

Ne értelmezze a normalizált állapotot úgy, mint minden fuvarozónál azonos adatokra vonatkozó ígéretet. A becsült kézbesítési dátumok, a helyadatok és a kézbesítési igazolás az alapul szolgáló fuvarozótól és küldeménytől függhetnek. Döntse el, hogyan viselkedik a felülete, ha ezek a mezők hiányoznak.

Ellenőrizze a hibák utáni helyreállítást mindkét oldalon

Szállítás esetén különös figyelmet érdemel a küldemény létrehozása közben fellépő időtúllépés: a kérés sikeres lehetett akkor is, ha az alkalmazás nem kapta meg a választ. Mielőtt vakon újrapróbálkozna, ellenőrizze a szolgáltató által támogatott duplikációmegelőzési és egyeztetési mechanizmusokat.

Nyomkövetés esetén tesztelje a duplikált értesítéseket, a késleltetett eseményeket, a sikertelen webhook-kézbesítést és az ideiglenes végpontkimaradásokat. Erősítse meg a hitelesítést, az újrapróbálkozási viselkedést és a helyreállítási lehetőségeket a vonatkozó dokumentációban. Úgy tervezze meg az eseményfeldolgozást, hogy egy frissítés újrajátszása ne küldje el ismét ugyanazt az ügyfélértesítést.

Hasonlítsa össze a teljes üzemeltetési költséget anélkül, hogy árazási modellt feltételezne

Válassza külön az API-díjakat a postaköltségektől és a fuvarozói fiók díjaitól. A szállítási és nyomkövetési szolgáltatások eltérő számlázási egységeket használhatnak, és egy kombinált platform eltérően csomagolhatja a képességeket. Kérjen árajánlatot, vagy tekintse át az alkalmazandó csomagot a pontosan végrehajtani kívánt munkafolyamathoz.

Kérdezze meg, hogyan határozzák meg a számlázható használatot, számítanak-e a sikertelen kérések, hogyan kezelik az ismételt nyomkövetési beküldéseket, és mi történik a keret túllépésekor. Vegye figyelembe a mérnöki karbantartást, a támogatási ráfordítást és két integráció összehangolásának költségét is. Meghatározott küldeményösszetétel és aktuális kereskedelmi feltételek nélkül félrevezető lenne kijelenteni, hogy az egyik kategória olcsóbb.

Tekintse át a biztonságot és az adatmegőrzést

A szállítási integrációk címzettcímeket és vámadatokat is feldolgozhatnak. A nyomkövetési integrációk szintén feldolgozhatnak küldeményazonosítókat és a hozzájuk kapcsolódó ügyféladatokat. Erősítse meg, mely mezők szükségesek, korlátozza a hitelesítő adatokat a szükséges hozzáférésre, és tartsa a titkokat a böngészőoldali kódon kívül.

Tekintse át a megőrzési, törlési és hozzáférés-vezérlési szabályokat az üzleti követelményei alapján. Egy kényelmes integráció nem igényelhet olyan ügyféladatok elküldését, amelyekre a munkafolyamatnak nincs szüksége.

Gyakorlati validációs terv az elköteleződés előtt

Gyorsindítási útmutató egyetlen sikeres példája helyett reprezentatív küldeményekkel végezzen koncepciótesztet. Az elfogadási kritériumokat egyeztesse az operációs, mérnöki és ügyfélszolgálati csapatokkal.

• Feladás: generálja a szükséges címkeformátumokat, és erősítse meg, hogy a raktári berendezések használni tudják őket.
• Rendelés-hozzárendelés: tesztelje a megosztott küldeményeket, a több csomagot és a csereküldeményeket az eredeti előzmények elvesztése nélkül.
• Nyomkövetés: ellenőrizze a tényleges eseménysorozatokat az üzlet szempontjából fontos fuvarozóknál és útvonalakon.
• Kivételek: ellenőrizze, hogy egy intézkedést igénylő kézbesítési probléma eljut-e a megfelelő csapathoz anélkül, hogy minden szokatlan szkennelést automatikusan hibának tekintene.
• Helyreállítás: szakítsa meg egy kérés vagy webhook-végpont működését, és mutassa be, hogyan egyezteti össze az alkalmazás a hiányzó információkat.
• Kommunikáció: erősítse meg, hogy minden ügyfélértesítést csak a kijelölt rendszer küld.
• Kereskedelmi illeszkedés: becsülje meg a költségeket a várható használat és a szolgáltató megerősített számlázási definíciói alapján.

A döntési szabály: először a hiányzó képességet vásárolja meg. Ha a feladás már működik, értékeljen egy nyomkövetési integrációt a teljesítési folyamat újjáépítése nélkül. Ha hiányzik a címkekészítés, először oldja meg a szállítás végrehajtását. Ha alkalmazása a teljes küldemény-életciklusért felelős, validálja mindkét képességet, és döntse el, hogy a kombinált vagy a különválasztott architektúra könnyebben üzemeltethető-e a csapata számára.

GYIK

A szállítási API mindig tartalmaz nyomkövetést?

Nem. Egyes szolgáltatások mindkét képességet tartalmazzák, míg mások külön végpontokon, termékekben vagy csomagokban biztosítják őket. Még ha a nyomkövetés szerepel is a szolgáltatásban, ellenőrizze az események részletességét, a frissítések kézbesítési módját, a fuvarozói támogatást és a használati feltételeket, mielőtt vásárlás utáni nyomkövetési megoldásként kezelné.

Nyomon követhetem azokat a csomagokat, amelyek címkéit egy teljesítési partner hozta létre?

Lehetséges, igen. Az alkalmazásának szüksége van a nyomkövetési integráció által megkövetelt azonosítókra, jellemzően a nyomkövetési számra, valamint ahol szükséges, fuvarozóazonosítóra vagy további ellenőrzési információra. Erősítse meg a partner fuvarozóinak támogatását, és gondoskodjon arról, hogy a nyomkövetési számok megbízhatóan eljussanak a rendszerébe.

Eléri-e egy nyomkövetési API, hogy a fuvarozói szkennelések hamarabb megtörténjenek?

Nem tud fizikai fuvarozói szkenneléseket létrehozni. Segíthet az alkalmazásának a nyomkövetési forrásokon keresztül elérhető információk lekérésében, rendszerezésében és terjesztésében. A frissítések működését tényleges küldeményekkel értékelje, és ne feltételezze, hogy egy API garantálja minden mozgás azonnali láthatóságát.

Két API-szolgáltatóra van szükségem mindkét képesség használatához?

Nem. Mindkét funkcióra szüksége van, nem feltétlenül két szállítóra. Használjon egy szolgáltatót, ha az megfelel a szállítási és nyomkövetési követelményeinek. Válassza külön őket, ha ez megőriz egy működő munkafolyamatot, vagy teljesít egy olyan konkrét követelményt, amelynek a kombinált lehetőség nem felel meg.

Kiválthatja-e egy nyomkövetési API a rendeléskezelő rendszert?

Nem. A nyomkövetési adatok a rendeléskezelés bemenetét jelentik, nem helyettesítik a készletallokációt, a teljesítési döntéseket, a fizetéskezelést vagy a rendelési rekordokat. Az alkalmazásának továbbra is hozzá kell rendelnie minden küldeményt a megfelelő rendeléshez, és el kell döntenie, hogyan befolyásolják a küldeményesemények az üzleti munkafolyamatokat.

Források

• FedEx Ship API dokumentáció — referencia a küldeménylétrehozáshoz, címkékhez és a szállítási munkafolyamat követelményeihez.
• FedEx nyomkövetési API dokumentáció — referencia a nyomkövetési kérésekhez és a küldeményállapotra vonatkozó információkhoz.
• 17TRACK Tracking API — hivatalos termékreferencia a nyomkövetési integráció kategóriájához.
• 17TRACK API dokumentáció — referencia a nyomkövetési regisztrációhoz, nyomkövetési adatokhoz és push-értesítési integrációhoz.