De ce discutăm asta în 2026

„CAPI vs Pixel” e o întrebare pe care o primesc la fiecare al doilea audit. Răspunsul scurt — pe care îl repet fără să mă plictisesc — e că nu există „vs”. În 2026, oricine rulează Meta Ads serios în România are Pixel + CAPI cu deduplicare. Dar confuzia e de înțeles: Meta a schimbat de 3 ori recomandarea oficială în 4 ani, documentația e împrăștiată, iar agențiile vând implementări care uneori fac mai mult rău decât bine.

Contextul istoric scurt, ca să înțelegi de ce acum CAPI e aproape obligatoriu:

  • Pre-2021: Pixel-ul funcționa perfect. Pui scriptul pe site, trimite evenimente via browser, Meta le corelează cu conturile Facebook prin cookie. Match quality natural 7-9.
  • Apr. 2021 (iOS 14.5 + ATT): Apple întreabă utilizatorul „îi permiți app-ului Facebook să te urmărească?”. 75% răspund NU. Meta pierde un bloc mare de atribuire pe iOS. Apare ATT + AEM (Aggregated Event Measurement).
  • 2022-2023 (Safari ITP 2.x, Firefox ETP): Cookie-urile third-party sunt șterse la 7 zile. Pixel-ul pierde încă 10-20% din semnale.
  • Sep. 2023 (iOS 17): Apple elimină query parameters de tracking din link-urile pe Messages, Mail, Safari Private Browsing (Link Tracking Protection). Pixel-ul primește user-i fără fbclid. Match quality coboară și mai mult.
  • 2024-2025: Chrome inițiază Privacy Sandbox. Third-party cookies se sting progresiv. Pixel-ul browser-side devine tot mai puțin fiabil pe trafic non-iOS.
  • 2026: Realitatea — Pixel-ul singur acoperă 55-75% din evenimente în funcție de industrie și proporție iOS. CAPI e cel care umple golul.

Dacă încă mai administrezi un cont Meta Ads doar cu Pixel, e ca și cum ai conduce un coach de raliu cu trei cauciucuri. Funcționează, dar mereu cu 20-30% sub potențial.

Ce e Meta Pixel — și de ce pierde evenimente

Meta Pixel e un fragment de JavaScript (cca. 20 KB gzipped) pe care îl instalezi în <head>-ul fiecărei pagini. Ascultă evenimente (PageView, ViewContent, AddToCart, Purchase, Lead etc.) și le trimite via browser la endpoint-ul Meta: https://www.facebook.com/tr/.

Cum funcționează în teorie

  1. Utilizatorul aterizează pe site.
  2. Pixel-ul pornește, setează cookie-uri _fbp (first-party) și citește _fbc din URL (fbclid).
  3. La fiecare eveniment (ex: buton Cumpără apăsat), Pixel-ul trimite o cerere GET/POST cu parametri: eventName, eventID, value, currency, plus _fbp/_fbc/user-agent/IP colectate automat de browser.
  4. Meta primește evenimentul, îl corelează cu profilul Facebook al utilizatorului prin cookie-uri și user_data, face optimizare pe campanie.

De ce pierde evenimente — 5 motive

1. Ad-blockers. uBlock Origin, AdBlock Plus, Brave Shields blochează Pixel-ul la nivel de DNS sau extension. Între 15-25% din utilizatorii tech-savvy au un ad-blocker activ. Pixel-ul nu se încarcă deloc pentru ei. CAPI, fiind server-to-server, trece.

2. iOS 17 Link Tracking Protection. Când cineva dă click pe anunț în Facebook app pe iOS și trece prin Mail/Messages/Safari Private, Apple strips parametrii fbclid. Pixel-ul primește utilizatorul pe pagină, dar nu mai are identificatorul care să-l lege de click-ul din reclamă. Match quality pe acel user: cvasi-zero.

3. Safari ITP (Intelligent Tracking Prevention). Cookie-urile third-party expiră în 7 zile pe Safari. Chiar și cookie-urile first-party setate de script-uri (ca _fbp) sunt șterse după 7 zile de inactivitate. Concret: utilizatorul vede anunțul luni, se gândește 10 zile, revine pe site. Pixel-ul îl vede ca utilizator nou — Meta nu-l atribuie reclamei din luni, deci CPL-ul pe care-l vezi în Ads Manager e umflat.

4. Browser privacy modes. Firefox Enhanced Tracking Protection, Brave, DuckDuckGo browser, Chrome Incognito + blocking — toate afectează Pixel-ul. Pe trafic enterprise (laptopuri corporate cu politici IT strict), procentul poate depăși 40%.

