Global Site Tag (gtag.js) Etkinlik İşlemleri

---

gtag.js (artık resmî adıyla Google tag), tek bir snippet üzerinden birden fazla Google ürününe (Analytics, Ads, Campaign Manager) veri göndermeyi mümkün kılan birleşik etiketleme katmanı. API tek bir fonksiyondan ibaret: gtag(<command>, <params>). Beş komut var¹: config (hedef yapılandırma), set (sayfa genelinde global parametre), event (event gönderimi), get (çağrı/callback ile değer okuma) ve consent (Consent Mode). Parametre kapsamı event > config > set önceliğiyle çalışır; çoklu mülk yönetimi, gruplama (groups parametresi) ve event yönlendirme (send_to parametresi) bu yapı üzerinde kuruluyor.

Bu yazıda gtag.js komutlarıyla event gönderiminin nasıl şekillendiğine, GA ile GA4 arasındaki parametre farklarına, koddan arayüze taşınan ayarlara ve sık karşılaşılan veri akışı sorunlarına (özellikle “Config command out of order” tipi sıralama hatalarına) bakacağım.

Global Site Tag (gtag.js) Etkinlik İşlemleri

Tek bir global snippet üzerinden hem Google Ads hem Google Analytics’i config parametresiyle başlatabilirsiniz.

Global Site Tag (gtag.js) event (etkinlik) işlemlerinde de yine bu yapı çerçevesinde hareket edilmekte. Bu sayede, birden fazla site (subdomain olmak zorunda değil) ve birden fazla Google Analytics ve Google Ads mülkünü tek bir satırda ve ayrı cookie tanımlamaları üzerinden tanımlamak kolaylaştırılmış durumda.

gtag("config", "GA_TRACKING_ID", {
  send_page_view: false,
});
gtag("config", "GA_TRACKING_ID_2");
gtag("config", "GA_TRACKING_ID_3");

Örneğin, yukarıdaki kod belirttiğiniz Google Analytics mülkü GA_TRACKING_ID’nün page_view takip etmemesini, tanımlanan diğer GA_TRACKING_ID2, GA_TRACKING_ID3 mülklerinin ise sorunsuz şekilde sayfa etkinliklerini almasını sağlayacaktır. Bu kullanım gruplama özelliğini de beraberinde getirmekte³. Google Analytics mülkünden Google Analytics 4 (GA4) mülküne geçişte de yine yapmanız gereken sadece GA4’e ait GA_TRACKING_ID değerini config ile belirtmek olacaktır.

Örneğin yukarıdaki tanımlama mülkleri default grubu altında işleyecektir. Açık bir şekilde tanımlama yapmak istersek kullanımı şu şekilde olacaktır:

gtag("config", "GA_TRACKING_ID_1", {
  groups: "default",
});
gtag("config", "GA_TRACKING_ID_2", {
  groups: "default",
});

Yukarıdaki mülkler default grubu içerisinde tanımlanır. groups kullanıcı tarafından atandığında ise kullanım şu şekilde olur:

gtag("config", "GA_TRACKING_ID_1", {
  groups: "access",
});
gtag("config", "GA_TRACKING_ID_2", {
  groups: "access",
});

Belirtilen mülk ID’leri access grubu altında tanımlanmış olur. Group tanımlaması event işlemlerinde istenilen verilerin belirtilen gruplara ve bu gruplar altındaki mülk ID’lerine iletilmesini sağlar.

Etkinliklerin İletilmesi

gtag.js eventleri bir event_name ve parametre listesinden oluşur. Universal Analytics raporlarında eventler Kategori, İşlem, Etiket ve Değer şeklinde gösterilirdi; GA4’te ise bu sabit yapı yerini event adı + serbest parametre modeline bıraktı. Her iki yapıda da bazı eventlerin tetiklenmesi için belirli bir kullanıcı aksiyonunun (görüntüleme, tıklama, gönderme gibi) gerçekleşmesi gerekir. Event adı bu tetikleyicilerle ilişkilendirildiği için isimlendirmenin belirli bir örüntü ve amaç takip etmesini öneririm.

gtag("event", "event_name", {
  send_to: "access",
  parameter_1: "value_1",
  parameter_2: "value_2",
  // ...
});

GA4 tarafında artık öntanımlı etkinliklerimiz (automatically-collected event) mevcut⁴.

• language
• page_location
• page_referrer
• page_title
• screen_resolution

