Meta CRM Dönüşüm Entegrasyonu: Nitelikli Lead Verisini Reklam Algoritmasına Geri Besleme

Meta reklam hesaplarının büyük çoğunluğunda algoritma, bir kullanıcının “dönüşüm” sayılması için yalnızca web sitesinde veya form üzerinde gerçekleşen ilk temas sinyaline bakar: form dolduruldu, WhatsApp’ta mesaj başlatıldı, arama tuşuna basıldı. Ama işletmenin gerçek anlamda önemsediği olay bambaşka bir yerde, çoğu zaman günler veya haftalar sonra gerçekleşir — CRM’de bir satış temsilcisinin lead’i “satışa dönüştü” olarak işaretlediği an. Meta’nın reklam algoritması bu ikinci, çok daha değerli sinyali hiçbir zaman görmez; çünkü CRM’deki bu bilgi Meta’nın sunucularına hiçbir zaman geri gönderilmez.

Bu kopukluk, reklam optimizasyonunun temel bir çelişkisini doğurur: algoritma “ucuz form dolduran” kullanıcı profillerini bulmakta gayet başarılıdır, ama “gerçekten satın alan” kullanıcı profillerini asla öğrenemez çünkü bu bilgi kendisine hiç ulaşmaz. Sonuç olarak reklam bütçesi, form doldurma oranı yüksek ama satışa dönüşüm oranı düşük kitlelere doğru optimize olmaya devam eder — tam da işletmenin istemediği yönde.

Bu yazı, tam olarak bu kopukluğu gidermeye odaklanır: CRM’de kayıtlı “gerçekten satışa dönüşen” lead bilgisinin, Meta’nın Offline Conversions API’si (Conversions API for CRM olarak da anılır) üzerinden reklam algoritmasına nasıl geri besleneceğini adım adım ele alır. Piksel ve Conversions API’nin temel kurulumuna (kod entegrasyonu, standart olaylar, iOS14 kısıtlamaları) burada girilmeyecek — bu konudaki temel kurulum için Meta Pixel Kurulumu ve Dönüşüm Takibi yazımıza bakabilirsiniz. Aynı şekilde, lead formunun Meta’dan CRM’e nasıl aktarılacağı (form → CRM yönündeki akış) da bu yazının kapsamı dışındadır; o konu için Meta Lead Formu CRM Entegrasyonu yazımıza bakabilirsiniz. Burada anlatılan, tam tersi yöndeki akıştır: CRM’den Meta’ya geri besleme.

1. CRM-Meta Veri Döngüsü Neden Reklam Performansını Doğrudan Etkiler?

Meta’nın reklam sunum algoritması (delivery algorithm), makine öğrenmesi tabanlı bir optimizasyon sistemidir ve kendisine hangi sinyaller beslenirse o sinyalleri maksimize etmeye çalışır. Eğer algoritmaya beslenen tek sinyal “form dolduruldu” ise, algoritma milyonlarca kullanıcı arasından “form doldurma olasılığı yüksek” profilleri bulmaya odaklanır. Bu profiller çoğu zaman düşük niyetli, meraktan tıklayan veya rakip firmalarla kıyaslama yapan kullanıcılardır — form doldururlar ama satın almazlar.

Buna karşılık, algoritmaya “bu kullanıcı sadece form doldurmadı, aynı zamanda 3 hafta sonra gerçek bir satışa dönüştü” bilgisi de beslendiğinde, sistem form doldurma davranışının ötesine geçip “satışa dönüşme olasılığı yüksek” profilleri aramaya başlar. Bu, reklam optimizasyonunda kalite sıçraması yaratan en güçlü mekanizmalardan biridir ve genellikle “yukarı huni optimizasyonundan aşağı huni optimizasyonuna geçiş” olarak adlandırılır.

Bu döngünün pratikte nasıl işlediğini üç aşamada özetleyebiliriz:

Aşama 1 — İlk temas sinyali: Kullanıcı reklama tıklar, form doldurur veya WhatsApp’ta mesaj başlatır. Bu olay piksel/CAPI ile anlık olarak Meta’ya iletilir. Bu aşamadaki veri hacimlidir ama kalite bilgisi içermez.

