Veri & Analitik – Promogo

SEO İçerik Güncelleme Önceliği Nasıl Belirlenir? Trafik, Ticari Değer ve Güncellik İçin Skorlama Modeli

Radar — Sat, 22 Aug 2026 21:18:24 +0000

İçerik kütüphanesi büyüdükçe her yazıyı aynı anda güncellemek mümkün değildir. Daha verimli yaklaşım, hangi sayfanın mevcut performans kaybına rağmen hâlâ değer taşıdığını, hangi sorunun gerçekten içerikten kaynaklandığını ve hangi çalışmanın beklenen getiriyi en düşük emekle sağlayacağını sistematik biçimde karşılaştırmaktır.

İçerik yenileme kararı yalnızca organik trafik kaybına göre verilmemelidir. Kullanıcıya sağlanan fayda, konuya uygunluk, uzmanlık, arama amacı ve okuma sonrasındaki tatmin de değerlendirmeye alınmalıdır.

İçerik yenileme önceliği neden ayrı bir model gerektirir?

Bir sayfanın daha az trafik alması, tek başına onun değersiz veya mutlaka güncellenmesi gereken bir varlık olduğunu göstermez. Trafik kaybı ile içerik sorunu arasındaki farkı ayırmak; kaynakların yanlış sayfalara harcanmasını önleyen temel adımdır.

Trafik düşüşü tek başına içerik yenilemenin gerekli olduğunu kanıtlamaz. Algoritma güncellemeleri, mevsimsellik, talep değişimi, teknik sorunlar, backlink kaybı ve ölçüm hataları ayrıca dışlanmalıdır.

İçerik çürümesinin olası nedenleri arasında sıralama kaybı, rakiplerin içeriklerini geliştirmesi ve arama niyetinin değişmesi bulunur.

Önceliklendirmede hangi veriler kullanılmalı?

Sağlam bir içerik envanteri, yalnızca URL ve yayın tarihinden oluşmaz. Her aday için performans, kullanıcı amacı, ticari katkı, güncellik, rekabet, bağlantı değeri, sorun güveni ve tahmini emek aynı görünümde toplanmalıdır. Böylece editoryal karar, tek bir metriğin etkisinden çıkarılır.

Google Search Console ve Google Analytics birlikte kullanılarak gösterim, tıklama, organik kullanıcı, etkinlik, anahtar etkinlik ve gelir gibi metrikler açılış sayfası bazında izlenebilir.

Organik trafiğin ticari değeri yalnızca oturum sayısıyla değil; lead, demo, satın alma, anahtar etkinlik, gelir ve desteklenen dönüşüm katkısıyla değerlendirilmelidir.

Bu nedenle envanterde hedef sorgu, arama amacı, son anlamlı güncelleme tarihi, son 3, 6 ve 12 aylık tıklama ile gösterim, konum, tıklama oranı, dönüşüm, gelir veya lead, backlink ve dahili bağlantı değeri gibi alanlar bulunabilir. Hızlı eskime riski taşıyan konular için güncellik riski ve içerik sorunu güveni de ayrı sütunlar olarak tutulmalıdır.

SEO İçerik Güncelleme Önceliği Nasıl Belirlenir? Trafik, Ticari Değer ve Güncellik İçin Skorlama Modeli — bölüm görseli 1

Trafik düşüşünü nasıl doğrulamalı?

Trafik düşüşünü incelerken farklı tarih aralıkları karşılaştırılmalı ve değişimin önceki sayfa düzenlemeleriyle ilişkisi kontrol edilmelidir.

Pratikte önce düşüşün kalıcı mı, dönemsel mi, yoksa ölçüm veya teknik bir değişiklikle ilişkili mi olduğunu kontrol edin. Ardından sorgu gruplarını, sayfa düzenlemelerini, arama sonuçlarındaki rakipleri ve sayfanın mevcut arama amacına uyumunu birlikte inceleyin. Bu aşamanın amacı hemen karar vermek değil, içerik sorunu güvenini artırmak veya azaltmaktır.

İçerik sorunu güveni, gözlenen performans kaybının gerçekten kalite, güncellik, arama amacı veya rekabet uyumsuzluğundan kaynaklandığına ilişkin ayrı bir değerlendirme alanıdır. Bu güveni, sayfanın yenilenmesi hâlinde taşıdığı ticari fırsattan bağımsız tutmak daha sağlıklı bir karar zemini oluşturur.

SEO içerik güncelleme skoru nasıl hesaplanır?

Her adayı 0 ile 100 arasında normalize ederek farklı veri türlerini aynı karar çerçevesine taşıyabilirsiniz. Başlangıç şablonunda görünürlük kaybı yüzde 25, ticari değer yüzde 25, güncellik riski yüzde 20, rekabet fırsatı yüzde 15 ve maliyetin ters puanı yüzde 15 ağırlıklandırılabilir.

Basit bir model şu mantıkla kurulabilir: Öncelik skoru, görünürlük kaybı, ticari değer, güncellik riski, rekabet fırsatı ve içerik varlığının toplamının içerik sorunu güveniyle çarpılıp tahmini yenileme maliyetine bölünmesiyle elde edilir. Sıfıra bölme riskini önlemek için minimum bir maliyet tabanı tanımlanmalıdır.

Önerilen yüzde ağırlıkları ve aksiyon eşikleri evrensel SEO gerçekleri değildir. Site hedefleri, içerik türü, dönüşüm verisi ve ekip kapasitesiyle test edilip kalibre edilmelidir.

Bu modelin amacı matematiksel kesinlik üretmek değil, ekip içindeki öncelik tartışmalarını görünür varsayımlara bağlamaktır. Örneğin yüksek trafik kaybı yaşayan fakat ticari katkısı düşük bir sayfa, yüksek ticari değer taşıyan ve küçük bir güncellemeyle iyileşme potansiyeli bulunan başka bir sayfanın gerisine düşebilir.

İçerik güncelleme maliyeti nasıl hesaplanmalı?

Yenileme maliyeti yalnızca yazılacak kelime sayısından ibaret değildir. Araştırma, uzman incelemesi, veri doğrulama, tasarım veya ekran görüntüsü değişimi, teknik uygulama, yönlendirme ve kalite kontrol gibi iş kalemlerini ayrı ayrı tahmin etmek gerekir.

