Meta Pixel ve Dönüşümler API’si, reklamın ardından web sitesinde gerçekleşen olaylar hakkında sinyal iletmek için kullanılan iki yoldur. Biri çoğunlukla tarayıcı tarafında, diğeri sunucu veya bir entegrasyon üzerinden çalışır. İşletme açısından temel soru “İkisini de açalım mı?” değil, hangi olayı niçin ölçeceği, aynı işlemin iki kez sayılmasını nasıl önleyeceği ve kullanıcı verisini hangi koşullarla işleyeceğidir. Teknik kurulum tek başına daha fazla satış anlamına gelmez. Bu rehber, geliştirici kodu yazmadan ölçüm kararlarını denetleyebilmeniz için hazırlanmıştır.
Ölçüm olayını bir iş adımına bağlayın
Sayfa görüntüleme, sepete ekleme, satın alma ve form gönderme aynı değer düzeyinde değildir. Ürün sayfasını açan herkes müşteri olmaz; form gönderimi de nitelikli görüşme olmayabilir. Önce reklamın ana sonucunu seçin. E-ticarette gerçekleşmiş sipariş, hizmette doğrulanmış başvuru uygun olabilir. Sonra bu sonuçların web sitesinde nerede oluştuğunu ve işletme kayıtlarında nasıl doğrulandığını haritalayın. “Dönüşüm” etiketinin hangi eylemde tetiklendiğini ekip üyeleri aynı şekilde tarif edemiyorsa raporu yorumlamak erkendir.
Örneğin telefon bağlantısına dokunma bir niyet işaretidir, tamamlanmış telefon görüşmesi değildir. Randevu formunun teşekkür sayfasına ulaşma bir başvurudur, randevuya gelme değildir. Bu ayrımları rapor sözlüğüne yazın. Ölçüm olayının adı, tetikleyicisi, sahibi ve işletme kaydındaki karşılığı belli olsun. Ardından reklam panelindeki sayıyla gerçek kayıt arasındaki farkı düzenli olarak gözden geçirin. Bu farkın varlığı otomatik olarak hata demek değildir; atıf ve kayıt kapsamları farklı olabilir.
Pixel neyi, Dönüşümler API’si neyi yapar?
Meta Pixel, siteye eklenen araçlarla ziyaretçinin web etkileşimlerine ilişkin olaylar iletebilir. Tarayıcı koşulları, izin tercihleri ve teknik engeller sinyalin iletilmesini etkileyebilir. Meta Dönüşümler API’si ise uygun olayları işletmenin sunucu veya bağlı platform akışından aktarır. İki yolun birlikte kullanılması bazı koşullarda ölçümün dayanıklılığını artırabilir; ama yanlış kurguda aynı işlemi çift raporlayabilir. Seçim, sitenin altyapısı, bakım kapasitesi ve veri yönetimiyle birlikte yapılmalıdır.
“Sunucudan gönderiyoruz, o halde kullanıcı tercihi önemli değil” düşüncesi yanlıştır. Veri kaynağı değişince işleme amacı ve yükümlülükler ortadan kalkmaz. Hukuki ve teknik ekip, çerez ve kişisel veri süreçlerini gerçek kurulumla birlikte incelemelidir. Gerekli olmayan ad, telefon, serbest metin veya sağlık bilgilerini reklam olayına taşımayın. Hassas içerikli form alanlarını ölçüm parametrelerine koymak özellikle ciddi bir risktir. Yalnızca amaç için gerekli sinyalleri ve uygun izin akışını değerlendirin.
Aynı olayın iki kez sayılmasını nasıl sorgularsınız?
Bir kişi sipariş verdiğinde tarayıcı Pixel’i ve sunucu API’si aynı siparişi ayrı olaylar olarak yollayabilir. Entegrasyonun bu iki bildirimi aynı işlem olarak eşleştirmesi gerekir. Teknik ekipten olay adı ve olay kimliği yaklaşımını, gerçek bir test siparişinin iki kanalda nasıl göründüğünü göstermesini isteyin. Hazır e-ticaret eklentisi kullanılsa bile “kuruldu” kutucuğu yeterli kanıt değildir. Platformun olay test ekranı ve sipariş kayıtları birlikte incelenmelidir. Kurulum yönteminin güncel uygulama ayrıntıları için Meta’nın geliştirici tekilleştirme belgeleri esas alınmalıdır.
| Olay | İşletmedeki karşılık | Test sorusu | Yorum riski |
|---|---|---|---|
| Sayfa görüntüleme | İçerik açıldı | Tek sayfa açılışında kaç kez tetikleniyor? | Satış sanılması |
| Form gönderme | Başvuru kaydı | Hatalı formda da olay çalışıyor mu? | Şişen lead sayısı |
| Satın alma | Onaylı sipariş | Test siparişi bir kez mi sayılıyor? | Çift kayıt veya yanlış tutar |
| İptal/iade | Net iş sonucu | Rapor dışındaki kayıt kimde? | Brüt satışın başarı sayılması |
Tek bir test işlemini izleyin
Bir deneme siparişinin tarayıcı, sunucu ve işletme kaydındaki izlerini aynı zaman aralığında karşılaştırın.
Olay kimliğini eşleştirin
İki teknik bildirim aynı işlemi temsil ediyorsa olay adı ve eşleştirme kimliğinin tutarlı olduğuna bakın.
Başarısız testte ilk inceleme
Çift sonuç görülürse önce entegrasyon kayıtlarını kontrol edin; aynı olayı farklı eklentilerin yeniden gönderip göndermediğini araştırın.
Teknik kontrolü gerçek kullanıcı yolu ile yapın
Kurulum denetiminde yalnız yönetim panelinde yeşil işaret görmek yeterli değildir. Çerez tercih ekranından başlayarak iki ayrı gerçek kullanıcı yolu deneyin: izin veren ve vermeyen kişi. Ardından ürün görüntüleme, form gönderme ya da test siparişi adımlarını izleyin. Gerektiğinde farklı tarayıcı ve mobil cihaz kullanın. Testin ne zaman, hangi hesapta, hangi site sürümünde yapıldığını kaydedin. Bir olay görünmüyorsa önce kullanıcının gerçekten son adıma ulaşıp ulaşmadığını doğrulayın.
Web sitesi yenilendiğinde, ödeme sayfası değiştiğinde veya yeni bir form eklendiğinde önceki test sonuçları geçersizleşebilir. Bu yüzden olay haritası canlı bir belge olmalı. Etiket yöneticisi, platform eklentisi ve özel kod aynı anda aynı olayı gönderiyorsa çakışma yaşanabilir. Her olayın tek teknik sahibi ve tek doğrulama yöntemi olsun. Kurulumu yapan ekip ayrıldığında işletmenin hangi bağlantıların aktif olduğunu okuyabilmesi için kısa bir devir notu hazırlayın.
Varsayımsal mağaza senaryosu
Örnek bir ev aksesuarı mağazası Meta reklamından gelen siparişleri ölçmek istiyor. Sitede Pixel, e-ticaret entegrasyonunda da Dönüşümler API’si açık. Reklam paneli bir gün 18 satın alma bildirirken sipariş sistemi 11 sipariş gösteriyor. Bu rakamlar tamamen varsayımsaldır; gerçek performans verisi değildir. Ekip ilk olarak zaman aralığı, iptaller, atıf tanımı ve test siparişlerini karşılaştırır. Sonra tek bir deneme siparişinin tarayıcı ve sunucu olaylarını inceler. Olay adları aynı, ancak eşleştirme kimlikleri uyumsuzsa teknik düzeltme ister.
Düzeltme yapıldıktan sonra aynı testi yeniden çalıştırır. Panel sayısı ile sipariş sayısının birebir eşitlenmesini otomatik başarı koşulu saymaz; farklı raporlama sınırlarını not eder. Önemli olan aynı gerçek işlemin ölçüm sisteminde beklenen biçimde temsil edilmesi ve karar için kullanılan tanımın değişmemesidir. Mağaza reklamı ölçeklemeden önce iadelerin ve yanlış tutarların rapora nasıl yansıdığını da anlar. Böylece bütçe kararı güvenilmez bir dönüşüm sayısına dayanmaz.
Veri minimizasyonunu kurulum şartı yapın
Olay parametresi seçerken “gönderebiliyoruz” ile “göndermeliyiz” ayrımını yapın. Ürün kimliği ve işlem tutarı bazı e-ticaret ölçümlerinde işlevsel olabilir; serbest form yanıtları çoğu zaman gereksizdir. Sağlık, finans veya başka hassas alanlarda reklam sistemine aktarılan veriler ayrıca değerlendirilmelidir. Denetim listesinde amaç, veri türü, aktarım noktası, saklama ve erişim sorumlusu yer alsın. İzin yönetimi aracı ile gerçek etiket davranışının eşleşmesi de test edilmelidir.
Teknik entegrasyon önerisini alırken geliştiriciden yalnız kod teslimi istemeyin. Olay sözlüğü, test ekranı görüntüleri, tekrar test tarihi, hata halinde iletişim kişisi ve kaldırma yöntemi de teslim edilsin. Bu belgeler, ileride kampanya raporunda açıklanamayan sıçramaları anlamayı kolaylaştırır. Dijital hizmetler için teklif değerlendirirken ölçüm kurulumu ile kampanya yönetiminin ayrı sorumluluklarını sorun.
Olay sözlüğünü nasıl hazırlarsınız?
Bir sayfalık olay sözlüğü kurulumun en yararlı teslimi olabilir. Her satırda olayın iş anlamı, tetiklenen ekran veya işlem, teknik kaynak, raporda kullanılacağı karar ve test yöntemi bulunur. “Lead” için yalnız buton tıklamasını mı, başarılı form gönderimini mi kastettiğinizi yazın. “Purchase” için sipariş onayının hangi sistemde oluştuğunu belirtin. Ekipler farklı sözlük kullandığında aynı rapor sayısı farklı yorumlanır. Teknik ekip değişse bile yeni kişi olayın niçin kurulduğunu anlayabilmelidir.
Sözlüğe sürüm ve tarih alanı ekleyin. Form yenilendiğinde veya ödeme sağlayıcısı değiştiğinde olayın eski tanımı çalışıyor gibi görünebilir ama artık doğru işlemi temsil etmeyebilir. Değişiklik öncesi ve sonrası test kaydını yan yana saklayın. Ürün varyantı, para birimi veya iptal gibi alanlar reklam kararını etkiliyorsa nasıl ele alındıklarını açıkça yazın. Bu belge yalnız geliştirici için değildir; pazarlama ekibi de “hangi sayıya göre bütçe değiştireceğiz?” sorusunun cevabını burada görmelidir.
Atıf ile gerçek siparişi ayırın
Reklam platformundaki dönüşüm raporu ile sipariş sistemindeki işlem sayısının farklı olması her zaman kurulum hatası anlamına gelmez. Zaman penceresi, farklı cihaz kullanımı, iptal edilen işlemler ve platformun atıf yaklaşımı fark yaratabilir. Bununla birlikte çok büyük veya ani fark teknik sorunu işaret edebilir. İyi denetim “rakamlar eşit değil” gözlemiyle bitmez; hangi kapsamların karşılaştırıldığını yazar. Aynı tarih aralığını, saat dilimini, para birimini ve test siparişlerinin durumunu kontrol edin.
Platform raporunu işletmenin finansal kayıtlarının yerine koymayın. Harcama kararında reklamın katkısını anlamaya çalışırken net sipariş, iade ve ürün katkısı işletme tarafında doğrulanır. Bir kampanya daha çok raporlanan dönüşüm getirirken gerçek yeni müşteri sayısı değişmemiş olabilir. Bu durumda ölçüm tanımını ve müşteri yolunu yeniden incelemek gerekir. Reklam paneli bir karar aracıdır; tek muhasebe kaydı değildir. Raporlamada bu sınır açıkça belirtilirse ekipler birbirine yanlış kesinlik satmaz.
Bakım planı ve erişim sorumluluğu
Ölçüm kurulduktan sonra canlı kalmasını sağlayan kişi belirlenmelidir. Sitedeki çerez aracı, tema, ödeme sayfası veya form eklentisi güncellendiğinde olaylar tekrar denenmelidir. Aylık kısa kontrol takvimi, büyük kampanya açılışından önce sürprizleri azaltır. Teknik yönetim erişimleri kişisel hesaplarda dağınık bırakılmamalı; işletmenin yetkili kişileri erişimi geri alabilmelidir. Dış destek sağlayan ekiple çalışılıyorsa hangi entegrasyonun kim tarafından kurulduğu ve kaldırılabileceği yazılı olsun.
Hata anında izlenecek sıra da basit tutulabilir: önce gerçek kullanıcı işlemi, ardından site kayıtları, sonra Meta olay test ekranı ve son olarak reklam raporu kontrol edilir. Bu sıra, rapordaki dalgalanmayı doğrudan kampanya yaratıcılarına bağlamayı önler. Sağlıkla ilgili veya kişisel ayrıntı içeren formlar varsa olay parametreleri özel olarak gözden geçirilmelidir. Formdaki serbest metni reklam sistemine aktarmadan da başarılı gönderim sayılabilir. Veri minimizasyonu, teknik kalitenin bir parçasıdır.
Olay testinde başarısız sonuç aldığınızda önce hangi bileşenin sorumlu olduğunu ayırın. Kullanıcı formu tamamlamamışsa ölçüm olayı beklenmez. Form tamamlanmış, işletme kaydına geçmiş ama tarayıcı olayı yoksa etiket tetikleme koşulu incelenir. Sunucu olayı yoksa entegrasyon kuyruğu veya bağlantı kontrol edilir. Her ikisi var ama çift sayılıyorsa tekilleştirme yaklaşımı gözden geçirilir. Bu sıralı teşhis, “reklam çalışmıyor” gibi geniş bir açıklamayla teknik sorunu gizlemez. Deneme sonuçlarının tarih ve test kimliğiyle saklanması sonraki güncellemelerde karşılaştırma sağlar.
Ajansa veya geliştiriciye sorulacak teslim soruları
Kurulum teklifinde “Pixel ve API kurulumu” yazması kapsamı anlamaya yetmez. Hangi olayların iletileceğini, testlerin hangi tarayıcı ve izin durumlarında yapılacağını, çift kayıt kontrolünün nasıl gösterileceğini ve bakım sorumluluğunu sorun. Hazır entegrasyon varsa sürümü ve olay eşleştirme davranışı açıklansın. Özel kod varsa teknik belgesi işletmenin erişebildiği yerde bulunsun. Kurulumun başka bir araca geçişte nasıl kaldırılacağı da bilinmelidir. Gereksiz karmaşıklık, küçük işletme için ölçüm yararından daha yüksek bakım yükü yaratabilir.
Rapor tesliminde yalnız ekran görüntüsü değil, bir test işleminin yolculuğunu isteyin: kullanıcı hangi adımı yaptı, olay hangi kaynaklardan gitti, tekilleştirme nasıl görüldü ve işletme kaydında ne oluştu? Bu örnek, ekiplerin aynı “dönüşüm” sözcüğünü kullanıp farklı şeyleri kastetmesini önler. Gerçek müşterinin kişisel verisini örnek dosyaya koymayın; test kaydı veya anonim teknik çıktı kullanın. Son olarak ölçümün sınırını yazın: platform atfı, gerçek kârlılığın doğrudan hesabı değildir.
Sık sorulan sorular
Pixel varsa API zorunlu mu?
Her işletme için zorunlu olduğuna dair genel bir kural yoktur. Ölçüm ihtiyacı, mevcut altyapı, veri işleme koşulları ve teknik bakım kapasitesi birlikte değerlendirilir. Önce Pixel olaylarının doğru tanımlandığından emin olmak çoğu durumda ilk adımdır.
İki araç birlikte her zaman daha çok dönüşüm mü gösterir?
Hayır. Amaç doğru olayları daha güvenilir yorumlamaktır. Hatalı çift kurulum rakamı şişirebilir. İki kanal kullanılıyorsa tekilleştirme ve gerçek kayıtlarla karşılaştırma testi gerekir.
API, izin yükümlülüğünü ortadan kaldırır mı?
Hayır. Olayın sunucudan aktarılması, veri işleme ve izin yükümlülüklerini ortadan kaldırmaz. Hangi verinin hangi koşullarda gönderilebileceği işletmenin hukuki ve teknik bağlamına göre değerlendirilmelidir.
Kurulumun çalıştığını kim doğrulamalı?
Teknik ekip olay testlerini yapar; pazarlama ekibi sonuç tanımını, işletme de sipariş veya başvuru kayıtlarını doğrular. Üç kontrolün birlikte yapılması yanlış optimizasyon kararını azaltır. Ölçüm kapsamını konuşmak için iletişime geçebilirsiniz.