5. Erori de implementare. Pixel care nu se încarcă pe mobile din cauza unui script blocant. Pixel care se declanșează înainte de consent cookie. Pixel pe subdomain care nu partajează cookie-ul cu domeniul principal. Toate astea sunt foarte comune și le vedem la 1 din 3 audituri.

🔥 Hot take

Dacă ai 30%+ trafic iOS și rulezi Meta Ads doar cu Pixel, CPL-ul pe care-l vezi în Ads Manager e minciuna polite a Meta. Realitatea e cu 15-30% mai mică — dar tu bid-uiești pe volumul văzut de Pixel, nu pe realitate. De aici pare că „nu merge cât ar trebui”.

Ce e Conversions API (CAPI) — și ce recuperează

CAPI (Conversions API, fostă „Server-Side API” sau „Graph API Events”) e canalul prin care site-ul tău trimite evenimente direct către serverele Meta, fără să treacă prin browser-ul utilizatorului. Ruta e: Backend-ul tău → HTTPS POST → graph.facebook.com.

Payload-ul CAPI — ce trebuie să trimiți

Un eveniment CAPI e un JSON cu structură fixată de Meta:

POST /v19.0/<PIXEL_ID>/events?access_token=<TOKEN>

{
  "data": [{
    "event_name": "Purchase",
    "event_time": 1714385100,
    "event_id": "ord_12345_server",
    "event_source_url": "https://site.ro/multumim",
    "action_source": "website",
    "user_data": {
      "em": ["<sha256(ion@firma.ro)>"],
      "ph": ["<sha256(+40722123456)>"],
      "client_ip_address": "85.123.45.67",
      "client_user_agent": "Mozilla/5.0 ...",
      "fbc": "fb.1.1714385000.AbcDef...",
      "fbp": "fb.1.1714380000.987654321"
    },
    "custom_data": {
      "currency": "RON",
      "value": 499.00,
      "content_ids": ["SKU-001"],
      "content_type": "product"
    }
  }]
}

Trei secțiuni critice:

  • event_id — ID-ul unic al evenimentului. Trebuie să fie identic cu cel trimis de Pixel pentru deduplicare.
  • user_data — identificatorii persoanei. Meta face matching cu conturile Facebook. Cu cât trimiți mai multe, cu atât EMQ crește.
  • custom_data — detalii despre eveniment (valoare, moneda, produs). Folosit pentru optimizare pe valoare și raportare.

De ce CAPI nu pierde ce pierde Pixel-ul

Neblocabil de ad-blockers: request-ul pleacă de pe server, ad-blocker-ul browser-ului nu-l poate atinge.

Insensibil la ITP: cookie-urile din Safari nu mai contează — trimiți direct email/phone/IP hashuite.

Independent de browser privacy: user-ul poate folosi Tor Browser, tot îți trimiți evenimentul către Meta.

iOS 17 Link Tracking: parțial. Dacă pierzi fbclid-ul, nu poți seta fbc. Dar încă ai email, phone, IP — match-ul se face pe alte campuri.

Ce poate CAPI, ce Pixel nu poate

  • Offline Conversions: trimiți evenimente care se întâmplă offline (call-center marchează lead ca „vândut”, trimiti „Purchase” din CRM către Meta, 24h mai târziu). Pixel-ul e browser-only.
  • Server-side value: poți trimite valoarea reală a comenzii din backend (după validare stoc, aplicare cupoane), nu din frontend unde poate fi manipulată.
  • Backend events: „Order Refunded”, „Subscription Cancelled”, „Upsell Purchased” — toate pot merge server-side.
  • Ecosistem cu app + site: combini evenimente din aplicație mobile și site sub același Pixel ID, prin CAPI.

Pixel vs CAPI — comparație directă

Tabel care rezolvă 90% din întrebările pe care le primesc la call-uri tehnice:

Criteriu Meta Pixel Conversions API (CAPI)
Locul execuțieiBrowser utilizatorServer backend
Blocat de ad-blocker?Da (uBlock, AdBlock etc.)Nu
Afectat de iOS 14.5 ATT?Da — puternicParțial (fbc lipsă)
Afectat de Safari ITP?Da (cookies 7 zile)Nu
Afectat de iOS 17?Da (fbclid strip)Parțial
Complexitate setupJoasă (lipește cod)Medie-Ridicată (backend)
Offline events posibile?NuDa
Trimite automat IP/UADa (browser nativ)Nu — trebuie setat manual
Trimite automat fbc/fbpDa (cookie)Nu — trebuie pasat din browser
Hash-uire identificatoriAutomatăManuală (SHA-256)
Raportare Meta„Browser” în Events Manager„Server” în Events Manager
EMQ tipic4-6 / 107-9 / 10 (dacă user_data e bogat)
Pixel + CAPI dedupe8,5-9,5 / 10 (setup de referință)

