Web sitesinde gad_* parametreleri nasıl korunur?

Web sitesinde gad_* parametrelerini korumak için gelen URL’nin sorgu dizesini yönlendirme, sayfa geçişi ve ölçüm kodu boyunca değiştirmemelisiniz. Bu parametreler silinir veya yeniden yazılırsa Google Ads ve Google Analytics oturum, kampanya ve dönüşüm eşleştirmesini kaybedebilir.

gad_* parametreleri neden korunmalıdır?

gad_* parametrelerini korumak, reklam tıklamasıyla açılış sayfası arasındaki ilişkiyi bozmamak için gereklidir. Google reklam URL’lerinde farklı otomatik etiketleme parametreleri kullanılabilir.

Her parametrenin işlevi aynı değildir. Bazıları reklam, kampanya veya kaynak bilgisinin taşınmasına yardım eder. Bazıları ise tarayıcı, gizlilik veya ilişkilendirme süreçlerinde kullanılır.

Bu nedenle geliştirici, yalnızca bildiği parametreleri değil, `gad_` ile başlayan yeni parametreleri de varsayılan olarak korumalıdır. Belirli bir listeye bağlı URL temizleme kodu risk oluşturur.

Örneğin kullanıcı şu URL ile siteye gelirse, sorgu dizesi açılış sayfasına ulaşmalıdır: `/hizmet?gad_source=1&gad_campaignid=123456789`. İlk sayfa bu değerleri almalı, gerekli durumda birinci taraf çerezine yazmalıdır.

Parametrelerin korunması, onları her sayfanın adres çubuğunda sonsuza kadar göstermek anlamına gelmez. Ölçüm ihtiyacı varsa değerleri kontrollü biçimde saklayabilirsiniz.

Ancak saklama süresi, çerez politikası ve kullanıcı izni birlikte değerlendirilmelidir. Özellikle reklam ölçümü için kullanılan teknolojilerde rıza yönetimi ayrıca kontrol edilmelidir.

Yanlış: URL daha kısa görünsün diye bütün `?` sonrası değerleri silmek. Doğru: Ölçüm parametrelerini doğrulayıp güvenli biçimde korumak veya saklamak.

Google Analytics kurulumu için ayrıca web sitesinde Google etiketi nasıl kurulur rehberindeki veri katmanı ve etiket yükleme kontrolleri incelenebilir.

Sunucu yönlendirmeleri gad_* parametrelerini nasıl korur?

Sunucu yönlendirmeleri, hedef URL’ye kaynak sorgu dizesini açıkça taşıdığı sürece gad_* parametrelerini korur. Sorun genellikle 301, 302 veya HTTPS zorlaması sırasında oluşur.

Örneğin `http://site.com/hizmet?gad_source=1` adresi, `https://site.com/hizmet` adresine yönleniyorsa parametre kaybolur. Hedef adres `https://site.com/hizmet?gad_source=1` biçiminde oluşmalıdır.

Nginx yapılandırmalarında yönlendirme kuralının sorgu dizesini nasıl ele aldığı kontrol edilmelidir. Bazı kurallar eski sorguyu otomatik korur, bazıları ise yeni bir sorgu tanımladığında eskisini kaldırır.

Apache tarafında da `mod_rewrite` kuralları incelenmelidir. Yeni hedefte sabit bir sorgu dizesi eklemek, mevcut parametrelerin üzerine yazabilir.

Uygulama seviyesindeki yönlendirmelerde de aynı mantık geçerlidir. PHP, Node.js, Laravel, WordPress eklentisi veya CDN kuralı kullanıyorsanız mevcut URL’nin query string bölümünü hedefe taşımalısınız.

Yönlendirme zincirini mümkünse tek adıma indirin. Kullanıcı önce HTTP’den HTTPS’ye, sonra `www` adresine, ardından slash düzenine yönleniyorsa her adım ayrı ayrı test edilmelidir.

Kontrol için tarayıcı geliştirici araçlarında Network sekmesini açın. Her 3xx yanıtının Location değerinde gerekli parametrelerin bulunup bulunmadığını izleyin.

URL temizleme kodları hangi parametreleri silmemeli?