Google tarafından tercih edilen sabit bir içerik kelime sayısı standardı bulunmaz.

Bu nedenle uzun bir metni otomatik olarak daha değerli veya daha kapsamlı kabul etmek yerine, arama amacını ne ölçüde karşıladığına ve kullanıcıya gerekli bilgiyi ne kadar iyi sunduğuna bakılmalıdır. Kelime sayısı, maliyet tahmininin yalnızca sınırlı bir girdisi olabilir.

SEO İçerik Güncelleme Önceliği Nasıl Belirlenir? Trafik, Ticari Değer ve Güncellik İçin Skorlama Modeli — bölüm görseli 2

Her sayfa için aynı aksiyon seçilmemeli

Bir içerik için güncelleme, birleştirme, yönlendirme, budama veya baştan yazma seçenekleri ayrı ayrı değerlendirilmelidir.

Model yalnızca “yenile” sonucu üretmemelidir. Sayfanın mevcut amacı korunabiliyorsa hemen yenileme, temel yapı bozuksa yeniden yazma, benzer sayfalar çakışıyorsa birleştirme, daha uygun bir hedef varsa yönlendirme, anlamlı talep veya değer bulunmuyorsa budama seçenekleri değerlendirilebilir.

Güncellik riski yüksek konular için trafik düşük olsa bile minimum inceleme ve güncelleme eşiği tanımlamak gerekir. Yasal, finansal, sağlık veya ürün özellikleri gibi hızlı eskime ihtimali bulunan içerikler bu yaklaşımın öncelikli adaylarıdır.

Rakip ve arama amacı analizi nasıl yapılmalı?

Rakip analizi, yalnızca araçların verdiği puanları karşılaştırmakla sınırlı tutulmamalıdır. Arama sonuçlarındaki içerik formatı, kapsam, uzmanlık, kaynak kullanımı ve kullanıcı beklentisi manuel olarak incelenmelidir.

Google, başlıkların açık, özgün, kısa ve sayfa içeriğini doğru yansıtmasını; anahtar kelime doldurmadan kaçınılmasını önerir.

Bu ilke, yenileme sırasında başlığı yalnızca hedef sorguyu eklemek için değiştirmek yerine, sayfanın gerçek vaadini daha doğru ifade etmeyi gerektirir. Başlık, içerik ve arama amacı arasında uyumsuzluk varsa sorun yalnızca başlık düzeyinde değil, sayfanın bütün yapısında ele alınmalıdır.

Google'ın people-first ve helpful content yaklaşımı, Mart 2024'ten itibaren ayrı bir sistem olmaktan çıkarılıp çekirdek sıralama sistemlerinin parçası hâline getirilmiştir.

SEO İçerik Güncelleme Önceliği Nasıl Belirlenir? Trafik, Ticari Değer ve Güncellik İçin Skorlama Modeli — bölüm görseli 3

Güncelleme sonrasında başarı nasıl ölçülür?

Güncelleme sonrasında arama görünürlüğündeki değişim birkaç saatten birkaç aya kadar sürebilir; genel değerlendirme için çoğu durumda birkaç hafta beklemek gerekir.

Yeniden tarama isteği gönderilebilir, ancak bu işlem sıralama veya trafik artışı garantisi vermez.

Yenileme sonrası sonuçların değerlendirme zamanı değişebilir. Kısa dönemli artış veya düşüşler tek başına nedensellik göstergesi değildir.

Başarı ölçümünü yalnızca sıralama değişimine bağlamak yerine tıklama, gösterim, konum, tıklama oranı, nitelikli organik oturum, desteklenen dönüşüm, doğrudan dönüşüm, gelir veya lead ve güncelleme başına harcanan saat birlikte izlenmelidir.

Ölçüm planı, güncelleme öncesi karşılaştırma dönemini ve değerlendirme penceresini baştan tanımlamalıdır. Böylece ekip, kısa vadeli oynaklıkla kalıcı performans değişimini birbirine karıştırmadan aynı karar çerçevesini kullanabilir.

Modeli tek seferlik denetim olmaktan çıkarın

İçerik öncelikleri sabit kalmaz. Arama talebi, rakip kapsamı, ticari hedefler, sayfa performansı ve ekip kapasitesi değiştikçe aynı adayın skoru da değişebilir. Bu nedenle içerik portföyünü düzenli olarak yeniden puanlamak, tek seferlik bir auditten daha işlevsel bir işletim modeli sağlar.

Tercihen çeyreklik denetimlerle envanteri güncelleyin; ancak hızlı eskime riski taşıyan konular için daha kısa kontrol aralıkları belirleyin. Her değerlendirmede puanların hangi veriye ve hangi varsayıma dayandığını kaydetmek, modelin zaman içinde kalibre edilmesine yardımcı olur.

SEO İçerik Güncelleme Önceliği Nasıl Belirlenir? Trafik, Ticari Değer ve Güncellik İçin Skorlama Modeli — bölüm görseli 4

Uygulanabilir başlangıç kontrolü

Uygulamaya başlamak için önce içerik envanterini performans ve ticari değer verileriyle zenginleştirin. Ardından trafik düşüşünü doğrulayın, içerik sorunu güvenini ayrı değerlendirin, güncellik ve rekabet fırsatını puanlayın, iş kalemlerine dayalı maliyet tahmini yapın ve her sayfa için uygun aksiyonu seçin.

Son olarak güncelleme öncesi ölçüm tabanını kaydedin, başarı metriklerini belirleyin ve sonuçları belirlenen değerlendirme penceresinde izleyin. Bu yaklaşım, “eski yazıları güncelleme” refleksini; ölçülebilir, ticari hedeflerle bağlantılı ve ekip kapasitesine uyarlanabilir bir içerik operasyonuna dönüştürür.

Kaynaklar

GA4 E-ticaret Hunisi Nasıl Kurulur ve Debug Edilir? Uygulamalı Rehber

Radar — Fri, 14 Aug 2026 22:48:08 +0000

