Conversion API Nedir? Meta CAPI, Google Data Manager API ve Sunucu Taraflı Dönüşüm Takibi (2026)

Kısa cevap: Conversion API nedir? Satış, form ya da üyelik gibi dönüşüm olaylarını ziyaretçinin tarayıcısı yerine kendi sunucunuzdan reklam platformuna gönderen arayüzdür. Meta'daki adı Dönüşümler API'si (CAPI); Google tarafında aynı işi gelişmiş dönüşümler ve Data Manager API, ChatGPT reklamlarında ise OpenAI'ın Conversions API'si görüyor. Meta, CAPI'yi Pixel'in yerine değil yanında kullanmayı öneriyor: aynı olay hem tarayıcıdan hem sunucudan gelir ve ortak bir olay kimliğiyle (event_id) tekilleştirilir. Sunucu taraflı kurulumun asıl değeri, platformlara giden verinin kaynağının tarayıcı değil, sipariş ve CRM kayıtlarınız olmasıdır.

Bu rehber, Meta ve Google'da düzenli reklam veren, sitesi ya da CRM'i özel yazılımla (Laravel, Node.js, .NET) kurulmuş veya satışı çevrimdışı kapanan e-ticaret ve B2B şirketlerinin pazarlama ve yazılım yöneticileri için hazırlandı. Bilgileri Meta, Google ve OpenAI dokümanlarından ve KVKK mevzuatından doğruladık; ikincil kaynakları ayrıca belirttik. Yazı 31 Ekim 2026 itibarıyla günceldir.

Conversion API nedir, Pixel'den farkı ne?

Pixel, olayı ziyaretçinin tarayıcısından gönderen bir JavaScript kodudur; reklam engelleyici, tarayıcı kısıtlaması ya da yarım kalan sayfa yüklemesi olayı yolda bırakabilir. Conversion API'de olayı sunucunuz üretip doğrudan platformun API'sine iletir. Böylece ödeme onayı, mağazada kapanan satış ya da CRM'de "nitelikli" işaretlenen lead gibi tarayıcının hiç görmediği olaylar da gönderilebilir.

Meta CAPI nedir? Meta'nın sunucu taraflı olay arayüzü; Türkçe Yardım Merkezi'nde adı "Dönüşümler API'si", aramalarda "Facebook Conversion API" olarak da geçiyor. Meta, CAPI'yi Pixel'in yanında kullanmayı öneriyor; geliştirici dokümanlarında bu yapının adı "redundant setup", yani yedekli kurulum. Pixel'deki eventID ile CAPI'deki event_id ve olay adları aynıysa iki kopya tek olay sayılır. Bu event_id tekilleştirmesi, aynı kimlikli ilk olayın alınmasından sonraki 48 saat içinde çalışır ve Meta genellikle önce gelen kopyayı tutar. fbp ya da external_id'ye dayanan alternatif yöntem ise çoğunlukla yalnızca önce tarayıcıdan, sonra sunucudan gelen olayları eşleyebiliyor; bu yüzden her olaya benzersiz bir event_id verin.

Google'da karşılığı iki parça: hash'lenmiş e-posta ve telefonu dönüşümle gönderen gelişmiş dönüşümler (enhanced conversions) ve çevrimdışı dönüşüm içe aktarmanın artık birincil yolu olan Data Manager API. ChatGPT reklamlarında OpenAI'ın Conversions API'si de aynı mantıkla çalışıyor.

Hazır eklenti mi, tek tıklamalı kurulum mu, özel Conversion API entegrasyonu mu?

Her işletmenin özel kuruluma ihtiyacı yok. Meta, 15 Nisan 2026'da web olayları için teknik uzmanlık, maliyet ve bakım gerektirmeyen tek tıklamalı bir CAPI kurulumu duyurdu; mevcut partner ve özel kurulumlar değişmiyor. PPC Land'e göre bu kurulum yalnızca web'i kapsıyor, olay ve parametre seçimi yapılandırılamıyor (Pixel ne gönderiyorsa sunucudan da o gidiyor); uygulama ve çevrimdışı olaylar için ayrı entegrasyon gerekiyor. ikas'ın "Facebook Conversion API" uzantısı ve Shopify'ın CAPI kullanan veri paylaşımı seviyeleri de hazır seçenekler.