Aşama 2 — CRM’de nitelendirme: Satış ekibi lead’i arar, WhatsApp üzerinden görüşür, ihtiyacı değerlendirir. CRM’de lead’in durumu güncellenir: “nitelikli”, “nitelikli değil”, “randevu alındı”, “teklif gönderildi” gibi aşamalar arasında ilerler. Bu bilgi, iş süreci içinde değerlidir ama şu ana kadar Meta’ya hiç ulaşmamıştır.

Aşama 3 — Geri besleme: CRM’de lead “satışa dönüştü” (veya işletmenin tanımladığı herhangi bir yüksek değerli aşamaya ulaştı) olarak işaretlendiğinde, bu bilgi Offline Conversions API üzerinden, kullanıcıyı tanımlayan eşleştirme verileriyle (telefon, e-posta gibi karma/hash’lenmiş bilgiler) birlikte Meta’ya geri gönderilir. Meta bu veriyi orijinal reklam etkileşimiyle eşleştirir ve algoritmanın öğrenme setine dahil eder.

Bu üç aşamalı döngü kurulmadığı sürece, ne kadar iyi hedefleme yapılırsa yapılsın algoritma “kalite” kavramını hiçbir zaman öğrenemez; sadece “hacim” kavramını optimize etmeye devam eder.

2. Offline Conversions API mi, Standart Conversions API mi?

Meta’nın dönüşüm izleme altyapısında iki farklı ama akraba mekanizma vardır ve bu ikisinin karıştırılması sık karşılaşılan bir kavram hatasıdır.

Bu iki mekanizma birbirinin yerine geçmez, birbirini tamamlar. Standart CAPI, kullanıcının web sitesinde veya uygulamada ne yaptığını (form doldurdu, sayfayı görüntüledi) doğru ölçmeye odaklanır ve iOS14 sonrası tarayıcı kısıtlamalarının etkisini azaltır. Offline Conversions API ise, web sitesi dışında (telefon görüşmesi, CRM kaydı, mağaza içi satış) gerçekleşen ve doğası gereği gecikmeli olan olayları Meta’ya bildirir. Sağlık turizmi, emlak, eğitim danışmanlığı, B2B hizmetler gibi satış döngüsü günler veya haftalar süren sektörlerde Offline Conversions API, reklam optimizasyonunun en kritik parçasıdır — çünkü bu sektörlerde “gerçek dönüşüm” web sitesinde değil, telefon görüşmesinin sonunda gerçekleşir.

3. Kurulum Öncesi Hazırlık: Hangi Bilgiler Gerekli?

Offline Conversions API kurulumuna başlamadan önce aşağıdaki bileşenlerin hazır olması gerekir. Bu hazırlık adımı atlanıp doğrudan teknik entegrasyona geçildiğinde, kurulumun ortasında tıkanma yaşanması neredeyse kaçınılmazdır.

Meta Business Manager’da Offline Event Set oluşturma: Events Manager içinde “Veri Kaynakları” (Data Sources) bölümünden yeni bir “Offline Event Set” tanımlanır. Bu, CRM’den gelecek dönüşüm verilerinin toplanacağı kapsayıcıdır ve ilgili reklam hesabına bağlanmalıdır.

Sistem Kullanıcısı (System User) ve erişim belirteci: Otomatik/programatik gönderim için kişisel bir Facebook hesabına değil, Business Manager üzerinde oluşturulan bir Sistem Kullanıcısına bağlı, süresi uzun (long-lived) bir erişim belirteci kullanılmalıdır. Kişisel hesap belirteçleri süresi dolduğunda entegrasyonun sessizce durmasına yol açar.

CRM’de eşleştirme alanlarının netleştirilmesi: Gönderilecek her lead kaydında, kullanıcıyı orijinal reklam etkileşimiyle eşleştirecek en az bir kimlik bilgisi bulunmalıdır — telefon numarası, e-posta adresi, veya ideal olarak reklam tıklama kimliği (fbclid’den türetilen click ID). Bu alanların CRM’de tutarlı biçimde (aynı format, aynı ülke kodu düzeni) saklandığından emin olunmalıdır.

