Meta Pixel ve Dönüşüm API’si kurulumu: Adım adım doğru ölçüm

Meta reklamlarında bütçenin verimli harcanması, sistemin kimin dönüşüm yaptığını doğru öğrenmesine bağlıdır. Meta pixel kurulumu bu öğrenmenin ilk adımıdır; ama tarayıcı engelleyicileri, çerez onayı, sayfa yüklenme hataları ve uygulama içi tarayıcılar yüzünden yalnızca Pixel’e dayanan ölçüm her geçen yıl daha fazla veri kaçırıyor. Meta’nın bugünkü önerisi açık: Pixel’i Dönüşüm API’si ile birlikte kullanmak ve aynı olayları iki kanaldan gönderip tekilleştirmek.

Biz ajans olarak devraldığımız hesapların önemli bir kısmında aynı tabloyla karşılaşıyoruz: Pixel iki kez yüklenmiş, satın alma olayı teşekkür sayfası her yenilendiğinde tekrar tetikleniyor, sunucu tarafı entegrasyon kurulmuş ama event_id gönderilmediği için her sipariş iki kez sayılıyor. Kampanya raporu güzel görünüyor, muhasebe ise başka bir şey söylüyor. Bu yazıda bu hataları baştan önleyen bir kurulumu adım adım anlatıyoruz: işletme portföyü yapısı, olay planı, Pixel kodu, Dönüşüm API’si isteği, tekilleştirme, izin yönetimi, test ve bakım.

Yazı teknik ayrıntı içeriyor ama yalnızca geliştiricilere yönelik değil. Pazarlama yöneticisinin ekibine ne isteyeceğini bilmesi, geliştiricinin de neden o şekilde kurduğunu anlaması için hazırladık. Platform kuralları sık değişir; aşağıdaki bilgileri Ekim 2026 itibarıyla Meta’nın resmî dokümanlarından doğruladık ve kaynaklarını yazının sonunda listeledik.

Önce temel: Meta Pixel ve Dönüşüm API’si ne yapar?

Meta Pixel, sitenize eklenen bir JavaScript kodudur. Ziyaretçi bir sayfayı görüntülediğinde, sepete ürün eklediğinde ya da form gönderdiğinde tarayıcıdan Meta’ya bir olay (event) gönderir. Bu olaylar üç iş için kullanılır: kampanyaların hangi sonuca göre optimize edileceğini belirlemek, reklam sonuçlarını raporlamak ve site ziyaretçilerinden özel hedef kitleler oluşturmak.

Dönüşüm API’si (Conversions API, kısaca CAPI) ise aynı olayları sizin sunucunuzdan, doğrudan Meta’nın Graph API’sine gönderir. Meta’nın en iyi uygulamalar sayfası, Dönüşüm API’sinin ağ sorunları ya da sayfa yükleme hataları nedeniyle Pixel’in kaçırabileceği olayları yakalayabildiğini ve Pixel’in hiç göremeyeceği çevrim dışı olayları da taşıyabildiğini belirtir; bu yüzden iki aracın birlikte, aynı olayları paylaşacak şekilde kullanılmasını önerir (Meta for Developers: Conversions API en iyi uygulamalar).

Bu “yedekli kurulum”un mantığı basit: Tarayıcı tarafı, kullanıcının oturumuna ait zengin sinyalleri (çerezler, sayfa adresi) taşır; sunucu tarafı ise engelleyicilerden etkilenmez ve sipariş veritabanınızdaki kesin bilgiyi (gerçek tutar, sipariş durumu) gönderir. İkisini birlikte kullandığınızda aynı olay iki kez gelir; Meta bunları ortak bir kimlikle eşleştirip tek olay sayar. İşin bütün inceliği de bu eşleştirmenin doğru yapılmasındadır.

1. Adım: İşletme portföyü ve sahiplik yapısını kurun