GA4 e-ticaret kurulumu yalnızca birkaç etkinlik eklemekten ibaret değildir. Sağlıklı bir ölçüm yapısı; kullanıcının ürünle etkileşiminden satın alma ve iade süreçlerine kadar her adımın hangi koşulda, hangi veriyle ve kaç kez gönderileceğini tanımlar. Bu nedenle asıl soru “Etkinlik gönderiliyor mu?” değil, “Gönderilen veri iş kararları almak için güvenilir mi?” olmalıdır.

Bu rehberde önce ölçüm planını ve veri sözleşmesini oluşturacak, ardından ürün ve işlem seviyesindeki parametreleri ayıracağız. Son bölümde GTM Preview, DebugView ve işlenmiş GA4 raporlarıyla doğrulama yaparak purchase ve gelir farklarını nasıl inceleyebileceğinizi ele alacağız.

GA4 e-ticaret hunisi nedir?

GA4 e-ticaret hunisi; ürün listeleme ve ürün detay görüntüleme, ürün seçimi, sepete ekleme, sepet görüntüleme, ödeme başlangıcı, kargo ve ödeme bilgisi, satın alma ve iade gibi gerçek kullanıcı aksiyonlarına karşılık gelen standart etkinliklerle kurulabilir.

Standart önerilen e-ticaret etkinlik adlarını kullanmak, GA4’ün önceden hazırlanmış e-ticaret raporlarının doğru verilerle doldurulmasına yardımcı olur.

Pratikte bu yapı, müşterinin hangi noktada kaybedildiğini görmek için bir akış oluşturur. Ürün detayından sepete geçiş düşükse ürün sunumu veya etkileşim ölçümü; ödeme başlangıcından purchase’a geçiş düşükse ödeme akışı, yönlendirme ya da satın alma etiketinin dönüş sayfasında çalışmaması incelenebilir. Bu yorumların anlamlı olabilmesi için her adımın tetiklenme koşulu önceden tanımlanmalıdır.

Kuruluma başlamadan önce tracking plan hazırlayın

İlk adım, bir tracking plan hazırlamaktır. Bu planda her huni adımı için etkinlik adı, tetiklenme koşulu, etkinlik seviyesindeki parametreler, items alanları, verinin kaynağı, beklenen tetiklenme sayısı ve test sonucu yer almalıdır. Böylece ölçüm kurulumu geliştirici, analist ve pazarlama ekipleri arasında ortak bir veri sözleşmesine dönüşür.

Örneğin ürün detay sayfasının gerçekten görüntülenmesi view_item için tetikleyici olabilir. Sepete ekleme onayının başarıyla gerçekleşmesi add_to_cart için kabul koşulu olarak yazılabilir. Purchase ise yalnızca başarılı siparişin oluştuğu ve sipariş kimliğinin kullanılabildiği durumda gönderilmelidir. Bu ayrım, buton tıklaması ile gerçekleşmiş iş sonucu arasındaki farkı görünür kılar.

Tracking plan yalnızca teknik bir doküman değil, kabul testi listesidir. Her etkinlik için “hangi kullanıcı aksiyonunda oluşmalı?”, “hangi veri zorunlu?”, “kaç kez oluşması bekleniyor?” ve “hangi sistemle karşılaştırılacak?” sorularına yanıt verilmelidir.

Ürün ve işlem seviyesindeki verileri ayırın

Ürün bilgileri items dizisinde; işlem veya kullanıcı aksiyonunu açıklayan value, currency, coupon, shipping ve tax gibi bilgiler ise etkinlik seviyesinde gönderilmelidir.

Bu ayrımın temel amacı, ürünün özellikleriyle işlemin toplamını birbirine karıştırmamaktır. item_id, item_name, price ve quantity gibi alanlar ürün satırını; value, currency, shipping ve tax gibi alanlar ise işlemin genel bağlamını açıklar. Bir ürünün fiyatını işlem toplamı alanına yazmak veya toplam indirim bilgisini ürün alanı gibi modellemek raporların yorumlanmasını zorlaştırabilir.

items dizisi bir etkinlikte birden fazla ürün taşıyabilir; dokümantasyondaki sınıra göre tek etkinlikte 200 ürüne kadar ürün gönderilebilir.

Bu nedenle sepet ve purchase kontrollerinde yalnızca etkinliğin oluştuğunu görmek yeterli değildir. Ürün sayısı, ürün kimlikleri, birim fiyatlar ve miktarlar sipariş ya da sepet ekranındaki gerçek içerikle karşılaştırılmalıdır.

value, currency ve gelir hesaplamasını doğrulayın

value gönderiliyorsa currency parametresi etkinlik seviyesinde açıkça belirtilmelidir.

purchase içindeki value, ürün fiyatı ve miktarların toplamını temsil eder; tax, shipping, coupon ve ürün seviyesindeki indirimler ayrıca gönderilebilir.

GA4 item revenue değerini items dizisindeki price ve quantity bilgilerine göre türetir; bu nedenle birim fiyat ve gerçek ürün adedi ayrıca doğrulanmalıdır.

Gelir kontrolünde tek bir toplam rakama bakmak yerine üç katmanlı bir mutabakat yapılmalıdır: sipariş sistemindeki toplam, purchase içindeki value ve items dizisindeki price ile quantity kombinasyonu. Vergi, kargo, indirim, iade ve iptal kurallarının hangi katmanda temsil edildiği ayrıca belgelenmelidir.

GA4 geliri ile ödeme sistemi toplamının birebir eşleşmemesi tek başına ölçüm hatıtı kanıtlamaz; iş kuralları ve veri işleme gecikmeleri fark yaratabilir.

purchase etkinliğini ve transaction_id kullanımını güvenceye alın

purchase etkinliğinde transaction_id, işlemi tanımlamak için kullanılmalı; aynı işlem kimliğinin tekrar gönderilmesi mükerrer satın alma ve gelir sorunlarına yol açabilir.

purchase etkinliği, eski ecommerce_purchase etkinliğinin yerine geçer; iki adlandırmanın birlikte kullanılması raporlama ve ölçüm karmaşası oluşturabilir.