Dönüşüm aşamasının tanımlanması: İşletme “satışa dönüşüm” olarak neyi sayacağını net biçimde tanımlamalıdır. Bazı işletmeler için bu “sözleşme imzalandı”, bazıları için “kapora alındı”, bazıları için “randevuya gelindi” olabilir. Bu tanım netleşmeden gönderilecek veri tutarsız ve karışık olur.

KVKK / veri işleme uyumu: CRM’deki müşteri verisinin Meta’ya (hash’lenmiş biçimde de olsa) aktarılacağı, gizlilik politikasında ve aydınlatma metninde belirtilmelidir. Hassas sektörlerde (sağlık gibi) bu konuda hukuki danışmanlık alınması önerilir.

Sorumluluk paylaşımının netleştirilmesi: Kurulumun kalıcı sağlığı, tek bir kişinin değil hem pazarlama/reklam ekibinin hem de CRM’i yöneten satış operasyonu ekibinin ortak sorumluluğundadır. Pipeline aşamaları yeniden adlandırıldığında veya yeni bir alan eklendiğinde, bu değişikliğin offline conversion otomasyonunu etkileyip etkilemediğini kontrol edecek bir sorumlunun önceden belirlenmesi, ileride yaşanacak sessiz veri kesintilerinin önüne geçer. Küçük işletmelerde bu genellikle ajans veya danışman tarafında, kurumsal yapılarda ise CRM yöneticisi ile reklam hesabı yöneticisinin ortak sorumluluğunda yürütülür.

4. Adım Adım Kurulum Süreci

Adım 1: Offline Event Set’i Oluşturma ve Reklam Hesabına Bağlama

Meta Events Manager içinde “Veri Kaynaklarını Bağla” adımından “Offline” seçeneği seçilir, bir isim verilir (örneğin “CRM Satış Dönüşümleri”) ve bu event set ilgili reklam hesabına atanır. Bir işletme birden fazla reklam hesabı yönetiyorsa, her hesap için ayrı ayrı bağlama yapılması gerekebilir.

Adım 2: Eşleştirme Verisinin Standardize Edilmesi

Meta’ya gönderilecek her kayıt; telefon numarası (uluslararası format, boşluksuz), e-posta adresi (küçük harfe çevrilmiş, boşluksuz), varsa fbclid veya fbc/fbp değerleri gibi alanları içermelidir. Bu değerler Meta’nın sunucularına gönderilmeden önce SHA-256 ile hash’lenir — ham (hash’lenmemiş) kişisel veri hiçbir zaman doğrudan iletilmemelidir. Meta’nın resmi SDK’ları ve çoğu entegrasyon aracı bu hash’lemeyi otomatik yapar, ancak özel (custom) bir entegrasyon kuruluyorsa bu adımın kod içinde doğru uygulandığından mutlaka emin olunmalıdır.

Adım 3: CRM’de Tetikleyici Olayın Tanımlanması

CRM içinde, lead’in durumu “satışa dönüştü” (veya tanımlanan hedef aşama) olarak değiştirildiğinde bir otomasyon tetiklenecek şekilde ayarlanır. Bu tetikleyici, kullanılan CRM’in yerleşik otomasyon motoru (workflow/pipeline automation), bir webhook veya Zapier/Make gibi bir ara katman üzerinden kurulabilir. Kritik nokta, bu tetiklemenin lead durumunun değiştiği anda (veya günlük toplu bir iş olarak) güvenilir biçimde çalışmasıdır.

Adım 4: Veri Gönderiminin Test Edilmesi

Canlıya almadan önce Meta Events Manager’daki “Test Events” veya offline event set’in kendi doğrulama arayüzü kullanılarak birkaç test kaydı gönderilir. Gönderilen kayıtların Meta tarafında “eşleşme oranı” (match rate) izlenir — bu oran, gönderilen kaç kaydın Meta’daki bir kullanıcı profiliyle başarıyla eşleştiğini gösterir. Düşük eşleşme oranı (örneğin yüzde 20’nin altı), eşleştirme verilerinin (telefon/e-posta formatı) hatalı olduğuna işaret eder ve kurulumun canlıya alınmadan önce düzeltilmesi gerekir.