Observația cheie: CAPI singur are EMQ mai bun decât Pixel singur, dar Pixel + CAPI împreună e ideal. Pixel-ul oferă automat fbp, fbc, IP și user-agent (greu de replicat corect server-side fără trucuri). CAPI oferă robustețea și offline events. Combinația bate oricare individual.

Event Match Quality — scorul care decide totul

Event Match Quality (EMQ) e metrica cel mai des ignorată și cel mai des motivul real pentru care Meta Ads „nu merge” pe un cont. O găsești în Events Manager → selectezi Pixel → tab „Overview” → coloană „Event match quality”.

Cum calculează Meta EMQ

Pentru fiecare eveniment, Meta numără câte din următoarele câmpuri sunt prezente și valide:

  • em — email (SHA-256)
  • ph — phone (SHA-256, format E.164)
  • fn, ln — first name, last name (hashuite)
  • ct, st, zp, country — oraș, județ, cod poștal, țară
  • external_id — ID user din CRM-ul tău (hashuit)
  • client_ip_address, client_user_agent
  • fbc — Facebook click ID
  • fbp — Facebook browser ID

Cu cât mai multe câmpuri, cu atât scorul urcă. Cu cât mai multe câmpuri se potrivesc cu un user Facebook real, cu atât și mai mult. Scală: 0-10 (Meta afișează ca „Great/Good/Okay/Poor/Very Poor”).

Ce scor trebuie să ai

Interval EMQ Interpretare Meta Impact pe campanie
0.0 – 3.9Very Poor / PoorMeta bid-uiește aproape orb, CPL ±50%
4.0 – 5.9OkayFuncționează, dar lookalike-urile ies slab
6.0 – 6.9Okay-GoodMinim acceptabil pentru lead gen
7.0 – 7.9GoodTarget realist pentru conturi mature
8.0 – 10.0GreatTarget pe e-commerce cu valoare mare
Benchmark real — cont agenție
EMQ 5,5 → 9,1

Creșterea medie pe 12 conturi client după implementarea Pixel + CAPI cu user_data bogat (email + phone + IP + UA + fbc + fbp). Pre-implementare: 5,5 mediu. Post-implementare: 9,1. CPL scăzut cu 18-27% în 30 de zile.

Cum urci EMQ-ul — checklist practic

  1. Trimite email-ul hashuit SHA-256 la orice eveniment unde-l ai (Lead, Purchase, Complete Registration). Cu asta singur urci EMQ cu 1,5-2,5 puncte.
  2. Trimite telefonul hashuit SHA-256, format E.164 (+40722123456, fără spații). Încă 1-2 puncte.
  3. Pasează fbc și fbp din browser în CAPI. Soluția tipică: citești cookie-urile _fbp și _fbc în JS, le pui în payload-ul cererii care trimite datele la backend-ul tău, backend-ul le relay-uiește la Meta via CAPI.
  4. Trimite client_ip_address + client_user_agent. Browserul ți le trimite implicit în header-ele HTTP pe backend — doar le citești și le pasezi.
  5. Adaugă external_id. ID-ul user-ului din CRM-ul tău (hashuit). Meta îl stochează și îl folosește pentru matching pe sesiuni multiple.
  6. Verifică săptămânal în Events Manager. Dacă EMQ coboară cu 1+ punct între săptămâni, ai o problemă de implementare (ex: PHP output empty string în loc de null pentru email lipsă, ce afectează hash-ul).

Deduplicarea — regula de aur cu event_id

Dacă trimiți același eveniment din Pixel ȘI CAPI fără deduplicare, Meta îl numără de 2 ori. Rezultat: CPL afișat jumătate decât în realitate, ROAS umflat cu 100%, bucurie falsă urmată de creștere brutală a bugetului și realitate care nu susține decizia.

Cum funcționează deduplicarea

Regula Meta: dacă primește două evenimente cu același event_name și același event_id în interval de 7 zile, păstrează doar unul. Evenimentul păstrat e cel cu mai multe user_data — de obicei cel din CAPI dacă ai trimis email + phone acolo și doar fbp via Pixel.

