Google Ads API v26 Dönüşüm Ayarı Nasıl Denetlenir?

Google Ads API v26 dönüşüm ayarı nasıl denetlenir?

Google Ads API v26'ya geçen bir ölçüm entegrasyonunda önce eski enhanced_conversions_for_leads_enabled alanını kullanan sorguları bulun. Resmî v26 sürüm notu, bu alanın kaldırıldığını ve hesap ayarını incelemek için ConversionTrackingSetting.enablement_setting alanını gösteriyor. Aynı notlarda effective_enablement_setting de birleşik ayarın etkili durumunu görmek için eklenmiş. Hangi alanın hangi hesapta okunacağını ve dönüşüm verisinin gerçekten gelip gelmediğini ayrı kontrol edin. Google Ads yardım sayfası, web ve potansiyel müşteri gelişmiş dönüşümlerinin birleşik aç/kapat ayarına alındığını açıklıyor.

Özellikle teklif formu ve satış ekibi takibi olan işletmelerde denetim iki katmanlıdır: API alan göçü ile gerçek potansiyel müşteri yaşam döngüsü. Alanın doğru okunması, form veya CRM olayının doğru eşleştiğini tek başına kanıtlamaz. Bu nedenle sürüm geçişini sorgu çıktısı, hesap yapılandırması ve anonim örnek talep üzerinden test edin.

Denetime olay sözlüğüyle başlayın

“Dönüşüm” adı altında hangi işi saydığınızı yazın. Form gönderimi, formun sunucuda kabul edilmesi, nitelikli teklif talebi ve gerçek satış farklı aşamalardır. Her biri için olay adı, kaynak sistem, benzersiz kayıt anahtarı, gerçekleşme zamanı ve iş sahibi belirleyin. Aynı talebin hem düğme tıklaması hem başarı sayfası hem de CRM kaydı olarak üç kez ana hedefe eklenmesi, rapordaki talep sayısını anlamayı zorlaştırır.

Hangi olayın kampanya optimizasyonunda kullanılacağına karar vermeden önce ölçümün güvenilirliğini inceleyin. Bir form tıklaması kullanıcının talebinin alındığını garanti etmez. Telefon düğmesine basılması da tamamlanmış görüşmeyle aynı şey değildir. Bu ayrımı reklam ekibi ile satış ekibi birlikte kararlaştırmalı; rapora bakıp sonradan anlam yüklememelidir.

Mevcut Google Ads veri gücü denetimi rehberi form, telefon, Analytics ve CRM zincirinin genel kalitesine odaklanır. Buradaki daha dar görev ise gelişmiş dönüşümün hesap ayarı, veri kaynağı ve olay eşlemesi arasında gerçekten tutarlı çalışıp çalışmadığını sorgulamaktır.

Hesap ayarı ile veri gönderimini ayırın

Google Ads arayüzündeki dönüşüm ayarını, kabul edilen veri şartlarını ve seçilmiş yöntemi kaydedin. Yardım dokümanına göre web ve potansiyel müşteri gelişmiş dönüşümleri birleşik bir aç/kapat ayarıyla temsil ediliyor; bu nedenle eski ekran görüntüsü veya eski alan adına göre karar vermeyin. API kullanan ekip, çağrının sürümünü de kaydetmeli. Google Ads API v26 notunda eski enhanced_conversions_for_leads_enabled alanının kaldırıldığı ve hesap düzeyi denetimde enablement_setting kullanılması gerektiği yazıyor. Bu, yalnızca v26 ile entegrasyon yapan kodun alan eşlemesiyle ilgili bir iddiadır; her reklamverenin aynı API sürümünde çalıştığını varsaymayın.

Ardından veri gerçekten gönderiliyor mu diye kontrol edin. Web etiketi, Data Manager ve API farklı uygulama yollarıdır. Bir yöntemin hesapta seçili olması diğer kaynaktan gelen verinin işlendiğini otomatik doğrulamaz. Google'ın yardım içeriği, düzenli dönüşüm etiketi olmadan API üzerinden web gelişmiş dönüşüm düzeltmesi kurulmaması gerektiğini; olayın kaydı ve birinci taraf verisinin eklenmesini ayrı adımlar olarak açıklıyor. Bu nedenle “ayar açık” ekran görüntüsünü yeterli kanıt kabul etmeyin.

Denetim sırasında gerçek müşteri e-postalarını veya telefonlarını rapor dosyasına koymayın. Gereken eşleştirme ve güvenlik yaklaşımı kullanılacak Google ürününün güncel dokümanına göre belirlenmeli. Örnek olayla akışı test edin; müşteri verisini yalnızca yetkili ve uygun sistemlerde işleyin. Veri işleme şartları ve kullanıcı izinleri tamamlanmadan yalnızca teknik olarak mümkün diye yeni veri akışı açmayın.