Ölçüm projelerinde en çok zaman kaybettiren sorun teknik değil, sahiplik sorunudur. Pixel’i yıllar önce bir freelancer kendi hesabında açmış, reklam hesabı eski ajansın işletme portföyünde kalmış, alan adını kimin doğruladığı bilinmiyor… Kod yazmaya başlamadan önce şu yapıyı netleştirin:

1. İşletme portföyü markanın olsunMeta’nın eski adıyla Business Manager, bugünkü adıyla işletme portföyü (business portfolio) markanın kendi şirket hesabı altında açılmalı. Ajanslar bu portföye “iş ortağı” olarak erişim almalı; varlıklar ajansın portföyünde yaşamamalı.
2. Varlıkları tek portföyde toplayınFacebook sayfası, Instagram hesabı, reklam hesabı, Pixel / veri seti, katalog ve alan adı aynı portföyde olmalı. Dağınık varlıklar izin karmaşasına ve “bu Pixel’i bu reklam hesabında göremiyorum” sorunlarına yol açar.
3. En az iki tam yetkili yönetici atayınTek bir çalışanın kişisel profiline bağlı portföy, o kişi ayrıldığında kilitlenir. İki yöneticiyi şirket içinden seçin, ajansa ve geliştiriciye yalnızca ihtiyaç duydukları görev erişimini verin.
4. Dönüşüm API’si için sistem kullanıcısı açınSunucu entegrasyonunda kullanacağınız erişim belirtecini (access token) kişisel bir kullanıcı yerine portföydeki bir sistem kullanıcısına bağlamak, çalışan değişikliklerinde entegrasyonun kırılmasını önler. Belirteci kod deposuna değil, sunucunun gizli ortam değişkenlerine koyun.
5. Alan adını doğrulayınMeta’nın alan adı doğrulama dokümanı, DNS TXT kaydı ya da web köküne HTML dosyası yükleme yöntemlerini anlatır ve doğrulamanın alan adınız üzerindeki sahipliği ve bağlantı düzenleme yetkilerini kontrol etmenizi sağladığını belirtir (Meta for Developers: Domain verification).

Alan adı doğrulama geçmişte Toplu Olay Ölçümü (Aggregated Event Measurement, AEM) için olay yapılandırmasının ön koşuluydu. Toplu Olay Ölçümü’ne bağlı olay önceliklendirme ve yapılandırma adımları zaman içinde değişti ve Meta’nın bu konudaki yardım sayfaları dönem dönem güncelleniyor. Bu yüzden Ekim 2026 itibarıyla Etkinlik Yöneticisi’nde hesabınıza özel olarak hangi adımların istendiğini kontrol etmenizi öneriyoruz. Gereklilik değişse bile doğrulamayı yapmanız için yeterli sebep var: sahiplik, bağlantı önizlemelerinin kontrolü ve ileride çıkabilecek gereksinimlere hazır olmak.

İsimlendirme düzeni

Portföyde birden fazla marka, ülke ya da site varsa isimlendirmeyi baştan standartlaştırın. Bizim kullandığımız basit kalıp şu:

Kural tek: Bir yıl sonra hesaba bakan biri, adından varlığın ne olduğunu anlayabilmeli. Kampanya tarafındaki isimlendirmeyi Meta reklam kampanyası kurgusu yazımızda ayrıca ele alıyoruz.

2. Adım: Olay planını kodlamadan önce yazın

“Pixel’i kuralım” talebi genellikle “her şeyi ölçelim” anlamına gelir; sonuç, Etkinlik Yöneticisi’nde anlamı belirsiz onlarca özel olaydır. Bunun yerine işletmenin gerçek hedefinden geriye doğru giden kısa bir olay planı hazırlayın. Bir e-ticaret sitesi için huni genellikle ürün görüntüleme, sepete ekleme, ödemeye başlama ve satın alma adımlarından oluşur; bir hizmet işletmesi için ise sayfa görüntüleme, iletişim niyeti ve form gönderimi.