Adım 5: Toplu (Batch) veya Anlık Gönderim Kararı

İki gönderim modeli mevcuttur: anlık (her lead durumu değiştiğinde tek tek gönderim) veya toplu (günde bir kez, örneğin gece yarısı, o gün biriken tüm dönüşümlerin tek seferde gönderilmesi). Düşük-orta hacimli işletmeler için günlük toplu gönderim hem daha az teknik bakım gerektirir hem de Meta’nın önerdiği bir yaklaşımdır. Yüksek hacimli, çok sayıda satış temsilcisinin eş zamanlı çalıştığı işletmelerde anlık gönderim, algoritmanın öğrenme hızını artırdığı için tercih edilebilir.

Adım 6: Eşleşme Oranı ve Öğrenme Etkisinin İzlenmesi

Kurulum canlıya alındıktan sonra ilk 2-4 hafta boyunca Events Manager’daki eşleşme oranı ve ilgili kampanyalardaki optimizasyon olayı sayısı düzenli izlenmelidir. Algoritmanın yeni sinyale göre davranışını gözle görülür biçimde ayarlaması genellikle birkaç hafta, yeterli örnek hacme ulaşana kadar sürer; bu süre, sektöre ve aylık dönüşüm hacmine göre değişir.

5. Kommo ile Meta Entegrasyonu: Özel Bir CRM Örneği

Kommo (eski adıyla amoCRM), özellikle WhatsApp üzerinden yoğun satış yapan işletmeler arasında Türkiye’de yaygın kullanılan bir CRM’dir ve Meta ile entegrasyon açısından iki farklı yaklaşım sunar.

Yerleşik entegrasyon üzerinden: Kommo’nun kendi pazar yerinde (marketplace) bazı üçüncü taraf uygulamalar, pipeline aşama değişikliklerini doğrudan Meta Offline Conversions API’sine bağlayacak şekilde yapılandırılabilir. Bu yaklaşım kod yazmadan kurulabilir ama esneklik açısından sınırlıdır — genellikle sabit bir aşama eşlemesi (örneğin “Kazanıldı” aşaması = satış dönüşümü) sunar.

Webhook + otomasyon platformu üzerinden: Kommo’nun her pipeline aşama değişikliğinde tetiklenen webhook altyapısı, Make veya n8n gibi bir otomasyon platformuna bağlanır. Bu platform, gelen webhook verisini alır, gerekli alanları (telefon, e-posta) hash’ler ve Meta’nın Offline Conversions API uç noktasına doğru formatta gönderir. Bu yaklaşım daha fazla kurulum emeği gerektirir ama hangi aşamaların hangi Meta olaylarına karşılık geleceğini (örneğin “Teklif Gönderildi” = bir olay, “Kazanıldı” = başka bir olay, farklı değerlerle) tam esneklikle tanımlamayı sağlar.

Kommo özelinde dikkat edilmesi gereken bir nokta, pipeline aşama adlarının işletmeden işletmeye özelleştirilmiş olmasıdır — bu nedenle otomasyon kurulumunda hangi aşama adının hangi Meta olayına eşleneceği net biçimde belgelenmeli ve pipeline yapısı değiştiğinde bu eşleme güncellenmelidir. Diğer CRM’ler (HubSpot, Pipedrive, Zoho gibi) için de aynı mantık geçerlidir; değişen sadece webhook/API’nin teknik detaylarıdır, kavramsal akış aynıdır.

6. WhatsApp Üzerinden Gerçekleşen Dönüşümlerin Takibi

Türkiye’deki pek çok işletme için satış sürecinin büyük kısmı, form doldurmanın ardından WhatsApp üzerinden devam eder: kullanıcı “Click to WhatsApp” reklamına tıklar, mesajlaşma başlar, birkaç gün içinde WhatsApp üzerinden randevu veya satış gerçekleşir. Bu süreç, standart web piksel/CAPI kurulumunun görüş alanı dışında kalır çünkü konuşmanın tamamı WhatsApp uygulaması içinde geçer.