Purchase için temel kabul testi, başarılı siparişin onay sayfasında tek bir işlem kimliğiyle ve doğru sipariş içeriğiyle ölçülmesidir. Sayfa yenileme, geri dönme veya aynı onay sayfasının tekrar açılması gibi senaryolarda aynı transaction_id’nin yeniden gönderilmediği kontrol edilmelidir.

Purchase etkinliğini yalnızca ödeme butonuna bağlamak yerine, mümkün olduğunda siparişin gerçekten tamamlandığını gösteren güvenilir bir durum üzerinden tasarlamak daha sağlam bir ölçüm yaklaşımıdır. Bu yaklaşım, başarısız ödeme ile tamamlanmış siparişi birbirinden ayırmaya yardımcı olur.

İade ölçümünü purchase kadar ciddiye alın

refund etkinliği transaction_id ile ilişkilendirilmeli; ürün seviyesinde iade analizi için item_id ve quantity gibi ürün bilgileri de gönderilmelidir.

İade verisi, yalnızca satın alma sayısını değil, ölçülen gelirin iş açısından ne kadar sürdürülebilir olduğunu anlamak için de önemlidir. Tam ve kısmi iadeler farklı senaryolarsa, tracking plan içinde hangi işlem kimliği ve hangi ürün miktarıyla temsil edilecekleri açıkça tanımlanmalıdır.

Gelir mutabakatında iade ve iptal kurallarını dışarıda bırakmak, GA4 ile sipariş sistemi arasındaki farkı yanlış yorumlamaya neden olabilir. Bu nedenle rapor karşılaştırmalarında satın alma, iade ve iptal dönemleri aynı kapsamla ele alınmalıdır.

Data layer ve GTM bağlantısını kontrol edin

Data layer, olayları ve değişkenleri GTM ile etiketlere taşımak için kullanılan yapılandırılmış veri katmanıdır; her sayfa yüklemesinde ve mümkünse GTM container kodundan önce hazır olmalıdır.

Data layer yapısında tutarlı anahtar adları ve veri tipleri kullanılmalıdır. Bir sayfada event, başka bir sayfada farklı bir olay anahtarı kullanılması; items dizisinin yanlış isimlendirilmesi; veri katmanının üzerine yazılması veya büyük-küçük harf farkları, etiketin beklediği değeri okuyamamasına yol açabilir.

GTM Preview ve Debug modu, etiketlerin hangi sırayla tetiklendiğini, tetikleyicileri, değişken değerlerini ve gönderilen parametreleri test etmeye yardımcı olur.

GTM Preview incelemesinde yalnızca etiketin tetiklenip tetiklenmediğine bakmayın. Önce dataLayer olayının doğru sırada oluştuğunu, sonra değişkenlerin beklenen değerleri taşıdığını ve son olarak GA4 etiketinin doğru değişkenleri okuduğunu kontrol edin.

DebugView ile gerçek zamanlı doğrulama yapın

DebugView, etkinlikleri ve kullanıcı özelliklerini gerçek zamanlı izlemek için kullanılabilir; çalışması için debug_mode sinyali veya desteklenen bir hata ayıklama yöntemi gerekir.

DebugView’da bir etkinliğin görünmesi, tüm parametrelerin işlenmiş raporlarda doğru kullanılacağını tek başına kanıtlamaz; value, currency, transaction_id ve items içeriği ayrıca incelenmelidir.

Bu nedenle gerçek zamanlı doğrulama iki ayrı soruya bölünmelidir: Etkinlik GA4’e ulaştı mı ve etkinlik doğru içerikle mi ulaştı? Birinci sorunun yanıtı olumlu olsa bile ikinci soru için parametre değerleri, ürün dizisi ve işlem kimliği tek tek incelenmelidir.

Testi temiz bir tarayıcı oturumunda ürün detayından purchase’a kadar sırayla tamamlamak, akışın hangi adımında veri kaybı oluştuğunu izlemeyi kolaylaştırır. Her adımda ekran davranışı, dataLayer olayı, GTM etiketi ve GA4 parametreleri birlikte kontrol edilmelidir.

Çok adımlı ödeme akışlarını ve yönlendirmeleri test edin

Ödeme akışında kargo ve ödeme bilgileri, yalnızca kullanıcının ilgili bilgiyi gerçekten sağladığı aşamada ölçülmelidir. Kullanıcı henüz seçim yapmadan tahmini ya da varsayılan değerleri göndermek, huninin gerçek davranışını bozabilir.

Harici ödeme sağlayıcısı veya farklı domain kullanılıyorsa purchase’ın onay sayfasına dönüşte korunup korunmadığı özel olarak test edilmelidir. Yönlendirme, consent durumu, etiketin sayfada bulunması ve dönüş URL’si birlikte incelenmelidir.

Harici ödeme sağlayıcıları, cross-domain akışlar, consent mode, sunucu tarafı etiketleme ve platforma özgü dataLayer yapıları farklı teknik çözümler gerektirebilir; genel GA4 dokümantasyonu tüm altyapı varyasyonlarını kapsamayabilir.

Gerçek zamanlı veriyi işlenmiş raporlarla karıştırmayın

GA4 raporları ve explorations e-ticaret verisini hemen göstermeyebilir; raporların dolması 24 saate, bazı genel veri işleme süreçleri ise 24–48 saate kadar sürebilir.

Bu nedenle doğrulama sırası önemlidir: önce GTM Preview, Tag Assistant veya DebugView ile gönderimin gerçekleştiğini kontrol edin; ardından veri işleme gecikmesini dikkate alarak GA4 raporlarını sipariş sistemiyle karşılaştırın.

Gerçek zamanlı araçlarda etkinliği görememek teknik soruna işaret edebilir; ancak etkinlik gerçek zamanlı araçta göründüğü halde raporda hemen görünmemesi de tek başına implementasyon hatası anlamına gelmez. Test sonucu, kullanılan aracın amacı ve beklenen işleme süresiyle birlikte değerlendirilmelidir.

Google Analytics ve Google Tag Manager arayüzlerindeki menü adları ve ekran yolları zaman içinde değişebilir; içerikte kalıcı olması için kavramlar ve test mantığı öne çıkarılmalıdır.