URL temizleme kodları, yalnızca açıkça güvenli olduğu bilinen parametreleri kaldırmalı ve gad_* değerlerini varsayılan olarak korumalıdır. Temizleme işlemi çoğunlukla JavaScript ile yapılır.

Birçok site, kullanıcı adresi kopyalarken takip parametrelerini silmek için `history.replaceState()` kullanır. Bu işlem ölçüm etiketi çalışmadan önce gerçekleşirse reklam ilişkilendirmesi bozulabilir.

Benzer risk, tek sayfa uygulamalarında route değişimi sırasında görülür. Router yeni URL’yi yalnızca path üzerinden oluşturuyorsa mevcut sorgu dizesi kaybolur.

Temizleme kodunu tamamen kaldırmak her zaman gerekli değildir. Önce parametrenin hangi araç tarafından kullanıldığı, hangi aşamada okunduğu ve ne kadar süre saklanması gerektiği belgelenmelidir.

Örneğin `utm_source`, `utm_medium`, `utm_campaign` ve `gad_*` değerlerini koruyan bir izinli liste oluşturabilirsiniz. Ancak `gad_*` için her parametreyi tek tek yazmak yerine önek kontrolü daha dayanıklıdır.

JavaScript tarafında şu mantık uygulanabilir: URL’yi oku, ölçüm için gerekli değerleri al, etiketi çalıştır, sonra yalnızca gereksiz parametreleri temizle. Temizleme işlemi, veri alımından önce yapılmamalıdır.

Bir başka seçenek, değerleri ilk sayfa yüklemesinde birinci taraf depolamaya yazmaktır. Bu yöntemde kullanıcı izni, saklama süresi ve tarayıcı kısıtları ayrıca değerlendirilir.

URL temizleme kodu reklam tıklamasını tek başına bozmaz; ancak Google etiketi parametreleri okuyamadan çalışırsa ilişkilendirme verisi eksilebilir. Bu yüzden zamanlama ölçümü kadar önemlidir.

Tek sayfa uygulamalarında her route değişimini ayrıca test edin. Ana sayfa doğru çalışırken form, ürün ve teşekkür sayfası geçişlerinde sorgu dizesi kaybolabilir.

Tek sayfa uygulamalarında gad_* değerleri nasıl taşınır?

Tek sayfa uygulamalarında gad_* değerlerini taşımak için ilk açılış URL’sini kaydetmeli ve route değişimlerinde ölçüm bağlamını korumalısınız. React, Vue veya benzeri yapılar bunu otomatik garanti etmez.

İlk yüklemede `window.location.search` okunabilir. Uygulama, ihtiyaç duyulan değerleri ölçüm katmanına aktarabilir veya izin verilen saklama yöntemlerinden birine yazabilir.

Sonraki sanal sayfa görüntülemelerinde tarayıcı adresinde parametre bulunmayabilir. Bu durum, ilk girişte değerler doğru kaydedildiyse tek başına sorun değildir.

Ancak route değişimi sırasında yeni bir kampanya URL’si ile giriş yapılırsa eski değerlerin üzerine yazma kuralı belirlenmelidir. Genellikle yeni ve geçerli kampanya bilgisi, eski bilgiden öncelikli kabul edilir.

Uygulama içindeki linklerde sorgu dizesini elle birleştirmekten kaçının. Değerlerin URL kodlaması yapılmazsa `&`, `+` veya özel karakterler bozulabilir.

Sunucu tarafında render edilen sayfalarda da aynı kontrol gerekir. İlk HTML içinde Google etiketi yükleniyor, ardından uygulama router’ı adresi değiştiriyorsa iki farklı ölçüm akışı oluşabilir.

Test sırasında şu senaryoları ayrı ayrı çalıştırın: reklam URL’siyle doğrudan giriş, çerez reddiyle giriş, sayfa yenileme, sanal route geçişi ve form gönderimi.

Uygulamanın `pushState` ve `replaceState` çağrılarını izlemek yararlıdır. Bu çağrılardan sonra `location.search` değerini karşılaştırarak parametre kaybının hangi adımda gerçekleştiğini bulabilirsiniz.

Landing page akışlarında bu kontrol daha kritiktir. Landing page nedir ve dönüşüm optimizasyonu rehberindeki mesaj eşleşmesine ek olarak, reklam URL’sinin teknik bütünlüğü de kontrol edilmelidir.