Özel yazılımla kurulmuş bir e-ticaret sisteminde en temiz yol olayı sipariş tablosundan üretmektir; benzer kararı ERP entegrasyonu yazımızda tartıştık.

2026'da Meta, Google ve OpenAI tarafında neler değişti?

Değişikliklerin çoğu Google'dan; 12 Kasım satırı ikincil kaynaklara dayanıyor.

12 Kasım 2026: Meta'nın "müşteri cihazlarında dönüşüm ölçümü" ayarı neyi değiştiriyor?

Meta'nın "Müşteri cihazlarında dönüşümlerin ölçülmesi hakkında" başlıklı bir Yardım Merkezi makalesi var; ayrıntılar panel metnini ve reklamveren e-postasını aktaran sektör yayınlarından. PPC Land'e göre Events Manager'da "Measure conversions on customer devices" seçeneğinin altında "Measurement starting November 12, 2026" yazıyor. Ayar olay gönderen veri kümelerinde varsayılan açık, veri kümesi bazında her an kapatılabiliyor ve kod değişikliği istemiyor; aynı habere göre yayılım 12 Kasım'dan itibaren kademeli olacak. MetricMaven'ın Meta'ya dayandırdığı bilgiye göre eşleştirme müşterinin cihazında yapılıyor; Meta yalnızca satın almanın gerçekleştiğini ve dönüşümün hangi kampanyaya yazılacağını öğreniyor; atıf penceresi ve modeli değişmiyor.

MetricMaven ve Stape'e göre özellik AB ve Birleşik Krallık'taki kişiler için aktif değil ve sitenin e-posta ya da telefonla giriş gerektirmesi gibi uygunluk koşulları var; bu doğruysa misafir ödemeli mağazalar kapsam dışı kalabilir. Meta'nın henüz açıklamadığı noktalar kritik: kurtarılan satın almaların CAPI olaylarıyla nasıl tekilleştirileceği, teklif vermeye etkisi, değer ve para biriminin aktarılıp aktarılmadığı ve rızanın nasıl ele alındığı. Zamanlama da hassas: 12 Kasım, 11.11 kampanyalarının hemen ardından ve 27 Kasım'daki Black Friday'den 15 gün önce geliyor. Önerimiz, kör kapatmak yerine ölçerek karar vermek; sektör kaynaklarıyla örtüşen kontrol listemiz:

1. Durumu kaydedin: Her veri kümesinde ayarın açık mı kapalı mı olduğunu not alın; panolara ve 11.11, Black Friday raporlarına 12 Kasım işareti koyun.
2. Baz çizgisi çıkarın: 12 Kasım öncesi her gün için "Meta'nın raporladığı satın alma ÷ gerçek sipariş" oranını hesaplayın; sonra oranı ve çift sayım sıçramalarını dört ila altı hafta izleyin.
3. Holdout kurun: Bölge ya da kampanya bazlı kontrol grubuyla raporlanan artışı gerçek siparişle doğrulayın.
4. Düzenlemeye tabi sektörlerde hukuk değerlendirmesine kadar kapatmak ve gerekçesini kaydetmek bir seçenek.

Conversion API kurulumu: Sunucu taraflı dönüşüm takibi (server side tracking) adım adım nasıl yapılır?

Referans mimarimizde doğruluk kaynağı sipariş ya da CRM kaydıdır; Meta, Google ve isteğe bağlı olarak OpenAI, bu kayıttan üretilen ve rıza bilgisini taşıyan tek olay akışından beslenir. Erişim jetonunu (Meta CAPI token) Events Manager'da Pixel'in Ayarlar sekmesindeki Dönüşümler API'si bölümünden üretin; bu bağlantıyı yalnızca işletmede geliştirici yetkisi olan kullanıcılar görür. Jetonu sunucuda gizli tutun.