Bu sayede kullanıcı tarafında sıklıkla gerçekleştirilen işlemler doğrudan Etkinlikler raporuna aktarılır. GA4’ün event modeli ise Universal Analytics’ten farklı şekilde kurgulanıyor; ayrıntıya birazdan geliyorum.

Örneğin, bu etkinlik access grubu ile etkileşime geçecektir. send_to kullanıcı tanımlı bir grup ile belirtilmemişse etkinlikler default gruba iletilecektir. Birden fazla grupla etkileşime geçilecek etkinlik ifadelerinde kullanım şu şekilde olacaktır.

// Kod yapısı
gtag('event', 'event_name', {
  send_to: ['group_name_1', 'group_name_2', ... ],
  parameter_1: 'value_1',
  parameter_2: 'value_2',
  // ...
});

Universal Analytics Temmuz 2023’te kapatıldığı için artık iki paralel model tutmaya gerek yok. GA4’ün event adı + parametre yapısı tek geçerli yol; eski Kategori/İşlem/Etiket alışkanlığını GA4’e taşımaya çalışmak veri tutarsızlığı yaratır.

// GA Sayfa görüntüleme işleminin ayrıca iletilmesi
gtag("config", "GA_MEASUREMENT_ID", {
  page_title: "homepage",
  page_path: "/home",
});

// GA Sayfa görüntüleme işleminin pasif hale getirilmesi
gtag("config", "GA_MEASUREMENT_ID", {
  send_page_view: false,
});

// GA Sayfa görüntüleme işleminin etkinlik olarak iletilmesi
gtag("event", "page_view", {
  page_title: "<Page Title>",
  page_location: "<Page Location>",
  page_path: "<Page Path>",
  send_to: "<GA_MEASUREMENT_ID>",
});

Universal Analytics etkinlik anatomisi (tarihsel referans):

Ad	Parametre	Durum
Kategori	event_category	Gerekli
İşlem	event_action	Gerekli
Etiket	event_label	Kullanımı tavsiye edilir
Değer	value	Opsiyonel

GA4’te bu sabit anatomi yok. Event bir ad + serbest parametre listesinden oluşur. Recommended eventlerin önerilen parametreleri belirlidir; custom eventlerde istediğiniz parametreleri serbestçe ekleyebilirsiniz⁵.

Yaygın GA4 recommended event parametreleri:

Event	Önerilen parametreler
login	method
sign_up	method
search	search_term (zorunlu)
view_item	currency, value, items[]
add_to_cart	currency, value, items[]
purchase	transaction_id (zorunlu), value, currency, items[]
generate_lead	value, currency

Örneğin GA4’te login recommended eventtir ve hangi kanal üzerinden giriş yapıldığını method parametresiyle taşır:

gtag("event", "login");

gtag("event", "login", {
  method: "Google",
});

Custom event yapısı, yani önerilen recommended event isimleri yerine kendi event adınızı ve parametrelerinizi kullanmak istediğinizde⁵:

gtag("event", "newsletter_signup", {
  signup_location: "footer",
  newsletter_type: "weekly",
});

Peki, grup bağlamında login etkinliğini farklı gruplarla iletişime geçecek şekilde uygulamak istersek:

gtag("event", "login", {
  send_to: ["default", "group_1", "group_2"],
  method: "Google",
});

Gruplama, global snippet, mülk temelli etkinlik işlemleri ve önerilen etkinlikler gtag.js özelliklerinden sadece birkaçı.

send_to ve groups Davranışı

send_to belirtilmediğinde event, sayfadaki tüm config çağrılarının doldurduğu default grubuna gider. Belirtildiğinde tek bir mülk ID’si, grup adı veya bunların karışık bir dizisi kullanılabilir:

gtag("event", "add_to_cart", {
  send_to: ["G-XXXXXX-1", "AW-YYYYYY", "agency"],
  ecommerce: {
    //...
  }
});

Resmi dokümantasyonda¹ göze çarpan iki kural var ki yapılandırırken atlanması veri kaybına yol açar:

• Grup adında tire (-) yasak. agency-team çalışmaz; agency_team ya da agencyTeam kullanın.
• config zaten hedefi default grubuna ekler. Yani groups: 'default' yazmak gereksiz; ancak grup adını açıkça belirtmek istiyorsanız yanlış da değil.

Kod Yerine Arayüzden Yönetilebilen Ayarlar

Eskiden yalnızca gtag('config', ...) parametresiyle yapılabilen birçok ayar artık Google tag arayüzünden (Google Ads > Data Manager, GA4 > Data Streams, GTM > Google tags) doğrudan yönetilebiliyor⁶. Bu, özellikle CMS kullanan veya site koduna sık dokunamayan ekipler için bir kaldıraç.