GA4 ile sipariş sistemi arasındaki farkları analiz edin

GA4 ve sipariş sistemi arasında fark gördüğünüzde doğrudan “ölçüm bozuk” sonucuna gitmeyin. Önce purchase etkinliğinin kaç kez gönderildiğini, transaction_id değerlerinin tekilliğini, value ve currency alanlarını, items içeriğini ve dönüş sayfasındaki etiket varlığını kontrol edin.

Teknik kontrollerden sonra vergi, kargo, indirim, iade, iptal, saat dilimi, consent ve veri işleme farklarını ayrı başlıklar halinde inceleyin. Farkın kaynağını bu katmanlara ayırmak, tek bir toplam sayı üzerinden yapılan belirsiz yorumlardan daha sağlıklı bir teşhis sağlar.

Karşılaştırmayı aynı tarih aralığı, aynı sipariş kapsamı ve mümkün olduğunca aynı iş kurallarıyla yapmak gerekir. Ayrıca beklenen etkinlik sayısı ile gerçek etkinlik sayısını tracking plan üzerinden düzenli olarak karşılaştırmak, veri kaybını rapor farkı büyümeden fark etmeye yardımcı olur.

Uygulanabilir son kontrol listesi

Kurulum tamamlandıktan sonra şu sırayla ilerleyin: tracking planı ve veri sözleşmesini gözden geçirin; ürün ve işlem seviyesindeki alanları ayırın; view_item ve add_to_cart içindeki items dizisini kontrol edin; purchase için transaction_id, value ve currency alanlarını birlikte doğrulayın; aynı işlem kimliğinin tekrarlanmadığını test edin; refund senaryolarını inceleyin; ardından gerçek zamanlı araçlar ve işlenmiş raporlar arasında karşılaştırma yapın.

Bu kontrol listesi, GA4 e-ticaret hunisini yalnızca rapor ekranında görünen bir dizi etkinlik olmaktan çıkarır. Her adımın tetiklenme koşulu, veri içeriği ve kabul testi tanımlandığında ölçüm yapısı pazarlama kararlarını destekleyecek denetlenebilir bir sisteme dönüşür.

Promogo açısından bu yaklaşım; ölçüm planı hizmetinde tracking plan şablonlarıyla, reklam optimizasyonunda güvenilir purchase ve gelir kontrolleriyle, dönüşüm analizinde ise beklenen ve gerçek etkinlik sayılarının karşılaştırılmasıyla ilişkilendirilebilir. Değer, yalnızca kurulumu yapmakta değil, kurulumun gerçekten çalıştığını kanıtlamaktadır.

Kaynaklar

Google Ads Offline Conversion Tracking: CRM Verisini Reklam Optimizasyonuna Aktarma Rehberi

Radar — Fri, 14 Aug 2026 22:37:35 +0000

Form gönderimi neden tek başına yeterli değildir?

B2B işletmelerde her form aynı ticari değeri taşımaz. Bir form yalnızca ilk ilgiyi gösterirken, satış ekibinin doğruladığı nitelikli lead, teklif veya kapanmış satış işletme açısından çok daha anlamlı sinyaller sağlayabilir. Bu nedenle reklam performansını yalnızca form hacmiyle değil, satış hunisinin alt aşamalarıyla birlikte değerlendirmek gerekir.

Google Ads offline conversion tracking, reklam tıklamasından sonra CRM’de gerçekleşen nitelikli lead, sözleşme veya satış gibi çevrimdışı dönüşümlerin Google Ads’e aktarılmasını sağlar.

Bu yaklaşımın temel amacı, reklam etkileşimini gerçek ticari sonuçlarla ilişkilendirmektir. Böylece ölçüm sistemi, yalnızca internet sitesindeki form gönderimini değil, satış sürecinde doğrulanan ilerlemeyi de görünür kılacak şekilde tasarlanabilir.

Google Ads offline conversion tracking nasıl çalışır?

Temel süreç; reklam etkileşimini CRM kaydıyla eşleştirmek, satış hunisinde ilgili aşama oluştuğunda dönüşümü göndermek ve veriyi raporlama ile teklif optimizasyonunda kullanmaktır.

Kurulum, reklam hesabında bir dönüşüm aksiyonu oluşturmaktan ibaret değildir. Kullanıcının reklamla etkileşimi, web sitesindeki form veya temas noktası, CRM kaydı, satış ekibinin değerlendirmesi ve Google Ads’e yapılan aktarım aynı veri akışının parçaları olarak ele alınmalıdır.

Google, yeni kurulumlarda klasik Offline Conversion Import yerine Enhanced Conversions for Leads çözümünü öne çıkarmaktadır.

Google’ın offline conversion import ve Enhanced Conversions for Leads yüklemeleriyle ilgili planlanan API geçişleri ürün davranışını etkileyebilir. Yayın öncesinde güncel resmi dokümantasyon ve geçiş durumu yeniden doğrulanmalıdır.

Önce CRM aşamalarını ve iş hedeflerini tanımlayın

B2B işletmeler için qualified lead ve converted veya closed lead aşamaları, satış hunisinin anlamlı dönüşüm hedefleri olarak kullanılabilir.

Qualified lead, satış ekibinin uygun veya ilgili bulduğu lead’i; converted veya closed lead ise satış sürecinde sözleşme ya da satış gibi nihai bir aşamaya ulaşan lead’i ifade eder.

Bu aşamaları birbirinden ayırmak, reklam optimizasyonunun hangi sinyale dayanacağını netleştirir. Form, qualified lead, teklif ve closed lead aynı dönüşüm aksiyonu içinde eritilmek yerine, satış hunisindeki rollerine göre ayrı ayrı izlenebilir.

Primary veya Secondary dönüşüm seçimi, her işletmenin optimizasyon hedefi ve dönüşüm hacmine bağlıdır. Aşama bazlı ölçüm desteklense de tüm işletmeler için tek bir seçim önerisi bulunmaz.

Tıklama kimliğini ve birinci taraf verilerini CRM’e taşıyın