Cum generezi event_id corect

Regula de fier: event_id trebuie să fie identic în Pixel și CAPI pentru același eveniment.

Două metode care funcționează:

Metoda A (recomandată): generat pe server, pasat în pagină

Backend-ul generează un UUID sau un ID bazat pe transaction_id. Îl injectează în pagina HTML ca variable JavaScript. Pixel-ul îl citește și-l trimite. Tot backend-ul, când trimite CAPI, folosește același ID.

// Server-side (PHP exemplu)
$event_id = 'ord_' . $order_id . '_' . time();
echo "<script>window._fbEventID = '$event_id';</script>";

// Pixel (browser)
fbq('track', 'Purchase', {
  value: 499.00,
  currency: 'RON'
}, { eventID: window._fbEventID });

// CAPI (server) — imediat sau prin queue
sendCAPI('Purchase', [
  'event_id' => $event_id,
  'value' => 499.00,
  'currency' => 'RON',
  ...
]);

Metoda B: hash determinist pe input-uri stabile

Dacă n-ai control complet pe server, poți genera event_id ca hash al unor valori stabile: sha256(order_id + user_id + timestamp_rounded_minute). Ambele surse (frontend + backend) produc același hash. Funcționează, dar fragilă — orice differență de fus orar sau rounding strică dedup-ul.

Cum verifici că dedup-ul merge

În Events Manager → Pixel → tab „Overview”:

  • „Deduplicated events” e coloana critică. Trebuie să fie > 70% pentru evenimente cu dublu-send. Dacă e 0% — ai event_id diferit. Dacă e 100% — trimiți doar dintr-o singură sursă.
  • Target realist: 85-95% deduplicated pentru Purchase/Lead dublu-sent.
🔥 Greșeală clasică

Agenția lipește Pixel-ul cu event_id generat de crypto.randomUUID() în browser și CAPI cu uniqid() pe PHP. ID-urile sunt diferite, dedup = 0%, conversiile se dublează, raportul lunar pare magic. Clientul dă mulți bani pe servicii, apoi se prinde după 3 luni că realitatea e jumate. Reputație dusă pe apă.

Setup CAPI — 4 metode ordonate după complexitate

Există cel puțin 4 căi de implementare, fiecare cu trade-offs. Alegi pe baza stack-ului tău tehnic și volumului.

1. Plugin nativ (WooCommerce, Shopify, Magento)

Complexitate: Joasă. Cost: 0-50 €/lună.

Pentru WooCommerce: Facebook for WooCommerce (plugin oficial Meta) sau PixelYourSite Pro. Pentru Shopify: configurare prin Shopify Admin → Settings → Apps → Facebook & Instagram.

Ce e bun: click + deploy. Trimite automat View Content, Add to Cart, Initiate Checkout, Purchase via CAPI cu dedupe.

Ce e limitat: user_data sunt minime (email + phone dacă utilizatorul e logged-in sau la checkout). EMQ stagnează la 6-7. Plus, plugin-urile nu pot trimite evenimente custom din backend-ul tău (ex: „Order Refunded” după 30 de zile).

Recomandare: Pornește cu plugin dacă ești sub 5.000 €/lună cifră de afaceri Meta Ads. Migrează la GTM sau custom când treci peste.

2. Google Tag Manager Server-side (GTM SS)

Complexitate: Medie. Cost: 50-150 €/lună GCP + 300-600 € setup.

Deploy container GTM Server-side pe Google Cloud Run sau App Engine. Configurezi Meta CAPI Tag în GTM. Toate evenimentele din GTM client-side sunt relayate către GTM server, care le trimite la Meta.

Ce e bun: flexibilitate mare, poți orchestra evenimente din multiple surse (Pixel, GA4, TikTok, LinkedIn) într-un singur tag server. First-party tracking pe propriul subdomain (ex: analytics.site-ul-tau.ro) crește match quality.

Ce e limitat: necesită cunoștințe GTM + DNS + GCP. Greu de debugat la început. Cost recurent lunar.

Recomandare: Stack-ul preferat pentru IMM care folosește deja GTM și are buget 5.000-20.000 €/lună pe Meta Ads.

3. Integrare custom (PHP / Node / Python / Laravel)

Complexitate: Medie-Ridicată. Cost: 800-1.500 € one-time + minim.

Scrii cod direct în backend-ul tău care trimite cereri HTTPS către Meta Graph API la fiecare eveniment critic. Îți gestionezi singur queue-ul (Redis/RabbitMQ recomandat pentru evenimente high-volume), retry logic, logging în caz de error.