Arayüzden yapılandırılabilen başlıca ayarlar:

• Otomatik etkinlik tespiti: page_view, scroll, outbound click, form interaction, video engagement, file download. Varsayılan olarak hepsi açık; istemediğiniz event türünü tek tıkla kapatabilirsiniz.
• Domain yapılandırması: cross-domain measurement (eskiden linker parametresiyle yapılırdı).
• Kullanıcı tarafından sağlanan veri (user-provided data): enhanced conversions için otomatik tespit, CSS selector veya manuel kod.
• İç trafik tanımı: IP adresi bazlı traffic_type etiketleme (GA filtreleriyle birlikte kullanılır).
• İstenmeyen referans listesi: belirli domain’lerden gelen trafiği referans olarak saymama (ignore_referrer).
• Oturum zaman aşımı: varsayılan 30 dakika, etkileşimli oturum eşiği 10 saniye.
• Çerez ayarları: süre ve güncelleme davranışı.
• Consent mode override: bölge bazlı varsayılan consent state.

Pratik etki: site kodunuzda sadece tag snippet’i bırakıp send_page_view, cross-domain, otomatik scroll/click takibi gibi ayarları arayüzden çevirebilirsiniz. Kod tarafındaki gtag() çağrıları ise mülk bazlı ince ayar, event gönderimi ve özel parametreler için kullanılmaya devam ediyor.

Event Callback ile Senkron Akışlar

Form submit veya yönlendirme gerektiren senaryolarda tetikleyiciyi doğrudan onclick’e bağlarsanız event request’i tarayıcı tarafından kesilebilir; ölçüm bitmeden sayfa değişir. event_callback ve event_timeout parametreleri tam bu sorunu çözer⁷:

function trackedSubmit(form) {
  gtag("event", "generate_lead", {
    send_to: "AW-YYYYYY",
    value: 99.99,
    currency: "USD",
    event_callback: function () {
      form.submit();
      console.log("Event completed");
    },
    event_timeout: 2000,
  });
  return false;
}

event_callback event işlemi tamamlandığında çalışır; event_timeout (ms) ise işlem askıda kalsa bile callback’in tetikleneceği üst sınırdır. İkisini birlikte kullanarak ölçüm güvenli, kullanıcı akışı da bloklanmamış olur.

Mülk ve Event Akışının Ayrışması

Her şey doğru olmasına karşın (kod üzerinden bakıldığında) veri akışında hâlâ sorun yaşıyor olabilirsiniz. Bunun muhtemel bazı nedenleri var.

Config Komutu Sıralaması

Google Tag Diagnostics’te sık karşılaşılan uyarılardan biri “Config command out of order”⁸. Bir sayfada event komutu, ilgili mülk için config komutundan önce çalıştırılırsa event verisi beklenmedik davranır; özellikle client_id, cookie_domain, cookie_prefix, linker, server_container_url, session_id, transport_url, user_id gibi ayarlar tetiklenmemiş olur.

Yanlış sıralama:

<script>
  gtag("config", "G-ABCDEF");
</script>
<script>
  gtag("event", "generate_lead", {
    send_to: "G-1234567",
    currency: "USD",
    value: 99.99,
  });
  // config G-1234567 burada gelirse, event ondan önce çalışmış olur
  gtag("config", "G-1234567", { user_id: "U1234" });
</script>

Doğru sıralama: tüm config komutları, ilgili event komutundan önce yüklenmeli.

<script>
  gtag("config", "G-ABCDEF");
  gtag("config", "G-1234567", { user_id: "U1234" });
</script>
<script>
  gtag("event", "generate_lead", {
    send_to: "G-1234567",
    currency: "USD",
    value: 99.99,
  });
</script>

Bu sorun özellikle birden fazla mülke event gönderen kurulumlarda, CMS şablonlarında snippet’lerin yanlış sırayla eklenmesinden kaynaklanır. send_to ile hedef belirtilmiş olsa bile, hedef mülkün config komutu daha sonra çalışıyorsa veri eksik kalır.

Resmi rehber bir adım daha ileri gider: bir Google tag için config komutunu yalnızca bir kez çağırın, sonraki çağrılarda set komutunu kullanın¹. Aynı mülk için ikinci bir config çalıştırmak (örneğin user_id’yi sonradan eklemek için) bu yüzden öngörülemez sonuçlar üretebilir; bunun yerine gtag('set', { user_id: 'U1234' }) daha güvenli.