Çerez izni gad_* parametrelerinin ölçümünü nasıl etkiler?

Çerez izni, gad_* parametrelerinin korunmasını doğrudan engellemez; ancak bu değerlerin nasıl okunacağı ve saklanacağı üzerinde belirleyici olabilir.

Kullanıcı ölçüm çerezlerini reddettiğinde parametreleri yine sunucu tarafında alabilirsiniz. Fakat bu verileri analitik amaçla saklamak veya ilişkilendirmek için uygulanabilir izin kurallarınız olmalıdır.

Rıza yönetim platformu, Google etiketi yüklenmeden önce karar üretmelidir. Etiket erken çalışırsa kullanıcı tercihi uygulanmadan ölçüm isteği gönderilebilir.

Bu nedenle consent mode, etiket tetikleme koşulları, çerez kategorileri ve varsayılan izin durumu birlikte test edilmelidir. Sadece banner metnini değiştirmek teknik uyumu kanıtlamaz.

Parametrelerin adres çubuğunda kalması da ayrı bir konudur. Kullanıcı reddettiğinde tüm parametreleri silmek, her durumda doğru çözüm değildir. Önce güvenlik ve ölçüm gereksinimi belirlenmelidir.

Örneğin ödeme sayfasına taşınan kampanya değeri kişisel veri içeriyorsa saklama ve erişim kuralları değişebilir. `gad_*` adını görmek, değerin otomatik olarak risksiz olduğu anlamına gelmez.

Çerez reddetme uygulaması hakkında karar verirken web sitesinde çerez reddetme butonu zorunlu mu başlığındaki hukuki ve teknik ayrımı dikkate alın.

Pratik testte izin vermeyen, izin veren ve karar vermeden sayfadan ayrılan üç kullanıcı senaryosu oluşturun. Her senaryoda URL, etiket isteği, çerezler ve dönüşüm sinyali ayrı kaydedilmelidir.

İzin yönetimi ölçümü azaltabilir; bu her zaman teknik hata değildir. Asıl hata, kullanıcının seçimine rağmen etiketlerin yanlış zamanda çalışması veya parametrelerin kontrolsüz saklanmasıdır.

UTM parametreleri ile gad_* parametreleri birlikte nasıl yönetilir?

UTM ve gad_* parametreleri birlikte yönetilmeli, fakat aynı veri gibi değerlendirilmemelidir. UTM değerleri kampanya adlandırması için manuel eklenir; gad_* değerleri Google reklam akışından gelebilir.

Reklam URL’sinde hem `utm_source=google` hem de `gad_source` bulunabilir. Birini diğerinin yerine koymak, raporlama kapsamını ve platformlar arası karşılaştırmayı değiştirebilir.

URL standardınızda hangi parametrenin hangi araç tarafından okunacağı açıkça yazılmalıdır. Geliştirici, pazarlama ekibi ve analitik sorumlusu aynı isimlendirme tablosunu kullanmalıdır.

UTM değerleri için küçük harf standardı, sabit kampanya formatı ve zorunlu alanlar belirleyebilirsiniz. Ancak gad_* değerlerini elle yeniden adlandırmak veya başka bir parametreye kopyalamak önerilmez.

Örneğin `gad_campaignid` değerini `utm_campaign` alanına otomatik yazmak, iki sistemin aynı anlamı taşıdığı varsayımına dayanır. Bu eşleme gerekmiyorsa veriyi olduğu gibi koruyun.

UTM parametreleri ve kampanya takibi rehberinde kaynak, mecra ve kampanya adlarının tutarlı kullanımını inceleyebilirsiniz. Buradaki adlandırma kuralları, gad_* koruma sürecinin yerini tutmaz.

Raporlamada ilk olarak ham giriş URL’sini kaydedin. Daha sonra GA4, Google Ads ve CRM kayıtlarında kampanya değerlerinin hangi alana aktarıldığını karşılaştırın.

Bir dönüşüm yalnızca UTM var diye doğru ilişkilendirilmiş sayılmaz. Tıklama bilgisi, kullanıcı oturumu, izin durumu ve dönüşüm isteği aynı testte birlikte incelenmelidir.