Meta’nın standart olayları bu hunileri karşılayacak şekilde tasarlanmıştır. Pixel referans dokümanına göre Purchase olayında value ve currency zorunludur; AddToCart, InitiateCheckout, Lead, ViewContent gibi olaylarda ise bu parametreler isteğe bağlıdır (Meta Pixel referansı). Standart bir olay işinizi karşılıyorsa özel olay icat etmeyin; standart olaylar optimizasyon ve raporlama tarafında daha geniş destek görür.

Örnek olarak 3 şubeli kurgusal bir diş kliniği düşünelim. Olay planı şöyle olabilir:

Bu tablonun değeri, son iki satırda ortaya çıkar. Form doldurmak ile gerçekten müşteri olmak arasındaki fark büyüktür; sunucu tarafı entegrasyon sayesinde CRM’deki “nitelikli” durumunu da Meta’ya geri besleyebilirsiniz. Bu konuyu ölçümleme ve analitik çalışmalarımızın merkezine koyuyoruz.

3. Adım: Meta pixel kurulumu, tarayıcı tarafı

Pixel’i siteye üç yoldan ekleyebilirsiniz: hazır platform entegrasyonu (ör. e-ticaret altyapınızın Meta eklentisi), Google Tag Manager gibi bir etiket yöneticisi ya da doğrudan koda ekleme. Hangisini seçerseniz seçin, aynı Pixel’in yalnızca bir kez yüklendiğinden emin olun. Hem eklentiyi açıp hem de tema dosyasına kod eklemek, en sık gördüğümüz çift sayma nedenidir.

Temel kod, sayfanın <head> bölümüne Meta’nın Etkinlik Yöneticisi’nde verdiği temel kod parçası olarak eklenir ve fbq('init', 'PIXEL_ID') ile fbq('track', 'PageView') çağrılarını içerir. Standart olayları ise ilgili anlarda tetiklersiniz. Tekilleştirme için olay çağrısına dördüncü parametre olarak eventID verilir. Meta’nın tekilleştirme dokümanındaki örnek şu biçimdedir:

fbq('track', 'Purchase', {value: 12, currency: 'USD'}, {eventID: 'EVENT_ID'});
fbq('track', 'Lead', {}, {eventID: 'EVENT_ID'});

Gerçek bir sipariş onay sayfasında bu çağrı, sunucunun ürettiği değerlerle doldurulur. Örneğin kurgusal bir sipariş için şablona şunu basarsınız:

<script>
  fbq('track', 'Purchase', {
    value: 1249.90,
    currency: 'TRY',
    content_ids: ['SKU-1042', 'SKU-2210'],
    content_type: 'product'
  }, {eventID: 'order-100457'});
</script>

Burada order-100457 değeri rastgele üretilmiş bir sayı değil, sipariş numarasından türetilmiş bir kimliktir. Aynı kimliği birazdan sunucu tarafında da kullanacağız. Teşekkür sayfasının yenilenmesi ya da kullanıcının sayfaya geri dönmesi durumunda olay yeniden tetiklense bile kimlik aynı kaldığı için Meta bunu yinelenen olay olarak ele alabilir; yine de sayfa tarafında “bu sipariş için olay zaten gönderildi” kontrolü eklemek iyi bir alışkanlıktır.

4. Adım: Dönüşüm API’si kurulum yöntemini seçin

Sunucu tarafı için tek bir doğru yol yoktur; altyapınıza ve ekibinize göre seçim yaparsınız. Meta’nın kurulum seçeneklerini karşılaştırdığı yardım sayfası dört ana yol sayar: e-ticaret platformlarının hazır entegrasyonları, Dönüşüm API’si Gateway (kendi bulut sunucunuzda çalışan, kod gerektirmeyen bir çözüm), diğer iş ortağı entegrasyonları (ör. Google Tag Manager sunucu tarafı) ve doğrudan entegrasyon (Meta İşletme Yardım Merkezi: Dönüşüm API’si kurulum seçeneklerini karşılaştırın).