Uçtan uca test senaryosu kurun

İlk test için tek bir örnek form talebi üretin. Formun istemci tarafında gönderilmesinden sunucu kaydına, dönüşüm etiketine ve CRM satırına kadar zaman damgalarını eşleştirin. Her sistemde aynı talebin nasıl tanımlandığını not edin. Ads raporlarının işleme süresi nedeniyle tüm yüzeylerin anında aynı sayıyı göstermesini beklemeyin; testin amacı olayın kaybolup kaybolmadığını ve tekrar üretilip üretilmediğini görmektir.

İkinci testte geçersiz formu deneyin. Kullanıcı arayüzünde düğmeye basıldı ama sunucu kabul etmedi ise bu olay nitelikli talep sayılmamalı. Üçüncü testte aynı talebi iki kez gönderin. Site, CRM ve Ads tarafındaki mükerrer kayıt davranışını belgeleyin. Dördüncü testte telefon veya WhatsApp gibi farklı temas yolunu deneyin; her etkileşimi form talebiyle aynı kategoriye zorlamayın.

Web için API üzerinden gelişmiş dönüşüm uygulamasında Google'ın resmî yardım içeriği, mevcut dönüşüm etiketinin yanında birinci taraf verisinin ayrıca gönderilmesini açıklar. Bu akışın kuralları sürüme ve kullanılan yönteme bağlıdır; gönderim penceresi, kimlik alanları ve tekilleştirme ayrıntılarını uygulama anındaki resmî dokümanla yeniden doğrulayın. Burada sabit bir reçete vermek yerine, hangi verinin hangi olaya bağlandığını denetlenebilir hale getirmek daha önemlidir.

Hata sinyallerini yanlış okumayın

Gelişmiş dönüşüm açık olduğu halde raporda beklenen değişim yoksa “özellik çalışmıyor” hükmüne atlamayın. Olayın temel etiketi tetikleniyor mu, kullanılan yöntem hesap ayarıyla uyumlu mu, aktarım hatası var mı, kayıt eşlemesi sağlam mı, bunları sırayla inceleyin. Kaynak sistemde hiç oluşmayan bir satış fırsatını Ads'in bulmasını bekleyemezsiniz. Benzer şekilde CRM'deki eski kayıtları yeni form talepleriyle karıştırmak test sonuçlarını bozar.

Yalnızca Ads dönüşüm sayısı ile GA4 oturumunu yan yana koyup bire bir eşitlik aramayın. Farklı işleme zamanı, kapsam ve metrik tanımı vardır. GSC tıklaması da ayrı bir arama performansı metriğidir. Karşılaştırma gerekiyorsa eşit tarih aralığı kullanın, son gün verisini olgunlaşmış veri gibi yorumlamayın ve her platformda hangi olayın sayıldığını tabloya yazın. Böylece bir farkın teknik hata mı yoksa tanım farkı mı olduğunu araştırabilirsiniz.

Bir diğer risk, amaç seçimidir. Kalitesiz bir tıklama olayı kampanya için ana başarı işaretiyse daha iyi eşleştirme bu temel tanım sorununu çözmez. Önce nitelikli talebi tanımlayın, sonra ona giden sinyallerin güvenilirliğini yükseltin. Değişiklik sonrası kampanya kararlarını kısa ve gürültülü bir zaman penceresiyle vermeyin.

Uygulanabilir kontrol listesi ve destek

Denetim çıktısı dört soruya net yanıt vermeli: hesap ayarı güncel belgelerle uyumlu mu; temel dönüşüm eylemi gerçek işi temsil ediyor mu; birinci taraf veri akışı ve eşleştirme hatasız mı; örnek talep uçtan uca tek kayıt olarak izlenebiliyor mu? Her soruya ekran görüntüsü yerine mümkün olduğunca olay kimliği ve anonim test kaydıyla kanıt ekleyin. Bir sorun bulunursa önce düzeltmeyi test ortamında yapın, ardından aynı senaryoyu tekrar çalıştırın.

Webinle'nin Google ve Meta reklam optimizasyonu hizmeti kapsamında görüşürken mevcut dönüşüm eylemi listesini, form başarı akışını ve anonim örnek talebi paylaşabilirsiniz. Böylece reklam hesabında yalnızca bir anahtarı açma işi değil, talep kalitesini gerçekten ölçebilen bir denetim kapsamı belirlenir; trafik veya sıralama sonucu garanti edilmez.