Google Play Veri Güvenliği Formu Nasıl Doldurulur? Red Yememek İçin Rehber

Bu sayfaya büyük ihtimalle formla ilgili bir uyarı gördükten, güncellemeniz takıldıktan ya da ilk yayına hazırlanırken soruların karşısında kararsız kaldıktan sonra geldiniz. Panik yapmanıza gerek yok. Önce şu beş adımı atın:

1. Uygulamanın cihazdan dışarı gönderdiği tüm verileri, kendi sunucunuz ve üçüncü taraf hizmetler dahil, tek bir tabloya yazın.
2. Kullandığınız her SDK'nın (yazılım geliştirme kiti) veri beyan rehberini açın ve tabloya ekleyin.
3. Gizlilik politikanızın bu tabloyla birebir uyuştuğunu kontrol edin.
4. Hesap açılan bir uygulamaysa uygulama içi silme yolunu ve web silme bağlantısını hazırlayın.
5. Formu bu belgelere bakarak doldurun ve önizlemeyi okuyun.

Bu yazıda Talha Aslan ve ekibi olarak süreci uçtan uca anlatıyoruz. Kuralları Play Console Yardım'daki veri güvenliği bölümü sayfasından doğruladık. Ancak Google soruları ve kapsamı zaman zaman günceller; bu nedenle güncel metni her zaman resmi sayfadan kontrol edin.

Formu hangi uygulamalar doldurmak zorunda?

Resmi yardım sayfasına göre Google Play'de yayında uygulaması olan tüm geliştiriciler bu formu doldurmak zorunda. Kapsam yalnızca üretim kanalıyla sınırlı değil; kapalı test ve açık test kanalında yayında olan uygulamalar da formu tamamlamalı. Önceden yüklü gelen ve Google Play üzerinden güncellenen uygulamalar da kapsam içinde.

Öte yandan bazı istisnalar var. Yalnızca dahili test kanalında etkin olan uygulamalar bu formdan muaf. Yani ekibinizle hızlı deneme yaptığınız aşamada formu henüz doldurmak zorunda değilsiniz. Ancak kapalı teste geçtiğiniz anda zorunluluk başlar. Bu yüzden biz formu her zaman kapalı test öncesinde hazır tutuyoruz. Yeni hesaplarda kapalı test süreci ayrıca uzun sürdüğü için Google Play kapalı test şartını anlattığımız yazıya da göz atmanızı öneririz.

Ayrıca sistem hizmetleri ve özel (private) uygulamalar da formu doldurmak zorunda değil. Kurumsal dağıtım için yalnızca kendi kuruluşunuza açtığınız bir uygulamanız varsa bu istisnanın sizi kapsayıp kapsamadığını resmi sayfadan kontrol edin.

Hiç veri toplamayan bir uygulama da bu formu doldurur mu?

Evet, doldurur. Google bunu açıkça yazıyor: kullanıcı verisi toplamayan uygulamaların geliştiricileri de formu tamamlamalı ve bir gizlilik politikası bağlantısı vermeli. Fark şu ki bu durumda formun büyük kısmını atlarsınız; ilk bölümde veri toplamadığınızı ve paylaşmadığınızı belirtirsiniz.

Ancak burada sık yapılan bir hata var. Birçok geliştiricinin aklındaki ilk cümle şudur: "bizim sunucumuz yok, o halde veri toplamıyoruz." Oysa uygulamaya eklediğiniz bir reklam SDK'sı, analiz kütüphanesi ya da çökme raporlama aracı veriyi cihazdan dışarı gönderiyorsa bu da sizin toplamanız anlamına gelir. Örneğin tamamen çevrimdışı çalışan bir hesap makinesi uygulaması gerçekten "veri yok" diyebilir. Fakat aynı uygulamaya reklam eklediğiniz anda cihaz kimlikleri ve uygulama etkileşimleri büyük ihtimalle forma girer.

Kısacası "veri toplamıyoruz" cevabını vermeden önce derleme dosyanızdaki bağımlılık listesini satır satır gözden geçirin. Şüphede kalırsanız SDK sağlayıcısının beyan rehberine bakın.

Google "veri toplama" derken tam olarak neyi kastediyor?

