Form gönderimini doğru ölçmek için ne gerekir?
Buton tıklamasını talep saymayın. Başarılı API yanıtı, generate_lead, izin ve form gizliliğini birlikte kontrol edin.

“Mesajı gönder” butonuna tıklanması, mesajın size ulaştığını göstermez. Alan doğrulaması başarısız olabilir, sunucu hata verebilir veya e-posta aktarımı tamamlanmayabilir. Talep olayını bu aşamaların sonuna bağlamak gerekir.
Standart iletişim formunda başarıyı sayın; kişisel bilgiyi ziyaret ölçümüne taşımayın. Yeni CRM veya özel backend kurmak başlangıç şartı değildir.
Başarının tanımını yazın
Bir formun başarısı uygulamasına bağlıdır. Bizim bu sitedeki formumuzda sunucu alanları kontrol eder ve mevcut Google Workspace üzerinden sabit marka adresine iletimi dener. Başarılı API yanıtından sonra ziyaretçiye başarı durumu gösterilir.
Başarılı sunucu yanıtı bile alıcının gelen kutusu veya spam konumunu tek başına kanıtlamaz. Gerçek e-posta teslimatı ayrı kontrol edilir. “API başarılı” ve “mesaj gelen kutusunda görüldü” raporda farklı kanıtlardır.
| Durum | Talep olayı? | Ziyaretçinin gördüğü |
|---|---|---|
| Alanlar eksik | Hayır | Eksik alan uyarısı |
| API / mail aktarımı hata verdi | Hayır | Tekrar deneme veya doğrudan e-posta yolu |
| API başarılı yanıt verdi | İzin varsa generate_lead | Gönderim başarı durumu |
| Sayfayı yeniledi | Yeni talep yok | Normal sayfa ziyareti |
GA4 ve reklam platformu farklı sorulara cevap verir
GA4 ziyaret ve işaretlediğiniz olayları raporlar. OpenAI reklam dönüşüm ölçümü ise bağlı veri kaynağı, kampanyanın olay tanımı, ilişkilendirme penceresi ve uygun tıklama sinyallerini kullanır. Birinin toplamı diğerinin toplamına eşit olmak zorunda değildir.
Bir GA4 etiketini kurmak OpenAI Pixel’in kurulduğu anlamına gelmez. Aynı şekilde kampanya bağlantısına UTM eklemek, reklam platformuna dönüşüm olayı göndermek değildir.
OpenAI, tıklama bağlantısına oppref adıyla bir referans ekleyebilir. Reklam ölçümü için bu referansın gerekli akışlarda korunması gerekir. Ancak genel ziyaret ölçümünde her URL parametresini taşımak doğru değildir; analitik URL’sini ayrı temizleyin.
Form içeriğini olay parametresine koymayın
Talep olayında form kimliği gibi genel bir etiket yeterli olabilir. Ad, e-posta, telefon, mesaj, hizmetle ilgili özel ayrıntı veya araçlara girilen tutarları GA4, Vercel Analytics veya oturum kaydına göndermeyin.
Clarity kullanıyorsanız form alanlarını maskeleyin ve izne bağlı yükleyin. Maskeleme, göndermek istediğiniz kişisel veriyi “zararsız” hale getirme gerekçesi değildir. En basit korunma, bu veriyi analitik olaylara hiç eklememektir.
Başlangıç testi yerelde yapılabilir
Yerel form testinde mail göndericisini mock ile değiştirin. Geçersiz alan, sunucu hatası ve başarılı yanıt senaryolarını çalıştırın. Hatada metin korunuyor mu, başarıda tek olay üretiliyor mu, yeniden sayfa açınca talep olayı tekrar etmiyor mu kontrol edin.
İzin testinde üç durum gerekir: ret, kabul ve sonradan geri alma. Kabul sonrası doğru site ölçüm kimliği kullanılmalı; ret sonrası yeni optional takip başlamamalı. Kampanya etiketi korunurken hassas URL parametreleri çıkarılmalı.
Canlı deneme gerçek veri üretir ve e-posta gönderir. Böyle bir testin yetkisini ayrıca netleştirin; yalnız GET ile API hazır durumunu okumak teslimat testi sayılmaz.
Standart ölçümün sınırını bilin
İlk form gönderimini saymak standart başlangıçtır. Nitelik, gerçekleşen görüşme, teklif kabulü veya offline satışın otomatik aktarımı başka sistemleri bağlamayı gerektirebilir. Özel CAPI, kapsamlı data layer veya CRM senkronizasyonunu küçük bir form ayarı gibi tekliflemeyin.
İlk raporu doğru okumak için uygun talep tanımını ve kampanya bağlantılarının düzenini aynı hazırlıkta belirleyin.
Kaynaklar ve kontrol tarihi
Kaynaklar 12.10.2026 tarihinde kontrol edildi. Platform özellikleri değişebileceği için yayından önce hesabınızdaki güncel koşulları doğrulayın.