EN
RO
Un magazin de piese auto originale care vinde si pe eMAG sau pe alt marketplace se lovește repede de aceeasi problema: catalogul propriu are compatibilitate exacta pe VIN, dar feed-ul trimis catre marketplace trebuie sa comunice aceeasi compatibilitate intr-un format pe care platforma il intelege si il valideaza automat. Fara aceasta traducere, riscul de respingere a ofertelor sau de comenzi pe piese incompatibile creste.
YQ Service, prin sistemul de identificare pe care il numim ACIS, furnizeaza datele tehnice de compatibilitate pentru piese originale (OE) pornind de la codul VIN al vehiculului. Aceste date exista in magazinul propriu, dar nu ajung automat in feed-ul de marketplace decat daca sunt mapate explicit pe structura ceruta de fiecare platforma.
In acest ghid explicam ce presupune sincronizarea unui feed de piese OE cu compatibilitate VIN catre eMAG si alte marketplace-uri, ce se pierde daca traducerea nu e facuta corect si cum arata un flux tehnic functional, plecand de la un proiect real implementat de HappyWeb.
De ce compatibilitatea VIN nu ajunge automat in feed-ul de marketplace
Un magazin cu integrare YQ Service stie, in interfata proprie, exact ce piese sunt compatibile cu un vehicul identificat prin VIN. Problema apare la exportul catre marketplace: eMAG si platformele similare nu accepta VIN-ul ca atribut de compatibilitate direct in feed. Ele cer atribute structurate — marca, model, generatie, motorizare, an de fabricatie, cod motor — organizate dupa taxonomia proprie a categoriei de piese auto.
Practic, exista doua sisteme de compatibilitate care trebuie sa comunice intre ele:
- Compatibilitatea pe VIN, precisa la nivel de exemplar de vehicul, folosita intern in magazin si in cautarea dupa VIN de pe site-ul propriu.
- Compatibilitatea pe atribute structurate, ceruta de marketplace, unde piesa este asociata unui set de vehicule descrise prin marca/model/generatie/motorizare, nu printr-un VIN individual.
Fara o mapare explicita intre cele doua, un magazin fie exporta compatibilitate incompleta (si pierde vizibilitate pe marketplace), fie exporta compatibilitate prea generala (si creste riscul de comenzi pe piese care nu se potrivesc de fapt cu vehiculul cumparatorului).
Ce inseamna, tehnic, un feed de piese OE cu compatibilitate VIN
Un feed catre eMAG sau alt marketplace este, in esenta, un fisier structurat (XML sau CSV, dupa cerinta platformei) generat periodic din baza de date a magazinului. Pentru piese auto cu compatibilitate VIN, feed-ul trebuie sa contina, pe langa atributele standard de produs (titlu, pret, stoc, imagine), un bloc dedicat de compatibilitate vehicul.
Fluxul de date, plecand de la YQ Service, arata astfel:
- API-ul yqservice.eu returneaza, pentru un cod de piesa OE, lista de vehicule compatibile identificate prin date de fabricatie (nu direct prin VIN-uri individuale ale clientilor).
- Magazinul traduce aceasta lista in atributele cerute de marketplace: marca, model, generatie, motorizare, perioada de fabricatie.
- Generatorul de feed asambleaza produsul cu blocul de compatibilitate completat, in formatul acceptat de platforma (de exemplu, XML pentru eMAG Marketplace).
- Feed-ul este trimis periodic (cron sau declansat de modificari), astfel incat stocul, pretul si compatibilitatea raman sincronizate cu magazinul propriu.
Cautarea dupa VIN ramane, in continuare, functia din site-ul propriu al magazinului. Pe marketplace, cumparatorul nu introduce un VIN — vede compatibilitatea deja tradusa pe atribute de vehicul, afisata de platforma in fisa produsului.
Cerinte specifice eMAG pentru categoria de piese auto
eMAG Marketplace cere, pentru categoria de piese auto, completarea atributelor de compatibilitate vehicul la nivel de ofertă, nu doar o descriere libera in titlu sau caracteristici. Cateva principii practice, valabile pentru majoritatea integrarilor de acest tip:
- Atributele de compatibilitate (marca, model, generatie, motorizare, an) trebuie completate consistent pentru fiecare produs, nu doar pentru o parte din catalog.
- O piesa compatibila cu mai multe generatii/motorizari trebuie sa listeze fiecare combinatie relevanta, nu un interval generic de ani.
- Modificarile de compatibilitate din sistemul sursa (YQ Service) trebuie reflectate la urmatoarea generare de feed, nu doar la lansarea initiala a integrarii.
- Categoria si atributele trebuie sa respecte exact taxonomia eMAG pentru piese auto, verificata in documentatia de integrare a marketplace-ului inainte de mapare.
Recomandarea practica este sa verifici direct in contul de seller eMAG (sectiunea de categorii si atribute) structura actuala ceruta, deoarece taxonomiile de marketplace se pot actualiza periodic.
Cum se face maparea intre datele YQ Service si atributele marketplace-ului
Maparea este pasul tehnic central si, de regula, cel mai consumator de timp la o integrare noua. Presupune:
| Date din YQ Service | Atribut echivalent pe marketplace |
|---|---|
| Producator vehicul | Marca (camp obligatoriu de compatibilitate) |
| Model si generatie vehicul | Model / generatie (adesea campuri separate) |
| Motorizare si cod motor | Motorizare (camp specific pentru piese de motor/transmisie) |
| Perioada de fabricatie | An de la / an pana la |
| Cod piesa OE | Cod producator / EAN, in functie de politica platformei |
Odata definita maparea, ea se automatizeaza in generatorul de feed, astfel incat orice piesa noua adaugata in magazin, cu date YQ Service asociate, sa primeasca automat atributele corecte de compatibilitate la exportul urmator.
Plan practic de implementare a sincronizarii feed-ului
Pentru un magazin care are deja YQ Service integrat pe site-ul propriu si vrea sa extinda catre eMAG sau alt marketplace, pasii practici sunt:
- Pasul 1 — audit date existente. Verifica ce procent din catalog are deja compatibilitate YQ Service completa (marca, model, motorizare, perioada).
- Pasul 2 — mapare atribute. Construieste tabelul de corespondenta intre campurile YQ Service si atributele exacte cerute de marketplace, verificate in contul de seller.
- Pasul 3 — generator de feed. Configureaza sau adapteaza modulul de generare feed astfel incat sa includa blocul de compatibilitate, nu doar atributele standard de produs.
- Pasul 4 — validare pe esantion. Testeaza feed-ul pe un set restrans de produse, verifica daca marketplace-ul accepta compatibilitatea fara erori de validare.
- Pasul 5 — sincronizare periodica. Programeaza actualizarea automata a feed-ului, astfel incat modificarile de stoc, pret si compatibilitate din YQ Service sa ajunga la timp pe marketplace.
- Pasul 6 — monitorizare post-lansare. Urmareste ratele de respingere ale ofertelor si eventualele reclamatii legate de compatibilitate, in primele saptamani dupa lansare.
Riscuri frecvente si cum se evita
- Compatibilitate incompleta trimisa in feed. Mitigare: nu exporta un produs pe marketplace pana cand blocul de compatibilitate nu este complet mapat din YQ Service.
- Date desincronizate intre site-ul propriu si marketplace. Mitigare: programeaza generarea feed-ului la un interval fix (de exemplu, la fiecare actualizare de stoc/pret), nu doar manual, ocazional.
- Mapare gresita intre motorizare si generatie de model. Mitigare: valideaza maparea pe un esantion real de vehicule cunoscute, nu doar teoretic, inainte de a exporta tot catalogul.
- Cataloage mixte OE + aftermarket cu surse de date diferite. Mitigare: pastreaza separat, in feed, sursa fiecarei compatibilitati (YQ Service pentru OE, TecDoc pentru aftermarket), pentru a evita suprapuneri sau conflicte de date.
Cand merita sa investesti in sincronizarea automata a feed-ului
Nu orice magazin are nevoie de un flux complet automatizat de la inceput. Cateva criterii practice de decizie:
| Situatie magazin | Merita sincronizare automata a feed-ului? |
|---|---|
| Catalog mare (mii de coduri OE), actualizat frecvent | Da, prioritate ridicata — actualizarea manuala nu tine pasul |
| Catalog mic, stabil, cateva zeci de coduri | Optional, un export manual periodic poate fi suficient initial |
| Vinde pe mai multe marketplace-uri simultan | Da, evita munca duplicata de mapare pentru fiecare platforma |
| Rata de respingere/reclamatii legate de compatibilitate deja ridicata | Da, prioritate ridicata — semnaleaza mapare deficitara existenta |
Studiu de caz: fluxul de date la stoauto.ro
stoauto.ro este un magazin online de piese auto originale, dezvoltat de HappyWeb, cu integrare directa a API-ului yqservice.eu. Implementarea include baza de date de vehicule (marcate activ/inactiv), scheme tehnice de piese OE cautabile, cautare dupa VIN pe site-ul propriu, import si actualizare periodica a preturilor prin CSV, precum si integrarea datelor in fluxul standard de ecommerce — inclusiv generarea de feed-uri pentru marketplace-uri.
Proiectul arata practic diferenta dintre a avea date de compatibilitate corecte in magazinul propriu si a le exporta corect, structurat, catre un canal extern precum un marketplace.
Intrebari frecvente despre feed-uri de piese OE cu compatibilitate VIN
Pot trimite direct codul VIN in feed-ul catre eMAG?
Nu. Marketplace-urile precum eMAG cer compatibilitate exprimata prin atribute structurate (marca, model, generatie, motorizare, an), nu prin VIN individual. VIN-ul ramane util pentru cautarea de pe site-ul propriu al magazinului, nu ca atribut de feed.
Ce se intampla daca trimit compatibilitate incompleta pe marketplace?
Fie oferta este respinsa la validare, fie ramane vizibila dar cu compatibilitate partiala, ceea ce creste riscul de comenzi pe piese care nu se potrivesc real cu vehiculul cumparatorului si, implicit, riscul de retur.
Feed-ul trebuie generat manual sau se poate automatiza complet?
Se poate automatiza complet, printr-un generator de feed conectat la baza de date a magazinului si la datele YQ Service, programat sa ruleze periodic. Automatizarea este recomandata pentru orice catalog de dimensiune medie sau mare.
Pot folosi acelasi feed pentru mai multe marketplace-uri?
Structura de date sursa poate fi comuna, dar formatul final de feed (XML/CSV, denumirea atributelor, taxonomia de categorii) difera intre platforme, deci este nevoie de o mapare separata pentru fiecare marketplace, chiar daca sursa datelor ramane aceeasi.
Ce se intampla cu piesele aftermarket din catalog, care nu au date YQ Service?
Acestea folosesc, de regula, o sursa de compatibilitate separata, precum TecDoc. Intr-un catalog mixt OE + aftermarket, feed-ul trebuie sa trateze cele doua surse distinct, fara sa le amestece in aceeasi mapare de atribute.
Compatibilitatea VIN corecta in magazinul propriu nu se transfera automat pe marketplace — are nevoie de o mapare explicita pe atributele cerute de fiecare platforma. Un feed bine structurat, sincronizat automat cu datele YQ Service, reduce ratele de respingere si comenzile pe piese incompatibile, fara sa afecteze acuratetea cautarii dupa VIN de pe site-ul propriu.
Vrei cautare dupa VIN si piese OE in magazinul tau auto, sincronizate corect si pe marketplace? Contacteaza-ne pentru o discutie despre integrare.
Imagine generată cu AI, folosită în scop ilustrativ.
Write a comment