1. Olayı kayıttan üretin. Satın alma, "teşekkürler" sayfası yüklenince değil, ödeme bildirimi doğrulanıp sipariş onaylanınca doğar; bu adımı sanal POS webhook rehberimizde anlattık.
2. Tıklama kimliklerini yakalayın. Meta için fbclid'den üretilen fbc (fb.${subdomain_index}.${creation_time}.${fbclid}) ve fbp; Google için gclid, gbraid, wbraid; OpenAI için, rıza kurallarınız izin veriyorsa __obref çerezi. Bu kimlikler, IP adresi ve user agent hash'lenmeden gönderilir.
3. Tek olay kimliği kullanın. Sipariş numarası Pixel'in eventID'si, CAPI'nin event_id'si, Google'ın transactionId'si ve OpenAI'ın id alanı olsun.
4. Rızayı olaya yazın. Kullanıcının o andaki tercihi olayla saklanır; Data Manager API'de bunun için adUserData ve adPersonalization alanları var.
5. Normalize edip hash'leyin (bir sonraki bölüm).
6. Kuyruğa yazın, idempotent gönderin. Olay kuyruğa yazılır, işçi süreç gönderir, hata alırsa artan aralıklarla yeniden dener. Yeniden deneme çift sayım yaratmaz: Meta ve OpenAI aynı anahtarla gelen kopyalardan ilkini tutar; Google ise bilinen bir transaction ID'yi yeni dönüşüm değil düzeltme sayar ve dönüşüm sayısını artırmaz.
7. Test edin, mutabakat yapın. Meta'da test_event_code (canlıda kaldırın), Google'da validateOnly ve requestStatus.retrieve, OpenAI'da validate_only. Canlıda platform raporunu her gün gerçek siparişle karşılaştırın.

Platform bazında gönderim kuralları

Türkiye'ye özgü normalizasyon ve hash tuzakları

Üç platform da e-posta ve telefonu SHA-256 ile hash'lenmiş istiyor. Tek karakter farkı bambaşka bir hash üretir; normalizasyon hatası, hata mesajı vermeyen sessiz bir eşleşme kaybıdır.

• Telefon her yerde aynı yazılmıyor. 0532 123 45 67 numarası Meta ve OpenAI Conversions API için 905321234567 (baştaki sıfır atılır, ülke kodu eklenir, "+" kullanılmaz), Google Data Manager API ve OpenAI kitle yüklemeleri için +905321234567 (E.164) biçiminde normalize edilip hash'lenir. OpenAI de bir API'nin telefon kuralının diğerinde geçerli olduğunu varsaymamanızı söylüyor.
• İ/ı küçültmesi hash'i değiştirir. Unicode'un varsayılan kuralında "İ" küçülünce iki karakterlik "i̇" (i + U+0307) olur; düz "i" ve "I"→"ı" yalnızca Türkçe yerel ayarda geçerli. Testimizde Python'da "İLKER".lower() "i̇lker" verdi ve hash'i "ilker"inkiyle eşleşmedi; "IŞIK".lower() "işik" oldu. PHP 8.2'den beri strtolower() yalnızca ASCII harfleri küçülttüğü için "İ" ve "Ş"ye dokunmuyor; Laravel'in Str::lower() yardımcısının kullandığı mb_strtolower() "İ"yi "i̇" yapıyor. Tersi de tehlikeli: Türkçe yerel ayarla (JavaScript'te toLocaleLowerCase('tr'), .NET'te tr-TR kültüründe ToLower()) "[email protected]", "ılker@fırma.com" olur.
• E-posta ve isme ayrı kural. E-postada yerel ayardan bağımsız küçültme kullanın ve önce "İ"yi "i"ye çevirin; mobil klavye ilk harfi Türkçe kurala göre büyüttüğünde adres "İlker@…" diye kaydedilebilir. İsimde kurallar ayrışıyor: Meta a–z öneriyor ama UTF-8 kabul ediyor, OpenAI aksanları korumanızı istiyor, Google küçük harf ve unvansız yazım istiyor. Türkçe karakterin hangi biçimde daha iyi eşleştiği belgelenmemiş; kendi verinizle test edin.
• Gmail kuralı yalnızca Google'da: gmail.com ve googlemail.com adreslerinde @ öncesindeki noktalar ile "+" işareti ve sonrası silinir. Meta ve OpenAI'ın kurallarında bu adım yok; OpenAI, kitle yüklemelerinde noktaları ve artı etiketlerini silmemenizi açıkça istiyor.
• TL ile kuruşu karıştırmayın. Google, yüklenen değerin etiketle aynı biçim ve birimde olmasını istiyor; tam sayı sent (bizde kuruş) gibi farklı bir birimin "ciddi dönüşüm değeri şişmesine" yol açtığını, sistemin birimi kendisi dönüştürmediğini yazıyor. 24990 kuruş olduğu gibi giderse 249,90 TL'lik sipariş 24.990 TL görünür.

