Studii de caz

Retailer online de suplimente: de la export la conector în 3 zile

60.000 de produse, 1,7 milioane de comenzi, platformă de ecommerce proprie (MariaDB, PHP), dezvoltată de o firmă terță. Vânzări pe site, eMAG și Trendyol.

Situația

Managementul voia răspunsuri despre marjă reală pe produs și pe canal, aprovizionare și evoluția clienților, fără să aștepte rapoarte de la furnizorul platformei. Nu aveau acces direct la baza de date, iar furnizorul nu avea capacitate de dezvoltare pentru rapoarte noi.

Ce am făcut

• Am cerut furnizorului un singur lucru: un export zilnic al bazei de date, pe FTP securizat, la o oră fixă. Fără modificări în platformă.
• Am analizat exportul local (structură, chei, date personale, tabele relevante) și am scris o specificație a tabelelor necesare: 45 din cele peste 200.
• Am construit importul automat: descărcare, verificare de integritate, pseudonimizare (clientul devine un identificator stabil; numele, adresele, telefoanele și emailurile nu intră în copia analitică), încărcare în Postgres, schimbare atomică a datelor noi cu cele vechi.
• Am scris stratul semantic: comentarii pe toate cele 45 de tabele și pe coloanele lor, 34 de reguli de business cu prioritate (cost pe bucată, discount de coș atribuit pe linie, marfă bonus, transport ca venit, ce înseamnă o comandă anulată) și 6 funcții de raport: vânzări pe perioadă și dimensiune, marjă pe produs, marjă pe factură, linii de vânzare, aprovizionare, comparații.
• Am pornit serverul MCP cu autentificare OAuth 2.1 pentru fiecare utilizator, pe un server dedicat în UE.

Rezultat

• 3 zile de la primul export la conector funcțional, testat din Claude de un utilizator care nu văzuse niciodată baza de date.
• Întrebări ca „marja netă pe canal, lunar, pe ultimul trimestru” sau „ce produse ale furnizorului X au stoc zero și ce cantitate ar trebui comandată” primesc răspuns în sub 10 secunde, cu calculul explicat.
• Import zilnic la 05:00, 46 de minute, cu verificări și alertă dacă exportul lipsește sau e trunchiat. Dacă furnizorul întârzie, conectorul răspunde din datele de ieri.

Următorul pas la acest client: conectori pentru Google Ads, GA4, Meta și Merchant Center, și un al doilea conector pentru firma de distribuție din același grup.

Unul dintre cele mai mari magazine online din România: date live și profit pe canal

Milioane de produse, vânzări pe site, B2B și marketplace, echipă proprie de dezvoltare. Proiectul de referință din care s-a născut idasc.

Situația

Un magazin cu volum mare, cu rapoarte interne bune, dar cu un blocaj clasic: fiecare întrebare nouă a managementului însemna o cerere către echipa de dezvoltare și câteva zile de așteptare. Marketingul compara cheltuiala din platforme cu conversiile raportate de aceleași platforme, nu cu comenzile reale.

Ce am făcut

• Conectare în timp real la baza de producție prin tabele externe în Postgres (46 de tabele), cu utilizator de citire, fără copii intermediare.
• Strat semantic complet: comentarii pe fiecare obiect, reguli de business cu prioritate, funcții de profit pe canal (site, B2B, marketplace) care încapsulează logica de cost și de discount a firmei.
• Un al doilea conector peste evenimentele de pe site (tracker propriu, fără cookie-uri terțe), inclusiv prețurile concurenței, monitorizate periodic.
• Conectori separați pentru Google Ads (inclusiv Keyword Planner), GA4, Search Console, Meta, Merchant Center și reclamele din ChatGPT, toți pe același tipar: acces de citire, documentație pentru model, instrucțiuni cu capcanele fiecărei platforme.

Rezultat

• Managementul întreabă direct, în română, și primește cifre cu sursă. Echipa de dezvoltare nu mai scrie rapoarte ad-hoc.
• Marketingul vede în aceeași conversație cheltuiala din Ads și comenzile reale din ERP, cu marja lor, și poate calcula atribuirea după regula firmei, nu a platformei.
• Codul serverului MCP a rămas generic: nimic specific firmei în cod, totul în baza de date. Acest lucru a permis replicarea la al doilea client în 3 zile.