Resmi tanım net: toplama, verinin uygulamanızdan kullanıcının cihazı dışına iletilmesidir. Yani veri cihazdan çıkıp sizin sunucunuza, bir bulut hizmetine ya da bir SDK sağlayıcısına gidiyorsa Google bunu toplama olarak kabul eder. Uygulamanızın kontrol ettiği bir web görünümü (webview) içinden toplanan veriler de bu kapsama girer.

Bununla birlikte iki durum kapsam dışında kalıyor:

• Yalnızca cihaz üzerinde işlenen ve dışarı gönderilmeyen veriler.
• Uçtan uca şifreleme kullanan ve geliştirici dahil hiçbir aracının okuyamadığı veriler.

Takma adlı (pseudonymous) veriye de dikkat edin. Google, makul ölçüde bir kullanıcıyla yeniden ilişkilendirilebilecek takma adlı verilerin beyan edilmesi gerektiğini söylüyor. Örneğin rastgele bir kullanıcı kimliği tek başına isim içermese de hesap verisiyle eşleşebiliyorsa beyan etmeniz gerekir. Bu nedenle "kimlik bilgisi yok" demeden önce verinin başka bir kayıtla birleşip birleşmediğini sorgulayın.

"Veri paylaşımı" ne demek, hangi aktarımlar paylaşım dışında kalır?

Paylaşım, uygulamanızdan topladığınız kullanıcı verisini üçüncü bir tarafa aktarmanızdır. Bu aktarım sunucudan sunucuya, cihaz üzerinde başka bir uygulamaya, bir SDK üzerinden ya da kontrol ettiğiniz bir web görünümü aracılığıyla olabilir. Üçüncü taraf ise sizden ve hizmet sağlayıcılarınızdan başka herhangi bir kuruluştur.

Ancak resmi sayfa bazı aktarımları paylaşım olarak beyan etmenizi gerektirmiyor:

• Sizin adınıza ve talimatınızla çalışan hizmet sağlayıcılara yapılan aktarımlar.
• Belirli yasal yükümlülükler veya resmi talepler nedeniyle yapılan aktarımlar.
• Kullanıcının kendi başlattığı ve makul olarak beklediği aktarımlar ya da politikaya uygun belirgin bir açıklama ve onayla yapılanlar.
• Hiçbir kullanıcıyla artık eşleşmeyecek biçimde tamamen anonim hale getirdiğiniz veriler.

Hizmet sağlayıcı istisnası en çok yanlış uygulanan maddedir. Örneğin Google'ın SSS bölümüne göre birden fazla müşterisinin verisiyle reklam profili oluşturan bir SDK bu istisnadan yararlanamaz. Dolayısıyla bir reklam ağını "hizmet sağlayıcımız" diye paylaşım dışında tutmak çoğu zaman doğru olmaz.

Geçici işleme nedir ve formda nasıl beyan edersiniz?

Geçici işleme (ephemeral processing), verinin yalnızca bellekte tutulduğu ve anlık bir isteği karşılamak için gereken süreden uzun saklanmadığı durumdur. Resmi sayfadaki örnek bir hava durumu uygulaması: uygulama konumu yalnızca o anki hava durumunu getirmek için kullanıyor ve kaydetmiyor.

Peki bu veriyi formda belirtmeniz gerekir mi? Evet, gerekir. Geçici işlenen veriyi form cevaplarınızda beyan edersiniz; ancak tanımı karşılıyorsa mağaza girişinde kullanıcı bu veriyi görmez. Yani formda saklamazsınız, yalnızca geçici olduğunu işaretlersiniz.

Öte yandan Google sınırı çok net çiziyor. Reklam veya kullanıcı profili oluşturmak için kullanılan veri geçici sayılamaz. Örnek senaryo olarak bir yemek sipariş uygulamasını düşünün: konumu yalnızca en yakın şubeyi bulmak için anlık kullanıyorsanız geçici işleme olabilir. Aynı konumu kampanya hedeflemesi için kaydediyorsanız artık geçici değildir ve tam beyan gerekir.

Google Play veri güvenliği formunda hangi veri türlerini beyan edersiniz?