Bu dönüşümlerin Meta’ya geri beslenmesi için iki tamamlayıcı yol vardır:

WhatsApp Business Platform (Cloud API) üzerinden konuşma sinyalleri: İşletme WhatsApp Business Platform’u kullanıyorsa, gelen konuşmanın kaynağındaki click ID (ctwa_clid) bilgisi yakalanabilir ve bu ID, konuşmanın sonunda CRM’de kaydedilen satış sonucuyla eşleştirilerek Meta’ya offline dönüşüm olarak bildirilebilir. Bu, WhatsApp üzerinden gerçekleşen dönüşümlerin eşleştirme kalitesini önemli ölçüde artırır çünkü telefon numarası yerine doğrudan reklam tıklama kimliği kullanılır.

CRM’de WhatsApp konuşmasının kayıt altına alınması: WhatsApp konuşmaları bir CRM’e (Kommo gibi WhatsApp entegrasyonu güçlü olan araçlar dahil) bağlıysa, konuşmanın hangi lead kaydına ait olduğu ve bu lead’in satışa dönüşüp dönüşmediği CRM içinde izlenir. Buradan sonrası, yukarıda anlatılan standart offline conversion akışıyla aynıdır — CRM’deki dönüşüm bilgisi, telefon numarası eşleştirmesiyle Meta’ya gönderilir.

Pratikte en yüksek eşleşme oranı, ctwa_clid tabanlı yaklaşımla elde edilir çünkü bu yöntem kullanıcının reklamla olan doğrudan bağlantısını korur. Telefon numarası tabanlı eşleştirme de çalışır ama Meta’nın kullanıcı profiliyle telefon numarasının örtüşüp örtüşmediğine bağlı olduğundan eşleşme oranı genellikle daha düşüktür.

7. Kurulum Yöntemlerinin Karşılaştırması

CSV tabanlı manuel yükleme, Meta Events Manager arayüzünden doğrudan yapılabilen ve hiç kod gerektirmeyen bir seçenektir; ancak bu yöntem otomasyon içermediği için haftalık/aylık manuel bir iş yükü yaratır ve algoritmanın öğrenme hızını düşürür. Küçük işletmeler için kurulumun ilk test aşamasında (otomasyon henüz kurulmadan doğru veri formatını doğrulamak için) kullanılabilir, ancak kalıcı çözüm olarak önerilmez.

8. Veri Kalitesi ve Eşleşme Oranını Yükseltmenin Yolları

Offline Conversions API kurulumunun başarısı, gönderilen verinin hacminden çok eşleşme kalitesinden geçer. Düşük kaliteli veri, algoritmayı yanlış yönlendirebilir veya hiç etki yaratmayabilir.

Birden fazla eşleştirme parametresi gönderin. Sadece telefon numarası göndermek yerine, mevcut olduğunda e-posta, ad-soyad, şehir bilgisi ve varsa fbclid/fbc değerini birlikte göndermek eşleşme olasılığını belirgin biçimde artırır. Meta, birden fazla parametreyi olasılıksal olarak birleştirerek daha güvenilir bir eşleşme kurar.

Telefon numarası formatını standardize edin. CRM’de bazı kayıtlar “0532…” bazıları “+90532…” bazıları boşluklu formatta tutuluyorsa, hash’leme öncesi bu formatların tek bir standarda (E.164 uluslararası format) normalize edilmesi gerekir; aksi halde aynı numara farklı hash değerleri üretir ve eşleşmez.

Olay zaman damgasını doğru gönderin. Offline Conversions API, olayın gerçekleştiği tarihi (dönüşümün CRM’e işlendiği tarih değil, gerçek satış tarihi) talep eder. Bu tarih yanlış gönderildiğinde Meta’nın atıf penceresiyle (attribution window) uyumsuzluk oluşabilir ve dönüşüm orijinal reklam etkileşimiyle eşleştirilemeyebilir.

