Amazon automatizacija su SP-API ir AI agentais
Su Amazon SP-API galima automatizuoti kainodarą, atsargų papildymą, PPC reklamos optimizavimą pagal ACOS, klientų palaikymą ir ataskaitas. AI agentai priima kontekstinius sprendimus, o kritinius veiksmus (kainų ribos, biudžetai) būtinai tvirtina žmogus.
Daugelis Amazon pardavėjų vis dar valdo verslą rankomis: atidaro Seller Central, tikrina kainas, spaudo mygtukus, kopijuoja skaičius į Excel. Kol turi 10 produktų – tai veikia. Kai turi 300, tai virsta pilnos darbo dienos rutina, kurioje klaidos neišvengiamos. Šitą sluoksnį darbo galima beveik visą perkelti mašinai per SP-API ir AI agentus. Šiame straipsnyje tiksliai apžvelgiame, ką realiai galima automatizuoti, o kur žmogaus parašas privalo likti.
Kas yra SP-API ir ką ji leidžia
SP-API (Selling Partner API) yra oficiali Amazon programavimo sąsaja, pakeitusi seną MWS. Tai kanalas, per kurį jūsų programa (arba AI agentas) tiesiogiai kalbasi su Amazon sistema – be pelės, be naršyklės, be rankinio įvedimo.
Per SP-API galima programiškai:
- Valdyti listingus – kurti, atnaujinti pavadinimus, aprašymus, atributus, vaizdų nuorodas.
- Skaityti ir keisti kainas (Product Pricing, Listings API).
- Stebėti atsargas ir FBA likučius realiu laiku (FBA Inventory API).
- Traukti užsakymus ir jų būsenas (Orders API).
- Generuoti ataskaitas – pardavimai, mokesčiai, grąžinimai, laikymo mokesčiai (Reports API).
- Valdyti reklamą per atskirą Amazon Ads API (PPC kampanijos, biudžetai, raktažodžiai).
Svarbu suprasti: SP-API yra oficialus ir Amazon skatinamas kelias. Automatizacija per ją nepažeidžia taisyklių – priešingai, tai būdas, kurį Amazon pati sukūrė profesionaliems pardavėjams. Rizika kyla ne iš API, o iš to, kaip ją naudojate.
Ką realiai galima automatizuoti
Ne viskas, kas įmanoma techniškai, yra verta automatizuoti. Žemiau – operacijos, kur automatizacija duoda didžiausią grąžą.
Kainodara
Klasikinis taikinys. Agentas gali stebėti konkurentų kainas, Buy Box būseną, jūsų maržą ir atsargų likutį, ir siūlyti kainos pokytį. Skirtingai nei paprastas repricer’is, AI agentas gali įvertinti kontekstą – pavyzdžiui, nekelti kainos į „lubas”, jei artėja sezono pabaiga ir reikia išparduoti atsargas.
Atsargų valdymas
Vienas skaudžiausių FBA taškų – stockout (atsargų pabaiga) arba, atvirkščiai, per didelės atsargos su brangiu ilgalaikiu laikymo mokesčiu. Agentas gali:
- Skaičiuoti pardavimo greitį (velocity) pagal Orders duomenis.
- Prognozuoti, kada baigsis atsargos.
- Suformuoti papildymo užsakymo pasiūlymą tiekėjui.
- Įspėti apie artėjančius ilgalaikio laikymo mokesčius.
Reklama ir ACOS
PPC valdymas – tai nuolatinis raktažodžių, bidų ir biudžetų koregavimas. Agentas per Amazon Ads API gali stebėti ACOS (Advertising Cost of Sales) kiekvienai kampanijai, žymėti neefektyvius raktažodžius (didelis išleidimas, nulis konversijų), siūlyti bidų mažinimą ar didinimą. Tai vietoje kelių valandų per savaitę – kelios minutės peržiūrai.
Klientų palaikymas
Standartinius klausimus (pristatymo terminai, grąžinimo tvarka, produkto specifikacijos) agentas gali apdoroti pagal jūsų žinių bazę ir paruošti atsakymo juodraštį. Sudėtingesni ar emociniai atvejai eskaluojami žmogui.
Ataskaitos ir monitoringas
Kasdieninė ataskaita – pardavimai, marža, ACOS, atsargų būklė, naujos neigiamos apžvalgos, Buy Box praradimai. Agentas gali tai surinkti per naktį ir pateikti santrauką ryte, vietoje to, kad jūs patys naršytumėte po Seller Central.
Lentelė: procesas, agentas, žmogaus patvirtinimas
| Procesas | Ką daro agentas | Ar reikia žmogaus patvirtinimo |
|---|---|---|
| Kainos koregavimas ribose | Keičia kainą tarp nustatytos min/max | Ne (jei laikosi kietų ribų) |
| Kainos strategijos keitimas | Siūlo naują kainų politiką / peržengti ribą | Taip – privaloma |
| Atsargų monitoringas | Skaičiuoja velocity, prognozuoja stockout | Ne |
| Papildymo užsakymas tiekėjui | Paruošia užsakymo pasiūlymą | Taip – privaloma |
| PPC bidų smulkus koregavimas | Mažina/didina bidus mažoje amplitudėje | Ne (su biudžeto stabdžiu) |
| PPC biudžeto didinimas | Siūlo padidinti kampanijos biudžetą | Taip – privaloma |
| Klientų DUK atsakymai | Ruošia atsakymo juodraštį | Rekomenduojama peržiūra |
| Neigiamos apžvalgos | Aptinka, žymi, eskaluoja | Taip – žmogus reaguoja |
| Kasdienė ataskaita | Surenka duomenis, pateikia santrauką | Ne |
| Listingo teksto keitimas | Siūlo SEO pagerinimą | Rekomenduojama peržiūra |
Kur žmogaus patvirtinimas yra būtinas
Automatizacija be stabdžių yra ne turtas, o bomba su laikrodžiu. Trys sritys, kur žmogaus parašas privalo likti:
- Kainų pokyčiai už ribų – klaidingas nulis ar kablelio vieta gali parduoti prekę už pusę savikainos per minutes. Kietos min/max ribos yra būtinos, o strategijos keitimas – tik su patvirtinimu.
- Biudžetai – reklamos ir pirkimų biudžetų didinimas turi būti sąmoningas sprendimas, ne agento improvizacija.
- Užsakymai tiekėjams – pinigų įsipareigojimas išorei visada eina per žmogų.
Auksinė taisyklė: agentas ruošia sprendimą, žmogus jį patvirtina. Tai vadinama human-in-the-loop modeliu. Praktiškai tai reiškia, kad kritiniai veiksmai patenka į patvirtinimo eilę (pvz. dienos santrauka su „patvirtinti / atmesti” mygtukais), o ne vykdomi tyliai.
Rizikos
- Paskyros saugumas – SP-API prieigos raktai (refresh token, LWA credentials) yra tas pats, kas raktai nuo verslo. Juos reikia laikyti šifruotus, niekada ne kode ir ne viešuose repozitoriuose. Nutekėjimas = svetimas prieina prie jūsų Amazon paskyros.
- Ribos (rate limits) – SP-API turi užklausų kvotas kiekvienam endpoint’ui. Per agresyvus scenarijus gaus throttling (429 klaidas) arba, blogesniu atveju, sukels įtarimą. Agentas turi laikytis ribų ir naudoti eiliškumą (queue) bei atsargų kartojimą (backoff).
- Klaidos masto efektas – rankinė klaida paliečia vieną listingą. Automatizuota klaida per sekundes paliečia visus 500. Todėl būtinos ribos, testavimas ir laipsniškas diegimas.
- Priklausomybė nuo Amazon pokyčių – Amazon keičia API ir politiką. Sistema turi būti prižiūrima, ne „paleista ir pamiršta”.
Realistiškas diegimo kelias
Nereikia iškart statyti visos autonomiškos sistemos. Protingas kelias yra laipsniškas:
| Etapas | Ką darai | Rizikos lygis |
|---|---|---|
| 1. Skaitymas | Agentas tik traukia duomenis ir teikia ataskaitas (read-only) | Minimalus |
| 2. Pasiūlymai | Agentas siūlo veiksmus, viską tvirtini rankomis | Žemas |
| 3. Riboti veiksmai | Agentas vykdo tik saugius veiksmus su kietomis ribomis | Vidutinis |
| 4. Platesnė autonomija | Agentas dirba savarankiškai kritinėse srityse su patvirtinimo eile | Valdomas |
Pradėkite nuo 1 etapo (read-only). Tai duoda vertę (matomumą) su nuline rizika ir leidžia pasitikrinti, ar agento logika teisinga, prieš duodant jam „rankas”.
Kuo agentai geresni už fiksuotus repricer’ius
Įprasti repricer’iai veikia pagal statines taisykles: „visada būk 0,01 EUR pigesnis nei konkurentas”. Problema – jie neturi konteksto. Jie gali įtraukti jus į kainų karą iki nuostolio arba nekelti kainos, kai tai būtų logiška.
AI agentas skiriasi tuo, kad vertina situaciją kaip visumą:
- Kokia mano marža prie šios kainos?
- Kiek liko atsargų ir kaip greitai jos juda?
- Ar apskritai verta laimėti Buy Box šitam produktui?
- Ar dabar sezono pikas, ar pabaiga?
Rezultatas – ne aklas kainos mažinimas, o sprendimas su pagrindimu, kurį žmogus gali greitai patvirtinti. Repricer’is optimizuoja vieną kintamąjį; agentas optimizuoja pelną.
Nuo ko pradėti
Amazon automatizacija per SP-API nėra ateities fantastika – tai prieinama technologija, kurios LT rinkoje beveik niekas dar nenaudoja. Būtent tai ir yra jūsų konkurencinis pranašumas. Pradėkite nuo read-only monitoringo, tada pereikite prie pasiūlymų su žmogaus patvirtinimu.
Norite gilesnio pagrindo? Peržiūrėkite Amazon automatizacijos paslaugas arba mokymus Amazon AI operatorius ir Amazon FBA. Bendrą kontekstą apie mūsų Amazon vertikalę rasite Amazon skiltyje. Turite konkretų atvejį? Susisiekite.