Google veri türlerini kategoriler altında topluyor. Formda her kategori için hangi alt türü topladığınızı ve paylaştığınızı ayrı ayrı işaretlersiniz. Resmi sayfadaki kategoriler şunlar:

• Konum: yaklaşık konum ve kesin konum.
• Kişisel bilgiler: ad, e-posta adresi, kullanıcı kimlikleri, adres, telefon numarası ve hassas sayılan diğer kişisel bilgiler.
• Finansal bilgiler: ödeme bilgileri, satın alma geçmişi ve diğer finansal bilgiler.
• Mesajlar, fotoğraf ve videolar, ses dosyaları: uygulama içi mesajlar, fotoğraf, video ve ses kayıtları.
• Dosyalar, takvim ve kişiler: belgeler, takvim etkinlikleri ve rehber.
• Uygulama etkinliği ve web'de gezinme: uygulama etkileşimleri, uygulama içi arama geçmişi, yüklü uygulamalar ve gezinme geçmişi.
• Uygulama bilgisi ve performans: çökme günlükleri ve teşhis verileri.
• Cihaz veya diğer kimlikler.

Çökme günlüklerini gözden kaçırmayın. Crashlytics gibi bir araç kullanıyorsanız uygulama performans verisi topluyorsunuz demektir. Bu araçların mağaza tarafındaki etkisini uygulama çökme oranı ve mağaza eşikleri yazımızda ayrıca anlattık.

SDK'ların topladığı verileri nasıl beyan edersiniz?

Resmi kural açık: uygulamanızdaki üçüncü taraf kütüphanelerin ve SDK'ların topladığı ya da paylaştığı veriyi de siz beyan edersiniz. Verinin size mi yoksa doğrudan SDK sağlayıcısına mı gittiği sonucu değiştirmez. Google ayrıca bu kodun Play politikalarına uygun olmasını sağlamanın sizin sorumluluğunuz olduğunu açıkça belirtiyor.

Bu nedenle biz her projede bir SDK envanteri çıkarıyoruz. Süreç şöyle işliyor:

1. Derleme dosyasındaki tüm bağımlılıkları listeleyin; dolaylı gelen kütüphaneleri de unutmayın.
2. Her SDK için sağlayıcının yayımladığı veri güvenliği rehberini bulun.
3. Mümkünse Google Play SDK Index üzerinden SDK'nın bilinen veri davranışına bakın.
4. SDK'nın hangi ayarla hangi veriyi gönderdiğini not edin; örneğin reklam kimliği toplamayı kapattıysanız bunu da yazın.
5. Envanteri forma aktarın ve her yeni sürümde güncelleyin.

Örnek senaryo olarak analiz, reklam ve çökme raporlama için üç SDK kullanan bir uygulamayı düşünün. Kendi sunucunuz yalnızca e-posta topluyor olsa bile form; cihaz kimliklerini, uygulama etkileşimlerini ve teşhis verilerini de içermek zorunda kalır.

Kullanım amaçlarını nasıl seçersiniz?

Her veri türü için o veriyi neden topladığınızı ve neden paylaştığınızı ayrı ayrı seçersiniz. Toplama ve paylaşım amaçları birbirinden bağımsızdır; aynı veri için farklı olabilir. Resmi sayfadaki amaç listesi şöyle:

• Uygulama işlevselliği.
• Analiz.
• Geliştirici iletişimi.
• Reklam veya pazarlama.
• Dolandırıcılığı önleme, güvenlik ve uyumluluk.
• Kişiselleştirme.
• Hesap yönetimi.

Amaç seçerken gerçek kullanımı esas alın. Örneğin e-posta adresini hem giriş için hem de bülten göndermek için kullanıyorsanız "hesap yönetimi" ile birlikte "geliştirici iletişimi" seçeneğini de işaretlemelisiniz. Öte yandan aklınıza gelebilecek her amacı "ne olur ne olmaz" diye işaretlemek de doğru değil; mağaza girişinde kullanıcıya gereksiz bir tablo çizer ve gizlilik politikanızla çelişebilir.

Kısacası amaç listesini geliştirici ekibiyle birlikte, kod ve sözleşmeler önünüzdeyken doldurun.