Düşük hacimli ama yüksek değerli olaylarda değer (value) parametresini de gönderin. Sadece “dönüşüm oldu” bilgisi değil, dönüşümün parasal değeri de gönderildiğinde, Meta’nın değer bazlı optimizasyon (value optimization) özelliklerinden faydalanmak mümkün hale gelir; bu, sadece “kaç kişi satın aldı” değil “hangi profiller daha yüksek değerli satış yapıyor” sorusuna da algoritmanın cevap üretmesini sağlar.

Düzenli aralıklarla eşleşme oranını denetleyin. CRM’de alan yapısı değiştiğinde (örneğin yeni bir form alanı eklendiğinde veya telefon alanı yeniden adlandırıldığında) otomasyon sessizce bozulabilir. Aylık bazda birkaç test kaydı gönderip Events Manager’da göründüğünü doğrulamak, sorunun büyümeden fark edilmesini sağlar.

9. Kurulum Sonrası Ölçüm: Hangi Metriklere Bakılmalı?

Offline Conversions API kurulumu canlıya alındıktan sonra, “çalışıyor mu” sorusunun cevabı tek bir sayıya değil, birkaç metriğin birlikte okunmasına dayanır. Aşağıdaki metrikler, kurulumun sağlığını ve algoritmanın gerçekten öğrenip öğrenmediğini izlemek için düzenli takip edilmelidir.

Eşleşme oranı (match rate): Events Manager’daki offline event set sayfasında görüntülenen bu oran, gönderilen kayıtların yüzde kaçının Meta’daki bir kullanıcı profiliyle eşleştiğini gösterir. Yüzde 50’nin altındaki oranlar genellikle eşleştirme verisi kalitesinde (format, eksik alan) bir sorun olduğuna işaret eder; yüzde 60-80 aralığı sağlıklı bir kurulum için makul bir hedef sayılabilir, yüzde 90 üzeri nadiren görülür ve genellikle çok güçlü eşleştirme parametreleri (fbclid gibi) kullanıldığında elde edilir.

Gönderilen olay sayısı ile CRM’deki gerçek dönüşüm sayısı karşılaştırması: Bu iki sayı arasındaki fark, otomasyonun bazı kayıtları hiç göndermediğinin (sessiz veri kaybı) en net göstergesidir. Aylık bazda CRM’deki “satışa dönüştü” olarak işaretlenen kayıt sayısı ile Meta’ya gönderilen offline event sayısı karşılaştırılmalı, aradaki fark araştırılmalıdır.

Kampanya bazında dönüşüm başına maliyetin (gecikmeli) yeniden hesaplanması: Meta Ads Manager’daki standart raporlar genellikle ilk temas olayına (form, mesaj) göre maliyet gösterir. Offline conversion verisi Meta’ya iletildikten sonra, Ads Manager’da özel bir sütun olarak bu ikinci aşama dönüşümün de kampanya bazında maliyeti izlenebilir hale gelir; bu, hangi kampanyanın/reklam setinin gerçekten satışa dönüşüm getirdiğini, hangisinin sadece ucuz form topladığını netleştirir.

Kitle/reklam seti bazında kalite dağılımı: Zaman içinde, algoritmanın hangi kitlelere daha fazla bütçe kaydırdığı izlenmelidir. Sağlıklı bir döngüde, offline dönüşüm oranı yüksek olan kitlelere doğru bütçe kayması beklenir; bu kaymanın gerçekleşip gerçekleşmediği, kurulumun etkisinin somut kanıtıdır.

Bu metriklerin haftalık bir panoda (Meta Ads Manager raporu, Google Data Studio/Looker Studio panosu veya CRM’in kendi raporlama ekranı) bir araya getirilmesi, hem teknik ekibin hem de satış/pazarlama ekibinin aynı veriye bakarak karar almasını sağlar. Bu tür bir izleme panosunun kurulması, kurulumun “bir kere yapılıp unutulan” bir proje değil, sürekli izlenen bir operasyonel süreç haline gelmesini sağlar.