GCLID, Google Ads tıklamasını CRM kaydıyla ilişkilendirmek için kullanılabilir; mobil ve uygulama senaryolarında GBRAID veya WBRAID gibi farklı kimlik türleri de söz konusu olabilir.

Form gönderimi sırasında tıklama kimliği ve gerekli birinci taraf verilerin CRM kaydına yazılması, offline dönüşümün doğru reklam etkileşimiyle eşleştirilmesi için önemlidir.

Enhanced Conversions for Leads, GCLID gibi tıklama kimliklerinin yanı sıra e-posta ve telefon gibi birinci taraf müşteri verilerini SHA-256 ile hashleyerek eşleştirme doğruluğunu artırmayı amaçlar.

Bu nedenle formdaki hidden field yapısı, CRM entegrasyonu ve veri kaydının ilk temas anından itibaren birlikte test edilmesi gerekir. Kullanıcı daha sonra satış sürecinde ilerlediğinde, CRM kaydının hangi reklam etkileşimiyle ilişkili olduğunu koruyabilmesi beklenir.

Enhanced Conversions for Leads kapsamında e-posta ve telefon gibi kişisel veriler SHA-256 ile hashlenir ve yalnızca işletmenin müşteriyle doğrudan paylaşılan birinci taraf verileri kullanılmalıdır.

GCLID veya kullanıcı tanımlayıcılarının saklanması ve işlenmesi için uygulanacak hukuki yükümlülükler işletmenin ülkesine, süreçlerine ve veri işleme rolüne göre değişebilir.

Google Ads Offline Conversion Tracking: CRM Verisini Reklam Optimizasyonuna Aktarma Rehberi — bölüm görseli 1

CRM aktarımında hangi alanlar bulunmalı?

CRM aktarımında dönüşüm aksiyonu adı, dönüşüm tarihi ve saat dilimi, dönüşüm değeri, para birimi ve uygun tıklama veya kullanıcı kimlikleri gibi alanlar kullanılabilir.

Pratikte bu alanların bir veri sözlüğünde açıkça tanımlanması, farklı ekiplerin aynı dönüşüm tanımını kullanmasına yardımcı olur. Benzersiz Order ID, kimlik alanları ve consent bilgisi de işletmenin veri modeline ve kullandığı aktarım yöntemine göre baştan planlanmalıdır.

Tarih alanlarında da tutarlılık önemlidir. CRM’deki satış zamanı ile Google Ads raporlarında kullanılan tarih aynı bağlama sahip olmayabileceği için saat dilimi ve dönüşümün hangi aşamada kaydedildiği dokümante edilmelidir.

Dönüşüm değerini nasıl belirlemelisiniz?

Dönüşüm değeri, CRM’deki ticari değeri yansıtacak şekilde nitelikli lead, teklif veya satış aşamasında gönderilebilir.

Her aşamaya aynı değeri vermek, satış hunisindeki ekonomik farkları gizleyebilir. Nitelikli lead için beklenen gelir, teklif için olasılık ağırlıklı değer, satış için gerçekleşen gelir gibi bir model işletmenin karar alma yapısına daha uygun olabilir.

Google kaynakları veri alanlarını ve değer aktarımını doğrulasa da B2B işletmeler için tek ve evrensel bir dönüşüm değeri formülü tanımlamaz. Değer modeli kapanış oranı, ortalama sözleşme değeri ve marj varsayımlarına göre işletmeye özel uyarlanmalıdır.

Aktarım hatalarını ve rapor farklarını kontrol edin

Benzersiz Order ID’nin birden fazla kez gönderilmesi DUPLICATE_ORDER_ID hatasına neden olabilir.

CLICK_NOT_FOUND uyarısı, yüklenen kaydın Google Ads tıklamasıyla eşleşmediğini gösterebilir.

Offline veri diagnostics raporu, API yanıtlarındaki partial failure bilgileri ve hata kayıtları aktarım sağlığını izlemek için kullanılabilir.

Kontrol sürecinde yalnızca kaç satır gönderildiğine bakmak yeterli değildir. Eşleşme oranı, CLICK_NOT_FOUND kayıtları, duplicate hataları, alan bazlı hatalar, dönüşüm gecikmesi ve kampanya bazında satış kalitesi birlikte izlenmelidir.

İçe aktarılan dönüşümler Google Ads raporlarında ilk reklam etkileşiminin tarihine göre raporlanabildiğinden, CRM dönüşüm tarihi ile Google Ads rapor tarihi farklı olabilir.

Bu nedenle CRM toplamı ile Google Ads toplamını karşılaştırırken yalnızca aynı takvim tarihine bakmak yanıltıcı olabilir. Tıklama tarihi, dönüşüm penceresi ve veri yükleme gecikmesi aynı değerlendirme çerçevesine alınmalıdır.

Satış sonucu değiştiğinde dönüşümü güncelleyin

Satış sonucu sonradan değiştiğinde conversion adjustments ile daha önce bildirilen dönüşüm geri çekilebilir veya değeri güncellenebilir; bu işlemlerde Order ID kullanılabilir.

Örneğin bir satış iptal olduğunda ya da CRM’deki ticari değer değiştiğinde, ilk aktarımın olduğu gibi kalması reklam optimizasyonunu güncel iş sonucundan uzaklaştırabilir. Order ID tabanlı düzeltme süreci, bu değişikliklerin ölçüm sistemine yansıtılmasını sağlayacak şekilde tasarlanmalıdır.

Google Ads Offline Conversion Tracking: CRM Verisini Reklam Optimizasyonuna Aktarma Rehberi — bölüm görseli 2

Uygulama için kısa kontrol listesi

Sağlıklı bir kurulum için aşağıdaki sıralama izlenebilir: önce form, qualified lead, teklif ve satış aşamalarını tanımlayın; ardından uygun tıklama veya kullanıcı kimliklerini CRM’e kaydedin. Daha sonra dönüşüm aksiyonlarını, değer modelini, para birimini ve veri düzeltme sürecini belirleyin.

Entegrasyon yayına alındığında test kayıtlarını ve aktarım yanıtlarını inceleyin. Eşleşmeyen tıklamaları, yinelenen Order ID’leri, eksik alanları ve raporlama tarihleri arasındaki farkları düzenli olarak kontrol edin.