Zorunlu ve isteğe bağlı veri ayrımını nasıl yaparsınız?

Formda her toplanan veri türünü zorunlu ya da isteğe bağlı olarak işaretlersiniz. İsteğe bağlı, kullanıcının bu veriyi vermeyi seçebildiği ya da toplamayı açıp kapatabildiği anlamına gelir.

Ancak Google bu etiketi sıkı bir şarta bağlıyor. Bir veriyi isteğe bağlı diye işaretleyebilmeniz için cihazı veya bölgesi ne olursa olsun tüm kullanıcıların bu veriyi vermeme ya da toplamayı kapatma seçeneğine sahip olması gerekir. Uygulamanın herhangi bir sürümü veriyi zorunlu istiyorsa beyanınız da zorunlu olmalıdır.

Örnek senaryo: bir fitness uygulaması profil fotoğrafını isteğe bağlı tutuyor, ancak uygulamanın tablet sürümü kayıt sırasında fotoğrafı zorunlu istiyor. Bu durumda fotoğrafı formda isteğe bağlı gösteremezsiniz. Dolayısıyla platformlar arasında farklı kayıt akışlarınız varsa her birini ayrı ayrı test edin. Biz bu kontrolü yayın öncesi test listemize ekliyoruz; böylece formdaki bir etiket ürün tarafındaki gizli bir farkla çelişmiyor.

Aktarım sırasında şifreleme sorusuna ne cevap vermelisiniz?

Formun güvenlik uygulamaları kısmında Google, verinin aktarım sırasında şifreli olup olmadığını soruyor. Google, aktarım halindeki veriyi şifrelemek için sektörün en iyi standartlarını izlemenizi istiyor ve yaygın örnek olarak TLS ile HTTPS'i gösteriyor.

Burada kritik bir ayrıntı var. Bu soruya "evet" diyebilmeniz için şifrelemenin uygulamanızın ve SDK'larınızın topladığı ve aktardığı tüm kullanıcı verileri için geçerli olması gerekir. Yani ana API'niz HTTPS kullansa bile eski bir uç nokta düz HTTP ile görsel ya da kayıt gönderiyorsa cevabınız doğru olmaz.

Bu yüzden şu kontrolleri öneriyoruz:

• Uygulamanın ağ trafiğini bir test cihazında izleyin ve şifresiz giden istek olup olmadığına bakın.
• Ağ güvenliği yapılandırmanızın şifresiz trafiğe izin verip vermediğini geliştiricinizle kontrol edin.
• Web görünümü içinde açılan sayfaların da HTTPS olduğundan emin olun.

Web tarafındaki şifreleme mantığını merak ediyorsanız SSL sertifikası ve HTTPS rehberimiz iyi bir başlangıç olur.

Veri silme talebi sorusu neden bu kadar önemli?

Formda kullanıcıların verilerinin silinmesini talep edip edemeyeceğini beyan edersiniz. Resmi sayfa belirli bir mekanizma dayatmıyor; ancak talep yolunun kullanıcılar tarafından kolayca bulunabilir ve erişilebilir olması gerektiğini söylüyor. Google örnek olarak uygulama içi bir özelliği, bir iletişim formunu ya da ayrı bir e-posta adresini sayıyor.

Ayrıca bu soru mağaza girişinde kullanıcının gördüğü bir bilgiye dönüşüyor. Silme talebi mekanizması sunuyorsanız ya da veriyi Google'ın belirlediği süre içinde otomatik olarak silip anonimleştiriyorsanız ilgili seçeneği işaretleyebilirsiniz. Yasal uyumluluk veya kötüye kullanımı önleme gibi nedenlerle bazı verileri saklamanız bu seçeneği engellemiyor.

Öte yandan "evet" dediğiniz mekanizmanın gerçekten çalışması gerekir. Örneğin silme için yönlendirdiğiniz e-posta adresine kimse bakmıyorsa beyanınız kâğıt üzerinde kalır. Biz bu nedenle silme taleplerini kayıt altına alan basit bir iş akışı kurmayı ve yanıt sürecini gizlilik politikasında anlatmayı öneriyoruz. Güncel süre ve koşulları resmi sayfadan kontrol edin.

