Google Ads geliştirici politikaları sıkılaştı: paylaşımlı proxy yasak, kendi Cloud projesi şart
Google Ads Developer Blog'un 31 Ağustos 2026 tarihli duyurusuna göre entegrasyonlar Google Ads servislerine artık kendilerine ayrılmış bir Google Cloud projesi üzerinden doğrudan bağlanmak zorunda. Paylaşımlı geliştirici proxy hizmeti işletmek ve kimlik bilgilerini ara katmana gömmek yasaklandı.
Politikanın adı da kapsamı da değişti
Google Ads Developer Blog'da 31 Ağustos 2026 tarihinde geliştirici politikalarındaki güncellemeleri duyuran bir yazı yayımlandı.
Politikanın adı Google Ads API Policy'den Google Ads Developer Policies'e güncellendi. Google bu güncellemenin amacını, yeni yapay zeka yetenekleri reklam sektörünü şekillendirmeye devam ederken geliştiricilerin sağlam ve yüksek kaliteli entegrasyonlar kurmasını desteklemek olarak tarif ediyor.
Proxy kuralının kendi gerekçesi ayrı yazılmış: reklam ortaklarını dolandırıcılık ve güvenlik risklerine karşı korumak. Google, programatik proxy'lerin son kullanıcılar ile Google arasındaki doğrulanabilir ve güvenli arayüzü devre dışı bıraktığını söylüyor.
Duyuruda genel bir yürürlük tarihi ya da son uyum tarihi verilmiyor. Metin, uyum ekibinin mevcut entegrasyonları hâlihazırda incelediğini belirtiyor.
Kural ne diyor, hangi yapılar yasak?
Yeni kurala göre entegrasyonlar Google Ads servislerine kendilerine ayrılmış bir Google Cloud projesi üzerinden doğrudan bağlanmak zorunda.
Politika metni iki şeyi açıkça yasaklıyor: kimlik bilgilerini işlemin kaynağını gizleyen bir ara katmana gömmek ve paylaşımlı geliştirici proxy hizmeti işletmek.
Paylaşımlı proxy yasağı koşullu yazılmış. Yasak, birden fazla bağımsız işletmenin otomatik isteklerini bireysel erişim şartını atlatmak amacıyla yönlendiren paylaşımlı geliştirici proxy hizmetlerini hedefliyor.
Politika, yasaklanan yapıları sayarken üçüncü taraf barındırmalı arayüz, ikincil API, sarmalayıcı hizmet ve MCP sunucusu ile proxy uç noktasını da anıyor.
Google'ın saydığı riskler üç başlıkta toplanıyor. Denetlenmemiş proxy kullanımı yetkisiz kişilere hesap erişimi açabiliyor.
İkincisi kiracılar arası veri sızıntısı riski: verinin amaçlanandan daha geniş biçimde açığa çıkması.
Üçüncüsü performans darboğazı. Tek bir proxy üzerinden geçen yüksek hacimli trafik veri akış hızını kısabiliyor, tüm kullanıcılarda gecikme yaratabiliyor ve yerel bir hizmet reddi saldırısı giderilirken yaptırımın o proxy'nin tüm kullanıcılarına uygulanmasını gerektirebiliyor.
Politika ayrıca ajansların ve son reklamveren müşterilerin kendi Google Cloud Platform hesaplarını ve kendi Google Ads erişimlerini kullanmasını şart koşuyor.
Uyumsuzluğun bedeli tanımlı: politika metni uyumsuzluk ücretlerinden ve erişim seviyesinin düşürülmesinden söz ediyor.
Google'ın uyum ekibi, geçiş yapması gereken geliştiricilerle doğrudan iletişime geçecek. Geliştiricilerden API Center'daki iletişim e-postasını güncel tutmaları isteniyor, bildirimlerin google.com uzantılı adreslerden geleceği belirtiliyor.
Görünmeyen halka: hesabınıza kim bağlanıyor?
Bu bölümdeki değerlendirme bize ait. Bir reklam hesabının güvenliği çoğunlukla parola ve iki adımlı doğrulama olarak düşünülür. Oysa gerçek risk yüzeyi, o hesaba bağlanan yazılım zincirinin tamamıdır.
Paylaşımlı proxy mimarisi tam da bu zincirin görünmeyen halkası. Bir raporlama panelinde onlarca farklı işletmenin verisi aynı teknik kapıdan geçiyorsa, o kapının sahibi sizin reklam hesabınızla aranızdaki en zayıf nokta demektir.
Google'ın performans gerekçesi bu yüzden dikkat çekici. Bir proxy'de yaşanan sorun için alınan önlemin o proxy'nin tüm kullanıcılarına uygulanabilmesi, komşunuzun hatasından sizin etkilenebileceğiniz anlamına geliyor.
Yasaklanan yapılar arasında MCP sunucusunun adının geçmesi de ayrı bir işaret. Yapay zeka ajanlarının reklam hesaplarına bağlanacağı katman daha yaygınlaşmadan kural altına alınıyor.
Bütün bunların yönü tek: aracı katmanı inceltmek ve her erişimi kimliği belli bir projeye bağlamak. Bu, sorumluluğun da adresini netleştiriyor.
Bir uyarı da gerekiyor: duyuruda takvimlenmiş bir son tarih yok. Yani bu, tarihi beklenecek bir geçiş değil, hâlihazırda yürüyen bir inceleme süreci.
Türkiye'deki işletmeler için anlamı
Aşağıdaki değerlendirme kaynakta yer almıyor, bizim okumamız. Metinde Türkiye'ye özgü bir bilgi bulunmuyor.
Türkiye'deki işletmelerin önemli bölümü Google Ads'i doğrudan değil, bir ajans paneli ya da yerli bir raporlama ve otomasyon aracı üzerinden izliyor. Bu araçların mimarisi çoğu zaman müşteriye hiç anlatılmaz.
Bu yüzden sorulacak soru teknik değil, ticari: reklam hesabıma hangi araç, hangi Google Cloud projesi üzerinden bağlanıyor.
İkinci soru da şu: kullandığım panel benim kendi Google Ads erişimimi mi kullanıyor, yoksa herkesin ortak kullandığı bir yapıyı mı. Politika, ajans ve reklamverenin kendi hesabını kullanmasını şart koştuğu için bu artık bir tercih değil.
Ajansıyla yolunu ayıran bir işletme için de sonuç net. Hesap erişimi kendi Google hesabınıza bağlıysa devir kolaydır, ortak bir aracıya bağlıysa veri ve geçmiş orada kalır.
Pratik adım: mevcut aracınıza ve ajansınıza bu değişikliği bilip bilmediklerini ve mimarilerini nasıl uyarlayacaklarını sorun. Cevabın netliği, çalıştığınız tarafın olgunluğu hakkında da fikir verir.
UNALSOFT açısı
Reklam yönetimi tarafında çalıştığımız her hesapta erişimin müşterinin kendi Google hesabına bağlı olmasını baştan şart koşuyoruz. Sebebi bu politika değil, basit bir ilke: müşterinin verisi ve hesabı müşteride kalır, ajans yalnızca yetkilendirilmiş bir kullanıcıdır. İş ilişkisi bittiğinde tek yapılması gereken yetkiyi geri almaktır, veri taşımak değil. Google'ın bu güncellemesi aynı ilkeyi platform seviyesinde zorunlu hale getiriyor. İşletmeler için asıl kazanım güvenlikten önce şeffaflık: hesabınıza kimin, hangi projeyle bağlandığını sorabildiğiniz anda, reklam bütçenizin arkasındaki teknik zinciri de görmeye başlarsınız.
Reklam hesabınıza kim bağlanıyor?
Hesap erişimlerinizi ve kullandığınız araçların bağlantı yapısını birlikte gözden geçirelim.