Tag Birleştirme ve Hedef Soyutlaması

Google tag arayüzünde iki etiketi (örneğin bir AW-XXXXXX ile bir G-YYYYYY) “Combine Google Tags” özelliğiyle birleştirdiğinizde, birleşen etiketlerden biri ana taşıyıcı (AW- veya GT-) rolünü üstlenir; diğeri bağımsız bir etiket olmaktan çıkıp yalnızca bir “destination” konumuna düşer. Pratik sonuç: ikincil hale gelen G-YYYYYY için CDN’de artık standalone bir gtag.js dosyası yayınlanmaz.

Kaynak kodunda şu satırı çağırırsanız:

<script async src="https://www.googletagmanager.com/gtag/js?id=G-YYYYYY"></script>

Tarayıcı konsolunda net::ERR_ABORTED 404 (Not Found) hatası alırsınız. Ana taşıyıcı (AW-XXXXXX) sorunsuz yüklenirken aynı sayfada bağımsız bir G- kütüphanesi çekmeye çalışmak başarısız olur, çünkü o G- kimliği artık ana etiketin alt hedefi konumunda.

Çözüm, sayfaya ikinci bir gtag.js eklemek değil; halihazırda yüklü olan AW- (veya GT-) kütüphanesi üzerinden event’i send_to ile yönlendirmek:

gtag("event", "purchase", {
  send_to: "G-YYYYYY",
  transaction_id: "T_12345",
  value: 299.99,
  currency: "USD",
});

Birleştirme arayüzden geri alınabilir gibi görünse de bazı durumlarda ana taşıyıcı seçildikten sonra dönüş yolu kapanır; bu yüzden birleştirmeden önce hangi etiketin “blueprint” olacağını dikkatlice belirlemek gerekiyor.

GTM Otomatik Google tag Yüklemesi

10 Nisan 2025 itibariyle Google Ads veya Floodlight tag’i içeren GTM kapsayıcıları, event tetiklendiğinde ilgili Google tag’i otomatik olarak yüklemeye başladı. Niyet iyi: yapılandırma eksikse event’ler yine de Google’a ulaşıyor. Ancak otomatik yüklenen bu kütüphane manuel yapılandırmadan bağımsız çalışır ve birkaç eksikle gelir:

• page_view event’i otomatik gönderilmez.
• Enhanced measurement event’leri (outbound click, scroll, file download) bu otomatik kütüphaneden tetiklenmez.
• Sayfada zaten manuel bir AW- veya G- snippet’i varsa, eşzamanlı iki Google tag yüklemesi çift sayım veya net::ERR_ABORTED ile sonuçlanabilir.

Pratik öneri: GTM kullanıyorsanız Google tag yapılandırmasını GTM içinden açıkça kurun, sayfada paralel bir manuel snippet bırakmayın. İkisini birlikte kullanmanız gerekiyorsa Tag Diagnostics’teki “Tag coverage” raporunu düzenli kontrol edin.

Otomatik Mülk Aktarımı

Universal Analytics yerini Google Analytics 4’e bırakırken sayfada bir bildirimin yer aldığını görmüşsünüzdür. Belirtilen tarihe kadar mülk aktarımının yapılmaması durumunda aktarım işlem otomatik olarak planlandığı şekilde gerçekleştirildi. Ancak, bu aşamada bazı mülklerde yapılandırma sorunları da söz konusu oldu. Var olan UA mülküyle ilişkili diğer mülkler temelinde GA4 mülkünün config çağrısında G- ve GT- en yaygın ölçüm kimliği tanımları olarak listelense de bazı durumlarda MC- ve AW-’in de burada yer aldığını fark ettim.

Bu durum config ile event arasında bir ilişki ayrımı yaratmakta. Config temelde tracking kütüphanesini ve yapılandırmayı kapsarken event hedefi için farklı bir mülk tanımının send_to ile ele alınması gerekebilmekte. Bu durum “Tag Birleştirme ve Hedef Soyutlaması” ve “Hatalı Yapılandırma” başlıkları ile benzerlik göstermekte.

Hatalı Yapılandırma