Hesap açılan uygulamalarda silme bağlantısını nasıl hazırlarsınız?

Uygulamanız kullanıcıların uygulama içinden hesap oluşturmasına izin veriyorsa Google iki şey istiyor. Bu kuralları Play Console Yardım'daki hesap silme şartları sayfasından doğruladık:

1. Kullanıcının hesabını ve ilişkili verilerini silebileceği bir uygulama içi yol; ideal olarak hesap ayarları gibi belirgin bir yerde.
2. Kullanıcının uygulamayı yeniden yüklemeden hesap ve veri silme talep edebileceği bir web sayfası bağlantısı.
3. Bu web bağlantısının veri güvenliği formundaki ilgili alana girilmesi.

Web sayfası çalışmalı, kullanıcının kolayca bulabileceği bir yerde durmalı ve Google Play'de görünen uygulama ya da geliştirici adına atıf yapmalı. Kullanıcının önce bir aboneliği iptal etmesi gibi ek adımlar varsa bunları sayfada açıkça anlatmalısınız. Ayrıca güvenlik, dolandırıcılığı önleme veya mevzuat gibi nedenlerle sakladığınız veriler varsa bunu kullanıcıya örneğin gizlilik politikasında açıkça bildirmelisiniz.

Uygulama dışında açılan bir kayıt akışına yönlendirseniz bile şart geçerli. Dolayısıyla "kayıt işlemi web sitemizde" demek sizi bu yükümlülükten kurtarmaz.

Gizlilik politikası ile form neden birebir uyuşmalı?

Google Play'in kullanıcı verisi politikasına göre her uygulama Play Console'daki ilgili alana bir gizlilik politikası bağlantısı eklemeli ve uygulama içinde de bu politikaya bağlantı ya da metin sunmalı. Bu şartları Kullanıcı Verileri politikası sayfasından doğruladık.

Politikanın da bazı koşulları var. Etkin, herkese açık, coğrafi kısıtlaması olmayan ve düzenlenemeyen bir adreste yayında olmalı; PDF kabul edilmiyor. İçerikte geliştirici bilgisi, gizlilik iletişim kanalı, erişilen ve toplanan veri türleri, paylaşılan taraflar, güvenli işleme yöntemleri ve saklama ile silme politikası yer almalı.

Peki uyum neden bu kadar önemli? Çünkü politika ile form birbirinden farklı şeyler söylediğinde inceleme ekibi ya da kullanıcı bu çelişkiyi kolayca fark eder. Örneğin politikada "reklam ortaklarıyla veri paylaşıyoruz" yazıp formda paylaşım yok demek doğrudan bir tutarsızlıktır. Türkiye'deki kullanıcılar için aydınlatma ve açık rıza tarafını mobil uygulamada KVKK uyumu yazımızda ayrıca ele aldık. Bu yazı hukuki danışmanlık değildir; metinleri hukuk danışmanınızla birlikte hazırlayın.

Play Console'da Google Play veri güvenliği formunu adım adım nasıl doldurursunuz?

Resmi sayfadaki akışa göre form, Play Console'daki Uygulama içeriği (App content) sayfasında yer alıyor. Menü adları zaman zaman değişebildiği için panelde ilgili bölümü bulamazsanız arama kutusunu kullanın. Akış genel hatlarıyla şöyle:

1. Play Console'da uygulamanızı açın ve Uygulama içeriği sayfasına gidin.
2. Veri güvenliği bölümünde başlat seçeneğine tıklayın ve genel bakışı okuyun.
3. İlk adımda (veri toplama ve güvenlik) gerekli veri türlerinden herhangi birini toplayıp paylaşmadığınızı belirtin; evet diyorsanız şifreleme ve silme sorularını yanıtlayın.
4. Veri türleri adımında topladığınız ve paylaştığınız türleri seçin.
5. Kullanım ve işleme adımında her tür için amaçları ve zorunlu ya da isteğe bağlı durumunu girin.
6. Mağaza girişi önizlemesinde bilgilerin kullanıcıya nasıl görüneceğini okuyun.
7. Formu gönderin ya da taslak olarak kaydedin.

