Aynı mağaza, aynı hafta, aynı siparişler. Google Ads paneli bir sayı veriyor, GA4 başka bir sayı. İlk refleks tag’de hata aramak oluyor, oysa iş çoğunlukla ondan önce başlıyor: iki panelin sayılarını ortak bir zemine indirmek. Ortak zemin üç sorunun iki tarafta da aynı yanıtlanması demek: ne sayılıyor, hangi güne yazılıyor, hangi siparişler kapsama giriyor. Üçü hizalanmadan alınan fark kurulumun değil, tanımların farkıdır.
Hizalama hiç yapılmadığında ya da üzerine düşünülmemiş bir hizalamayla yetinildiğinde, birbirini tutan sayılar en yanıltıcı sonucu verebilir. İncelediğim hesaplardan birinde GA4 tarafındaki sipariş sayısı ile Ads panelindeki dönüşüm sayısı arasındaki fark tek haneliydi; GA4 tarafında Explore raporundaki sipariş satırları, Ads tarafında Webpages raporundaki “Webpage” satırları sayılmıştı ve ilk bakışta kurulum mantıklı görünüyordu. Peki neden?
GA4 ve Ads tarafındaki sayılar farklı nedenlerle daraltılmıştı: GA4 tarafı cookie’sinde hâlâ click ID taşıyan siparişlere, Ads tarafı sayfa adresi kaydedilebilmiş dönüşümlere inmişti. İki ayrı filtre iki paydayı birden daraltmış, örtüşme gerçekte olduğundan iyi görünmüştü. Yakınlık bir doğrulama değil, rastlantıydı.
Bu yazı ortak zeminin ilk iki sorusunu ele alıyor: ne sayılıyor ve hangi güne yazılıyor. Üçüncü soru, hangi siparişlerin kapsama girdiği, satır seviyesinde birleştirmeyi gerektiriyor ve ona ayrı bir yazıda giriyorum. Amaç iki sayıyı eşitlemek değil, aradaki farkı adı konmuş ve ölçülebilir nedenlere ayırmak.
Aynı Sipariş, Her Kolonda Başka Bir Sayım Birimi
Uyuşmazlığın kökeni raporlarda değil, tanımlarda. İki panelin altı ayrı kolonunda aynı sipariş altı farklı şeye dönüşüyor; bu görülmeden karşılaştırma anlamlı olmuyor.
| Kolon | Neyi sayar | Hangi güne yazar | Birim |
|---|---|---|---|
GA4 purchase | Sitede tetiklenen etkinlik | Etkinliğin günü | Tam sayı etkinlik |
Ads Conversions | Conversion action, sayım ayarına göre | Tıklamanın günü | Kredi payı, kesirli olur |
Ads Conversions (by conv. time) | Aynı eylem | Dönüşümün günü | Kredi payı, kesirli olur |
Ads All conv. | İkincil eylemler ve view-through dönüşümler dahil | Tıklamanın günü | Kredi payı |
Ads Orders / Revenue | Sipariş adedi ve tutarı, yalnızca sepet verisi paylaşan hesaplarda | Tıklamanın günü | Sipariş |
| GA4 Advertising raporları | Rapora göre değişir, tek bir sayım biçimi yok | Rapora göre değişir | Karma |
Buradan çıkan kurallar şunlar:
- Ads’in
Conversionskolonu sipariş adedi değildir.OrdersveRevenueayrı metriklerdir ve yalnızca sepet verisi paylaşan hesaplarda dolar.1 Her hesapta bulunmazlar.Ordersürünü değil siparişi sayar, aynı siparişteki iki ürün tek sipariştir;Revenueise sipariş düzeyindeki indirim düşülmüş tutardır.1 BulunuyorlarsaOrdersileConversionsarasındaki fark beklenen bir durumdur, eşitlenmeye çalışılmaz. - GA4 Advertising bölümü tek bir sayım biçimi değildir. Bölümdeki raporlar birbirinden farklı davranır.
Attributionraporları GA4’ün kendi modelini kullanır ve Ads’in kopyası değildir.Conversion performanceraporu ise Ads perspektifine alındığında Ads hesabına atfedilenAll conversionssayısıyla eşleşmek üzere tasarlanmıştır.2 Hangi raporun okunduğu bilinmeden bu bölümdeki bir sayı Ads ile karşılaştırılamaz. - Sayma ayarı conversion action bazında değişir ve varsayılanları tekdüze değildir. Web sitesi ve Analytics işlemleri için varsayılan
Every, Analytics hedefleri ve reklamdan gelen aramalar içinOne.3 Yani aynı hesapta, kimse bir seçim yapmadan, iki farklı sayma mantığı yan yana çalışıyor olabilir.Oneolan bir eylem, tek tıklamadan iki kez alan müşteride GA4’ün sistematik olarak altında kalır ve bunun tag ile hiçbir ilgisi yoktur. All conv.ileConversionsarasındaki fark bir teşhis aracıdır. Fark neredeyse sıfırsa o hesapta view-through şişmesi yoktur. Fark büyükse hemen view-through denmemeli: ikincil işaretlenmiş conversion action’lar da yalnızcaAll conv.içinde sayılır,Conversionskolonuna girmez.4
Yaygın Yanlış Bilgiler
| Yanlış Bilinenler | Google’ın Sunduğu Bilgi |
|---|---|
| ”Ads conversion window varsayılan olarak 90 gündür” | Varsayılan 30 gün. 90 gün ayarlanabilen üst sınır.5 |
| ”Ads last-click, GA4 data-driven kullanır” | DDA (data-driven attribution) çoğu conversion action’da Ads’in de varsayılanıdır, ama evrensel değildir. Last click hâlâ destekleniyor; kaldırılanlar ilk tıklama, doğrusal, zaman azalmalı ve konum bazlı modellerdir.6 |
| ”Fark görüntüleme dönüşümlerinden geliyor” | View-through dönüşümler Conversions kolonuna hiç girmez. All conv. içinde ve kendi ayrı kolonunda sayılır.7 Dahası GA4 bu dönüşümleri hiç desteklemez.8 |
| ”GA4 sayısı Ads’ten yüksekse ölçüm bozuktur” | Varsayılan ayar zaten asimetrik. GA4 raporları paid ve organic kanalları birlikte sayar, Ads raporları yalnızca Google paid kanallarını.9 |
| ”DDA için 200 dönüşüm ve 2.000 etkileşim eşiğini geçmek gerekir” | Eşik diye bir şey yok. Hacmi ne olursa olsun tüm conversion action’lar uygun. 200 dönüşüm ve 2.000 etkileşim bir eşik değil, modelin kalıpları daha iyi ayırt etmesi için verilmiş istatistiksel bir tavsiyedir.10 |
Üçüncüsü özellikle dikkat çekici, çünkü doğru gözlemden yanlış sonuca götürür: All conv. ile Conversions arasında fark vardır, ama GA4’ü Conversions kolonuyla karşılaştırmada view-through o farkın parçası değildir.
Zaman Ekseni: Tıklama Günü ile Dönüşüm Günü Aynı Şey Değil
Google Ads bir dönüşümü varsayılan olarak tıklamanın gerçekleştiği güne yazar.11 Bunun mantıklı bir nedeni var: maliyet zaten tıklama gününde oluşur, dönüşüm de aynı güne yazılınca günlük ROAS (Return on Ad Spend) kendi içinde tutarlı kalır. GA4 ise bir reklam paneli olmadığı için, ilgili key event’i davranışsal veri olarak etkinliğin gerçekleştiği güne yazar.
Sabit bir tarih aralığında bu iki kayıt biçimi arasında net bir akış oluşur. Pencereden önce tıklanıp pencere içinde dönüşen siparişler dönüşüm zamanı eksenine dahil olur, pencere içinde tıklanıp sonra dönüşenler ise dışarı çıkar. Örneğin, bazı hesaplarda aynı iki aylık pencerede dönüşüm zamanına göre okunan rakam, tıklama zamanına göre okunandan yaklaşık üçte bir oranında yüksek görünebilir.
Fark hunide derinleştikçe de büyüyor. Bir örnek hesapta (by conv. time) ile tıklama günü arasındaki sapma add_to_cart etkinliği ile ilişkili dönüşümde yaklaşık yüzde on üç, begin_checkout etkinliği ile ilgili dönüşümde yüzde on sekiz, purchase etkinliği ile ilişkili dönüşümde yüzde otuzdu. Yön mantıklı: eylem ne kadar geç gerçekleşiyorsa, tıklama gününe yazma kuralı onu o kadar yerinden oynatıyor. Yani bu örnekte zaman ekseni ağırlıklı olarak satın alma eylemini etkiliyor.
Daha önemlisi bu farkın kampanya tipine göre değişmesidir. Marka aramada karar süresi kısa olduğu için gecikme düşük kalıyor, dinamik arama ve ürün odaklı kampanyalarda ise fark iki katından fazlasına çıkabiliyor. Düşük hacimli kampanyalarda oran matematiksel olarak anlamını yitiriyor, tek bir siparişin gecikmesi yüzdeyi belirgin biçimde değiştiriyor.
Pratikte bunun üç sonucu var:
- Son günler her zaman eksik görünür ve sonradan dolar. Conversion window doksan güne kadar çıkabildiği için geriye dönük yazım uzun sürebilir.5 Dünkü ROAS’a bakıp karar vermek yapısal olarak hatalıdır. DDA ayrıca bir dönüşümü gerçekleştikten sonra yedi güne kadar yeniden ilişkilendirebiliyor, yani rakam dolduktan sonra bile yer değiştirebilir.12
- Uzun değerlendirme süreli kampanyalar sistematik olarak eksik sayılır. Marka kampanyası ile karşılaştırıldığında haksız biçimde kötü görünürler.
- Saat dilimi ayarı da farkı büyütür. Ads hesabının saat dilimi ile GA4 mülkünün saat dilimi farklıysa gün sınırındaki her sipariş yanlış tarafa düşer.13
Raporun Tarih Aralığı Nerede Bitmeli
Google bu konuda “yakın günlere dikkat” demekle yetinmeyip kontrol edilebilir bir kural veriyor: raporun tarih aralığı bugünden en az otuz gün geride bitmeli, conversion window’un daha uzunsa daha da geride.14 Tarih seçicisinde tek bakışta doğrulanır ve karşılaştırmaya oturmadan önce yapılacak ilk iştir.
Panel eksikliğin miktarını da verebiliyor. Smart Bidding kullanan hesaplarda, seçilen tarih aralığına daha fazla dönüşümün geleceği öngörülüyorsa, teklif stratejisi raporunda Conversions, Cost / conv. ve Conv. rate üzerine gelindiğinde ortalama gecikme süresi ve henüz raporlanmamış tahmini dönüşüm sayısı görünüyor; performans grafiğinde de hâlâ dolmakta olan tarih aralığı işaretleniyor.14 Koşul önemli: aralık yeterince geride bitiyorsa ya da bekleyen dönüşüm öngörülmüyorsa bu bilgi hiç çıkmaz ve bu bilginin çıkmaması da bir cevaptır. Müşteriye “son günler eksik” demek yerine, hiçbir dışa aktarma yapmadan eksiğin rakamını vermek mümkün.
Gecikmenin kendi dağılımını görmek içinse Campaigns, Ad groups veya Search keywords ekranında segment simgesinden Conversions > Days to conversion seçilir. Dönüşüm kolonlarını en fazla on dokuz satıra böler.14
Dönüşüm Zamanına Göre Raporlayan Kolonlar
Karşılaştırma yapmadan önce yapılacak ikinci normalizasyon: Ads tarafında dönüşüm zamanına göre raporlayan kolonlara geçmek. Bu kolonlar zaten üçüncü taraf analiz araçlarıyla karşılaştırma yapılabilsin diye eklenmiş durumda.11
Aile altı kolondan oluşuyor ve tamamı bu kadar: Conversions (by conv. time), Conv. value (by conv. time), Value / Conv. (by conv. time), All conv. (by conv. time), All conv. value (by conv. time), Value / all conv. (by conv. time).11
Listenin eksiği asıl bilgiyi veriyor: maliyet tarafının dönüşüm zamanı sürümü yok. Cost / conv. ya da harcama içeren başka bir kolonun bu ailede karşılığı bulunmuyor. Nedeni yapısal: maliyet tıklama gününe yazılır; dönüşümü kendi gününe taşıdığında pay ile payda iki farklı eksene oturur. Dolayısıyla bu kolonlarla CPA ya da ROAS hesaplamak yanlış olur. Karşılaştırma için kullan, verimlilik değerlendirmesi için kullanma; verimliliği tıklama günü kolonlarında oku.
İki kısıt daha var: veri Mart 2019’dan itibaren mevcut ve mağaza ziyareti ile mağaza satışı dönüşümleri bu kolonlara hiç girmiyor.11 Fiziksel mağazası olan bir hesapta dönüşüm zamanı toplamı, tıklama günü toplamının birebir karşılığı değildir; aradaki fark modelden değil kapsamdan gelir.
Aynı Rapor, Bir Açılır Menü, Yirmi Altı Puandan Başlayan Fark
Gecikme raporunda kolayca gözden kaçan bir kontrol var: süre ilk reklam etkileşiminden mi son etkileşimden mi ölçülsün. Örnek bir hesapta aynı haftayı aynı lookback window’da, yalnızca bu menüyü değiştirerek iki kez çektim. Toplam dönüşüm sayısı ikisinde de birebir aynı. “Bir günden az” kovasının payı ise şöyle:
| Lookback window | Son etkileşimden | İlk etkileşimden |
|---|---|---|
| Otuz gün | %83,9 | %58,3 |
| Altmış gün | %81,1 | %53,7 |
| Doksan gün | %80,3 | %51,7 |
Fark tek bir açılır menüden geliyor ve pencereye göre değişiyor: otuz günde yaklaşık yirmi altı puan, altmış günde yirmi yedi, doksan günde yirmi dokuz. Yani “müşterilerimiz aynı gün alıyor” cümlesi, müşteri davranışını değil hangi kontrolün varsayılanda bırakıldığını anlatıyor. İki sütunun aralığı pencere genişledikçe açılıyor, çünkü geniş pencere daha geriye giden ilk temaslar buluyor.
Kuyruğun kendisi de bilgi taşıyor. Aynı hesapta iki aylık bir aralığa baktığımda dönüşümlerin yaklaşık altıda biri aynı gün gerçekleşmiyordu: yüzde on biri bir haftadan, yüzde yedisi iki haftadan, yüzde ikisi bir aydan uzun sürüyordu. Bu dağılımın bir özelliğini atlamamak gerekiyor: rapor tüm conversion action’ları birlikte gösteriyor ve o hesapta kolonun üçte ikisi sepete ekleme. Yani bu bir satın alma gecikmesi eğrisi değil, aynı oturumda tetiklenen bir mikro dönüşümün baskın olduğu bir dağılım; satın almalar eğrinin uzun ucunda duruyor. Son dilim yine de önemli, çünkü otuz günlük varsayılan conversion window’da o dönüşümler hiç kaydedilmez; hesabın penceresi daha uzun olmasa raporda o kovalar boş çıkardı.
Bu dağılımın kendisinde de bir yanlılık var ve yönü bellidir. Raporu bugüne kadar çekersen son günlerin geç dönüşümleri henüz gerçekleşmemiştir, yani kısa kovalar tamamlanmışken uzun kovalar hâlâ dolmaktadır. Aralığın en az otuz gün geride bitmesi gerektiği kuralı14 tam da bunun için var. Sonuç olarak aynı gün payı, hangi menüyle ölçülürse ölçülsün, olduğundan yüksek görünür.
Bu, konunun tamamının küçük ölçekli bir örneği: sayı değişmiyor, tanım değişiyor.
Buraya kadarki iki eksen, sayım birimi ve zaman, farkın büyük kısmını kapatıyor ve ikisi de hiç kod yazmadan, yalnızca panel ayarlarıyla hizalanıyor. Geriye iki soru kalıyor ve ikisi de kendi başına bir yazıyı hak ediyor.
Birincisi, panelde bir siparişin karşısında neden 0.29 gibi kesirli bir değer göründüğü. Yaygın açıklama DDA’yı işaret ediyor ama eksik: kesirli değerin birbirine karışan iki ayrı nedeni var ve hangisiyle karşı karşıya olduğunu anlamanın basit bir testi var. Ads panelinde kesirli dönüşüm yazısında model karşılaştırmasını, pencere testini ve hesap düzeyinde ölçtüğüm toplam korunumunu ele aldım.
İkincisi, iki panelin nasıl gerçekten karşılaştırılacağı. Toplamları yan yana koymak yerine iki tarafta da bulunan ortak bir kimlik üzerinden satır seviyesinde birleştirmek gerekiyor. Satır seviyesinde birleştirme yazısında birleştirme anahtarının nasıl seçildiğini, sonucun neden tek bir eşleşme oranı olarak okunamayacağını ve yöntemin ölçülen tavanını anlattım. On dört maddelik kontrol listesi de orada.
Zaman ekseni ve pencere genişliği ayrıştırıldığında kalan fark genellikle beklenenden küçük çıkıyor. Mevcut kurulumun hangi kalemde ne kadar veri kaybettiğini satır seviyesinde çıkarmak genellikle bir günlük bir iş.
Durumu AktarFootnotes
-
Sepet verili dönüşüm metrikleri (Google Ads Yardım).
OrdersveRevenuemetrikleri için ön koşul açık: “You must share cart data as part of your website or app conversions.” ↩ ↩2 - Dönüşüm performansı raporu (Google Analytics Yardım). “In both the data visualizations and the data table, the All conversions count attributed to your Google Ads account will match the count you see in Google Ads.” Aynı sayfa, bazı büyük mülklerde hiçbir kanala atfedilemeyen dönüşümlerin toplamdan çıkarılabildiğini ve bu durumda veri kalitesi simgesinin göründüğünü belirtiyor. ↩
-
Dönüşüm sayma seçenekleri hakkında (Google Ads Yardım). Varsayılan sayma ayarı dönüşüm kaynağına göre değişir: web sitesi, uygulama içi işlemler, Analytics işlemleri ve içe aktarma eylemlerinde “Her dönüşüm”; reklamdan gelen aramalar, Analytics hedefleri ve uygulama yüklemelerinde “Bir dönüşüm”. Aynı sayfa tekrarlama oranını “her dönüşüm sayısının bir dönüşüm sayısına bölünmesi” olarak tanımlıyor ve ayarı değiştirmenin bu oranı değiştirmediğini belirtiyor. Sayma seçimi
Conversions,All conv.veView-through conv.kolonlarına yansıyor. ↩ -
Conversion goals overview (Google Ads API).
primary_for_goalalanıfalseolan conversion action’lar “All conv.” ve türevlerinde görünür, “Conversions” kolonuna girmez ve teklife katılmaz. Aynı sayfa, GA4’ten içe aktarılan dönüşümlerde API üzerinden değiştirilebilen alanları da sıralıyor. ↩ - About conversion windows (Google Ads Help). Aralık her conversion action için ayrı ayarlanır: “You can set different conversion windows for each of your conversion actions.” Tıklama conversion window’un varsayılanı otuz gündür ve Arama ile Görüntülü Reklam kampanyalarında kaynağa göre otuz, altmış veya doksan güne kadar çıkarılabilir. ↩ ↩2
- About attribution models (Google Ads Help). Ads tarafında iki model destekleniyor: “Last click” ve “Data-driven”. Sayfa DDA’yı “the default attribution model for most conversion actions” olarak tanımlıyor, yani tümü için değil; ayrıca last click’in “still supported” olduğunu belirtiyor. Kaldırılanlar ilk tıklama, doğrusal, zaman azalmalı ve konum bazlı modeller. Kredi dağıtımının kendisi için ayrıca DDA sayfası. ↩
-
Dönüşüm izleme verilerinizi anlama (Google Ads Yardım). “Google Analytics ile Google Ads arasındaki verileri adil bir şekilde karşılaştırmak için Google Analytics Reklamcılık bölümüne gidin veya raporları google / cpc olarak ayarlanan ‘Oturum kaynağı / aracı’ için filtreleyin… nihai sonuçları karşılaştırmadan önce her zaman 24-48 saatlik işlem gecikmesini hesaba katın.” Aynı sayfa view-through dönüşümlerinin
Conversionskolonuna hiç girmediğini, yalnızcaAll conv.içinde sayıldığını da belirtiyor. ↩ - İlişkilendirme raporları hakkında (Google Ads Yardım). Dönüşüm kapsamı satırı: “Etkileşimli görüntüleme dönüşümleri (KGD’ler) hem Google Ads’de hem de Google Analytics 4 (GA4) mülklerinde desteklenir ancak gösterimlerle ilişkilendirilen dönüşümler (GD’ler) şu anda GA4’te desteklenmemektedir.” ↩
- İlişkilendirme ayarlarını seçme (Google Analytics Yardım). Varsayılan kanal ayarı iki tarafta farklıdır: Ads raporlarında Google paid, GA4 raporlarında paid ve organic. Aynı sayfa key event lookback window’un varsayılanını edinme etkinlikleri için otuz, diğer tüm key event’ler için doksan gün olarak veriyor ve saat dilimi farkını da uyuşmazlık kaynağı sayıyor. ↩
- Veriye dayalı ilişkilendirme hakkında (Google Ads Yardım). İngilizce sürümde birebir: “All conversion actions are eligible for data-driven attribution (DDA), regardless of conversion or interaction volume.” 200 dönüşüm ve 2.000 etkileşim eşik değil tavsiye; sayfa modelin daha az veriyle de çalıştığını belirtiyor. Model reklamverene özeldir, dönüşen yollarla dönüşmeyen yolları karşılaştırarak kredi dağıtır. Aynı sayfa toplamların eşitliğini garanti olarak vermiyor, yalnızca “last click ve veriye dayalı ilişkilendirme modelleri belirli durumlarda aynı sonuçları verebilir” diyor. ↩
-
Understand your conversion tracking data (Google Ads Help).
(by conv. time)kolonları dönüşümün gerçekleştiği güne raporlar: “Conversions (by conv. time) columns report conversions based on the date the conversion occurred.” Aynı sayfa bu kolonların üçüncü taraf analiz ve CRM sistemleriyle karşılaştırma için eklendiğini belirtiyor. ↩ ↩2 ↩3 ↩4 - İlişkilendirmeye başlarken (Google Analytics Yardım). DDA hakkındaki notta açıkça yazıyor: “Conversions can be reattributed for up to 7 days after the conversion.” Aynı sayfa modelin girdilerini de sıralıyor: dönüşüme kalan süre, cihaz tipi, reklam etkileşimi sayısı, gösterim sırası ve kreatif tipi. ↩
- Data discrepancies: Factors and troubleshooting (Google Ads Help). Ads raporlaması hesabın saat dilimini kullanır; hesap ile mülkün saat dilimi farklıysa raporlarda uyuşmazlık görülür. Aynı sayfa dönüşüm gecikmesini ve geçersiz trafik filtrelemesini de fark kaynağı olarak sayar. ↩
- Müşterilerinizin dönüşüm gerçekleştirmesinin ne kadar sürdüğünü öğrenin (Google Ads Yardım). “Raporunuzun eksiksiz dönüşüm verilerini içerdiğinden emin olmak için raporun tarih aralığının en az 30 gün önce (veya daha uzun bir conversion window’a sahipseniz daha uzun süre) bitip bitmediğini kontrol edin.” Aynı sayfa segment yolunu (Dönüşümler > Dönüşüme kadarki gün sayısı, en fazla 19 satır) ve Akıllı Teklif raporlarında henüz raporlanmamış tahmini dönüşüm sayısının nasıl görüleceğini veriyor. ↩ ↩2 ↩3 ↩4
- 01 Ads dönüşümü tıklama gününe yazar, GA4 etkinlik gününe (örneğin, satın alma) yazar. Aynı pencerede iki kolon arasındaki fark üçte bire yaklaşabilir ve kampanya tipine göre iki katından fazla değişir.
- 02 Ads'in Conversions kolonu sipariş adedi değildir. Sipariş adedini veren Orders ve Revenue metrikleri yalnızca sepet verisi paylaşan hesaplarda bulunur, aradaki fark beklenen bir durumdur ve eşitlenmeye çalışılmaz.
- 03 Dönüşüm zamanına göre raporlayan kolon ailesi altı kolondan ibaret ve maliyet tarafının karşılığı yok. Bu kolonlarla CPA ya da ROAS hesaplamak yanlış olur; karşılaştırma için kullanılır, verimlilik değerlendirmesi için değil.
- 04 Raporun tarih aralığı bugünden en az otuz gün geride bitmeli, conversion window daha uzunsa daha da geride. Bu sağlanmadan çekilen hiçbir karşılaştırma tam değildir ve son günler sonradan dolar.
- 05 Gecikme raporundaki 'aynı gün' payı, müşteri davranışını değil hangi kontrolün varsayılanda bırakıldığını anlatıyor: süre ilk etkileşimden mi son etkileşimden mi ölçülüyor sorusu aynı veride yirmi altı puandan başlayan bir fark üretiyor.
+ Google Ads dönüşüm sayısı GA4 satın alma sayısından neden yüksek çıkar?
En büyük tek neden zaman eksenidir. Ads dönüşümü varsayılan olarak tıklamanın gerçekleştiği güne yazar, GA4 ise etkinliğin gerçekleştiği güne. Sabit bir tarih aralığında pencereden önce tıklanıp içeride dönüşen siparişler Ads tarafında içeri girer, içeride tıklanıp sonra dönüşenler dışarı çıkar. Karşılaştırmadan önce Ads tarafında dönüşüm zamanına göre raporlayan kolonlara geçmek gerekir. İkinci neden sayım birimidir: Ads kolonu sipariş adedi değil, kredi payı taşır.
+ GA4'te dönüşüm sayısı Google Ads'ten yüksek çıkıyorsa kurulum bozuk mudur?
İki panelin varsayılan kanal ayarı zaten asimetriktir: GA4 raporları paid ve organic kanalları birlikte sayar (GA4 model alanında 'Paid and organic channels' olarak görebilirsin), Google Ads raporları yalnızca Google paid kanallarını. Buna bir de şu eklenir: Ads tarafındaki conversion action bir GA4 key event'inden besleniyorsa, GA4 yalnızca Google Ads'in last non-direct click olduğu etkinlikleri Ads'e gönderir. Google Ads'in yolda olduğu ama last click olmadığı her sipariş GA4'te görünür, Ads'te görünmez. Karşılaştırma yapmadan önce iki tarafın kanal ayarını okumak ve GA4 tarafını paid ve organic last click modeline almak gerekir.
+ Ads'in Conversions kolonu kaç sipariş olduğunu söyler mi?
Söylemez. O kolon kredi payı taşır ve hesapta kaç conversion action'ın birincil işaretlendiğine göre tek siparişte birden büyük çıkabilir. Sipariş adedini veren metrikler Orders ve Revenue, ama bunlar yalnızca sepet verisi paylaşan hesaplarda dolar. Orders ürünü değil siparişi sayar, Revenue ise sipariş düzeyindeki indirim düşülmüş tutardır. Bulunuyorlarsa Conversions ile aralarındaki fark beklenen bir durumdur.
+ (by conv. time) kolonlarıyla CPA veya ROAS hesaplanır mı?
Hesaplanmaz. Bu ailenin altı kolonu var ve hiçbiri maliyet içermiyor; Cost / conv. gibi bir kolonun dönüşüm zamanı sürümü yok. Nedeni yapısal: maliyet tıklama gününe yazılır, dönüşümü kendi gününe taşıdığında pay ile payda iki farklı eksene oturur. Bu kolonları üçüncü taraf araçlarla karşılaştırma için kullan, verimliliği tıklama günü kolonlarında oku. İki kısıt daha var: veri Mart 2019'dan itibaren mevcut ve mağaza ziyareti ile mağaza satışı dönüşümleri bu kolonlara hiç girmiyor.
+ Dünkü ROAS'a bakıp karar vermek neden hatalı?
Çünkü son günler yapısal olarak eksik görünür ve sonradan dolar. Conversion window doksan güne kadar çıkabildiği için geriye dönük yazım uzun sürebiliyor, DDA ayrıca bir dönüşümü gerçekleştikten sonra yedi güne kadar yeniden ilişkilendirebiliyor. Google'ın kendi kuralı, raporun tarih aralığının bugünden en az otuz gün geride bitmesi. Smart Bidding kullanan hesaplarda panel eksiğin tahmini rakamını da verebiliyor, ama bu bilgi yalnızca aralığa daha fazla dönüşüm geleceği öngörülüyorsa çıkıyor.