10. Ölçeklenme: Birden Fazla Ürün/Hizmet veya Reklam Hesabı Varsa

Birden fazla ürün grubu, şube veya reklam hesabı yöneten işletmelerde offline conversion kurulumu tek bir event set yerine katmanlı bir yapıya ihtiyaç duyabilir. Örneğin, farklı şehirlerdeki şubeleri ayrı reklam hesaplarıyla yöneten bir zincir işletme için her reklam hesabının kendi offline event set’ine sahip olması ve CRM’deki lead kaydının hangi şubeye/hesaba ait olduğunun otomasyon içinde doğru yönlendirilmesi gerekir. Aksi halde bir şubenin dönüşüm verisi yanlışlıkla başka bir şubenin reklam hesabına gönderilir ve her iki hesabın da öğrenme kalitesi bozulur.

Benzer şekilde, birden fazla ürün/hizmet kategorisi satan işletmelerde (örneğin hem estetik hem ortodonti hizmeti veren bir klinik), her kategori için ayrı özel dönüşüm olayları tanımlamak, algoritmanın kategori bazında kaliteyi öğrenmesini sağlar. Tek bir genel “Satış” olayı altında tüm kategorileri birleştirmek, kategoriler arasındaki maliyet ve dönüşüm farklarını algoritmadan gizler.

11. Vaka Kurgusu: Bir Diş Kliniğinin CRM-Meta Döngüsü Kurması

Bir estetik diş kliniği, Meta reklamlarından aylık yaklaşık 220 form/WhatsApp lead’i alıyor, ancak bu lead’lerin yalnızca yaklaşık 30’u (yüzde 14’ü) gerçek tedaviye dönüşüyordu. Reklam hesabı yalnızca “mesaj başlatıldı” olayına göre optimize olduğu için, algoritma zamanla “mesaj başlatma olasılığı yüksek ama randevuya gelme olasılığı düşük” bir kitleye doğru kaymıştı — özellikle fiyat araştırması yapan, ciddi niyeti olmayan kullanıcı segmentleri giderek daha fazla gösterim alıyordu.

Klinik, Kommo CRM’ini kullanıyordu ve pipeline’da beş aşama tanımlıydı: “Yeni Lead”, “İletişime Geçildi”, “Randevu Planlandı”, “Muayene Yapıldı”, “Tedavi Onaylandı”. Ekip, “Tedavi Onaylandı” aşamasını Meta’ya bildirilecek hedef dönüşüm olarak belirledi ve Make üzerinden bir otomasyon kurdu: pipeline’da bir lead bu aşamaya geçtiğinde, ilgili kaydın telefon numarası ve varsa e-postası hash’lenerek Meta Offline Conversions API’sine “Tedavi Onaylandı” özel olayı olarak, tedavi tutarıyla birlikte gönderiliyordu.

İlk iki haftada eşleşme oranı yüzde 35 civarında kaldı; inceleme sonucunda telefon numaralarının bir kısmının CRM’de yerel format (“0532…”) diğer kısmının uluslararası format (“+90532…”) ile tutulduğu görüldü. Format standardize edildikten sonra eşleşme oranı yüzde 61’e çıktı. Üçüncü haftanın sonunda kampanya, algoritmanın yeni sinyale göre öğrenmeye başladığının ilk işaretlerini vermeye başladı: form/mesaj başına maliyet hafifçe artarken, aynı reklam bütçesiyle elde edilen “Tedavi Onaylandı” sayısı artış eğilimine girdi. Altı haftalık dönemin sonunda, toplam lead hacmi önceki döneme göre yaklaşık yüzde 8 azalmış olsa da, tedaviye dönüşen lead sayısı yaklaşık yüzde 35 artmıştı — algoritma artık “çok lead” yerine “doğru lead” getiren kitleye doğru kaymıştı. (Vaka temsilidir.)

12. Sık Yapılan Hatalar

1. Ham (hash’lenmemiş) kişisel veriyi doğrudan göndermeye çalışmak. Meta’nın Offline Conversions API’si, telefon ve e-posta gibi kişisel verilerin SHA-256 ile hash’lenmiş halini bekler. Hash’lenmemiş veri gönderimi hem API hatası hem de veri güvenliği ihlali riskine yol açar.