Parametreleri gereksiz yere çoğaltmak URL’leri uzatır ve hata olasılığını artırır. Her parametrenin sahibi, kullanım amacı, saklama süresi ve silme koşulu dokümante edilmelidir.

gad_* parametrelerinin korunup korunmadığı nasıl test edilir?

gad_* parametrelerinin korunduğunu doğrulamak için gerçek reklam tıklamasını beklemeden kontrollü URL, yönlendirme ve tarayıcı testleri yapmalısınız.

Test URL’sinde gerçek kampanya değerleri yerine ölçüm ortamınızın kabul ettiği örnek değerler kullanın. Böylece yanlış dönüşüm veya gereksiz reklam sinyali üretme riskini azaltırsınız.

1. Parametre içeren bir giriş URL’si oluşturun.
2. HTTP, HTTPS, www ve slash varyasyonlarını ayrı açın.
3. Her 3xx yanıtının Location başlığını kaydedin.
4. İlk HTML ve ağ isteklerinde parametre aktarımını inceleyin.
5. JavaScript route değişiminden sonra adresi ve depolamayı karşılaştırın.
6. Google Analytics DebugView ve ilgili reklam tanılama ekranlarını kontrol edin.
7. Form gönderimi veya satın alma gibi dönüşüm adımını tekrar test edin.

Tarayıcı geliştirici araçlarında Network sekmesi, Application sekmesi ve Console birlikte kullanılmalıdır. Sadece adres çubuğuna bakmak, etiketin doğru veri gönderdiğini kanıtlamaz.

Sunucu loglarında ilk istek URL’sini ve yönlendirme yanıtını saklayın. Loglarda sorgu dizesi kişisel veri içerebileceği için erişim ve saklama politikalarını uygulayın.

Google Analytics DebugView, olayın geldiğini gösterebilir; fakat reklam tıklaması ilişkilendirmesinin tüm ayrıntılarını tek başına doğrulamayabilir. Bu nedenle reklam ve analitik tarafını ayrı kontrol edin.

Testi en az mobil ve masaüstü tarayıcılarında tekrarlayın. Safari, Firefox ve Chromium tabanlı tarayıcılar depolama, yönlendirme ve izleme davranışlarında farklı sonuçlar üretebilir.

gad_* kaybı hangi belirtilerle anlaşılır?

gad_* kaybı genellikle reklam trafiğinde beklenmeyen düşüş, doğrudan trafiğinde artış veya dönüşümlerin kampanyalara bağlanamamasıyla fark edilir.

Bu belirtiler tek başına parametre kaybını kanıtlamaz. Reklam bütçesi, açılış sayfası değişikliği, izin oranı, etiket hatası ve raporlama gecikmesi de benzer sonuç yaratabilir.

Önce kaybın hangi aşamada oluştuğunu belirleyin. Giriş isteğinde parametre yoksa reklam URL’sini veya reklam platformu ayarını inceleyin.

Girişte var, yönlendirme sonrasında yoksa sunucu, CDN veya uygulama yönlendirmesi sorumludur. İlk sayfada var, ölçüm isteğinde yoksa etiket ya da veri katmanı kodunu inceleyin.

Ölçüm isteğinde var, raporda yoksa izin, ilişkilendirme, filtre veya raporlama işleme süreci değerlendirilmelidir. Bu aşamada yalnızca front-end kodunu değiştirmek doğru olmayabilir.

Aşağıdaki kontrol listesi, sorunu aşamalara bölmenizi sağlar:

• Reklam URL’sinde gad_* parametreleri gerçekten bulunuyor mu?
• İlk HTTP yanıtı parametreleri taşıyor mu?
• 301 veya 302 zincirinde değer kayboluyor mu?
• CDN, güvenlik duvarı veya cache kuralı sorguyu değiştiriyor mu?
• JavaScript URL temizleme kodu etiketlerden önce çalışıyor mu?
• Tek sayfa uygulaması route değişiminde query string’i siliyor mu?
• Google etiketi doğru izin durumuyla yükleniyor mu?
• Dönüşüm isteğinde gerekli ilişkilendirme sinyali mevcut mu?

Her kontrolün sonucunu tarih, tarayıcı, URL ve yanıt koduyla kaydedin. Böylece geliştirici değişikliğinden sonra önceki ve sonraki davranışı karşılaştırabilirsiniz.

