Înainte să dai vina pe cod: cât are voie raportul să întârzie
Pe 1 septembrie 2026, rapoartele standard din Google Analytics 4 au arătat aproape nimic pe foarte multe proprietăți. Prima reacție e să cauți greșeala la tine. A doua e să cauți o pagină de stare. Amândouă sunt pripite, iar cifrele care le rezolvă sunt publicate — doar că pe alte pagini decât cele pe care le citești.
Ce s-a schimbat. Pe 1 septembrie 2026, rapoartele standard din GA4 au arătat zero sau aproape zero pe foarte multe proprietăți, în timp ce raportul în timp real continua să funcționeze — o problemă de procesare, nu de trafic. Presa de specialitate a scris despre asta pe 2 septembrie.
De ce nu e pentru toată lumea. Dacă raportarea ta încrucișează deja două numărători independente, ai văzut golul într-o oră și ai mers mai departe. Pagina asta e pentru firmele care luni dimineața citesc un singur tablou de bord și decid luna din el. Sunt multe, și nu e o prostie: e exact ce te invită uneltele să faci.
Ce câștigi. Câte ore are voie fiecare raport să întârzie, după documentația proprie a furnizorului; unde publică Google, de fapt, starea serviciului Analytics; și ce conține istoricul acelei pagini când îl descarci în loc să te uiți la el.
- GA4 scrie negru pe alb: „procesarea datelor poate dura 24-48 de ore”.
- Search Console e cel mai lent: „datele colectate ar trebui să fie disponibile în 2-3 zile”.
- Google Analytics nu are pagină de stare proprie: cea oficială e tabloul de bord Google Ads.
- Istoricul publicat acolo are 35 de incidente din 24 octombrie 2025. Niciunul nu e pentru Analytics.
Întârziat sau lipsă? Răspunsul documentat, în ore
Prospețimea datelor este intervalul pe care un furnizor și-l rezervă prin documentație până când un număr apare în raport și încetează să se mai schimbe; pentru Google Analytics 4 el ajunge la 24-48 de ore, pentru Google Ads la o oră pe clicuri, iar pentru Search Console la 2-3 zile.
Aproape toată panica de pe 1 septembrie ar fi fost dezamorsată de tabelul ăsta. Google Analytics 4 publică o pagină de prospețime a datelor: timpul real e „de obicei câteva minute”, datele intrazilnice pe o proprietate standard vin în 2-6 ore, raportul zilnic la 12 ore. Iar propoziția de reținut e cea mai simplă de pe pagină: „procesarea datelor poate dura 24-48 de ore. În acest timp, datele din rapoarte se pot modifica”. Nu „pot lipsi” — se pot modifica. Un număr fotografiat marți dimineața are dreptul să fie alt număr miercuri, prin proiectare, fără ca ceva să fie stricat.
Google Ads e mai rapid și o spune precis: clicurile, afișările și costul au „un obiectiv de prospețime a datelor de 1 oră (SLO), ceea ce înseamnă că sunt împrospătate din oră în oră”. Conversiile sunt mai lente și depind de drumul pe care vin: 3 ore pe modelul ultimul clic, 15 ore pe celelalte modele, iar obiectivele și tranzacțiile importate din Analytics au 12 ore pe ultimul clic și 24 de ore pe celelalte modele.
Search Console e cel mai lent dintre cele trei și cel pe care îl uită toată lumea: „în mod normal, datele colectate ar trebui să fie disponibile în 2-3 zile”. Pentru un site nou adăugat, aceeași pagină spune că „poate dura până la o săptămână până se generează date”. Trei zile nu sunt o defecțiune: e comportamentul documentat al raportului pe care multe firme îl deschid zilnic.
Trei zile la Search Console, o oră la clicurile din Google Ads
Întârzierea maximă documentată pentru fiecare metrică, din paginile de prospețime a datelor ale celor trei furnizori, citite pe 3 septembrie 2026. Ore, nu estimări.
Sursa: cele patru pagini de stare și cele trei pagini de ajutor despre prospețimea datelor, citite pe 3 septembrie 2026 · cittago.com
| ore | |
|---|---|
| Search Console · Performanță | 72 h |
| GA4 · procesare completă | 48 h |
| Ads · conversii GA, alte modele | 24 h |
| Ads · conversii, alte modele | 15 h |
| Ads · conversii GA, ultimul clic | 12 h |
| GA4 · rapoarte zilnice | 12 h |
| GA4 · intrazilnic, proprietate standard | 6 h |
| Ads · conversii, ultimul clic | 3 h |
| Ads · clicuri, afișări, cost | 1 h |
Măsurarea are o asimetrie neplăcută: dacă aștepți o oră, pierzi o oră; dacă schimbi în panică o configurație care funcționa, pierzi o lună de comparabilitate. Reinstalarea unui tag bun în timpul unei defecțiuni la furnizor e cea mai scumpă variantă a zilei ăsteia.
Unde publică Google starea serviciului Analytics
Google Analytics nu are o pagină de stare cu numele lui. Sursa pe care Google o documentează este Google Ads Status Dashboard, la ads.google.com/status/publisher, care listează Analytics printre șaisprezece produse, alături de AdSense, AdMob și Ad Manager. Articolul de ajutor „Analytics service status” o spune într-un rând: tabloul „afișează starea de performanță a unor produse Google, inclusiv Analytics”, iar fraza e valabilă și pentru versiunea standard, și pentru 360.
Pe 3 septembrie 2026 am încercat variantele evidente: status.analytics.google.com nu se rezolvă, analytics.google.com/status/ întoarce 404, status.google.com nu se rezolvă nici el. Google ține tablouri separate pentru Workspace și pentru Search; Analytics călătorește pe cel de publicitate.
Citită pagina de destinație, cusătura se vede. Descrierea ei proprie spune: „Această pagină oferă informații de stare despre serviciile care fac parte din Google Ads”. Google Analytics nu face parte din Google Ads. Nici AdSense, nici Ad Manager. Șaisprezece produse stau pe un tablou al cărui titlu descrie o mulțime mai mică decât cea pe care o duce, iar articolul care îl explică e arhivat în ajutorul Google Ad Manager, nu în cel de Analytics.
Ce s-a întâmplat pe 1 septembrie 2026
Search Engine Roundtable a publicat pe 2 septembrie 2026, la 6:13: „datele de 1 septembrie 2026 arată zero trafic către site-uri; cred că e valabil pentru fiecare instalare de Google Analytics”. Interpretarea articolului e că a fost o defecțiune de raportare, nu vizite pierdute — „e un bug al Google, n-ai nimic de făcut la tine” — și că raportul în timp real a continuat să arate activitate, în timp ce rapoartele standard nu.
Un detaliu merită păstrat, nu netezit, pentru că e genul de lucru care decide dacă o relatare e de încredere. Același articol o citează pe specialista Dana DiTomaso: „se pare că Google Analytics are o problemă cu procesarea datelor de ieri (31 august)”, în timp ce titlul și corpul vorbesc despre 1 septembrie. Sunt două date diferite. Ambele se potrivesc cu o coadă de procesare care se blochează și trage după ea rapoartele zilei următoare, dar nu îți putem spune care zi a fost atinsă în proprietatea ta — și nici articolul nu poate.
Ce îți putem spune e ce arăta suprafața oficială de stare. Am deschis Google Ads Status Dashboard pe 3 septembrie 2026: „No incidents”, ultima actualizare la 7:20 UTC, cu cele opt coloane datate mergând de la 27 august la 3 septembrie — o fereastră care conține integral ziua de 1 septembrie.
Ce scrie în istoric, când îl descarci
Tabloul face un lucru mai bun decât aproape toate: își publică datele. Jos, în pagină, sunt două linkuri, incidents.json și products.json, și amândouă răspund cu JSON la o cerere simplă. Le-am descărcat pe 3 septembrie 2026, iar asta transformă o pagină la care te uiți într-un tabel pe care îl poți număra.
products.json întoarce 16 produse. incidents.json întoarce 35 de incidente: cel mai vechi începe pe 24 octombrie 2025, la 17:44 UTC, cel mai recent pe 1 septembrie 2026, la 14:28 UTC. Sunt 313 zile de istoric față de ziua în care l-am citit, ceea ce se potrivește cu titlul paginii de cronologie, „incidente raportate în ultimele 365 de zile”. Două din cele 35 ating mai mult de un produs, deci sunt 37 de perechi produs-incident de împărțit.
Toate cele 35 de incidente aparțin la șase produse, iar Analytics nu e printre ele
Incidente pe produs, din fișierul de istoric al Google Ads Status Dashboard, descărcat pe 3 septembrie 2026. Fereastra merge de la 24 octombrie 2025 la 1 septembrie 2026.
Sursa: incidents.json și products.json de pe Google Ads Status Dashboard, descărcate pe 3 septembrie 2026 · cittago.com
| incidente | |
|---|---|
| Google Ad Manager | 24 |
| AdMob | 8 |
| Ad Manager DAI | 2 |
| AdSense | 1 |
| Exchange Platforms | 1 |
| Ad Manager Data Transfer | 1 |
| Google Ads | 0 |
| Google Analytics | 0 |
Zece din cele șaisprezece produse listate nu au niciun incident în fereastra publicată: Ads Data Hub, Campaign Manager 360 și API-ul lui, Display & Video 360, Google Ads, Google Ads API, Google Analytics, Platform Home, Platform Reporting și Search Ads 360. Tot ce a fost publicat aparține părții de editori: Ad Manager de 24 de ori, AdMob de 8, Ad Manager DAI de două, iar AdSense, Exchange Platforms și Ad Manager Data Transfer câte o dată.
Gravitățile din fișier merită un rând, pentru că arată că ștacheta nu e pusă la catastrofă: 27 din 35 sunt înregistrate ca întreruperi de serviciu, 7 ca informații de serviciu și exact una ca indisponibilitate totală. Articolul de ajutor definește întreruperea drept „funcționalități majore ale produsului sunt indisponibile sau afectate de o problemă cunoscută” — ceea ce descrie bine niște rapoarte standard pe zero. Duratele merg de la 30 de minute la 18 zile și 14 ore, cu o mediană de 17 ore.
Tabloul publică în jur de trei incidente pe lună, iar august 2026 a fost luna cea mai plină
Incidente după luna în care au început, din același fișier. Octombrie 2025 și septembrie 2026 sunt luni parțiale, la marginile ferestrei, și rămân în afara numărătorii.
Sursa: incidents.json și products.json de pe Google Ads Status Dashboard, descărcate pe 3 septembrie 2026 · cittago.com
| incidente | |
|---|---|
| nov | 4 |
| dec | 2 |
| ian | 5 |
| feb | 2 |
| mar | 4 |
| apr | 5 |
| mai | 2 |
| iun | 2 |
| iul | 1 |
| aug | 6 |
E o propoziție pe care nu o putem scrie, și merită spus de ce. Nu putem afirma că Google Analytics n-a avut niciodată un incident publicat, pentru că fișierul e o fereastră mobilă: 35 de intrări care merg în urmă 313 zile, fără vreo cale, din afară, de a ști dacă intrările mai vechi au fost șterse sau pur și simplu nu existau. Ce susține fișierul e mai îngust și tot util: în istoricul pe care tabloul îl publică azi, produsul pe care o firmă îl verifică atunci când rapoartele se golesc n-a fost niciodată subiectul unei intrări.
Cine ce publică: patru tablouri, patru promisiuni
O firmă europeană care face căutare, social și un site depinde de patru astfel de pagini, iar ele nu sunt construite după același standard. Le-am deschis pe toate patru pe 3 septembrie 2026 și am numărat rândurile cu nume de pe fiecare, pentru că numărul de rânduri e cea mai ieftină măsură onestă a cât de precisă acceptă să fie o pagină de stare.
Microsoft numește 33 de părți ale platformei; Google Search numește patru
Numărul de componente numite separat pe fiecare pagină publică de stare, numărate pe 3 septembrie 2026. Mai multe rânduri nu înseamnă automat mai bine, dar e o promisiune despre unde acceptă furnizorul să fie precis.
Sursa: cele patru pagini de stare și cele trei pagini de ajutor despre prospețimea datelor, citite pe 3 septembrie 2026 · cittago.com
| componente numite | |
|---|---|
| Google Search | 4 |
| Google Ads | 16 |
| Meta | 17 |
| Microsoft Ads | 33 |
Google Search ține lista cea mai scurtă: accesare cu crawlere, indexare, ranking, servire. Fișierul lui de istoric are zece intrări între 26 august 2025 și 18 august 2026, iar opt dintre ele nu sunt defecțiuni: sunt actualizări de ranking și de Discover, anunțate pe același canal. E o alegere deliberată, dar înseamnă că pagina răspunde mai des la întrebarea „Google schimbă ceva?” decât la „Google e stricat?”.
Meta publică șaptesprezece rânduri în patru grupuri: șapte la Ads, trei la Business Tools, cinci la Developer Platform și două la Transparency Tools, fiecare cu pagina și fluxul lui. Toate șaptesprezece arătau „No known issues” la 7:22 UTC, pe 3 septembrie 2026. Ce lipsește merită numit: niciunul dintre cele șaptesprezece rânduri nu e pixelul, Events Manager sau Conversions API. Livrarea reclamelor are un rând; lucrul care numără rezultatele nu are.
Microsoft Advertising e, de departe, cea mai granulară. Pagina ei de sănătate a platformei numește 33 de componente în patru zone — șase aplicații, nouă servicii de platformă, șapte API-uri și unsprezece rânduri de rețea și formate. Două dintre ele sunt „Reporting Data” și „UET”, tagul Microsoft: stratul de măsurare are propriul rând de stare, adică exact rândul care lipsea în altă parte pe 1 septembrie.
| Pagina | Rânduri cu nume | Istoric publicat | Acoperă măsurarea? |
|---|---|---|---|
| Google Ads Status Dashboard | 16 | JSON, 35 de incidente din 24 oct. 2025 | Analytics e listat; nicio intrare în istoric |
| Google Search Status Dashboard | 4 | JSON, 10 intrări din 26 aug. 2025 | Nu — crawling, indexare, ranking, servire |
| metastatus.com | 17 | Istoric pe produs și RSS | Niciun rând pentru pixel, Events Manager sau Conversions API |
| Microsoft Advertising, platform health | 33 | Format de blog, pe zone | Da — „Reporting Data” și „UET” sunt rânduri |
Am căutat și regula care decide când se publică un incident, fiindcă ar explica multe, și n-am găsit-o. Nici pe tablou, nici în articolul de ajutor Ad Manager către care trimite tabloul, nici în articolul Analytics care numește tabloul. Toate trei explică ce înseamnă pictogramele; niciunul nu spune de la ce prag o problemă devine o intrare. Le-am citit în engleză, pe 3 septembrie 2026.
Ce NU spun cifrele astea
- Nu spun că Google Analytics e nesigur. Numărând incidentele de pe o pagină de stare măsori ce publică un furnizor, nu ce i se întâmplă. Sunt două mărimi diferite și doar una se vede din afară.
- Nu spun că datele de pe 1 septembrie s-au pierdut. Defecțiunile de raportare se completează de obicei ulterior, iar relatările descriu o problemă de procesare, nu de colectare. Nu am verificat completarea pe nicio proprietate și nu o afirmăm.
- Nu spun că Analytics n-a avut niciodată un incident publicat. Fișierul descărcat e o fereastră mobilă de 35 de intrări care acoperă 313 zile.
- Nu clasifică furnizorii după fiabilitate. Treizeci și trei de rânduri pe o pagină și patru pe alta sunt o diferență de proiectare a transparenței, nu un punctaj.
- Nu se aplică la Google Analytics 360, Google Cloud sau Workspace, care au aranjamente proprii, necitite pentru articolul ăsta.
Cum verifici, în ordine
- Compară raportul cu propria lui întârziere documentată. Dacă rândurile lipsă sunt în fereastra de 24-48 de ore pe care o documentează GA4, așteaptă înainte de orice altceva.
- Deschide timpul real. Dacă timpul real arată vizitatori iar rapoartele standard nu, colectarea merge și procesarea nu: e forma unei probleme la furnizor, nu a unui tag stricat.
- Verifică a doua numărătoare. Log-urile serverului sau panoul de găzduire, plus coloana de clicuri din platforma de reclame. Două surse care nu se potrivesc cu a treia o identifică pe a treia.
- Deschide pagina de stare corectă — pentru Analytics, cea de la Google Ads — și notează ora pe care o afișează, nu doar culoarea pictogramei.
- Scrie ce ai văzut, cu ora. O notă datată valorează mai mult decât o amintire când aceeași întrebare revine peste trei săptămâni.
- Abia apoi atinge tagul. Cea mai scumpă variantă a zilei ăsteia e cea în care cineva reinstalează un tag funcțional în timpul unei defecțiuni la furnizor și petrece două săptămâni comparând două configurații.
Ordinea asta e tot metoda. Și e și motivul pentru care, atunci când construim marketing digital pentru o firmă, partea de măsurare primește cel puțin două numărători independente înainte să pornească prima campanie: nu din eleganță, ci pentru că una dintre ele va tăcea exact în ziua în care trebuie luată o decizie.
Cine nu are nevoie de nimic din toate astea
Dacă deciziile tale sunt lunare și facturile vin de la platformele de reclame, o zi de rânduri lipsă nu schimbă nimic din ce faci: citește o dată tabelul de întârzieri și întoarce-te la treabă. Dacă deja reconciliezi două surse la sfârșit de lună, ai găsit golul fără noi. Iar dacă raportarea ta merge pe colectare din server, cu depozitul tău de evenimente brute, articolul ăsta descrie o problemă pe care ai eliminat-o prin proiectare acum câțiva ani.
Firmele pentru care e scris sunt cele în care un singur tablou de bord e tot sistemul de măsurare: majoritatea firmelor mici și destule mari. Rezolvarea nu e un sistem mai mare. E să știi ce pagină să deschizi și cât să aștepți înainte s-o deschizi. Pentru un magazin din Cluj-Napoca, a doua sursă e deja pornită și nu costă nimic: log-urile site-ului.
Glosar
| Termen | Ce înseamnă |
|---|---|
| Pagină de stare (status dashboard) | Pagina publică pe care un furnizor înregistrează defecțiunile și întreruperile. Pentru Google Analytics, cea documentată e Google Ads Status Dashboard. |
| Întrerupere de serviciu | Gravitatea de mijloc la Google: „funcționalități majore ale produsului sunt indisponibile sau afectate de o problemă cunoscută”. 27 din cele 35 de incidente publicate o poartă. |
| Indisponibilitate totală | Gravitatea maximă: „produsul este inaccesibil pentru toți utilizatorii”. Unul din 35. |
| Prospețimea datelor | Cât timp își rezervă un furnizor până când un număr apare sau încetează să se schimbe. GA4 documentează 24-48 de ore pentru procesarea completă. |
| Intrazilnic | Date parțiale pentru ziua în curs, înainte de procesarea zilnică. Pe o proprietate GA4 standard, cu 2-6 ore în urmă. |
| Completare ulterioară (backfill) | Rânduri care sosesc mai târziu și umplu un gol rămas gol înainte. Frecventă după defecțiunile de raportare, și motivul pentru care o captură cu ora pe ea e utilă. |
Trei praguri, ca să vezi cât te privește
- O singură unealtă, decizii o dată pe lună. Salvează cele patru adrese și cifrele de prospețime. Asta e toată treaba: o zi lipsă se va fi umplut înainte să conteze.
- O singură unealtă, decizii săptămânale. Adaugă o a doua numărătoare în trimestrul ăsta — log-urile serverului sunt gratuite și deja pornite. O decizie săptămânală luată într-o luni mută e o decizie luată pe nimic.
- Licitare automată alimentată din conversii importate. Aici un gol nu e un neajuns de raportare: e o intrare în algoritm. Întârzierile documentate de 12 și 24 de ore la import sunt motivul pentru care o reacție în aceeași zi la o zi slabă e aproape întotdeauna pripită.
Toate astea au fost citite pe 3 septembrie 2026, pe pagini care se schimbă fără preaviz. Mai discutăm despre asta peste 3-6 luni 😉
Întrebări pe care nu ni le-a pus nimeni
Pagina e nouă, așa că astea sunt întrebările pe care ni le-am pus noi în timp ce citeam cele patru tablouri.
Cât poate să întârzie, legitim, un raport GA4?
După pagina Google de prospețime a datelor: timpul real „de obicei câteva minute”, intrazilnic 2-6 ore pe o proprietate standard, 12 ore pentru raportul zilnic, iar „procesarea datelor poate dura 24-48 de ore. În acest timp, datele din rapoarte se pot modifica”. Un gol în interiorul ferestrei ăsteia e comportament documentat, nu defecțiune.
Dar la Google Ads și Search Console?
Google Ads documentează un obiectiv de prospețime de 1 oră pentru clicuri, afișări și cost; conversiile stau la 3 ore pe ultimul clic și 15 ore pe celelalte modele, iar cele importate din Analytics la 12, respectiv 24 de ore. Search Console spune că „datele colectate ar trebui să fie disponibile în 2-3 zile”, și până la o săptămână pentru un site nou adăugat.
Are Google Analytics o pagină de stare?
Nu sub numele lui. Articolul „Analytics service status” trimite la Google Ads Status Dashboard, pe ads.google.com/status/publisher, care „afișează starea de performanță a unor produse Google, inclusiv Analytics”, pentru versiunile standard și 360. Pe 3 septembrie 2026, status.analytics.google.com nu se rezolva, iar analytics.google.com/status/ întorcea 404.
De ce stă Analytics pe tabloul Google Ads?
Google nu explică asta în niciuna dintre cele trei pagini pe care le-am citit. Tabloul se descrie ca fiind despre „serviciile care fac parte din Google Ads”, dar duce și AdSense, AdMob, Ad Manager și Analytics, iar articolul care îl documentează stă în ajutorul Google Ad Manager. Consecința practică e că pagina e greu de găsit pornind din Analytics.
A raportat tabloul problema din 1 septembrie 2026?
În fișierul de istoric nu există o intrare. Am descărcat incidents.json pe 3 septembrie 2026: 35 de incidente din 24 octombrie 2025, niciunul pentru Google Analytics. Cele trei incidente a căror fereastră include 1 septembrie sunt pentru Ad Manager, Ad Manager DAI și AdMob.
Ce fac mai întâi dacă raportul arată zero?
Compari raportul cu propria lui întârziere documentată, apoi deschizi timpul real. Dacă timpul real arată vizitatori iar rapoartele standard nu, colectarea e bună și procesarea nu. Abia după aia merită deschisă o pagină de stare, și abia după aia merită atins tagul: reinstalarea unui tag funcțional în timpul unei defecțiuni costă săptămâni de comparabilitate.
Publică Meta starea pixelului?
Nu. metastatus.com listează 17 produse cu nume și niciunul nu e pixelul, Events Manager sau Conversions API. Ads Manager, Marketing API și Messaging Ads au fiecare câte un rând; stratul de măsurare nu are. Toate 17 arătau „No known issues” la 7:22 UTC, pe 3 septembrie 2026.
Care platformă e cea mai precisă despre starea ei?
Microsoft Advertising, după numărul de rânduri cu nume: 33 de componente în aplicații, platformă, API-uri și formate de rețea, inclusiv „Reporting Data” și „UET”. E o măsură a transparenței, nu a fiabilității — o pagină cu mai multe rânduri îți spune mai mult când se strică ceva, și nimic despre cât de des se strică.
E de ajuns o singură unealtă de analiză pentru o firmă mică?
Pentru decizii lunare, de obicei da, cu condiția să știi cifrele de prospețime. Pentru decizii săptămânale, o a doua numărătoare care se strică independent — log-urile serverului, panoul de găzduire, coloana de clicuri din platformă — e cea mai ieftină asigurare care există, pentru că e deja pornită și nu costă nimic s-o citești.
Contează asta și dacă am doar clienți din România?
Da: niciuna dintre paginile astea nu e regională. Tablourile privesc produsele, nu piețele, iar întârzierea documentată a GA4 sau a Search Console e aceeași pentru un magazin din Cluj-Napoca și pentru o platformă americană. Diferă doar cât costă o decizie luată pe un rând lipsă.
Ultima actualizare: 3 septembrie 2026. Numărătoarea incidentelor vine din incidents.json și products.json de pe Google Ads Status Dashboard, descărcate pe 3 septembrie 2026; fișierul conținea 35 de incidente începute între 24 octombrie 2025 și 1 septembrie 2026 și este o fereastră mobilă, nu întreaga viață a tabloului. Numărul de componente pentru Google Search, Meta și Microsoft Advertising a fost luat de pe paginile randate în aceeași dimineață, în engleză. Cifrele de prospețime vin din paginile de ajutor GA4, Google Ads și Search Console, citite tot pe 3 septembrie 2026. Defecțiunea din 1 septembrie este relatată de presa de specialitate; nu am găsit o intrare de incident și nici o declarație oficială. Actualizăm pagina când o pagină de stare schimbă ce acoperă sau când se modifică o cifră de prospețime.
Surse: Google Ads Status Dashboard · Istoricul de incidente al tabloului (JSON) · Analytics Help, Analytics service status · Ad Manager Help, Monitor product status · [GA4] Data freshness · Google Ads, About data freshness · About Search Console data · Google Search Status Dashboard · Starea produselor Meta pentru afaceri · Microsoft Advertising, platform health · Search Engine Roundtable, 2 septembrie 2026