2. Kişisel hesap erişim belirteci kullanmak. Bir çalışanın kişisel Facebook hesabına bağlı belirteç, o kişi şifresini değiştirdiğinde, hesabından çıkış yaptığında veya işten ayrıldığında sessizce geçersiz hale gelir ve entegrasyon fark edilmeden durur. Sistem Kullanıcısı (System User) belirteci kullanılmalıdır.

3. Her CRM aşamasını Meta’ya göndermek. Pipeline’daki her aşama değişikliğini (“İletişime Geçildi” gibi düşük değerli aşamalar dahil) Meta’ya bildirmek, sinyali seyreltir ve algoritmanın gerçekten değerli olan dönüşümü öğrenmesini zorlaştırır. Sadece iş açısından anlamlı, yüksek değerli aşama(lar) gönderilmelidir.

4. Eşleşme oranını hiç kontrol etmemek. Kurulumun “çalıştığını” sadece veri gönderiminin hata vermemesinden anlamak yanıltıcıdır. Gönderilen kayıtların gerçekten Meta’daki kullanıcılarla eşleşip eşleşmediği (match rate) düzenli izlenmelidir; düşük eşleşme oranı kurulumun etkisiz kaldığının en net göstergesidir.

5. Telefon/e-posta formatlarını standardize etmeden göndermek. Aynı numaranın CRM’de farklı biçimlerde (boşluklu, tireli, ülke kodlu/kodsuz) tutulması, hash’leme sonucunda farklı değerler üretir ve eşleşmeyi başarısız kılar.

6. Gecikmeli dönüşümlerde atıf penceresini göz ardı etmek. Satış döngüsü Meta’nın standart atıf penceresinden (örneğin 7 gün tıklama) daha uzun süren sektörlerde, offline dönüşüm gönderilse bile Meta orijinal reklam etkileşimiyle eşleştiremeyebilir. Bu durumda kampanya ayarlarındaki atıf penceresi ve raporlama beklentileri buna göre kalibre edilmelidir.

7. Otomasyonu kurup bir daha hiç izlememek. CRM alan yapısı değiştiğinde, pipeline aşamaları yeniden adlandırıldığında veya erişim belirteci süresi dolduğunda entegrasyon sessizce durabilir. Aylık düzeyde basit bir test gönderimi ve eşleşme oranı kontrolü alışkanlık haline getirilmelidir.

8. Tüm dönüşüm değerini tek bir sabit sayıyla göndermek. Farklı büyüklükteki satışları aynı sabit değerle raporlamak, Meta’nın değer bazlı optimizasyon özelliklerinin gerçek potansiyelini kullanmasını engeller; mümkün olduğunca gerçek işlem tutarı gönderilmelidir.

CRM’de biriken “gerçekten satışa dönüşen” lead bilgisini Meta’nın reklam algoritmasına geri besleyen bir döngü kurmak, reklam bütçesinin zamanla daha kaliteli kitlelere doğru optimize olmasını sağlayan en güçlü ama en az kullanılan yöntemlerden biridir. Bu döngü kurulmadan çalıştırılan Meta kampanyalarının çoğu, uzun vadede yalnızca “en çok tıklayan” kitleyi bulmaya odaklanır; oysa işletmenin asıl istediği “en çok satın alan” kitleyi bulmaktır ve bu ikisi çoğu zaman aynı kişiler değildir. CRM-Meta geri besleme döngüsü, tam olarak bu farkı algoritmaya öğreten mekanizmadır ve bir kez doğru kurulduğunda, ek reklam bütçesi harcamadan, sadece mevcut bütçenin daha isabetli kullanılmasıyla dönüşüm kalitesini artırır. Bu kurulumun uçtan uca (piksel/CAPI temel kurulumundan CRM entegrasyonuna, offline conversion akışına kadar) doğru kurgulanmasını istiyorsanız Meta Reklam Yönetimi hizmetimiz hakkında bilgi alabilirsiniz.