Önizleme adımını atlamayın. Kullanıcının mağazada göreceği özet, formdaki teknik cevapların sade bir çevirisidir; orada size garip gelen bir satır varsa büyük ihtimalle bir cevabı yanlış seçmişsinizdir. Ardından Google gönderdiğiniz formu uygulama incelemesinin bir parçası olarak değerlendirir.

CSV ile içe ve dışa aktarma ne işe yarar?

Resmi sayfaya göre veri güvenliği sayfasında formu CSV dosyası olarak dışa aktarabilir ve CSV dosyasından içe aktarabilirsiniz. Google ayrıca çevrimdışı doldurmak için örnek bir CSV dosyası sunuyor. Her satır bir cevabı temsil ediyor ve yanıt değeri sütununa doğru ya da yanlış değerini yazıyorsunuz.

Bu özellik özellikle şu durumlarda işe yarar:

• Aynı altyapıyı kullanan birden fazla uygulamanız varsa ortak bir şablondan başlarsınız.
• Formu hukuk ya da güvenlik ekibinizle paylaşıp onay almak istiyorsanız tabloyu e-postayla gönderirsiniz.
• Her sürümde formun bir kopyasını arşivleyerek neyi ne zaman değiştirdiğinizi takip edersiniz.

Ancak dikkat edin: içe aktarma, formda daha önce girdiğiniz cevapların üzerine yazar. Bu yüzden içe aktarmadan önce mevcut formu mutlaka dışa aktarıp yedekleyin. Böylece yanlış bir dosya yüklerseniz eski cevaplara dönebilirsiniz. Biz her güncellemede dosyayı sürüm numarasıyla adlandırıp proje klasöründe saklıyoruz.

İsteğe bağlı rozetler ne anlama geliyor?

Formun güvenlik uygulamaları kısmında zorunlu olmayan bazı beyanlar da var. Bunlar mağaza girişinde ek bir bilgi olarak görünebiliyor; ancak her uygulama için uygun değiller.

İlki bağımsız güvenlik incelemesi. Resmi sayfaya göre bu inceleme isteğe bağlı, ücretini geliştirici ödüyor ve Google'ın yetkilendirdiği bir laboratuvar bu işi mobil uygulama güvenlik değerlendirmesi (MASA) çerçevesinde, OWASP MASVS standardına göre yürütüyor. Ancak Google, bu incelemenin kapsamının form beyanlarınızın doğruluğunu ve eksiksizliğini doğrulamayı içermeyebileceğini de belirtiyor. Yani rozet, formu doğru doldurma sorumluluğunuzu ortadan kaldırmaz. Uygulama güvenliğinin genel çerçevesi için OWASP Top 10 yazımıza göz atabilirsiniz.

İkincisi Aileler politikası taahhüdü. Çocukları hedefleyen ve uygun olan uygulamalar, Play Aileler politikasına uyma taahhüdünü bu bölümde gösterebiliyor. Hedef kitlenizde çocuklar varsa Aileler politikasının tüm şartlarını ayrıca okuyun.

Yanlış beyanın sonuçları nelerdir?

Google beyanların eksiksiz ve doğru olmasından yalnızca geliştiricinin sorumlu olduğunu açıkça söylüyor. Üstelik inceleme sürecinin beyanlarınızın doğruluğunu tek tek doğrulamak için tasarlanmadığını da belirtiyor. Ancak bu "kimse bakmıyor" anlamına gelmiyor; Google tutarsızlıkları tespit edebiliyor ve yaptırım uygulayabiliyor.

Resmi sayfanın SSS bölümüne göre Google veri beyanı yanlış olan bir uygulamadan düzeltme istiyor. Uyumlu hale gelmeyen uygulamalar ise politika yaptırımına konu oluyor; Google örnek olarak güncelleme engelini ve uygulamanın mağazadan kalkmasını sayıyor.

Dolayısıyla yanlış beyanın maliyeti yüksek. Uygulamanız mağazadan kalktıysa itiraz sürecini Google Play politika ihlali ve itiraz yazımızda adım adım anlattık. Hiçbir yöntem itirazın kabulünü garanti etmez. Yeni bir geliştirici hesabı açarak yaptırımı atlatmaya çalışmak da kuralları atlatma girişimi anlamına gelir ve durumu ağırlaştırır.