Özel yazılım geliştirdiğimiz projelerde çoğunlukla doğrudan entegrasyonu tercih ediyoruz; çünkü asıl değer, sipariş ya da CRM durumu değiştiğinde olayı gönderebilmekte. Hazır altyapı kullanan bir mağaza için ise platform entegrasyonu genellikle yeterli ve daha az bakım ister.

5. Adım: Sunucu isteğini doğru kurun

Doğrudan entegrasyonda olaylar https://graph.facebook.com/{API_VERSION}/{PIXEL_ID}/events adresine, erişim belirteci ile POST edilir. Meta’nın dokümanı tek istekte en fazla 1.000 olay gönderilebileceğini belirtir ve olayların gerçekleştiği anda, mümkün olduğunca gerçek zamana yakın gönderilmesini önerir (Meta for Developers: Using the API). Sürüm numarası düzenli olarak yükseldiği için kodunuzda sürümü yapılandırma değişkeni olarak tutun.

Yukarıdaki siparişin sunucu tarafındaki karşılığı şöyle görünür (değerler örnektir, hash’ler kısaltılmıştır):

{
  "data": [{
    "event_name": "Purchase",
    "event_time": 1793520000,
    "event_id": "order-100457",
    "action_source": "website",
    "event_source_url": "https://www.ornekmarka.com.tr/siparis/tamamlandi",
    "user_data": {
      "em": ["7b17fb0bd1…"],
      "ph": ["a3f1c9e2d4…"],
      "external_id": ["5e884898da…"],
      "client_ip_address": "203.0.113.24",
      "client_user_agent": "Mozilla/5.0 (…)",
      "fbp": "fb.1.1793400000000.1098115397",
      "fbc": "fb.1.1793410000000.AbCdEf…"
    },
    "custom_data": {
      "currency": "TRY",
      "value": 1249.90,
      "content_ids": ["SKU-1042", "SKU-2210"],
      "content_type": "product"
    }
  }]
}

Zorunlu ve kritik alanlar

Sunucu olayı parametreleri dokümanına göre event_name, event_time ve action_source zorunludur. event_time, GMT saat diliminde Unix zaman damgasıdır ve olayı Meta’ya gönderdiğiniz andan en fazla 7 gün öncesine ait olabilir; 7 günden eski bir olay tüm isteğin reddedilmesine yol açar. Web sitesi olaylarında event_source_url gereklidir ve doğrulanmış alan adınızla eşleşmelidir. event_id teknik olarak isteğe bağlı görünse de tekilleştirme için önerilir (Meta for Developers: Server event parameters).

action_source alanı olayın nerede gerçekleştiğini söyler: website, app, phone_call, chat, physical_store, system_generated, business_messaging, email ya da other. Meta, bu değerin doğru olduğunu beyan ettiğinizi kabul eder; en iyi uygulamalar sayfası da çevrim dışı olaylar için website dışında bir değer seçmenizi ister. Kliniğe gelen hastayı “website” olarak işaretlemek, ölçümü yanıltır.

Müşteri bilgisi: neyi hash’lemeli, neyi hash’lememeli?

Sunucu olaylarının değeri, Meta’nın olayı bir kişiyle eşleştirebilmesine bağlıdır. Meta’nın müşteri bilgisi parametreleri dokümanı şu ayrımı yapar (Meta for Developers: Customer information parameters):

• SHA-256 ile hash’lenir: e-posta (em), telefon (ph), ad (fn), soyad (ln), doğum tarihi, cinsiyet, şehir, il, posta kodu, ülke. external_id için hash önerilir.
• Hash’lenmez: client_ip_address (asla hash’lenmemeli), client_user_agent, fbc ve fbp çerez değerleri.
• E-posta normalizasyonu: baştaki ve sondaki boşlukları silin, tamamını küçük harfe çevirin, sonra hash’leyin.
• Telefon normalizasyonu: sembolleri, harfleri ve baştaki sıfırları kaldırın, ülke kodunu ekleyin (Türkiye için 90), sonra hash’leyin. Örneğin “0 (532) 000 00 00” biçimindeki bir numara “905320000000” olarak normalize edilir.

