Google Business API ile Otomasyon

Bu konuda ilk öğrenilmesi gereken şey teknik değil idari: Google Business Profile API'leri herkese açık değil.

Google'ın kendi dokümanı bunu net söylüyor: API'leri kullanmak için erişim talep etmek gerekiyor ve erişime meşru bir iş gerekçesi gösterebilen kişi ya da şirketler onaylanıyor. Ayrıca API'ler, büyük ve teknik kapasitesi olan işletmeleri ve üçüncü tarafları temsil eden geliştiriciler için tasarlanmış.

Yani Cloud Console'dan API'yi etkinleştirip kullanmaya başlamak mümkün değil. Bu, geliştiricilerin en çok zaman kaybettiği noktada duruyor.

Kota 0 ne anlama geliyor Erişim modelinin en kafa karıştıran belirtisi bu ve doğru teşhis edilmediğinde haftalar kaybediliyor.

API'yi etkinleştirdikten sonra kota limitiniz 0 görünüyorsa, bu bir kota problemi değil: erişiminiz henüz verilmemiş demek. Google'ın dokümanı bu durumda ne yapılmayacağını da söylüyor — kota artışı istemeyin. Yapılması gereken, temel API erişim başvurusunu göndermek.

Ayrım önemli, çünkü iki farklı süreç var: erişim (API'yi hiç kullanabiliyor musunuz) ve kota (ne kadar kullanabiliyorsunuz). Erişim yokken kota artışı talep etmek, yanlış kuyrukta beklemek anlamına geliyor.

Erişim verildikten sonra kota limitleri devreye giriyor. Google, adil kullanım ve sistem kararlılığı için istek kotası uyguluyor; limiti aşan istek HTTP tarafında 429 Too Many Requests, gRPC tarafında RESOURCE_EXHAUSTED ile dönüyor. Kota artışı bu aşamada, kullanım gerekçesiyle talep edilebiliyor.

Bir kural da net: üretim ortamında sahte ya da test amaçlı kayıtlar kabul edilmiyor. Deneme için gerçek olmayan işletme oluşturmak, erişimi riske atan bir davranış.

Federe yapı: tek API değil, endpoint ailesi Mimari beklentiyi baştan düzeltmek gerekiyor. "Google Business Profile API" tek bir arayüz değil.

Google'ın dokümanına göre API'ler federe bir model kullanıyor: farklı işlevler için ayrı endpoint'ler var ve her endpoint'in base URL'i farklı. Gönderiler ve yorumlar bunun örnekleri olarak veriliyor.

Bunun pratik sonuçları var:

Tek bir istemci yapılandırması yetmiyor. Her endpoint için doğru base URL ve doğru sürüm bilgisi gerekiyor.

Yetkilendirme kapsamları ayrı düşünülmeli. Hangi işlem için hangi izin gerektiği endpoint bazında değişiyor.

Dokümantasyonu tek yerden okumak yanıltıyor. Bir endpoint'te geçerli olan alan adı, diğerinde bulunmayabiliyor.

İşlevsel olarak API'lerin kapsamı geniş: hesap ve konum bilgisi yönetimi, verinin Google genelinde nasıl sunulduğunu kontrol etme, veriyi kimin ortak yönettiğini belirleme ve fotoğraf, gönderi, yorum gibi kullanıcı verilerinin yönetimi. Google, API'lerin arayüzle neredeyse aynı özellikleri sunduğunu, buna ek olarak API'ye özgü bazı özellikler bulunduğunu belirtiyor.

v4'ten neler değişti Eski kod tabanlarını taşıyanlar için en kritik başlık bu.

Google My Business API v4'te daha önce bulunan özelliklerin çoğu artık emekliye çıkarılmış durumda ve kullanıcılar Account Management ile Notifications API'lerine yönlendiriliyor.

Bunun anlamı şu: internette bulduğunuz v4 örnekleri büyük olasılıkla çalışmıyor. Eski bir blog yazısındaki istek gövdesini kopyalayıp denemek, hata ayıklamayla geçirilen bir gün demek.

Doğru davranış, referans dokümantasyonunu birincil kaynak olarak kullanmak ve hangi işlevin hangi API'ye taşındığını oradan doğrulamak. Bu, schema tarafında da geçerli olan genel bir ilke: yüzeyler değişiyor, dokümana bakmak gerekiyor: schema markup kurulumu.

OAuth ve erişim yönetimi API üzerinden çalışan bir uygulama, işletmenin verisine kullanıcı adına erişiyor. Bu ilişkinin iki tarafı da yönetilebilir olmalı.

Kullanıcı tarafında: Google hesabı, hesaba erişimi olan uygulamaları ve o uygulamanın hangi veriye erişebildiğini gösteriyor. Kullanıcı erişimi dilediği an kaldırabiliyor.

Bunun işletme sahibi için pratik sonucu önemli: bir ajans ya da yazılımla çalışıp yolları ayırdığınızda, o uygulamanın erişimini kendi hesabınızdan kaldırmak sizin elinizde. Bu, franchise ve ajans ilişkilerinde erişim yapısının neden yazılı olması gerektiğine bağlanıyor: franchise'ta yerel SEO yönetimi.

Geliştirici tarafında ise erişimin kaldırılabileceğini varsayarak çalışmak gerekiyor: token geçersizleştiğinde uygulamanın sessizce durmaması, hatayı görünür kılması lazım.

Kota ile yaşamayı öğrenmek Erişim alındıktan sonra karşılaşılan gerçek mühendislik problemi bu: kota sınırlı ve sınıra çarpmak kaçınılmaz.

Kotayı aşan isteğin 429 ile döndüğünü bilmek, bu hatayı beklenen bir durum olarak ele almak anlamına geliyor. Pratikte üç davranış işe yarıyor:

Geri çekilerek tekrar deneme. 429 alan isteği hemen tekrarlamak durumu kötüleştiriyor. Artan bekleme aralıklarıyla tekrar denemek doğru davranış.

İstek sayısını azaltacak biçimde tasarlamak. Her şubeyi ayrı ayrı sorgulamak yerine toplu işlem imkânlarını kullanmak, aynı işi daha az istekle bitiriyor.

Kendi tarafında önbellek tutmak. Saatte bir değişmeyen veriyi saatte bir çekmek kotayı boşa harcıyor. Konum bilgisi gibi yavaş değişen veriyi saklayıp yalnız değişimi takip etmek gerekiyor.

Bir de sıralama meselesi var: gece yapılan toplu iş ile gündüz yapılan tepkisel iş aynı kotayı paylaşıyor. Toplu senkronizasyonu yoğun saat dışına almak, gerçek zamanlı ihtiyaç için kota bırakıyor.

Kota artışı talep etmek mümkün, ama talep kullanım gerekçesine dayanıyor — yani önce verimli kullanmak, sonra istemek.

Otomasyonun gerçekten işe yaradığı yerler API'yi kurmak bir maliyet; karşılığında ne alındığı net olmalı. Ölçek olmadan bu maliyet karşılanmıyor.

Toplu bilgi güncelleme. Onlarca şubede saat, telefon ya da hizmet değişikliğini elle yapmak günler alıyor. Asıl kazanç burada: çoklu şube yönetimi.

Yorumları tek yerde toplamak. Bütün şubelerin yorumlarını tek panelde görmek, cevapsız kalan yorumu bulmanın en hızlı yolu. Zincir ortalamasının zayıf şubeyi gizlediği problem burada çözülüyor: yorum yanıt şablonları.

Performans verisini biriktirmek. Profil arayüzü geçmişi sınırlı gösteriyor. Veriyi düzenli çekip kendi tarafınızda saklamak, mevsimsellik gibi soruları cevaplanabilir hâle getiriyor: istatistikleri okuma.

Bildirimlerle tepki süresini kısaltmak. Yeni yorum ya da değişiklik bildirimini kendi sistemine bağlamak, cevap süresini elle kontrole göre belirgin biçimde düşürüyor. Olumsuz yorumda geçen her saat, cevabın okunma değerini düşürüyor.

Doğrulama ve tutarlılık kontrolü. Şubeler arasında kategori, isim biçimi ve saat tutarlılığını programlı denetlemek, elle yapılamayacak bir iş: NAP tutarlılığı. Bu denetimi haftalık çalıştırmak, bir şubede sessizce bozulan bilgiyi müşteri fark etmeden yakalıyor.

Otomasyonun işe yaramadığı yerler Burada dürüst olmak gerekiyor, çünkü API bazı işleri daha kötü yapıyor.

Yorum cevabı yazmak. Otomatik üretilen cevap şablon gibi okunuyor ve şablon cevap güven üretmiyor. API'nin doğru kullanımı cevabı yazmak değil, cevaplanmayanı bulmak.

Gönderi üretmek. Söylenecek bir şey yokken program tarafından üretilen gönderi, boş içerik oluyor: gönderi zamanlama.

Sıralamayı etkilemek. API bir sıralama aracı değil; arayüzden yapılabilen işleri programlı yapıyor. Otomasyon kurmak görünürlük getirmiyor, bakımı ölçeklendiriyor.

Küçük işletmede bakım. Tek şubeli bir işletmede API kurmanın maliyeti, kazandırdığı zamandan yüksek. O ölçekte doğru araç bir takvim: haftalık bakım takvimi.

Başvuru öncesi hazırlık Erişim başvurusunun meşru iş gerekçesi istediği düşünülünce, hazırlık başvurunun kendisinden önemli hâle geliyor.

Ne yapacağınızı somut yazın. "Profilleri yönetmek" değil; hangi veriyi, hangi sıklıkta, hangi amaçla kullanacağınız.

Kimin adına çalıştığınızı netleştirin. Kendi işletmeniz mi, müşterileriniz mi? Üçüncü taraf olarak çalışıyorsanız bu ilişki tanımlı olmalı.

Gerçek kayıtlarla çalışın. Test için sahte işletme oluşturmak üretim ortamında kabul edilmiyor.

Erişim ile kotayı ayırın. Kota 0 görüyorsanız kota artışı değil erişim başvurusu yapın.

Süre konusunda gerçekçi olmak gerekiyor: bu bir onay süreci ve proje planına gecikme payı koymak gerekiyor. Açılışa yetişmesi gereken bir iş varsa erken başlatmak şart: yeni işletme 30 günlük plan.

Sıkça sorulan sorular Google Business Profile API'sini herkes kullanabilir mi? Kullanamaz. Google'ın dokümanına göre API'ler herkese açık değil; erişim talep etmek gerekiyor ve meşru iş gerekçesi gösterebilenler onaylanıyor.

Kota limitim 0, ne yapmalıyım? Kota artışı istemeyin. Kota 0, erişimin henüz verilmediğini gösteriyor; temel API erişim başvurusunu göndermeniz gerekiyor.

Kota aşımında ne oluyor? İstek, HTTP tarafında 429 Too Many Requests, gRPC tarafında RESOURCE_EXHAUSTED ile dönüyor. Erişim verildikten sonra kullanım gerekçesiyle artış talep edilebiliyor.

Tek bir API mi var? Yok. API'ler federe bir model kullanıyor: farklı işlevler için ayrı endpoint'ler ve her birinin farklı base URL'i var.

v4 örneklerini kullanabilir miyim? Büyük olasılıkla hayır. v4'teki özelliklerin çoğu emekliye çıkarılmış ve kullanıcılar Account Management ile Notifications API'lerine yönlendiriliyor.

API kurmak sıralamamı yükseltir mi? Yükseltmiyor. API, arayüzden yapılabilen işleri programlı yapıyor; kazancı ölçekte bakım hızı, görünürlük değil.