Ce e bun: control total pe payload. Poți îmbogăți user_data cu tot ce știi despre user din CRM. Poți trimite offline events din backend automat. Poți orchestra cu restul infrastructurii (Segment, Kafka, datawarehouse).

Ce e limitat: necesită dev-time. Tu menții codul când Meta schimbă versiunea API.

Recomandare: Standardul nostru pentru clienți e-commerce cu 50.000+ €/lună cifră de afaceri Meta Ads. Control, EMQ maxim, offline events complete.

4. iPaaS / Zapier / Make

Complexitate: Joasă. Cost: 20-100 €/lună.

Folosești conectori existenți (Zapier → Meta Conversions, Make → Meta CAPI) care trimit evenimente pe baza trigger-urilor din CRM-ul tău. Util pentru offline conversions — când Pipedrive/HubSpot marchează lead ca „Won”, Zapier trimite „Purchase” la Meta.

Ce e bun: setup rapid fără dev. Perfect pentru trimitere offline events din CRM.

Ce e limitat: latență mare (minute), cost per task poate urca, nu înlocuiește Pixel + CAPI real-time pentru evenimente online.

Recomandare: Complementar metodei 1, 2 sau 3 — folosește-l DOAR pentru offline events din CRM.

Cât recuperezi cu CAPI — date reale din conturi agenție

Partea concretă. Cifrele de mai jos sunt măsurate în Events Manager înainte și după implementarea Pixel + CAPI pe conturile noastre. Nu benchmark-uri globale, ci observații directe.

E-commerce — 3.863 purchases tracked

Metrică Pre-CAPI (Pixel-only) Post-CAPI (Pixel + CAPI dedup) Diferență
Purchase events capturate~2.600 (estimat din raportare)3.863 măsurate+48%
Event Match Quality (mediu)5,49,1+3,7 pct
Cost/achiziție raportat38,60 lei25,99 lei−32,6%
ROAS raportat2,8x4,1x+46%
Lookalike Audience calitateMedieBună-Foarte bună—

Atenție la interpretare: nu înseamnă că clientul a vândut cu 48% mai mult — înseamnă că Meta a văzut realitatea mai clar. Cifrele de cifră de afaceri reală din backend au fost identice pre și post-CAPI (cum era normal: CAPI nu vinde produse, doar raportează mai fidel). Dar cum Meta bid-uie pe ce vede, și vede mai bine, CPC-ul pe aceleași audiențe a scăzut cu 20-35% în 4 săptămâni.

Lead generation — 12.263 leads agregate

Pe Lead Ads native (formular în Facebook), CAPI nu ajută pentru event-ul „Lead” în sine — formularul trăiește în Facebook, Meta captează lead-ul intern. DAR: am implementat CAPI pentru evenimente downstream:

  • CompleteRegistration — utilizator a făcut cont pe site după call-ul sales (offline → CAPI).
  • Qualified Lead — evenil custom trimis din CRM după ce sales a confirmat calificarea (offline → CAPI via Make).
  • Customer — client a plătit factura, trimis din ERP (offline → CAPI via Zapier).

Rezultat pe 4 conturi B2B testate: optimizarea campaniilor pe „Qualified Lead” (nu pe „Lead” raw) a dus la:

Impact CAPI offline pe calitatea lead-ului
−41% CPL calificat

Măsurat pe 4 conturi B2B după 60 de zile de optimizare pe eveniment Qualified Lead (CAPI offline din CRM) vs Lead raw (pixel + form submit). Bonus: rata Lead → Customer a urcat de la 11% la 19%.

Când NU ai nevoie de CAPI

Honest moment — nu e cazul pentru toată lumea. Situații în care poți amâna CAPI:

1. Buget sub 300 €/lună pe Meta Ads

Matematica simplă: la 300 €/lună, dacă CAPI reduce CPL-ul cu 20%, câștigi 60 €/lună. Implementarea custom costă 800-1.500 € one-time. Break-even în 14-25 de luni — nerezonabil.

Soluție alternativă: Plugin gratuit WooCommerce (CAPI „light”), fără să investești în custom. Marginale, dar gratuit.

2. 100% Lead Ads native, fără remarketing pe site

Dacă toată strategia e Lead Ads și nu ai remarketing pe website visitors, Pixel-ul are valoare marginală. CAPI ajută doar dacă faci offline events (Qualified Lead, Customer) din CRM. Altfel, Lead Ads native sunt auto-trackuite de Meta.