Normalizasyon atlanırsa hash farklı çıkar ve eşleşme gerçekleşmez; bu yüzden normalizasyon fonksiyonunu tek bir yerde yazıp test edin. Türkçe karakterli e-posta adresleri nadir olsa da küçük harfe çevirme işleminde “İ/i” dönüşümüne dikkat edin; dil ayarına bağlı küçük harf fonksiyonları yerine standart bir dönüşüm kullanın.

fbp ve fbc değerleri tarayıcıdaki _fbp ve _fbc çerezlerinden okunur. Bunları sunucuya taşımanın en kolay yolu, form ya da sipariş kaydı sırasında çerez değerlerini de sunucuya göndermek ve siparişle birlikte saklamaktır. Böylece sipariş saatler sonra “ödendi” durumuna geçtiğinde bile olayı doğru tarayıcı oturumuyla ilişkilendirebilirsiniz.

6. Adım: event_id ile tekilleştirme

Yedekli kurulumun kalbi tekilleştirmedir. Meta’nın tekilleştirme dokümanı kuralı net koyar: Tarayıcıdaki eventID ile sunucudaki event_id eşleşmeli, olay adları da aynı olmalıdır. Aynı Pixel kimliği için aynı anahtar kombinasyonu 48 saat içinde gelirse sonraki olaylar atılır; olaylar anlamlı biçimde farklı değilse genellikle önce gelen tutulur. Olaylar, ilk olayın alınmasından itibaren 48 saat içinde gelirse tekilleştirilir (Meta for Developers: Deduplicate Pixel and server events).

Dokümanda ikinci bir yöntem de var: fbp ve/veya external_id değerlerini iki kanalda tutarlı göndermek. Ancak bu yöntem genellikle yalnızca tarayıcı olayı önce, sunucu olayı sonra geldiğinde çalışır ve yalnızca tek kaynaktan (yalnızca tarayıcı ya da yalnızca sunucu) gelen olayları tekilleştirmez. Bu kısıtlar nedeniyle Meta, olay kimliği yöntemini önerir. Biz de her iki yöntemin parametrelerini birlikte göndermeyi, ama tekilleştirmeyi event_id üzerine kurmayı tercih ediyoruz.

Kimliği nerede üretmeli?

Tekilleştirmenin en sık bozulduğu yer, kimliğin iki tarafta ayrı ayrı üretilmesidir. Doğru tasarım şudur:

• Satın alma: order-{sipariş_no} gibi kalıcı ve benzersiz bir kimlik kullanın.
• Form: form kaydı oluştuğunda veritabanı kimliğinden türetin (lead-{kayıt_id}).
• Sepete ekleme gibi sık olaylar: tarayıcıda UUID üretip hem Pixel’e verin hem de AJAX isteğiyle sunucuya taşıyın.
• PageView: sunucudan da gönderiyorsanız sayfa isteği başına bir kimlik üretip şablona basın; göndermiyorsanız tekilleştirmeye gerek yoktur.

Meta’nın dokümanı, aynı olayı iki kanaldan göndermiyorsanız o olay için tekilleştirmeye ihtiyaç olmadığını da belirtir. Örneğin yalnızca CRM’den gönderdiğiniz “nitelikli müşteri” olayı için event_id yine faydalıdır (yeniden denemelerde çift kaydı önler) ama tarayıcı karşılığı aramanıza gerek yoktur.

Özetle (Meta’nın tekilleştirme dokümanının özeti): Aynı olay iki kaynaktan geliyorsa, olay adı ve olay kimliği iki tarafta birebir aynı olmalı ve ikinci olay ilkinden sonraki 48 saat içinde ulaşmalıdır.

7. Adım: Çerez onayı ve yasal çerçeve