Kalıcı çözüm için hangi teknik politika uygulanmalıdır?

Kalıcı çözüm, parametreleri koruyan tek bir kural seti, ölçüm dokümantasyonu ve düzenli regresyon testi oluşturmayı gerektirir.

Önce tüm yönlendirme noktalarını listeleyin: CDN, web sunucusu, uygulama, CMS, eklentiler, kampanya takip aracı ve JavaScript router.

Her katmanda gelen sorgu dizesinin aynen taşınıp taşınmadığını belgeleyin. Bir katman parametreleri temizliyorsa, bunun amacı, zamanı ve izin koşulu açıkça yazılmalıdır.

İkinci olarak ortak bir parametre politikası hazırlayın. `gad_*`, UTM, oturum ve işlevsel parametreler ayrı sınıflandırılmalıdır.

Üçüncü olarak otomatik test ekleyin. En azından test ortamında parametreli URL’nin 200, 301, 302 ve uygulama route yanıtlarında beklenen değerleri koruduğu doğrulanabilir.

Deploy öncesi smoke test, canlıya çıktıktan sonra da sentetik izleme kullanılabilir. Test URL’leri gerçek reklam dönüşümü üretmeyecek biçimde hazırlanmalıdır.

Google etiketi güncellendiğinde izin akışını yeniden kontrol edin. Google Ads AI Max açılış sayfası raporu gibi raporlar, açılış sayfası davranışını izlemek için yararlı olabilir; ancak teknik kaybın kaynağını tek başına göstermez.

Parametre koruma kuralı, güvenlik filtresiyle karıştırılmamalıdır. Zararlı sorgular engellenebilir; fakat bunu yaparken geçerli ölçüm parametrelerinin yanlışlıkla silinmediği doğrulanmalıdır.

Son olarak sorumluluk atayın. Sunucu yönlendirmelerini geliştirici, izin akışını analitik sorumlusu, kampanya URL’lerini pazarlama ekibi düzenli olarak kontrol etmelidir.

gad_* parametrelerini korumak ne zaman yeterli olmaz?

gad_* parametrelerini korumak tek başına doğru ölçüm garantisi vermez; etiket, izin, dönüşüm ve platform ayarları da aynı akışta doğru çalışmalıdır.

Parametre girişte ve ölçüm isteğinde bulunsa bile kullanıcı çerezleri reddetmiş olabilir. Bu durumda raporlama kapsamının azalması, uygulanan izin politikasının sonucu olabilir.

Benzer şekilde yanlış Google etiketi kimliği, hatalı veri akışı veya dönüşüm yapılandırması parametre korumasından bağımsız sorun üretir. Önce veri akışının temel kurulumunu doğrulayın.

URL’ye hassas veya kişisel veri eklemek de doğru değildir. Parametreleri koruma amacı, kullanıcı adı, e-posta veya telefon gibi bilgileri reklam URL’sinde taşımayı haklı çıkarmaz.

Güvenlik duvarı, WAF veya CDN sorgu dizesini güvenlik nedeniyle değiştiriyorsa ölçüm kuralı ile güvenlik kuralı birlikte tasarlanmalıdır. Birini diğerinden habersiz değiştirmek veri kaybı yaratır.

Çok sayıda yönlendirme varsa parametreleri korumak yerine yönlendirme zincirini azaltmak daha doğru olabilir. Nihai açılış sayfasına mümkünse tek bir 301 veya doğrudan 200 yanıtla ulaşın.

Değişiklikten sonra yalnızca reklam raporunu beklemeyin. Önce teknik testleri, sonra gerçek trafik örneklerini, ardından dönüşüm raporlarını karşılaştırın.

Site yapısında büyük değişiklik planlanıyorsa [web sitesinde INP skoru nasıl düşürülür](/web-sitesinde-inp-skoru-nasil-dusurulur) rehberindeki performans kontrolleriyle birlikte ölçüm scriptlerinin yükleme sırasını da değerlendirin.

Ölçüm akışınızda yönlendirme, etiket, izin veya kampanya parametresi kaynaklı belirsizlik varsa Medyografya, sorunu URL’den rapora kadar aşamalı olarak inceleyecek teknik kontrol sürecini planlayabilir.