3. Trafic dominant Android + desktop non-Apple

Pe trafic 80%+ Android + desktop Chrome/Firefox, Pixel-ul capturează 80-90% din evenimente. Câștigul CAPI e 10-15%, nu 30%+ cum e pe iOS. Încă merită, dar nu e urgent.

4. Stack tehnic 100% static (GitHub Pages, JAMstack)

Dacă nu ai backend, CAPI devine complex (necesită serverless functions, edge functions). GTM Server-side e alternativa acolo.

În toate celelalte cazuri — bugetul 500+ €/lună, 25+% trafic iOS, e-commerce sau B2B — CAPI e obligatoriu în 2026.

5 erori frecvente la implementare

1. Hash SHA-256 făcut greșit

Meta cere hash SHA-256 cu input normalizat: lowercase, fără spații, fără prefix tel: sau mailto:. Greșeala clasică: hash-uiezi Ion.Popescu@Gmail.com în loc de ion.popescu@gmail.com. Hash-ul e complet diferit, Meta nu face match cu contul Facebook, EMQ rămâne scăzut.

Fix: sha256(strtolower(trim($email))). Pentru telefon: E.164 strict (+40722123456), fără (, ), - sau spații.

2. Trimiți CAPI dar uiti fbc/fbp

Ești tentat să trimiți doar email + phone din backend. Dar fără _fbp și _fbc (cookie-uri setate de Pixel pe browser), Meta nu poate corela evenimentul cu click-ul din reclamă. EMQ rămâne blocat.

Fix: pasează cookie-urile din browser la backend (hidden input în formular sau fetch request), backend-ul le pune în payload-ul CAPI.

3. event_id diferit între Pixel și CAPI

Deduplicarea nu merge, conversiile se dublează. Discutat mai sus — verifică în Events Manager coloana „Deduplicated events”. Trebuie > 70%.

4. Trimiți CAPI fără consent cookie

GDPR. Dacă user-ul n-a dat accept pe cookie-banner, nu ai voie să trimiți nimic (Pixel ori CAPI) către Meta cu identificatori. Consent Mode v2 e standardul: trimiți evenimente „denied” pentru user-i fără consent, iar Meta le tratează separat fără atribuire personală.

Fix: banner Cookiebot/Usercentrics/CookieYes + logic în backend care check-uie consent-ul înainte de CAPI call.

5. Access token leaked în frontend

Access token-ul CAPI e PAID — cu el poți trimite orice event către Pixel-ul target. Unii dezvoltatori îl pun în fetch() direct din browser pentru „simplitate”. Oricine deschide Network tab îl vede. Atacatorii îl pot folosi să poluteze Pixel-ul cu evenimente false.

Fix: Access token sta DOAR pe backend. Browser-ul trimite evenimentul la un endpoint al tău (/api/track), care relayuiește către Meta cu token-ul server-side.

Concluzie

CAPI vs Pixel e o întrebare prost formulată în 2026. Răspunsul real e Pixel + CAPI cu deduplicare + Event Match Quality 8+. Cu setup-ul ăsta, Meta Ads bid-uie pe realitate, lookalike-urile ies bune, CPL-ul scade și raportele nu te mai mint.

Ce trebuie să reții:

  • Pixel singur = 20-40% evenimente pierdute după iOS 17 și blocări browser. Numerele tale din Ads Manager sunt umflate artificial.
  • CAPI recuperează golul server-to-server, insensibil la ad-blockers și ITP.
  • event_id identic în Pixel + CAPI = deduplicare curată. Altfel dublezi conversii.
  • Event Match Quality 7+ e ținta. Cu email + phone + fbc + fbp + IP + UA ajungi la 8,5-9,5.
  • Plugin → GTM SS → custom, în ordinea complexității și volumului. Pentru 5.000+ €/lună buget, custom e worth it.
  • Offline events via CAPI e ace-ul în mânecă pentru B2B — optimizezi pe Qualified Lead, nu pe Lead raw.
  • GDPR: consent-first, hash-uri corecte, access token pe backend.

Dacă vrei verificare rapidă pe setup-ul tău actual — accesezi Events Manager, te uiți la EMQ pe Purchase/Lead și la Deduplicated events. Dacă EMQ e sub 7 sau Dedupe e 0%, suni la cineva care știe CAPI. Pierzi bani în fiecare zi.

Și dacă acel cineva suntem noi, completează formularul mai jos. În 48h primești raport scris cu top 5 lucruri de reparat.