Türkiye’de kişisel verilerin işlenmesi KVKK kapsamındadır; reklam ve ölçüm amaçlı çerezler için Kişisel Verileri Koruma Kurumu’nun çerez uygulamalarına ilişkin rehberini ve hukuk danışmanınızın görüşünü esas alın (kvkk.gov.tr). Teknik tarafta yapmanız gereken, kullanıcının tercihini Pixel’e doğru aktarmaktır. Meta’nın Pixel dokümanı bunun için bir izin API’si sunar: fbq('consent', 'revoke') çağrısı Pixel gönderimlerini durdurur ve her sayfada, Pixel başlatılmadan önce çağrılmalıdır; kullanıcı onay verdiğinde fbq('consent', 'grant') ile gönderim devam eder (Meta for Developers: Pixel consent).

<script>
  fbq('consent', 'revoke');      // varsayılan: onay yok
  fbq('init', 'PIXEL_ID');
  fbq('track', 'PageView');
  // Kullanıcı "Kabul et" dediğinde çerez yönetim aracınız şunu çağırır:
  // fbq('consent', 'grant');
</script>

Sunucu tarafında da aynı tercihi uygulamanız gerekir. Pixel’i durdurup sunucudan aynı kişinin verisini göndermeye devam etmek, onay mekanizmasını anlamsız kılar. Bizim önerimiz, onay durumunu oturum ya da sipariş kaydıyla birlikte saklamak ve Dönüşüm API’si gönderiminden önce bu alana bakmaktır. Yasal yorumu hukuk ekibinize bırakın; teknik tasarım ise onayın iki kanalda tutarlı uygulanmasını garanti etmeli. Google tarafındaki karşılığı için Consent Mode v2 ve çerez yönetimi yazımıza bakabilirsiniz.

8. Adım: Test edin, sonra canlıya alın

Kurulumu canlıya almadan önce Etkinlik Yöneticisi’ndeki Test Olayları (Test Events) aracını kullanın. Dokümana göre bu aracın verdiği test_event_code değeri, istek gövdesinde data ile aynı seviyede gönderilir; yalnızca test içindir ve canlı gönderimde kaldırılmalıdır. Test kodlu olaylar atılmaz, Etkinlik Yöneticisi’ne akar. En iyi uygulamalar sayfası, test olaylarında kendi gerçek müşteri bilginizi kullanmanızı, çünkü eşleşmeyen test olaylarının atılabileceğini belirtir.

Bizim test planımız şu sırayı izler:

1. Tarayıcı kontrolüMeta Pixel Helper tarayıcı eklentisi ve tarayıcının ağ sekmesiyle Pixel’in tek kez yüklendiğini, olayların doğru parametrelerle gittiğini görün.
2. Sunucu kontrolüTest Olayları ekranında sunucu olaylarının geldiğini, event_source_url ve action_source değerlerinin doğru olduğunu doğrulayın.
3. Tekilleştirme kontrolüAynı test siparişi için tarayıcı ve sunucu olaylarının tek olay olarak işlendiğini, tekilleştirme durumunun ekranda göründüğünü kontrol edin.
4. Onay senaryolarıÇerezleri reddeden ve kabul eden iki ayrı oturumla test yapın; reddedilen oturumda olay gitmemeli.
5. Uç durumlarTeşekkür sayfasını yenileme, ödeme hatası, iptal edilen sipariş ve geri tuşu senaryolarını deneyin.
6. Canlıya almatest_event_code’u kaldırın, ilk günlerde Etkinlik Yöneticisi’ndeki olay sayılarını sipariş veritabanıyla karşılaştırın.

Olay eşleşme kalitesi

Etkinlik Yöneticisi, web olayları için 10 üzerinden bir Olay Eşleşme Kalitesi (Event Match Quality) puanı gösterir. Meta’nın en iyi uygulamalar sayfası, yalnızca eşleşen olayların ilişkilendirme ve reklam yayını optimizasyonu için kullanılabileceğini ve e-posta, IP adresi, ad, telefon gibi müşteri bilgisi parametrelerinin eşleşmeyi iyileştirdiğini belirtir. Puan düşükse önce şu üç şeye bakın: fbp/fbc sunucuya taşınıyor mu, e-posta ve telefon doğru normalize ediliyor mu, IP ve tarayıcı bilgisi gerçek kullanıcıya mı ait (sunucunuzun ya da yük dengeleyicinin IP’sine değil).

