--- title: Metode — Going Stellar site: https://goingstellar.ro language: ro-RO license: CC BY 4.0 count: 52 feed: https://goingstellar.ro/ro/metode/feed.xml --- # Metode — Going Stellar Cum construim aplicații și jocuri, cum conducem e-commerce pe profit, cum ținem datele cinstite și cum facem site-uri pe care asistenții AI le pot cita: rețete pas cu pas, cu capcanele și verificările de acum. Fiecare rețetă descrie cum lucrăm de fapt, inclusiv greșelile care au format-o. Fiecare are o oglindă în text curat la adresa `.md` de mai jos şi poate fi refolosită cu atribuire, sub CC BY 4.0. ## Testul de cerere: cum decidem dacă merită construită o aplicație - Publicat: 2026-10-11 - Subiect: Cercetare · Piețe - Pagină: - Markdown: Înainte să scriem o linie de cod, punem pieței o singură întrebare: vine cineva acum în nișa asta și plătește cineva? Răspundem din date publice pe care le scanăm singuri, măsurăm fluxul, nu totalurile de-o viață, citim reclamațiile integral, numărăm oameni, nu locuri, și nu estimăm nicio piață până nu putem numi mecanismul platformei de care depinde produsul. ## Trei cercetări adânci, contopite într-o singură foaie de parcurs - Publicat: 2026-10-11 - Subiect: Cercetare · Metodă - Pagină: - Markdown: La începutul fiecărui proiect, și din nou înaintea fiecărei versiuni mari, trecem aceeași întrebare prin trei motoare AI de deep research și contopim rapoartele într-o singură foaie de parcurs. Valoarea vine din dezacordurile dintre motoare și din verificarea la sursă a fiecărei afirmații importante; rapoartele în sine sunt ciorne, nu constatări. ## Cum construim o aplicație Shopify - Publicat: 2026-10-11 - Subiect: Aplicații · Shopify - Pagină: - Markdown: Construim fiecare aplicație Shopify pe același șasiu comun, ținem logica ce o face diferită într-un modul pur pe care îl testăm gratuit și considerăm plata nedovedită până când un clic real ajunge pe pagina de aprobare a Shopify. Metoda e mai ales o listă de verificări adăugate după ce ceva s-a stricat. ## Cum construim un add-on Google Workspace - Publicat: 2026-10-11 - Subiect: Aplicații · Google Workspace - Pagină: - Markdown: Construim fiecare add-on pe Apps Script și CardService, cu cel mai îngust scope care face treaba, apoi îl trecem prin consimțământ, verificare și recenzie. Aprobarea dovedește puțin: ce le-a ținut în funcțiune a fost testarea pe un cont curat, testarea a ceea ce scriu și numărarea oamenilor, nu a locurilor de domeniu. ## Cum construim și livrăm aplicații Atlassian Forge - Publicat: 2026-10-11 - Subiect: Aplicații · Atlassian Forge - Pagină: - Markdown: Am construit 25 de aplicații pentru Jira și Confluence pe câteva șasiuri comune și le-am trimis la review deodată. Patru sunt publice; celelalte 21 au fost respinse și stau blocate într-o stare de listare pe care doar Atlassian o poate curăța, fiindcă am sărit pasul care ne-ar fi arătat zidul: să ducem întâi o singură aplicație până la aprobare. ## Cum construim o aplicație monday.com - Publicat: 2026-10-11 - Subiect: Aplicații · monday.com - Pagină: - Markdown: Am construit o singură aplicație pentru monday.com, o vizualizare de board care scrie un scurt rezumat AI al board-ului, și am trimis-o la review în august 2026. În septembrie a fost respinsă pentru că se suprapune cu aplicații care există deja. Metoda de construcție a ținut; pasul sărit a fost să întrebăm monday, înainte de a scrie cod, dacă ideea trece de politica lor de duplicare. ## Cum construim o aplicație de iPhone - Publicat: 2026-10-11 - Subiect: Aplicații · iOS - Pagină: - Markdown: Testăm cererea cu propriul scanner de App Store înainte să scriem cod, ținem motorul într-un pachet care se poate verifica fără Xcode și tratăm o instalare curată pe simulator drept primul recenzent. Exemplul nostru, Null Field, e construit și gata de trimis, dar nu a fost trimis. ## Cum construim o aplicație Android pentru Google Play - Publicat: 2026-10-11 - Subiect: Aplicații · Android - Pagină: - Markdown: Citim regulile Google Play și măsurăm cererea înainte de cod, construim o aplicație nativă în Kotlin și Compose, apoi ne uităm la ea rulând: cele mai grave defecte s-au văzut doar pe ecran. Prima noastră aplicație e construită, dar nepublicată, iar propria noastră cercetare spune că distribuția organică pe Play nu o va duce departe. ## Filmarea demonstrațiilor care trec de recenzia din marketplace - Publicat: 2026-10-11 - Subiect: Aplicații · Recenzie - Pagină: - Markdown: Filmăm pagina, nu ecranul, într-un browser dedicat, cu pașii adresați prin selectori și subtitrarea arsă în imagine. Fiecare moment din film arată un lucru la care e folosită permisiunea cerută, ca recenzentul să vadă aplicația făcând ce promite listarea. Cele mai multe reprize ratate au venit din interfața gazdă și din starea rămasă de la reprizele anterioare, nu din aplicație. ## Cum răspunzi la chestionarele de confidențialitate, GDPR și securitate pentru aplicațiile din marketplace-uri - Publicat: 2026-10-11 - Subiect: Aplicații · Conformitate - Pagină: - Markdown: Fiecare marketplace de aplicații întreabă ce date atinge aplicația, unde ajung, cine le mai prelucrează și ce le protejează. Răspundem la toate formularele dintr-o singură hartă de date per aplicație, susținem fiecare „Da” cu o pagină publică sau cu un contract și tratăm un „Nu” care blochează aprobarea ca pe un motiv să construim, nu să reformulăm. ## Cum facem un joc în Godot - Publicat: 2026-10-11 - Subiect: Jocuri · Godot - Pagină: - Markdown: Construim SOLOMONAR, un joc folk-horror la persoana întâi, într-un sat din Maramureș, pe parcursul a șapte zile. Agenții scriu cea mai mare parte, iar un om decide. Metoda se sprijină pe trei decizii luate din prima zi, pe o lume care se poate verifica fără ecran și pe o singură regulă: nicio verificare automată nu primește încredere până nu am văzut-o picând pe o lume stricată intenționat. ## Asseturi de joc cu buget mic: personaje CC0, retargetarea animațiilor și voci românești locale - Publicat: 2026-10-11 - Subiect: Jocuri · Asseturi - Pagină: - Markdown: Pentru SOLOMONAR luăm oameni, animații, voci și muzică din surse gratuite, iar vocile le generăm pe mașinile noastre. Metoda: citim fiecare licență în fișier, sub titlul sub care stă, și verificăm tot lanțul din care vine un asset. Citirea asta ne-a întors o decizie: vocea românească pe care o declaraserăm curată nu era. ## Publicăm fără cifre inventate: cum scriem aceste articole - Publicat: 2026-10-11 - Subiect: Proces · Scriere - Pagină: - Markdown: Articolele de pe acest site sunt scrise de agenți AI, verificate de alți agenți și apoi de un script în care nu există niciun model. Metoda pornește de la o constatare din prima rundă: modelele de limbaj inventează cantități scrise în litere la fel de ușor ca în cifre, deci o verificare care citește doar cifre lasă să treacă mare parte din ce ar trebui să oprească. ## Cum lucrăm cu o flotă de agenți AI de programare fără să pierdem muncă - Publicat: 2026-10-11 - Subiect: Proces · Agenți AI - Pagină: - Markdown: Rulăm mulți agenți AI de programare deodată, adesea pe aceleași fișiere și aceleași sisteme. Aproape nimic din ce am pierdut nu a venit din cod prost. A venit din coordonare: agenți care împart un spațiu de lucru, două fluxuri care scriu același fișier live, un deploy care a publicat munca neterminată a altcuiva și fluxuri care au murit împreună și au fost reluate orbește. Acestea sunt regulile după care lucrăm acum. ## Poarta de onestitate: nicio funcție promisă fără dovadă în cod - Publicat: 2026-10-11 - Subiect: Proces · Afirmații despre produs - Pagină: - Markdown: Înainte de orice trimitere la review comparăm fiecare afirmație de pe pagina de planuri, din listare sau din paginile publice cu codul care ar trebui s-o susțină. O afirmație rămâne doar dacă un comerciant poate ajunge la o implementare care funcționează; altfel construim funcția sau ștergem afirmația. Un script prinde cazurile mecanice, restul îl citim de mână. ## Cum faci un site pe care asistenții AI îl pot citi și cita - Publicat: 2026-10-11 - Subiect: AI · Site-uri citibile de mașini - Pagină: - Markdown: Publici fiecare pagină de două ori, în HTML pentru oameni și în Markdown pentru mașini, și le generezi pe amândouă din aceeași sursă, ca să nu se poată contrazice. Adaugi un index llms.txt, un flux Atom, date structurate de articol care trimit la Markdown și un robots.txt care numește crawlerele AI. Apoi verifici fiecare fișier după ce trimite serverul de fapt, nu după faptul că răspunde. ## Cum faci un magazin Shopify citibil de asistenții AI (GEO pentru e-commerce) - Publicat: 2026-10-11 - Subiect: AI · GEO pentru Shopify - Pagină: - Markdown: Optimizarea pentru motoarele generative (GEO) a unui magazin Shopify e SEO obișnuit, țintit pe răspunsurile AI: lași crawlerele AI să intre, scrii pagini care răspund la întrebări în pasaje ce se pot cita, adaugi date structurate adevărate, îi dai asistentului Shopify întrebări frecvente reale și măsori vizitele venite de la asistenți. Asta e metoda pe care am pus-o în aplicația noastră Shopify, Cite Me, cu greșelile care au format-o. ## Cum transformăm munca repetată în skill-uri pentru agenți AI - Publicat: 2026-10-11 - Subiect: AI · Skill-uri pentru agenți - Pagină: - Markdown: Un skill de agent este un folder cu un fișier SKILL.md care îi spune unui agent AI de programare când și cum să facă o anumită sarcină recurentă, plus scriptul de care are nevoie sarcina. Extindem un skill existent înainte să creăm unul nou, orice scriere rulează implicit în gol, iar regulile care trebuie respectate stau în afara promptului: în hook-uri, în roluri de bază de date doar-citire și într-o bază de cunoștințe comună. ## Cum calculezi CPA-ul de prag pentru un magazin cu plata la livrare - Publicat: 2026-10-11 - Subiect: E-commerce · Economia comenzii - Pagină: - Markdown: CPA-ul de prag e cel mai mult pe care un magazin îl poate plăti în reclame pentru o comandă plasată, înainte ca acea comandă să piardă bani. La un magazin cu ramburs, pragul înseamnă venit fără TVA, minus marfă și transport, numărat doar pe comenzile livrate, minus transportul deja plătit pe fiecare colet refuzat. Scalăm doar sub 70% din acest prag. ## Cum judeci campaniile de reclame pe profit, nu pe CPA-ul țintă - Publicat: 2026-10-11 - Subiect: E-commerce · Publicitate plătită - Pagină: - Markdown: Ca să decizi dacă scalezi, menții sau tai o campanie, compari costul ei pe comandă cu CPA-ul de prag al magazinului, nu cu un CPA țintă ales de cineva. ROAS-ul raportat de platformă e umflat, așa că CPA-ul e poarta mai sigură; campaniile pe numele brandului și reclamele pe produse epuizate cer teste separate, pentru că arată altfel în raport decât în contul bancar. ## Cum prinzi erorile tăcute de date: watchdog de prospețime, semnale de viață și reconciliere - Publicat: 2026-10-11 - Subiect: Inginerie · Monitorizare - Pagină: - Markdown: O eroare tăcută de date este un pipeline care raportează succes deși datele lui sunt vechi sau greșite. Le prindem cu trei verificări programate: un watchdog care citește cel mai nou rând în loc de statusul jobului, semnale de viață trimise doar la succes și o reconciliere zilnică a aceleiași cifre din două surse independente. Chiar verificările au greșit de câteva ori, iar greșelile acelea fac parte din metodă. ## Deploy sigur: dry-run implicit, verificare de paritate și controlul a ce s-a publicat de fapt - Publicat: 2026-10-11 - Subiect: Inginerie · Deploy - Pagină: - Markdown: O comandă de deploy reușită dovedește că a avut loc un transfer, nu ce s-a transferat. Facem deploy-urile sigure cu trei obiceiuri: orice script de deploy rulează în dry-run dacă nu primește --apply, o verificare zilnică de paritate compară fișierele de pe server cu git, iar după publicare comparăm sursa servită și corpul răspunsurilor cu ce voiam să livrăm. ## Testarea unui site la lățime de telefon: de ce mint capturile headless - Publicat: 2026-10-11 - Subiect: Inginerie · Testare web - Pagină: - Markdown: Chrome headless nu așază o pagină mai îngust de circa 500 de pixeli CSS, deci o captură de 390 de pixeli e un decupaj dintr-o pagină mai lată, nu un telefon. Testăm lățimile de telefon prin emulare de dispozitiv peste Chrome DevTools Protocol și apoi măsurăm pagina în loc să ne uităm la ea. Șase capcane de pe propriul nostru site s-au văzut doar așa. ## Cum expiră și cum se reînnoiesc tokenurile Shopify Admin API: tokenuri permanente, tokenuri care expiră și capcanele reînnoirii - Publicat: 2026-10-11 - Subiect: Inginerie · Shopify API - Pagină: - Markdown: Tokenurile Shopify Admin API sunt de mai multe feluri și nu se tratează la fel: un token permanent de aplicație custom nu trebuie să treacă niciodată prin logica de reînnoire, iar unul care expiră se reînnoiește cu un refresh token de unică folosință, pe care îl salvezi de fiecare dată. Cele mai multe pane de token pe care le-am avut nu au venit din tokenuri expirate, ci din reînnoire aplicată tokenului greșit sau din două reînnoiri care s-au călcat pe picioare. ## Cum faci deploy la cod Google Apps Script prin API, în loc de copy-paste - Publicat: 2026-10-11 - Subiect: Inginerie · Apps Script - Pagină: - Markdown: Codul Google Apps Script se poate citi și scrie prin Apps Script API, deci un script nu mai trebuie lipit de mână în editor. Unealta noastră rulează implicit în modul de probă, face backup proiectului înainte de fiecare scriere, retrimite toate fișierele fiindcă API-ul înlocuiește proiectul întreg și verifică rezultatul de două ori: recitind codul și verificând ce a scris scriptul. ## Cache-uri și backfill-uri sigure: nu ștergi istoricul înainte să sosească datele noi - Publicat: 2026-10-11 - Subiect: Inginerie · Fluxuri de date - Pagină: - Markdown: Un cache sigur la eșec este unul în care o reîmprospătare picată lasă datele vechi neatinse: scrii cu upsert pur, niciodată ștergere urmată de reinserare, și reîncerci exact excepția de timeout pe care o aruncă biblioteca. Backfill-ul umple goluri cu IS NULL în loc să rescrie decizii, instantaneele se verifică singure la citire, iar o valoare de azi nu răspunde niciodată la o întrebare despre trecut. ## Capcane SQLite și de baze de date în aplicații mici de producție - Publicat: 2026-10-11 - Subiect: Inginerie · Baze de date - Pagină: - Markdown: Capcanele de baze de date care lovesc aplicațiile mici nu țin de scară: o citire lungă pe SQLite blochează toate scrierile, un filtru pe o coloană criptată nu găsește nimic fără să dea eroare, DISTINCT crapă pe un tabel cu coloană json, commit() și rollback() expiră obiectele ORM chiar și în handlerul de eroare, iar un epsilon fix e prea mic pentru o coloană float32. Toate trec un test rapid și cedează în producție, de obicei fără o eroare clară. ## Cum verifici imaginile de produs înainte de publicare: capcanele din packshot-urile și infograficele automate - Publicat: 2026-10-11 - Subiect: E-commerce · Imagini de produs - Pagină: - Markdown: Toate defectele serioase de imagine pe care le-am găsit au trecut de verificările automate: un packshot curat căruia îi lipsea jumătate din produs, un infografic cu cote corecte desenate peste alt produs, un fișier clar care devenea neclar după decupare. Metoda este să deschizi fiecare imagine și s-o compari cu o referință independentă pentru produsul fizic, nu cu alte poze din același pachet al furnizorului. ## Cum analizezi termenii de căutare din Google Ads și cuvintele cheie negative fără să tai conversii - Publicat: 2026-10-11 - Subiect: E-commerce · Google Ads - Pagină: - Markdown: Termenii de căutare din Google Ads se analizează grupând căutările reale în cuvinte și expresii scurte (n-grame); cuvinte cheie negative pui doar pe tiparele care chiar nu au legătură cu ce vinde magazinul, iar negativele existente le verifici periodic, ca să le găsești pe cele care blochează cumpărători. Zero conversii pe un singur termen nu dovedește risipă: pe Shopping și Performance Max, cele mai multe vânzări vin dintr-o coadă lungă de căutări care convertesc fiecare rar. ## Cum eviți suspendarea pentru misrepresentation în Google Merchant Center și cum ții feedul sănătos - Publicat: 2026-10-11 - Subiect: E-commerce · Merchant Center - Pagină: - Markdown: Suspendarea pentru misrepresentation (prezentare înșelătoare) în Merchant Center vine de obicei din semnalele de încredere, nu din checkout: identitatea firmei ascunsă sau contradictorie, pagini de politici lipsă, informații de business necompletate și afirmații neadevărate pe site, ca numărătorile inverse care o iau de la capăt la fiecare vizitator sau numărul inventat de produse vândute. Repari toate semnalele înainte să ceri revizuirea, pentru că cererile sunt limitate, și verifici sănătatea feedului săptămânal, ca problemele pe produse să nu se adune. ## Cum depistezi oboseala creativelor în reclamele Meta și TikTok - Publicat: 2026-10-11 - Subiect: E-commerce · Reclame sociale - Pagină: - Markdown: Oboseala creativelor se vede ca tipar, nu ca o singură metrică proastă: frecvența urcă în timp ce rata de click scade sau costul pe achiziție crește. Comparăm ultimele 7 zile ale fiecărui cont de reclame cu cele 21 de zile dinainte, marcăm contul doar când frecvența a crescut cu peste 15% și CTR-ul a scăzut cu peste 10% sau CPA-ul a crescut cu peste 20%, abia apoi coborâm la nivel de reclamă. Cele mai multe alarme false au venit din date, nu din public. ## Cum auditezi fluxurile automate de email și SMS înainte să scrii campanii noi - Publicat: 2026-10-11 - Subiect: E-commerce · Email și SMS - Pagină: - Markdown: Înainte de încă o campanie de email, verifică ce fluxuri automate rulează deja magazinul față de o listă standard de 10, dacă fiecare e activ sau doar ciornă și cât își atribuie platforma de email peste ce arată analiza de trafic. Apoi verifică două lucruri pe care niciun audit de fluxuri nu le vede: că retragerea consimțământului ajunge imediat la platforma care trimite și că segmentele pornesc de la clienți care chiar și-au primit comenzile. ## Cum prinzi comenzile duble înainte să se printeze eticheta de expediere - Publicat: 2026-10-11 - Subiect: E-commerce · Comenzi duble - Pagină: - Markdown: O comandă dublă înseamnă același client care plasează aceeași comandă de două ori, de obicei la câteva minute distanță. Prindem comenzile duble rulând decizia chiar în pasul care creează eticheta, potrivind după numărul de telefon normalizat, și anulăm automat doar perechile strict identice; restul ajunge la un om. Primul nostru detector decidea corect, dar prea târziu, iar aproape tot ce știm am învățat din cazurile în care a greșit. ## Colete fantomă: etichete create, dar nescanate niciodată de curier, și cum le găsești - Publicat: 2026-10-11 - Subiect: E-commerce · Livrare - Pagină: - Markdown: Un colet fantomă este un colet a cărui etichetă de expediere există, dar pe care curierul nu l-a scanat niciodată la ridicare, deși clientul a aflat deja că i s-a expediat comanda. Găsim coletele fantomă întrebând curierul, nu evidențele noastre, care e ultimul eveniment al fiecărei etichete mai vechi de câteva zile, tratând lipsa răspunsului ca pe o citire eșuată, nu ca pe un status, și trimițând fiecare caz la un om, în loc să refacem etichetele automat. ## Cum folosești AI ca să scrie ciorne de răspuns la tichetele de customer service, fără să le trimită - Publicat: 2026-10-11 - Subiect: E-commerce · Customer service - Pagină: - Markdown: Lăsăm un model de limbaj să scrie ciorne de răspuns pornind de la macro-urile aprobate ale echipei și de la procedurile învățate din răspunsurile reale ale agenților, cu datele reale ale comenzii clientului. Un om citește și trimite fiecare răspuns; modelul nu trimite nimic. Gărzile din jurul ciornei contează mai mult decât promptul, iar cele mai multe lecții au venit din gărzi care nu funcționau și nimeni nu observa. ## Cum prinzi rambursările promise, dar neefectuate: un paznic de rambursări pentru customer service - Publicat: 2026-10-11 - Subiect: E-commerce · Customer service - Pagină: - Markdown: Paznicul de rambursări este un raport doar de citire care găsește clienții cărora magazinul le datorează bani și nu i-a returnat: comenzi plătite cu cardul și anulate fără rambursare, și retururi acceptate, trimise la plată, dar neplătite. Aplică două reguli simple pe evidența comenzilor și a retururilor și pune cazurile cele mai vechi primele. Cel mai grav eșec al nostru a fost un buton de rambursare care nu funcționase niciodată, în timp ce fiecare tichet apărea rambursat. ## Cum calculezi cantitatea de comandat și data epuizării per SKU din instantaneele zilnice de stoc - Publicat: 2026-10-11 - Subiect: E-commerce · Planificarea stocului - Pagină: - Markdown: Cantitatea de comandat per SKU este viteza zilnică de vânzare înmulțită cu zilele până la următoarea livrare plus o rezervă, minus ce e în stoc și ce e deja pe drum. Viteza se poate citi din instantaneele zilnice de stoc, dar numai după ce corectezi reaprovizionările, rupturile de stoc și rândurile de stoc dublate, iar marfa „pe drum” trebuie luată din ce s-a încărcat efectiv, nu din ce s-a comandat. ## Cum construiești o aplicație de scanare coduri de bare pentru depozit, pe scanere Android - Publicat: 2026-10-11 - Subiect: Inginerie · Scanare în depozit - Pagină: - Markdown: O aplicație de scanare pentru depozit transformă codul citit de un terminal Android industrial într-un răspuns pe care culegătorul îl înțelege dintr-o privire. Luăm scanarea de la scanerul hardware ca broadcast, trecem toate ecranele prin același handler de scanare, scriem stările ca etichete scurte, cu culoarea pentru gravitate, și măsurăm fiecare culoare de text pe fiecare fundal, în tema de zi și în cea de noapte. Majoritatea bug-urilor noastre au fost reparații care existau pe un ecran și lipseau de pe celelalte. ## Cum printezi etichete de expediere din mai multe stații de depozit fără să pierzi sau să dublezi etichete - Publicat: 2026-10-11 - Subiect: E-commerce · Printare etichete - Pagină: - Markdown: Când mai multe stații de depozit printează etichete de expediere din aceleași comenzi, varianta sigură e o singură coadă de print, în care descărcarea unei etichete e chiar gestul care o scoate din coada tuturor stațiilor. Trimitem fiecare etichetă la o singură stație printr-o regulă comună, filtrăm înainte de descărcare, marcăm printat tot ce exportăm pe orice altă cale și trimitem un lot ca un singur document complet. Fiecare etichetă pierdută sau printată de două ori a venit dintr-o descărcare făcută în locul greșit sau la momentul greșit. ## Normalizarea adreselor de livrare în mai multe țări: coduri poștale, chirilică, limite de lungime - Publicat: 2026-10-11 - Subiect: E-commerce · Adrese - Pagină: - Markdown: Normalizarea adresei transformă ce a scris clientul în forma pe care o acceptă curierul și o confirmă un nomenclator național. O facem pe fiecare țară în parte: aflăm întâi dacă acolo codul poștal descrie o stradă sau o localitate întreagă, validăm pe un nomenclator ale cărui defecte le știm, normalizăm nomenclatorul și căutarea cu aceeași funcție și îi trimitem curierului scrierea și identificatorii lui. Cele mai multe eșecuri au venit din instalația din jurul adresei, nu din adresă. ## Cum gestionezi cererile GDPR de ștergere în magazin, helpdesk și platforma de email - Publicat: 2026-10-11 - Subiect: E-commerce · Confidențialitate - Pagină: - Markdown: O cerere GDPR de ștergere înseamnă că un client îi cere magazinului online să-i șteargă datele personale. Oprim marketingul către acea persoană în aceeași oră, cartografiem fiecare sistem care ține o copie, ștergem doar după chei exacte și instalăm un registru de ștergeri înainte să ștergem ceva, fiindcă sincronizările de noapte refac ce ai șters. Unele înregistrări, ca facturile, se păstrează prin lege, așa că răspunsul nu spune niciodată „am șters tot”. E metoda noastră de lucru, nu consultanță juridică. ## Cum scrii articole SEO pentru blogul unui magazin online fără fapte inventate - Publicat: 2026-10-11 - Subiect: E-commerce · Bloguri de magazin - Pagină: - Markdown: Un articol SEO pe blogul unui magazin are voie să pomenească doar produse care există și sunt pe stoc și doar afirmații pe care magazinul le poate dovedi. Îi dăm celui care scrie un catalog exportat din magazin, punem un al doilea agent să încerce să infirme fiecare ciornă și lăsăm un script fără model să blocheze publicarea la linkuri de produs false, cuvinte interzise și caractere AI invizibile. ## Cum calculezi profitul pe produs într-un magazin cu plata la livrare - Publicat: 2026-10-11 - Subiect: E-commerce · Economia comenzii - Pagină: - Markdown: Profitul pe produs este contribuția pe care o lasă fiecare SKU după costurile lui: venitul fără TVA, minus costul mărfii, transportul și marketingul, numărat doar pe comenzile livrate. Cadourile gratuite își poartă costul real, transportul vine din costul real al fiecărei comenzi, cu o cascadă de rezervă, iar marketingul se împarte pe comenzi. Partea grea nu e formula, ci să iei fiecare intrare din sursa potrivită. ## Cum împarți costul reclamelor pe produse când reclamele nu se potrivesc unu la unu - Publicat: 2026-10-11 - Subiect: E-commerce · Atribuire marketing - Pagină: - Markdown: Ca să împarți costul reclamelor pe produse, citești costul la nivel de reclamă, legi fiecare reclamă de un produs printr-o scară fixă de reguli (cod SKU exact, apoi cuvânt-cheie, apoi cont), împarți conturile partajate după un jeton din numele campaniei și distribui restul pe produse după numărul de comenzi. Fiecare regulă cedează pe tăcute într-un fel anume, așa că metoda înseamnă mai ales să prinzi acele cedări. ## Cum compari profitabilitatea magazinelor din mai multe țări UE: cote de TVA, monede și curs valutar - Publicat: 2026-10-11 - Subiect: E-commerce · Vânzări transfrontaliere - Pagină: - Markdown: Ca să compari magazine care vând în țări diferite din UE, scoți din venit TVA-ul țării de destinație, convertești fiecare comandă din moneda ei la un curs datat, iei costurile fără TVA-ul de pe propriile facturi și abia apoi compari contribuția pe comandă livrată. Cele mai multe greșeli între țări le-am făcut cu un divizor de TVA greșit, cu un curs vechi sau cu un cost citit în altă monedă. ## Face bani promoția 2+1 gratis? O metodă pe comandă - Publicat: 2026-10-11 - Subiect: E-commerce · Promoții - Pagină: - Markdown: Promoția 2+1 gratis (cumperi două, primești trei) face bani când o comandă de trei bucăți lasă contribuție pozitivă după costul tuturor celor trei bucăți, al unui colet și costul de reclamă al unei comenzi. O măsori pe comandă, împărțit după numărul de bucăți, doar pe comenzile livrate, cu bucata gratuită socotită la cost întreg. ## Segmente de clienți, RFM și valoarea pe viață la magazinele cu ramburs: de ce folosești doar comenzile livrate - Publicat: 2026-10-11 - Subiect: E-commerce · Analiza clienților - Pagină: - Markdown: Segmentarea RFM, retenția pe cohorte și valoarea pe viață a clientului au sens la un magazin cu plata la livrare doar dacă le calculezi pe comenzile livrate, pentru că un colet refuzat la ușă nu aduce bani. Punctăm fiecare client după recență, frecvență și valoare doar din comenzile livrate, separat pe magazin și pe monedă, și găsim același client în toate sistemele după ultimele nouă cifre ale telefonului. Partea grea n-au fost formulele, ci să ne asigurăm că o căutare și datele folosesc aceeași normalizare. ## Cum construiești „cumpărate frecvent împreună” din propriile comenzi - Publicat: 2026-10-11 - Subiect: E-commerce · Vânzare încrucișată - Pagină: - Markdown: Un bloc „cumpărate frecvent împreună” se calculează din propriile comenzi prin analiza coșului de cumpărături: numeri de câte ori apar două produse în aceeași comandă și ordonezi perechile după lift, care arată de câte ori mai des se vând împreună decât ar fi la întâmplare. Calculăm perechile pe fiecare magazin pe ultimele 180 de zile, dintr-o sursă care conține aproape toate comenzile, cu praguri minime care nu lasă produsele rare să dea lifturi absurde. Metoda găsește perechi reale; transformarea lor în pachete a fost mai grea decât matematica. ## Cum pui videoclipuri de produs și UGC în Performance Max: de la clip la asset group - Publicat: 2026-10-11 - Subiect: E-commerce · Video Performance Max - Pagină: - Markdown: Performance Max nu primește fișiere video: fiecare asset video e un videoclip YouTube referit prin ID, deci drumul e clip, MP4 verificat, încărcare pe canalul YouTube al brandului, apoi legare la asset group. Păstrăm clipuri de cel puțin 11 secunde, livrăm variante 16:9, 1:1 și 9:16, atașăm câteva, nu zeci, și verificăm fiecare pas citind rezultatul înapoi. Cele mai multe probleme au venit din pași care au raportat succes fără să fi făcut treaba. ## Programarea postărilor pe rețele sociale prin API: de ce „programat” nu înseamnă „publicat” - Publicat: 2026-10-11 - Subiect: E-commerce · Rețele sociale - Pagină: - Markdown: Un API de programare care răspunde HTTP 200 a acceptat postarea, nu a publicat-o; publicarea vine mai târziu și poate pica separat pe fiecare rețea. În perioada măsurată, posterul nostru a raportat succes la fiecare rulare, în timp ce toate cele 17 postări pe Facebook și 12 pe Instagram au picat. Acum citim starea finală pe fiecare rețea după ora publicării, punem expirare pe orice listă de conturi conectate ținută în cache și verificăm descrierile generate în cod, pe textul care chiar pleacă. ## Cum faci auditul de conversie al unei pagini de produs, pas cu pas - Publicat: 2026-10-11 - Subiect: E-commerce · Audit de conversie - Pagină: - Markdown: Auditul de conversie al unei pagini de produs verifică, într-o ordine fixă, dacă un vizitator de pe telefon vede oferta, prețul, butonul de cumpărare și motivele să aibă încredere în magazin, și dacă pagina se încarcă destul de repede ca să fie văzută. Rezultatul este o listă de ipoteze ordonate după impactul probabil, nu o creștere dovedită: doar un test A/B arată dacă o modificare a crescut conversia. ## Cum monitorizezi prețurile concurenței pentru produse de larg consum - Publicat: 2026-10-11 - Subiect: E-commerce · Prețuri - Pagină: - Markdown: Ca să monitorizezi prețurile concurenței, ții o listă care leagă fiecare produs al tău de același produs de pe site-urile concurente, citești prețul din datele structurate ale paginii în fiecare noapte, păstrezi fiecare citire într-un istoric în care doar adaugi rânduri și compari cu prețul tău doar prețurile proaspete și plauzibile. Potrivirea produsului corect și menținerea fluxului în viață sunt mai grele decât citirea prețului. O schimbare de preț pornită de la comparație este o decizie de testat, nu un câștig dovedit.