Sonuç olarak Google Ads offline conversion tracking, form sayısını artırmaya odaklanan ölçümden CRM’de doğrulanan ticari sonuca odaklanan ölçüme geçiş sağlar. En değerli kurulum, işletmenin satış sürecini doğru tanımlayan, veri kalitesini izleyen ve değişen satış sonuçlarını geriye dönük olarak güncelleyebilen kurulumdur.

Kişisel verilerin kullanımı, hashleme, consent ve ilgili veri koruma yükümlülükleri teknik kurulumdan ayrı düşünülmemelidir. Bu konular işletmenin hukuki danışmanlığıyla değerlendirilerek veri akışının kapsamı netleştirilmelidir.

Kaynaklar

Meta Conversion API (CAPI) Kurulumu: Tarayıcı Kısıtlamaları Dönüşüm Ölçümünü Nasıl Etkiler?

Radar — Fri, 14 Aug 2026 17:55:14 +0000

Meta Conversion API (CAPI), web sitesi, uygulama, CRM, fiziksel mağaza ve çevrimdışı dönüşüm verilerini Meta’nın optimizasyon, hedefleme ve ölçüm sistemlerine doğrudan bağlayan bir altyapıdır. Bu nedenle CAPI’yi yalnızca web sitesine eklenen teknik bir etiket olarak değil, farklı kaynaklardaki dönüşüm sinyallerini Meta’ya taşıyan bir veri bağlantısı olarak değerlendirmek gerekir.

CAPI kurulumu gündeme geldiğinde temel soru yalnızca “Sunucu tarafı veri gönderiyor muyuz?” olmamalıdır. Önce hangi müşteri yolculuğu aşamalarını ölçmek istediğinizi, bu olayların hangi sistemlerde oluştuğunu ve reklam optimizasyonunda hangi sonuçların değerli olduğunu tanımlamak daha sağlıklı bir başlangıç sağlar.

Conversion API neden gündeme geldi?

Meta Pixel tarayıcı üzerinden çalıştığı için tarayıcı yükleme hataları, bağlantı sorunları ve reklam engelleyicilerden etkilenebilir. CAPI ise sunucu, web platformu, uygulama veya CRM üzerinden veri ilettiğinden bu sorunlardan Pixel’e kıyasla daha az etkilenebilir.

Bu fark, Pixel’in gereksiz olduğu anlamına gelmez. Tarayıcıdan gelen davranış sinyalleri ile sunucu veya CRM kaynaklı sonuçların birlikte ele alınması, ölçüm altyapısının tek bir veri aktarım kanalına bağımlı kalmamasına yardımcı olabilir. Ancak iki kanal aynı dönüşümü gönderiyorsa, veri akışlarının birbirinden bağımsız değil, birlikte tasarlanması gerekir.

CAPI tarayıcı kısıtlamalarını tamamen ortadan kaldırmaz ve tüm dönüşümlerin eksiksiz yakalanacağını garanti etmez. Yanlış olay tanımı, eksik parametre, izin eksikliği veya çift gönderim gibi sorunlar sunucu tarafı entegrasyonunda da görülebilir.

CAPI’nin kampanya performansına etkisi her işletmede aynı olmayabilir. Otomatik bir performans artışı garanti edilmediğinden sonuçlar olay doğruluğu, veri kalitesi, izinler, deduplikasyon ve kampanya stratejisiyle birlikte değerlendirilmelidir.

Pixel ve CAPI birlikte nasıl çalışır?

Meta, web olaylarında Pixel ve CAPI’nin birlikte kullanılmasını önerir. Aynı dönüşümün iki kez sayılmasını önlemek için deduplikasyon kurulmalıdır.

Tarayıcıdan gönderilen Pixel olayı ile sunucudan gönderilen CAPI olayının aynı dönüşüm olduğunu belirtmek için ortak ve benzersiz bir event_id kullanılmalıdır. event_name ve event_time gibi alanların da tutarlı üretilmesi gerekir.

Event deduplication’ın pratik amacı, aynı satın alma veya lead işleminin iki ayrı kanal üzerinden ulaşmasına rağmen tek bir dönüşüm olarak ilişkilendirilmesini sağlamaktır. Bu nedenle entegrasyon testlerinde yalnızca olayın ulaşıp ulaşmadığı değil, Pixel ve CAPI olaylarının aynı dönüşüm anahtarını taşıyıp taşımadığı da kontrol edilmelidir.

Müşteri bilgilerine ilişkin ek ve uygun parametrelerin CAPI ile gönderilmesi, olayların kullanıcılarla eşleştirilmesine ve Event Match Quality değerinin iyileştirilmesine yardımcı olabilir.

Buradaki hedef, mümkün olan en fazla veriyi göndermek değil; gerekli, doğru, güncel ve izinli bilgileri doğru olayla ilişkilendirmektir. Ölçüm kalitesi, yalnızca olay hacmiyle değil, olayların kullanıcıyla ne kadar iyi eşleştirilebildiğiyle de ele alınmalıdır.

E-ticaret siteleri için CAPI kurulum planı

E-ticarette temel olaylar arasında ViewContent, AddToCart, InitiateCheckout ve Purchase bulunur. Purchase olayında value ve currency bilgilerinin doğru aktarılması gerekir.

Müşteri yolculuğunun ara aşamalarını da ölçmek, kampanya optimizasyonu ile gerçek satış verisini karşılaştırmayı kolaylaştırabilir. Bu nedenle ölçüm planı yalnızca Purchase olayına indirgenmemelidir.

E-ticaret akışında önce ürün görüntüleme, sepete ekleme, ödeme başlatma ve satın alma adımlarının işletme sistemlerinde nasıl oluştuğu haritalanmalıdır. Ardından her aşamanın hangi kaynaktan gönderileceği, hangi parametrelerin gerekli olduğu ve satın alma olayında siparişin nasıl benzersiz biçimde tanımlanacağı belirlenmelidir.