9. Adım: Bakım, izleme ve sık yapılan hatalar

Ölçüm, bir kez kurulup unutulacak bir iş değildir. Tema güncellemesi, ödeme altyapısı değişikliği, yeni bir çerez aracı ya da API sürüm yükseltmesi kurulumu sessizce bozabilir. Bu yüzden kurulumun yanına küçük bir izleme düzeni ekliyoruz:

• Haftalık: Etkinlik Yöneticisi’ndeki Purchase / Lead sayısı ile sipariş / CRM kayıtlarını karşılaştırın; sapma belirgin şekilde artarsa inceleyin.
• Her gönderimde: API yanıtını loglayın; hata dönen olayları kuyruğa alıp sınırlı sayıda yeniden deneyin.
• Her sürüm çıkışında: teşekkür sayfasında Pixel ve eventID çıktısını otomatik testle kontrol edin.
• Üç ayda bir: Graph API sürümünü ve Meta’nın değişiklik günlüğünü kontrol edin, erişim belirtecinin yetkilerini gözden geçirin.
• Etkinlik Yöneticisi’ndeki tanılama (diagnostics) uyarılarını boş bırakmayın.

En sık gördüğümüz on hata

Ölçüm kurulduktan sonra raporların nasıl okunacağı ayrı bir konu: Meta’nın raporladığı dönüşümler ile GA4 ve CRM verisi hiçbir zaman birebir tutmaz, çünkü ilişkilendirme modelleri farklıdır. Bu farkı nasıl yorumladığımızı reklam ölçümü, GA4, ROAS ve CPA yazımızda anlatıyoruz.

Avri olarak nasıl çalışıyoruz?

Meta ölçüm projelerine kodla değil, bir “ölçüm sözleşmesi” ile başlıyoruz: hangi olayın hangi iş anlamına geldiği, hangi kanaldan gönderileceği, kimliğin nerede üretileceği ve onayın nasıl uygulanacağı tek sayfalık bir dokümanda yazılı oluyor. Ardından mevcut kurulumu denetleyip (çift yükleme, eksik parametre, sahiplik sorunları) temizliyor, Pixel ve Dönüşüm API’sini birlikte kuruyor, test planını müşterinin ekibiyle birlikte yürütüyoruz.

Özel yazılım tarafındaki deneyimimiz sayesinde CRM ve randevu sistemlerinden gelen “nitelikli müşteri” sinyallerini de Meta’ya geri besleyebiliyoruz. Kampanya yönetimi tarafında ise bu altyapının üzerine performans reklamları hizmetimizle kampanya, kitle ve kreatif yapısını kuruyoruz. Amacımız, raporla muhasebenin aynı hikâyeyi anlatması.

Sık sorulan sorular

Doğru bir Meta pixel kurulumu; tek yüklenen bir Pixel, iş anlamı net bir olay planı, aynı olayları sunucudan da gönderen bir Dönüşüm API’si entegrasyonu, ortak event_id ile tekilleştirme, iki kanalda tutarlı uygulanan çerez onayı ve düzenli bir test-izleme rutini demektir. Bu temeli bir kez sağlam kurduğunuzda kampanya kararlarınızı tahmine değil, güvenilir veriye dayandırırsınız.

Kaynaklar

• Meta for Developers: Deduplicate Pixel and Server Events
• Meta for Developers: Server Event Parameters
• Meta for Developers: Customer Information Parameters
• Meta for Developers: Conversions API – Using the API
• Meta for Developers: Conversions API Best Practices
• Meta for Developers: Meta Pixel Reference
• Meta for Developers: Domain Verification
• Meta İşletme Yardım Merkezi: Dönüşüm API’si kurulum seçeneklerini karşılaştırın