Normalizasyonu tek, birim testli bir fonksiyonda topluyoruz; örnek vektörler: " İ[email protected]" → [email protected], Google için "[email protected]" → [email protected].

Google Data Manager API, çevrimdışı dönüşümler ve CRM'den lead kalitesi

Google: Gelişmiş dönüşümler ve Data Manager API

Google'ın takvimine göre gelişmiş dönüşümler Haziran 2026'dan itibaren web ve potansiyel müşteriler için tek bir aç/kapat ayarı; dönüşüm işlemi bazında kapatılabiliyor. Google, Data Manager API'yi çevrimdışı dönüşüm içe aktarmanın birincil yolu olarak tanımlıyor; yeni projelere doğrudan onunla başlıyoruz. Geçişte dikkat:

• Developer token gerekmiyor (Google Ads API de 9 Eylül 2026'dan beri token'ı yok sayıyor); kotalar Google Cloud projesine bağlı.
• operating_account, dönüşüm işleminin sahibi olan hesap olmalı; üst ya da alt hesap kabul edilmiyor.
• Yükleme ve düzeltme aynı IngestEvents çağrısında; mevcut transaction ID'yi yeni değerle göndermek düzeltme sayılıyor. Geri çekmede dokümanlar çelişkili: yükseltme rehberi ve düzeltmeler sayfası yalnızca değerin yeniden beyan edilebildiğini, dönüşüm sayısının değişmediğini söylüyor; çevrimdışı dönüşümler sayfası ise geri çekmeden söz ediyor. İade senaryonuzu canlıdan önce test edin.
• GCLID'yi mümkün olan her olayla gönderin; kullanıcı verisini etiketle toplamıyorsanız zorunlu.

Asıl yenilik çok kaynaklı dönüşümler (beta): Google etiketi ya da GTM ile elle kurulmuş bir web dönüşümüne CRM veya sipariş veritabanınızdan ikinci kaynak eklenebiliyor. Kayıtlar transaction ID ile tekilleştiriliyor; eklenen kaynak, eşleşen olaylarda etiketin değerinin üzerine yazarak değerin tek doğru kaynağı oluyor. İlk 14 günlük denemede değer güncellemeleri kapalı ve yeni dönüşümler teklifte kullanılmıyor.

Meta: CRM'deki lead aşamalarını geri göndermek

Conversion Leads entegrasyonunda Meta, en iyi sonuç için 15–17 haneli Meta Lead ID'yi CRM'de saklamanızı öneriyor; yoksa tıklama kimliği, telefon ya da e-posta gönderiliyor. Koşullar: ayda en az 200 lead, optimize edilecek aşamanın lead'den sonraki 28 gün içinde gerçekleşmesi ve %1–40 dönüşüm oranı, en az günlük yükleme. Meta öğrenme süresini 2–4 hafta olarak veriyor. Uzun satış döngüsü olan B2B'de kapanış 28 günü aşabildiği için "kazanıldı" yerine "nitelikli lead" gibi daha erken bir aşamayı optimize etmek gerekebilir. Aynı aşama değişikliği Google'a GCLID ve hash'li e-postayla, potansiyel müşteriler için gelişmiş dönüşüm olarak Data Manager API üzerinden gider. CRM ve ERP projelerinde aşama alanlarını baştan bu ihtiyaca göre tasarlıyoruz.

KVKK ve rıza: Hukuk birimine hangi soruları götürmelisiniz?

Bu bölüm hukuki görüş değildir.

