ChatGPT Ads nu este un produs care se activează identic pentru toate companiile, în aceeași zi și cu aceleași funcții. În septembrie 2026 există o bază tehnică deja documentată, instrumente care depind de tipul contului, opțiuni distribuite gradual și capabilități anunțate pentru o etapă ulterioară. Diferența dintre aceste stări este importantă: o funcție prezentată într-un email sau într-un changelog nu este automat disponibilă în fiecare cont și nu trebuie inclusă într-un plan de campanie înainte de verificare.
Acest articol este o fotografie operațională realizată la 16 septembrie 2026. Nu reia explicația generală din ghidul ChatGPT Ads pentru România, ci răspunde unei întrebări mai concrete: pe ce poate conta astăzi o companie și ce trebuie tratat încă drept acces condiționat, distribuire sau promisiune de produs?
Regula utilă: o funcție este cu adevărat disponibilă pentru o campanie numai când apare în contul potrivit, poate fi configurată, trece verificările și produce date în raportare. Documentația publică dovedește existența produsului, nu eligibilitatea fiecărui advertiser.
De ce disponibilitatea nu poate fi redusă la „da” sau „nu”
Într-o platformă publicitară nouă există mai multe niveluri de acces. Compania poate avea un cont Ads, dar să nu aibă încă acces la feeduri de produse. Poate vedea un obiectiv de conversie, dar să nu aibă un Pixel valid sau suficiente evenimente. Poate conecta un instrument de lucru, dar campania să rămână blocată de verificarea brandului, a reclamei, a metodei de plată ori de inventarul disponibil în țara selectată.
De aceea am folosit patru stări, nu o singură etichetă „lansat”. Ele pot fi aplicate separat fiecărei funcții:
| Stare | Ce înseamnă în practică | Cum trebuie tratată |
|---|---|---|
| Activă și documentată | Există în documentația curentă și poate fi folosită de conturile eligibile în configurația descrisă | Poate intra în plan, după verificarea contului și a politicilor |
| Activă, dar condiționată | Funcția există, însă depinde de acces acordat contului, facturare, tipul campaniei, dimensiunea audienței sau alte condiții | Se planifică numai după confirmarea directă în cont |
| În distribuire | OpenAI o extinde gradual, iar două conturi pot avea interfețe diferite în aceeași perioadă | Se pregătește procesul, fără a promite data activării |
| Anunțată | Direcția a fost comunicată, dar documentația operațională ori accesul general nu sunt încă suficiente | Nu se includ rezultate estimate sau dependențe critice în planul curent |
Mai există o categorie pe care merită să o numim direct: afirmații neconfirmate. Capturile din alte conturi, mesajele din comunități și formulările comerciale pot sugera o funcție care nu apare în documentație sau în propriul cont. În această situație, răspunsul corect este „nu putem planifica încă”, nu „probabil va funcționa”.
Nucleul care este activ și documentat
Documentația Advertiser API descrie deja structura de bază necesară unei campanii: cont publicitar, cheie API, campanie, grup de reclame, reclamă, targetare, buget și raportare. Sunt documentate obiective pentru afișări, clicuri și conversii, precum și operații de creare, citire și actualizare. Acest lucru arată că ChatGPT Ads a depășit etapa unei simple demonstrații, dar nu elimină verificările de eligibilitate și de livrare.
Administrarea campaniilor și stările de verificare
Campaniile, grupurile și reclamele au fiecare propriul status. O campanie poate fi setată ca activă în timp ce o reclamă copil este încă în verificare sau a fost respinsă. Programul de difuzare, bugetul, limita contului și targetarea pot opri livrarea chiar dacă obiectul principal apare „active”. Prin urmare, activarea nu trebuie confundată cu publicarea efectivă și nici cu apariția imediată a impresiilor.
Fluxul corect presupune verificarea ierarhiei complete: cont, campanie, grup, reclamă și elementele folosite de aceasta. Pentru feeduri se adaugă starea sursei și a produselor; pentru optimizarea conversiilor se adaugă evenimentul selectat și sănătatea fluxului de măsurare. Acesta este motivul pentru care un test de livrare controlat este mai valoros decât o captură care arată doar un buton „Active”.
Măsurarea prin Pixel și Conversions API
OpenAI documentează Measurement Pixel pentru evenimente din browser și Conversions API pentru evenimente transmise din server. Cele două pot fi folosite împreună, cu deduplicare printr-un identificator comun. Sunt acceptate evenimente standard, iar sistemul poate primi date despre valoare, monedă și identificatori eligibili pentru potrivire, cu respectarea cerințelor de consimțământ și protecție a datelor.
Raportarea include conversii atribuite clicurilor și, pentru situațiile eligibile, conversii atribuite vizualizării. La data verificării, conversiile view-through folosesc o fereastră de o zi, iar clicul eligibil are prioritate. Important: aceste conversii sunt încă raportate ca informație suplimentară. Metricile precum CPA, rata de conversie după clic și optimizarea curentă pentru conversii rămân bazate pe rezultatele produse după clic.
Strategiile Maximize Results
Strategiile maximize_clicks și maximize_conversions sunt documentate pentru campanii standard și pentru campanii bazate pe feed. Ambele cer un buget zilnic și folosesc clicul drept eveniment de facturare. Optimizarea pentru conversii cere exact un eveniment standard activ, ales explicit. Asta înseamnă că funcția există, dar nu poate compensa un semnal de conversie slab, dublat sau definit prea devreme în traseul clientului.
Articolul despre audiențe, conversii, carusele și bugete în ChatGPT Ads explică detaliat compatibilitatea dintre tipul de buget, licitare și evenimente. Pentru harta de disponibilitate este suficientă o distincție: Maximize Results este activ, în timp ce modelul anunțat care ar optimiza și pe baza conversiilor după vizualizare este o capabilitate diferită.
Audiențele personalizate și targetarea
Administrarea audiențelor personalizate este activă în documentația curentă. Membrii pot fi adăugați, eliminați, înlocuiți sau combinați fără recrearea permanentă a audienței. Tipurile acceptate includ identificatori precum email, telefon și Google Advertising ID, în formele permise. Includerea și multiplicatorii de licitație cer minimum 25.000 de utilizatori potriviți; pentru o audiență pregătită folosită exclusiv la excludere, documentația curentă nu impune acest minim.
Targetarea după platformă include aplicațiile iOS și Android, plus web. Actualizarea din 10 septembrie 2026 a adăugat opțiuni web mai precise: desktop, web pe iOS și web pe Android. Opțiunea generală „web” rămâne disponibilă. Targetarea geografică și restricțiile de eligibilitate trebuie verificate împreună, deoarece alegerea unei țări nu garantează că inventarul și audiența eligibilă sunt suficiente pentru livrare.
Funcții active care nu sunt egale pentru toate conturile
Aici apar cele mai multe confuzii. Documentația poate fi completă, însă accesul este acordat numai anumitor conturi sau configurații comerciale. O agenție nu ar trebui să prezinte aceste opțiuni drept standard înainte de a inspecta contul concret.
| Funcție | Stare la 16 septembrie 2026 | Condiția care trebuie verificată |
|---|---|---|
| Feeduri de produse | Documentate și utilizabile pentru conturile cu acces | Contul trebuie să aibă acces la Product Feed API, iar produsele și imaginile să fie public accesibile |
| Metrici pentru cardurile din carusel | Active în raportare | Campania trebuie să livreze formatul cu mai multe produse și să existe date la nivel de produs |
| Limită zilnică la nivel de cont | Adăugată la 9 septembrie 2026 | Documentată pentru conturile cu facturare postplătită prin factură |
| Ferestre de limitare a cheltuielii | Disponibile numai unor conturi | Opțiunea trebuie să apară în configurația contului; nu se presupune acces general |
| Pluginul Ads Manager în ChatGPT sau Codex | Acces dependent de cont, spațiu de lucru, rol și distribuire | Pluginul trebuie să fie vizibil, conectabil și autorizat pentru contul publicitar corect |
Feedurile de produse sunt un acces, nu doar un fișier
Un catalog valid tehnic nu este suficient. Contul are nevoie de acces la funcția de feed, iar fiecare produs trebuie să aibă o pagină de destinație și o imagine accesibile public. Produsele pot fi respinse sau pot rămâne fără livrare. Raportarea la nivel de produs și card ajută la diagnostic, dar apare numai când formatul și datele necesare există. Dacă endpointul ori opțiunea nu este disponibilă, recomandarea oficială este contactarea echipei de cont, nu simularea funcției printr-un flux improvizat.
Controalele de cheltuială depind de facturare
Limita zilnică a contului, introdusă în changelog la 9 septembrie, se aplică explicit conturilor eligibile cu facturare postplătită prin factură. Ea este separată de bugetul campaniei. O campanie poate avea bani disponibili în propria limită și să fie oprită de plafonul contului. În schimb, ferestrele de cheltuială sunt descrise ca disponibile doar anumitor conturi. Aceste diferențe trebuie incluse în procedura financiară, mai ales când mai multe campanii împart același cont.
Pluginul poate exista fără ca toate acțiunile să fie disponibile
Pluginul Ads Manager permite lucrul conversațional cu structura campaniei, analiza și pregătirea modificărilor. Prezența sa într-un spațiu de lucru nu înseamnă că utilizatorul are automat acces la orice cont, rol sau funcție publicitară. Conectarea, permisiunile, previzualizarea și confirmarea acțiunilor rămân esențiale. Un răspuns generat în conversație este un ajutor de operare, nu o dovadă că reclama a trecut verificarea ori că poate livra în România.
Ce a fost adăugat recent și poate fi folosit acum
Istoricul actualizărilor este util tocmai pentru că separă modificările deja intrate în API de anunțurile generale. La 10 septembrie 2026 a fost adăugată targetarea web granulară, iar la 9 septembrie a apărut limita zilnică la nivel de cont pentru configurațiile de facturare eligibile. Pe 25 august au fost extinse operațiile pentru audiențe, inclusiv modificarea membrilor și folosirea audiențelor mici sau goale pentru excludere.
Alte schimbări deja documentate includ optimizarea pentru conversii, lansată în iunie, segmentarea rapoartelor după produs, țară și dispozitiv, precum și extinderea datelor despre produse fără impresii. Acestea nu trebuie prezentate drept funcții viitoare. Totuși, a fi prezente în API nu înseamnă că vor produce automat volum sau că toate elementele din interfață au ajuns simultan în fiecare cont.
| Data actualizării | Capabilitate | Interpretare corectă |
|---|---|---|
| 10 septembrie 2026 | Targetare separată pentru desktop web, iOS web și Android web | Opțiunile sunt documentate; decizia de segmentare trebuie susținută de volum și rezultate |
| 9 septembrie 2026 | Limită zilnică de cheltuială a contului | Disponibilă pentru conturi eligibile cu facturare postplătită, nu pentru orice structură de plată |
| 25 august 2026 | Actualizări flexibile ale audiențelor și excluderi fără prag minim | Operațiile sunt active, dar includerea și multiplicatorii păstrează pragul de potrivire |
| 16 iunie 2026 | Licitare optimizată pentru conversii | Este activă în configurația documentată și folosește conversii după clic |
| 11 iunie 2026 | Raportare extinsă pe produse, țări și dispozitive | Datele sunt disponibile când campania, feedul și dimensiunile cerute sunt eligibile |
Ce se află încă în distribuire sau necesită confirmare
Distribuirea geografică și accesul self-service nu trebuie confundate cu livrarea uniformă. O piață poate fi inclusă într-un val de extindere, dar un cont nou să aibă încă pași de verificare, metode de plată diferite sau inventar limitat. Pentru România, confirmarea utilă este cea din contul real: țara apare la targetare, moneda și fusul orar sunt corecte, metoda de plată este acceptată, reclama trece verificarea și campania începe să raporteze impresii.
Optimizarea care include conversii după vizualizare nu este încă modelul curent
OpenAI a anunțat un model de optimizare care ar urma să folosească atât conversii după clic, cât și conversii după vizualizare, cu facturare bazată pe impresii. Acest model nu trebuie confundat cu strategiile Maximize Results documentate acum. În raportarea curentă, conversiile view-through sunt suplimentare și nu modifică licitarea, facturarea sau CPA-ul bazat pe clic.
Până când noul model primește documentație completă și apare în cont, o companie nu ar trebui să construiască prognoze pe conversii asistate de vizualizare. Este util să păstreze aceste date ca indicator secundar, să urmărească ferestrele de atribuire și să evite însumarea mecanică a rezultatelor dacă alte canale revendică aceeași conversie.
Distribuirea uniformă a pluginului și a noilor controale
Chiar dacă pluginul sau un control a fost anunțat, apariția sa poate depinde de plan, rol, regiune, organizație și starea contului Ads. Echipele mari pot avea acces diferit între utilizatori din același spațiu de lucru. De aceea, procedura de lansare trebuie să poată funcționa și fără o comandă conversațională anume: modificările importante trebuie verificate în obiectele campaniei și în raportare.
Pacingul bugetului total trebuie observat, nu presupus ca setare
Comunicarea pentru advertiseri a menționat distribuirea mai uniformă a cheltuielii în campaniile cu buget total. Documentația API arată bugetul zilnic și bugetul pe durată, dar nu prezintă un câmp separat prin care advertiserul să aleagă manual algoritmul de pacing. Interpretarea prudentă este că platforma poate aplica acest comportament, iar echipa trebuie să îl observe în livrare. Nu este justificat să promitem o cheltuială identică în fiecare zi, deoarece oportunitățile eligibile pot varia.
Cinci afirmații care ar trebui evitate în ofertă
- „ChatGPT Ads este disponibil, deci reclama va apărea imediat.” Livrarea depinde de verificare, program, buget, ofertă, targetare și inventar.
- „Toate conturile au aceleași funcții.” Feedurile, controalele de cheltuială și pluginul pot depinde de acces, facturare sau distribuire.
- „Conversiile după vizualizare optimizează deja campania.” Ele sunt raportate separat; modelul care le-ar folosi în optimizare a fost anunțat pentru o etapă viitoare.
- „Dacă funcția apare în API, este activă în orice interfață.” Documentația tehnică și disponibilitatea dintr-un anumit cont nu sunt sinonime.
- „O campanie activă confirmă eligibilitatea tuturor componentelor.” Reclama, feedul, produsul, evenimentul și metoda de plată pot avea stări distincte.
Verificarea corectă înainte de buget
În locul unei liste de funcții preluate dintr-un anunț, compania are nevoie de o verificare reproductibilă. Aceasta poate fi făcută înainte de a produce toate materialele creative și înainte de a rezerva un buget semnificativ.
- Confirmă contul și rolul. Verifică organizația, ID-ul contului publicitar, utilizatorul conectat, permisiunile, moneda, fusul orar și tipul de facturare.
- Citește capabilitățile reale. Notează obiectivele, strategiile de licitare, targetarea, feedurile și controalele care apar efectiv. Păstrează data verificării.
- Verifică stările dependente. Contul, campania, grupul, reclama, brandul, feedul și produsele trebuie analizate separat. Un status verde la nivel superior nu anulează o respingere mai jos.
- Testează măsurarea. Trimite un eveniment controlat prin Pixel și, dacă există, prin Conversions API. Verifică ID-ul de deduplicare, valoarea, moneda și apariția în raport.
- Confirmă geografia și platforma. Selectează România sau piețele vizate, apoi verifică opțiunile pentru aplicații și web. Nu fragmenta targetarea dacă volumul inițial este prea mic.
- Lansează un test limitat. Folosește un buget suficient pentru semnal, dar suficient de mic pentru a limita riscul. Urmărește livrarea, clicurile, conversiile și rezultatul comercial.
- Repetă verificarea după schimbări. Un rollout, o modificare de facturare sau un nou tip de campanie poate schimba ce este disponibil. Data ultimei verificări trebuie să apară în documentația internă.
O matrice simplă de decizie pentru companiile din România
| Situație | Decizie recomandată | Motiv |
|---|---|---|
| Contul are campanii standard, targetare locală și raportare funcțională | Poate începe un pilot controlat | Nucleul necesar este disponibil și poate fi măsurat |
| Strategia depinde de feed, dar funcția nu apare în cont | Nu construi încă întreaga campanie pe carusel | Accesul la feed trebuie confirmat înaintea producției și a prognozei |
| Pluginul nu este vizibil, dar Ads Manager funcționează | Continuă prin interfață sau API, dacă echipa este pregătită | Pluginul este o modalitate de operare, nu condiția existenței campaniei |
| Planul depinde de optimizare view-through | Amână acea ipoteză și folosește modelul curent documentat | Capabilitatea nouă este anunțată, nu confirmată drept activă general |
| Trackingul nu poate separa leadurile valide de formularele brute | Repară măsurarea înainte de scalare | O funcție de licitare activă nu poate transforma un semnal slab într-un rezultat bun |
Pentru multe firme, primul test nu trebuie să folosească fiecare funcție disponibilă. O campanie standard, o pagină de destinație clară, un singur rezultat măsurabil și o limită controlată oferă o bază mai bună decât o arhitectură complexă construită pe funcții aflate încă în distribuire. Complexitatea se adaugă după ce datele arată unde este necesară.
Cum păstrăm această hartă utilă după lansare
O hartă de disponibilitate expiră repede dacă nu are dată și proprietar. Echipa ar trebui să păstreze un registru scurt cu funcția, starea observată, contul verificat, sursa oficială, data și impactul asupra campaniei. La fiecare actualizare importantă se modifică registrul, nu prezentarea comercială din memorie.
Merită urmărite trei surse: documentația de produs, istoricul actualizărilor și propriile date de cont. Prima arată regulile, a doua arată ce s-a schimbat, iar a treia confirmă ce poate folosi compania. Niciuna nu este suficientă singură. O funcție poate fi documentată și indisponibilă contului; poate apărea în cont și să nu livreze; poate livra și totuși să nu producă valoare comercială.
Pentru un test administrat, serviciul Web Hat de promovare prin ChatGPT Ads poate acoperi verificarea accesului, configurarea campaniei, măsurarea și interpretarea rezultatelor. Bugetul media rămâne separat, iar funcțiile folosite sunt stabilite după ce apar în cont și pot fi validate, nu doar după anunțurile de produs.
Surse oficiale verificate
- OpenAI Ads, prezentarea produsului și accesul la documentație
- Advertiser API Overview, obiecte, acces și capabilități
- Account Management, limite și controale la nivel de cont
- Campaign Management, ierarhie și stări
- Campaign Targeting, platforme și audiențe
- Platform Targeting, aplicații și opțiuni web
- Custom Audiences, actualizări, includere și excludere
- Product Feeds, acces și cerințe pentru produse
- Conversion-Optimized Campaigns, modelul activ de optimizare
- Bidding and Budgets, strategii și compatibilități
- Reporting, conversii, atribuire și date despre produse
Starea funcțiilor a fost verificată la 16 septembrie 2026. OpenAI poate modifica accesul, politicile, interfața și specificațiile; înaintea unei decizii de buget trebuie verificată documentația curentă și configurația contului care va rula campania.