Bir Google Analytics 4 mülkünü farklı uygulamalar ve bağlantılar üzerinden de oluşturabilirsiniz. Merchant Center ve Google Ads bunun en yaygın örnekleri. Bu mülk ilişkili yapıda kimi zaman Google Analytics 4 yapılandırması ana mülk olarak diğer mülkün verileri alacak şekilde ele alınır. Yani, asıl veri kaynağı Google Ads iken hedef olarak Google Analytics 4 eklenir ve veri Google Ads üzerinden edinilir. Bu tür durumda yine config için Google Ads ele alınırken verinin (harici event verileri, vb.) send_to ile ayrıca iletilmesi gerekir. Çünkü, Google Ads’e iletilen event verileri ile Google Analytics 4’e iletilen veriler farklılık gösterebilir.

Eğer Google Analytics 4 etkinlik raporlarında sıklıkla sayfa görüntüleme ve diğer otomatik toplanan event’leri görüyorsanız ancak ecommerce ve diğer özelleştirilmiş event verileri bu raporlara yansımıyorsa muhtemel durum bu başlık altında belirttiğim mülkler arası veri aktarımı ile ilişkilidir.

Sandbox Kısıtlamaları

Eğer Shopify Pixel kullanıyorsanız burada birkaç farklı durumu bir arada yaşayabilirsiniz. İlk olarak, daha önce kullandığınız Universal Analytics ile GA4 geçişinde bir sorun yaşanmış olabilir; bkz: Otomatik Mülk Aktarımı. İkinci olarak, Google & Youtube uygulaması üzerinden Google Ads’i oluşturmuşsanız ve mülk işlemlerini otomatik gerçekleştirmişseniz mülkler birbirleri ile hedef bağlamında ilişkilendirilmiş olabilir; bkz: Hatalı Yapılandırma. Son olarak, pixeller yapısı gereği sandbox modunda çalışır. Yüklendiği aşama ve sonrasında page_viewed ile (en temelde) ilk veriler elde edilir. Eğer kurulum script’i sayfa akışlarında yüklenmiyorsa ve/veya config geride kalıyorsa (çeşitli kontroller nedeniyle) event verisi nereye gideceğini bilemez. Bu tür durumlarda yine her event için send_to kullanılması oluşacak akış problemlerinin de önüne geçecektir.

---

Footnotes

1. Google tag API reference. Google Developers ↩ ↩² ↩³
2. About the Google tag. Google Tag Manager Help ↩
3. Send data to Google Analytics with gtag.js. Google Analytics ↩
4. Otomatik olarak toplanan etkinlikler ↩
5. Measure Google Analytics Events. Google Analytics ↩ ↩²
6. Configure your Google tag settings. Google Tag Manager Help ↩
7. Google tag parameter reference. Google Developers ↩
8. Troubleshoot: Config command out of order. Google Analytics Help ↩

Önemli Noktalar

• 01 config ile hedef yapılandırılır, set ile global parametre, event ile event gönderilir, send_to ile yönlendirilir
• 02 GA4'te eski category/action/label modeli yok; event adı + recommended/custom parametreler
• 03 Recommended event örnekleri: login → method, purchase → transaction_id + value + currency + items[]
• 04 Çoklu mülk kurulumlarında send_to ile açık hedef belirtin
• 05 Config command out of order için config çağrılarını eventlerden önce yükleyin

Sık Sorulan Sorular (FAQ)

+ gtag.js ile birden fazla GA mülkü nasıl yönetilir?

Her mülk için ayrı config çağrısı yapılır. groups parametresiyle mülkler gruplandırılabilir. send_to ile eventler belirli gruplara yönlendirilebilir.

+ GA ve GA4 etkinlik parametreleri arasındaki fark nedir?

Universal Analytics her event için event_category, event_action, event_label ve value parametrelerini beklerdi. GA4'te bu sabit yapı yok; event adı + serbest parametre listesi var. Recommended eventlerin (login, purchase, search gibi) önerilen parametreleri belirli, custom eventlerde istediğiniz parametreleri ekleyebilirsiniz.

+ send_to parametresi ne işe yarar?

Event verilerini belirli mülklere veya gruplara yönlendirmek için kullanılır. Belirtilmezse event default gruba gönderilir.

+ GA4'e otomatik geçişte veri kaybı yaşanır mı?

Otomatik mülk aktarımı sırasında config ve event hedefleri arasında uyumsuzluk oluşabilir. Her event için send_to kullanmak bu sorunu önler.

+ Shopify Pixel ile gtag.js kullanırken nelere dikkat edilmeli?

Sandbox kısıtlamaları, otomatik mülk aktarımı ve hatalı yapılandırma sorunları yaşanabilir. Her event için açıkça send_to belirtilmeli.