Test sırasında gerçek bir kullanıcı senaryosu izlenerek ürün görüntüleme, sepete ekleme, ödeme başlatma ve satın alma akışı denenmelidir. Sipariş numarası veya başka bir benzersiz anahtarın event_id üretiminde istikrarlı kullanıldığı ve aynı siparişin Pixel ile CAPI tarafından çift raporlanmadığı doğrulanmalıdır.

Lead kampanyalarında web, instant form ve CRM ayrımı

Web formu gönderimleri için web olayları ve web CAPI kullanılabilir. Instant form lead’lerinin satış, randevu veya nitelikli fırsata dönüşmesi gibi aşağı-funnel sonuçlar CRM’den CAPI aracılığıyla Meta’ya geri gönderilebilir.

Lead retrieval entegrasyonu yeni lead’leri CRM’e taşırken, CAPI CRM’deki aşağı-funnel sonuçları Meta’ya geri göndermeye yarar. Bu iki entegrasyon aynı şey değildir.

Web CAPI kurulmuş olması, instant form lead’leri için CRM tabanlı dönüşüm entegrasyonunun otomatik olarak tamamlandığı anlamına gelmez.

Lead kampanyalarında form doldurma başlangıç dönüşümüdür. Daha anlamlı optimizasyon için lead’in CRM’de satışa, randevuya veya nitelikli fırsata dönüşmesini ayrı bir veri akışı olarak planlamak gerekir. Bu nedenle web formu, instant form, lead retrieval ve CRM’den Meta’ya geri besleme adımları ayrı ayrı haritalanmalıdır.

Meta Conversion API (CAPI) Kurulumu: Tarayıcı Kısıtlamaları Dönüşüm Ölçümünü Nasıl Etkiler? — bölüm görseli 1

Veri kalitesi nasıl denetlenir?

Veri kalitesi değerlendirmesinde yalnızca olay hacmi incelenmemelidir. Event Match Quality, olay teşhisleri, tarayıcı ve sunucu olaylarının oranı, deduplikasyon, olay gecikmesi, eksik parametreler ve CRM kayıtlarıyla oluşan farklar birlikte değerlendirilmelidir.

Bu kontrol listesi, “Events Manager’da olay görünüyor mu?” sorusunu daha kapsamlı bir denetime dönüştürür. Olayın görünmesi tek başına doğru değer, doğru zaman, doğru kullanıcı eşleştirmesi veya tekil raporlama anlamına gelmeyebilir. Bu yüzden kurulum sonrası teknik sinyaller ile işletmenin gerçek sipariş ve CRM kayıtları karşılaştırılmalıdır.

Event Match Quality veya tarayıcı-sunucu olay oranı için tüm işletmelere uygulanabilecek tek bir başarı eşiği yoktur. Kabul edilebilir seviyeler platforma, trafiğe, izin yapısına ve dönüşüm akışına göre değişebilir.

CAPI kurulumu için hangi yöntem seçilmeli?

Meta’nın kurulum seçenekleri arasında partner entegrasyonu, Conversions API Gateway ve manuel kurulum bulunur. Uygun seçenek platforma, ekip yetkinliğine, CRM yapısına ve gizlilik gereksinimlerine göre belirlenmelidir.

Partner entegrasyonu, Gateway veya manuel kurulum arasında seçim yaparken yalnızca ilk kurulum hızına odaklanmak yeterli değildir. Veri akışının nerede oluştuğu, CRM mimarisinin ne kadar özelleştirildiği, teknik ekibin bakım kapasitesi ve veri üzerinde ne düzeyde kontrol gerektiği birlikte değerlendirilmelidir.

Meta arayüzündeki menü adları, kurulum seçeneklerinin ayrıntıları ve geliştirici dokümanlarındaki alan gereksinimleri zaman içinde değişebilir. Yayına almadan önce güncel Events Manager ve geliştirici dokümanlarıyla doğrulama yapılmalıdır.

Gizlilik ve veri kullanımı açısından dikkat edilmesi gerekenler

CAPI, gizlilik kurallarını veya iOS App Tracking Transparency gerekliliklerini aşmak için tasarlanmış bir yöntem değildir. Müşteri bilgileri uygun amaçlar, izinler ve Meta Business Tools şartları çerçevesinde kullanılmalıdır.

Sunucu tarafı aktarım, verinin teknik olarak daha kontrollü iletilmesini sağlayabilir; ancak teknik kontrol hukuki uygunluğun yerine geçmez. Hangi müşteri bilgisinin neden işlendiği, hangi izinlerin bulunduğu ve hangi verinin gerçekten gerekli olduğu entegrasyon tasarımının parçası olmalıdır.

Yerel mevzuat, açık rıza, veri sorumlulukları ve müşteri bilgilerinin işlenmesine ilişkin özel yükümlülükler ülkeye ve senaryoya göre değişebilir. Bu içerik hukuki danışmanlık yerine genel bir uygulama çerçevesi sunar.

Meta Conversion API (CAPI) Kurulumu: Tarayıcı Kısıtlamaları Dönüşüm Ölçümünü Nasıl Etkiler? — bölüm görseli 2

Promogo yaklaşımıyla ölçüm altyapısını yönetmek

Promogo açısından Meta Ads yönetimi yalnızca kampanya kurulumundan ibaret değildir. Pixel, Conversion API, Events Manager, CRM ve dönüşüm kalitesinin birlikte yönetilmesi; e-ticarette Purchase ve gelir doğrulamasının, lead kampanyalarında ise formdan nitelikli lead veya satış sonucuna uzanan CRM geri beslemesinin izlenmesini gerektirir.

Sağlıklı bir çalışma akışı; funnel’ın tanımlanması, olayların ve veri kaynaklarının haritalanması, Pixel-CAPI deduplikasyonunun kurulması, gerçek senaryolarla test yapılması ve düzenli veri kalitesi raporlaması adımlarından oluşur. Böylece CAPI, tek başına mucizevi bir çözüm olarak değil, daha kontrollü bir ölçüm altyapısının parçası olarak konumlanır.

Müşteri verilerinin yalnızca gerekli amaçlarla, uygun izinler ve veri minimizasyonu ilkesi doğrultusunda kullanılması gerekir. Hash’leme veya teknik aktarım tek başına hukuki uygunluk sağlamaz.