Mağaza reddinin diğer yaygın nedenlerini ise en sık mağaza red nedenleri yazımızda topladık.

Örnek senaryoda bir sipariş uygulamasının formu neye benzer?

Aşağıdaki tablo tamamen bir örnek senaryodur; kendi uygulamanızın cevapları veri akışınıza göre farklı olacaktır. Senaryoda kullanıcı hesap açıyor, sipariş veriyor, konumla en yakın şubeyi buluyor ve uygulama analiz ile çökme raporlama SDK'sı kullanıyor.

Ödeme kartı bilgisini bu senaryoda bilerek tabloya koymadık. Kart bilgisi doğrudan ödeme sağlayıcısının ekranında işleniyorsa beyanın nasıl yapılacağını sağlayıcının rehberinden kontrol etmeniz gerekir. Kısacası tablo bir şablon değil, düşünme biçimini gösteren bir örnektir.

Göndermeden önce hangi kontrol listesini kullanmalısınız?

Biz formu göndermeden önce aşağıdaki tabloyu satır satır kontrol ediyoruz. Her satırda "evet" diyemiyorsanız formu taslak olarak kaydedin ve eksikleri tamamlayın.

Bu listeyi her sürümde yeniden çalıştırın. Özellikle yeni bir SDK eklediğiniz ya da bir özelliği kaldırdığınız sürümlerde form da değişir.

Google Play veri güvenliği formunu ne zaman güncellemelisiniz?

Resmi sayfa cevapların her zaman doğru ve eksiksiz kalması gerektiğini söylüyor. Yani form bir kez doldurulup unutulan bir belge değil; uygulamanızın veri davranışı değiştiğinde siz de formu güncellersiniz.

Şu durumlarda formu mutlaka yeniden gözden geçirin:

• Yeni bir SDK eklediğinizde ya da mevcut SDK'nın sürümünü yükselttiğinizde.
• Yeni bir özellik yeni bir veri türü topladığında; örneğin fotoğraf yükleme ya da sohbet eklediğinizde.
• Bir veriyi yeni bir amaçla, örneğin pazarlama için kullanmaya başladığınızda.
• Gizlilik politikanızı değiştirdiğinizde.

Ayrıca resmi sayfa, form güncellemesinin cihazlara yansımasının birkaç gün sürebileceğini belirtiyor. Bu nedenle değişikliği sürümden hemen önce değil, makul bir süre önce planlayın. iOS tarafında aynı işi gizlilik etiketleriyle yaparsınız; bunu App Store gizlilik etiketleri yazımızda anlattık.

Formu kendiniz mi doldurmalısınız, ekip desteği mi almalısınız?

Basit, sunucusu olmayan ve SDK kullanmayan bir uygulamanız varsa formu bu rehberle kendiniz doldurabilirsiniz. Ancak hesap açılan, ödeme alan, reklam gösteren ya da birden fazla SDK kullanan bir uygulamada formu doğru doldurmak kodu bilmeyi gerektirir. Çünkü formdaki her cevap, kodda gerçekten ne olduğuna dayanır.

Talha Aslan ve ekibi olarak geliştirdiğimiz uygulamalarda veri envanterini, SDK listesini, gizlilik politikası taslağını ve hesap silme akışını projenin baştan bir parçası olarak ele alıyoruz. Uygulamanızı biz geliştirir, mağazaya biz çıkarırız; veri güvenliği formunu da bu sürecin içinde biz hazırlarız. Projenizi anlatıp teklif almak için mobil uygulama geliştirme hizmetimizin sayfasına göz atabilirsiniz.

Mevcut bir uygulamanız formdaki bir sorun yüzünden takıldıysa da süreci birlikte değerlendirebiliriz. Kod tabanınızı inceleyip veri akışını çıkarır, formu ve gizlilik metnini gerçek duruma göre düzenleriz. Bunun için mobil uygulama hizmet sayfamızdaki teklif formunu kullanabilirsiniz. Hiçbir hizmet mağaza onayını garanti etmez; ancak doğru beyan, sorun çıkma ihtimalini ciddi ölçüde azaltır.