• Aydınlatma ve açık rıza ayrı mı? Kurul'un 2026/347 sayılı ilke kararına göre aydınlatma, hukuki sebep ne olursa olsun işlemeden önce yapılır; açık rızaya dayanılıyorsa iki metin farklı başlıklar altında ayrı düzenlenir, başka bir hukuki sebebe dayanılıyorsa açık rıza metni sunulmaz.
• Yurt dışına aktarım neye dayanıyor? 1 Haziran 2024'ten beri yürürlükte olan 9. madde, işleme şartının yanında önce yeterlilik kararı, yoksa standart sözleşme gibi uygun güvenceler arıyor; standart sözleşme imzadan itibaren beş iş günü içinde Kurum'a bildirilmeli. Açık rıza yalnızca "arızi" aktarımda istisnai bir yol; Yönetmelik arızi aktarımı düzenli olmayan, tek ya da birkaç sefer gerçekleşen, süreklilik arz etmeyen ve olağan faaliyet akışı içinde bulunmayan aktarım olarak tanımlıyor. Her siparişte çalışan bir akış buna uyar mı?
• Hash anonimleştirme mi? Hash'in amacı kişiyi platformdaki hesapla eşleştirmek; Google da hash'li veriyi oturum açmış hesaplarla karşılaştırıyor. Biz hash'i anonimleştirme değil, güvenlik önlemi sayıyoruz.
• Varsayılan rıza ne? OpenAI Pixel'i rızayı varsayılan olarak true başlatıyor; gereken yerde init'ten önce oaiq('consent', false) çağırın.
• Avrupa'daki kullanıcılara reklam veriyor musunuz? Google'ın AB kullanıcı rızası politikası Avrupa Ekonomik Alanı, Birleşik Krallık ve İsviçre'deki kullanıcıları kapsıyor ve reklam kişiselleştirmesi için kişisel veri toplama, paylaşma ve kullanmaya geçerli rıza istiyor. Google ürünleriyle Almanya'daki kullanıcılara ulaşan bir ihracatçı, bu kullanıcılar için politikanın kapsamına girer. Türkiye trafiğinde çerçeveyi KVKK çiziyor.

Veri envanterini ve tedbirleri, entegrasyonu tasarlamadan önce bir KVKK/GDPR uyumluluk çalışmasıyla netleştirin.

Partnerfy bu süreçte nasıl yardımcı olur?

Conversion API'ye bir etiket kurulumu olarak değil, sipariş ve CRM verinizden başlayan bir entegrasyon projesi olarak bakıyoruz. Önce mevcut Pixel ve sunucu olaylarınızı denetliyor, ardından olay şemasını Meta, Google ve gerekiyorsa OpenAI'a eşleyip event_id stratejisini ve normalizasyon kurallarını test vektörleriyle sabitliyoruz. Gönderim katmanını kullandığınız altyapıda (ör. Laravel, Node.js ya da .NET) kuyruk, idempotent yeniden deneme ve hata izlemeyle kuruyor, rıza durumunu olayın parçası yapıyoruz. Canlıya geçtikten sonra platform raporlarını gerçek siparişlerle karşılaştıran bir mutabakat ve izleme görünümü de hazırlıyoruz. Ayrıntılar Conversion API entegrasyonları sayfamızda; mevcut kurulumunuzu birlikte incelemek için bize yazın.

Kaynaklar

• Meta for Developers: tekilleştirme, müşteri bilgisi parametreleri, API kullanımı, erişim jetonu, Conversion Leads
• Meta: 15 Nisan 2026 duyurusu; Yardım Merkezi: Dönüşümler API'si hakkında, müşteri cihazlarında ölçüm
• Google Ads API: kullanımdan kaldırmalar, developer token, Developer Blog, 15 Mayıs 2026
• Google Ads Yardım: potansiyel müşteriler için gelişmiş dönüşümler, ayar güncellemeleri, çok kaynaklı dönüşümler
• Google Data Manager API: yükseltme rehberi, çevrimdışı dönüşümler, düzeltmeler, events.ingest, hata modeli, biçimlendirme, Consent; Google: AB kullanıcı rızası politikası
• OpenAI Ads: Conversions API, Measurement Pixel, Custom Audiences, Targeting, değişiklik kaydı, Ads Manager ülke listesi
• KVKK: 2026/347 sayılı ilke kararı duyurusu, 6698 sayılı Kanun; Resmî Gazete: yurt dışına aktarım yönetmeliği
• Teknik: Unicode SpecialCasing, MDN, Microsoft Learn, PHP strtolower; hazır altyapılar: ikas, Shopify
• İkincil kaynaklar: PPC Land, 27 Ekim 2026, PPC Land, 27 Nisan 2026, Stape, 22 Ekim 2026, MetricMaven, 19 Ekim 2026

Sıkça Sorulan Sorular (S.S.S.)