App Privacy Labels Nedir, Nasıl Hazırlanır?

App Privacy Labels, Apple App Store ve Google Play Store üzerinde dağıtılan mobil uygulamaların hangi kullanıcı verilerini topladığını, bu verileri hangi amaçlarla işlediğini ve üçüncü taraflarla paylaşıp paylaşmadığını şeffaf bir biçimde beyan eden standartlaştırılmış gizlilik bildirimleridir. Mobil ürün yöneticileri, teknik kurucular ve geliştiriciler için bu etiketleri doğru kurgulamak, yalnızca mağaza onay süreçlerini (App Review) sorunsuz geçmek adına değil; KVKK, GDPR ve CCPA gibi küresel veri koruma regülasyonlarına uyum sağlamak açısından da kritik bir operasyonel zorunluluktur. Bu teknik rehberde; veri envanterinin çıkarılmasından üçüncü taraf SDK analizlerine, App Store Connect ve Google Play Console formlarının adım adım doldurulmasından yaygın ret (rejection) nedenlerine kadar tüm süreç derinlemesine incelenmektedir.

App Privacy Labels (Uygulama Gizlilik Etiketleri) Nedir?

App Privacy Labels, Apple tarafından iOS 14.4 lansmanıyla hayatımıza giren ve kısa süre sonra Google Play ekosisteminde "Data Safety" (Veri Güvenliği) adıyla zorunlu hale getirilen yapılandırılmış veri şeffaflığı sistemidir. Geleneksel yaklaşımlarda kullanıcı sözleşmeleri ve gizlilik politikaları on binlerce kelimelik hukuki metinlerin ardına gizlenirken, modern uygulama mağazaları bu pratikleri kullanıcıların tek bakışta anlayabileceği modüler "besin değerleri tablosu" formatına dönüştürmüştür. Bir mobil uygulamanın App Store veya Google Play Store ürün sayfasında yer alan bu etiketler; toplanan verilerin türünü, toplanma amacını, verinin kullanıcı kimliğiyle doğrudan eşleştirilip eşleştirilmediğini ve üçüncü taraf reklam ağlarıyla çapraz takip (cross-app tracking) amacıyla paylaşılıp paylaşılmadığını açıkça listeler.

Geliştiriciler ve işletmeler açısından App Privacy Labels, yalnızca mağazaya yükleme aşamasında doldurulan statik bir form değildir. Bu etiketler; uygulamanın kaynak kodunda çalışan her bir fonksiyonun, arka uç (backend) mimarisinin ve projeye dahil edilen analitik, reklam, çökme raporlama veya bildirim SDK'larının (Software Development Kit) gerçekleştirdiği tüm veri alışverişinin yasal ve teknik bir özetidir. Konsol üzerinde yapılan beyanlar, mağaza inceleme ekiplerinin (App Review Teams) otomatik statik kod analiz araçları ve dinamik ağ trafiği denetleyicileri tarafından taranır. Beyan edilmeyen bir ağ isteği veya bildirilmeyen bir veri alanı tespit edildiğinde, güncelleme derlemeleri (build) anında reddedilir.

Mobil ürün yaşam döngüsünde gizlilik etiketleri, kullanıcı edinme maliyetlerini (CAC) ve dönüşüm oranlarını doğrudan etkileyen bir güven unsuru haline gelmiştir. Kullanıcıların %70'ten fazlasının indirme öncesinde izin ve veri taleplerini incelediği düşünüldüğünde, gereksiz veya aşırı agresif veri toplama beyanında bulunan uygulamaların mağaza dönüşüm hunisinde (App Store Conversion Funnel) ciddi düşüşler yaşadığı görülmektedir. Dolayısıyla, bir veri alanının toplanıp toplanmayacağı kararı yalnızca teknik bir optimizasyon değil, aynı zamanda stratejik bir ürün yönetimi kararıdır.

Mobil Ekosistemde Veri Şeffaflığı Standartları

Apple ve Google, mobil işletim sistemleri düzeyinde kullanıcı mahremiyetini merkeze alan kapsamlı mimari değişiklikler uygulamaktadır. Apple tarafında App Tracking Transparency (ATT) çerçevesiyle IDFA (Identifier for Advertisers) erişimi kullanıcı iznine bağlanmış; Google tarafında ise Privacy Sandbox ve Advertising ID (GAID) kısıtlamaları devreye alınmıştır. Gizlilik etiketleri, bu işletim sistemi düzeyindeki teknik kontrollerin mağaza vitrinindeki yansımasıdır. Standartlaştırma sayesinde kullanıcılar; finansal bilgilerden kesin konum verilerine, cihaz tanımlayıcılarından kullanıcı etkileşim loglarına kadar onlarca farklı veri tipinin ne amaçla işlendiğini standart parametrelerle karşılaştırabilir.

Platform standartları, toplanan verileri "isteğe bağlı" ve "zorunlu" olmak üzere iki farklı operasyonel boyutta değerlendirir. Eğer bir e-ticaret uygulaması teslimat adresini doğrulamak için konum verisi topluyorsa, bu veri doğrudan uygulama işlevselliği (App Functionality) kapsamında değerlendirilir. Ancak aynı konum verisi kullanıcının haberi olmadan reklam hedefleme amacıyla üçüncü taraf bir programmatic ağa iletiliyorsa, bu işlem gizlilik etiketlerinde "Takip Amaçlı Kullanılan Veriler" (Data Used to Track You) altında beyan edilmek zorundadır. Standartların ihlali yalnızca mağaza kurallarını değil, küresel veri koruma standartlarını da doğrudan tetikler.

Besin Değeri Tablosu Modeli ve Temel Bileşenler

Uygulama gizlilik etiketleri konsepti, gıda sektöründeki "besin değerleri tablosu" analojisinden ilham almıştır. Bir tüketici nasıl ki satın aldığı ürünün kalori, yağ ve şeker oranını ambalajdan görüyorsa; bir mobil uygulama kullanıcısı da yükleme yapmadan önce dijital ayak izinin nasıl işleneceğini görebilmelidir. Bu model üç temel eksen üzerine inşa edilmiştir:

• Veri Kategorileri: Konum, iletişim bilgileri, finansal bilgiler, sağlık verileri, kullanıcı içerikleri, arama geçmişi, tanımlayıcılar (ID), kullanım verileri, tanılama (diagnostics) ve diğer hassas veri türleri.

• Kullanım Amaçları: Üçüncü taraf reklamcılığı, geliştiricinin kendi reklam veya pazarlama faaliyetleri, analiz (analytics), ürün kişiselleştirme, uygulama işlevselliği ve dolandırıcılığı önleme/güvenlik.

• İlişkilendirme ve Takip Düzeyi: Verilerin kullanıcı hesabıyla veya cihaz kimliğiyle bağlanıp bağlanmadığı (Linked to User) ve harici veri broker'ları veya reklam ağlarıyla eşleştirilip eşleştirilmediği (Tracking).

Bu bileşenlerin eksiksiz haritalanması, uygulamanın teknik mimarisinde çalışan her bağımlılığın tek tek denetlenmesini zorunlu kılar.

Gizlilik Etiketleri Neden Zorunludur? Yasal ve Platform Yaptırımları

Gizlilik etiketlerinin doldurulması, uygulama geliştiricileri için opsiyonel bir tercih veya pazarlama süsü değil, hem Apple App Store Review Guidelines (özellikle Madde 5.1.1) hem de Google Play Developer Distribution Agreement uyarınca bağlayıcı bir sözleşme koşuludur. Bu etiketlerin eksik bırakılması durumunda App Store Connect ve Google Play Console, yeni bir derleme (IPA veya AAB dosyası) yüklenmesine veya mevcut uygulamanın güncellenmesine izin vermemektedir. Zorunluluğun arkasında yalnızca platformların kendi ekosistemlerini koruma arzusu değil; Avrupa Birliği, Amerika Birleşik Devletleri, Birleşik Krallık, Türkiye ve Birleşik Arap Emirlikleri gibi farklı yargı bölgelerindeki katı veri gizliliği yasaları yatmaktadır.

Platformlar, kendi yasal sorumluluklarını minimize etmek adına veri işleme pratiklerinin sorumluluğunu geliştiriciye aktarmaktadır. Konsollar üzerinde yapılan her beyan, geliştiricinin imzaladığı yasal bir taahhüt niteliğindedir. Yanlış veya yanıltıcı beyanların bulunması durumunda Apple ve Google, bağımsız denetim mekanizmalarını veya kullanıcı şikayetlerini gerekçe göstererek uygulamayı doğrudan yayından kaldırabilmekte (delisting) ve geliştirici hesabını kalıcı olarak sonlandırabilmektedir. Geliştirici hesabının feshi (Account Termination), o hesaba bağlı tüm diğer uygulamaların, abonelik gelirlerinin ve mağaza varlıklarının anında dondurulması anlamına gelir.

Hukuki düzlemde ise bu etiketler, resmi gizlilik politikasının (Privacy Policy) kamuya açık bir özeti olarak kabul edilmektedir. Regülatörler ve veri koruma otoriteleri, bir şirketin mobil uygulamasının gerçekte ne topladığını denetlemek için ilk olarak mağaza gizlilik etiketlerini ve resmi aydınlatma metinlerini çapraz kontrole tabi tutar. Konsol beyanları ile sunucu logları veya ağ istekleri arasında çelişki tespit edildiğinde, veri sorumlusu tüzel kişilikler doğrudan idari para cezaları ve soruşturmalarla karşı karşıya kalmaktadır.

Yasal Zorunluluklar ve Düzenleyici Çerçeve (GDPR, KVKK, CCPA)

Dünya genelindeki veri gizliliği mevzuatları, veri sorumlularına şeffaflık, hesap verebilirlik ve amaca bağlılık ilkelerini dayatmaktadır. App Privacy Labels, bu mevzuatların şeffaflık ve açık rıza gereksinimlerini karşılamak için teknik bir arayüz görevi görür:

• Avrupa Birliği (GDPR): Madde 13 ve 14 kapsamında veri sorumlusu, verinin toplanma anında işleme amaçlarını, yasal dayanaklarını ve alıcı gruplarını kullanıcıya bildirmek zorundadır. Gizlilik etiketleri bu bilgilendirmenin mağaza aşamasındaki ilk temas noktasıdır.

• Türkiye (6698 Sayılı KVKK): Madde 10 uyarınca veri sorumlusunun aydınlatma yükümlülüğü bulunmaktadır. Veri kategorilerinin, aktarım amaçlarının ve üçüncü taraflara veri transferinin (yurt içi/yurt dışı) açıkça tanımlanması zorunludur.

• Amerika Birleşik Devletleri (CCPA/CPRA & Eyalet Yasaları): Kullanıcılara verilerinin "satılması" (sale) veya "paylaşılması" (share) konusunda bilgilendirilme ve bundan çıkma (opt-out) hakkı tanınır. App Store ve Play Store etiketleri, özellikle reklam amaçlı veri paylaşımının beyan edilmesini CCPA uyumu için zorunlu kılar.

• Birleşik Arap Emirlikleri (Federal Decree Law No. 45/2021 on PDPL): BAE sınırları içinde kişisel veri işleyen uygulamaların rıza mekanizmalarını ve veri işleme sınırlarını net şekilde belgelemesini gerektirir.

Platform Kuralları, Uygulama Reddi (Rejection) ve Hesap Feshi Riskleri

Uygulama mağazalarında gizlilik etiketi kaynaklı yaptırımlar aşamalı ancak sert bir biçimde uygulanır. En yaygın risk faktörleri şunlardır:

1. Statik İnceleme Reddi (Metadata Rejection): Konsolda belirtilen veri etiketleri ile uygulamanın talep ettiği izinler (Info.plist veya AndroidManifest.xml içerisindeki izin dizgileri) uyuşmadığında derleme incelemeden geçemez. Örneğin, kamerayı kullanan ancak gizlilik etiketlerinde "Kullanıcı İçeriği: Fotoğraflar veya Videolar" seçeneğini işaretlemeyen uygulamalar anında reddedilir.

2. Dinamik Ağ Analizi Tespiti: Apple ve Google test ortamlarında uygulamayı otomatik botlarla çalıştırır. Uygulamanın açılış anında, kullanıcı rızası alınmadan üçüncü taraf bir analitik ya da reklam sunucusuna cihaz tanımlayıcısı (IDFV, GAID) gönderildiği tespit edilirse uygulama "Guideline 5.1.2 - Data Collection and Storage" gerekçesiyle mağazadan çekilir.

3. Kalıcı Geliştirici Hesabı İptali: Kasıtlı olarak veri toplama pratiklerini gizleyen, gizli arka kapı kodları barındıran veya mağaza uyarılarına rağmen gizlilik etiketlerini düzeltmeyen geliştiricilerin hesapları "Trust and Safety" politikaları kapsamında kapatılır.

Uygulama Veri Envanterinin Çıkarılması (Hazırlık Aşaması)

Konsol ekranlarına geçmeden önce yapılması gereken en kritik operasyonel aşama, kapsamlı bir Mobil Veri Envanteri (Mobile Data Inventory) çıkarmaktır. Birçok yazılım ekibi ve ürün yöneticisi, yalnızca kendi yazdıkları kod üzerinden veri topladıklarını varsayarak yanılgıya düşer. Oysa modern bir mobil uygulamanın kaynak kodunun ortalama %60 ila %80'i açık kaynaklı kütüphanelerden ve üçüncü taraf SDK'lardan oluşmaktadır. Konsolda yanlış beyan verilmesinin bir numaralı nedeni, entegre edilen harici SDK'ların arka planda topladığı verilerden geliştiricinin haberdar olmamasıdır.

Veri envanteri süreci; yazılım geliştiriciler, ürün yöneticileri, siber güvenlik uzmanları ve hukuk/uyum departmanının ortaklaşa yürüteceği teknik bir denetimdir. Bu aşamada uygulamanın topladığı tüm veri noktaları bir matriste listelenmeli, her bir veri tipinin kaynağı (birinci taraf kod mu, harici SDK mı?), toplanma yöntemi, sunucuda saklanma süresi ve işleme amacı netleştirilmelidir.

Birinci Taraf (First-Party) Veri Toplama Pratiklerinin Analizi

Birinci taraf veri, doğrudan uygulamanızın kendi backend sistemlerine iletilen, kullanıcı tarafından manuel girilen veya cihaz sensörleri aracılığıyla doğrudan uygulamanın kendi fonksiyonları için toplanan verilerdir. Bu verilerin analizi yapılırken şu sorular yanıtlanmalıdır:

• Kayıt ve Profil Bilgileri: Kullanıcıdan ad, soyad, e-posta adresi, telefon numarası veya doğum tarihi isteniyor mu? Bu bilgiler veritabanında kullanıcı kimliğiyle (User ID) mi tutuluyor?

• Finansal ve Ödeme Verileri: Uygulama içi satın alma haricinde doğrudan kredi kartı, fatura adresi veya banka hesap bilgisi toplanıyor mu? (Not: Apple In-App Purchase ve Google Play Billing verileri platform tarafından yönetilir, ancak özel ödeme altyapıları beyan gerektirir).

• Konum Verileri: GPS tabanlı kesin konum (Precise Location - 5 metreden daha hassas) mu yoksa IP tabanlı yaklaşık konum (Coarse Location) mu alınıyor?

• Kullanıcı Etkileşim ve Davranış Verileri: Uygulama içindeki tıklamalar, sayfa görüntülemeleri, oturum süreleri ve video izleme geçmişi kendi sunucularınızda kayıt altına alınıyor mu?

Üçüncü Taraf SDK'ların (Third-Party SDK) Veri Toplama Etkisi

Mobil ekosistemde en büyük gizlilik riskini üçüncü taraf SDK'lar oluşturur. Uygulamanıza eklediğiniz her bir kütüphane, uygulamanın sahip olduğu tüm izinlere (kamera, konum, internet erişimi, depolama vb.) doğrudan erişim hakkı kazanır. Bu nedenle projenizdeki her bir SDK'nın resmi "Data Collection Disclosure" veya "Privacy Manifest" belgeleri incelenmelidir:

Apple App Store Connect Üzerinde App Privacy Nasıl Doldurulur?

Apple ekosisteminde gizlilik etiketlerinin doldurulması işlemi App Store Connect platformu üzerinden, uygulamanın "App Privacy" (Uygulama Gizliliği) menüsü altından gerçekleştirilir. 1 Mayıs 2024 itibarıyla Apple, üçüncü taraf SDK'lar için "Privacy Manifests" (PrivacyInfo.xcprivacy dosyası) zorunluluğu getirmiştir. Bu mimari güncelleme sayesinde, Xcode derleme aşamasında SDK'ların beyan ettiği gizlilik bildirimleri otomatik olarak birleştirilmekte ve geliştiricinin App Store Connect üzerindeki beyanlarıyla karşılaştırılmaktadır.

Sürece başlamak için App Store Connect'e giriş yapılarak ilgili uygulama seçilir ve sol menüdeki App Privacy sekmesine tıklanır. Karşınıza ilk olarak "Do you or your third-party partners collect data from this app?" (Siz veya üçüncü taraf iş ortaklarınız bu uygulamadan veri topluyor musunuz?) sorusu çıkar. Eğer uygulamanız tamamen çevrimdışı çalışan, hiçbir ağ isteği atmayan, hiçbir analitik veya çökme raporlama SDK'sı barındırmayan bir araç değilse, bu soruya mutlaka "Yes, we collect data from this app" yanıtı verilmelidir.

Bu yanıtın ardından Apple, toplanan verileri 14 farklı kategori ve bu kategorilerin altındaki onlarca veri tipi üzerinden sorgulamaya başlar. Her bir veri tipi için üç temel aşama tamamlanmalıdır: Veri Türünün Seçilmesi, Veri Kullanım Amacının Belirlenmesi ve Verinin Kullanıcı Kimliğiyle İlişkilendirilme Durumunun Tanımlanması.

Adım Adım Veri Türlerini (Data Types) Eşleştirme

Apple ekosisteminde veri tipleri şu ana gruplara ayrılmıştır:

• Contact Info (İletişim Bilgileri): Name, Email Address, Phone Number, Physical Address.

• Health & Fitness (Sağlık ve Fitness): HealthKit verileri, egzersiz kayıtları.

• Financial Info (Finansal Bilgiler): Payment Info, Credit Score, Salary/Income.

• Location (Konum): Precise Location (kesin GPS), Coarse Location (hücresel/IP).

• Sensitive Info (Hassas Bilgiler): Irk, etnik köken, cinsel yönelim, dini/felsefi inançlar, sendika üyeliği.

• User Content (Kullanıcı İçeriği): Emails/Text Messages, Photos/Videos, Audio Data, Gameplay Content, Customer Support.

• Browsing History (Tarama Geçmişi): Uygulama içi web tarayıcısında ziyaret edilen URL'ler.

• Search History (Arama Geçmişi): Uygulama içi arama motorunda yapılan sorgular.

• Identifiers (Tanımlayıcılar): User ID (hesap ID'si), Device ID (IDFV, donanım kimlikleri).

• Usage Data (Kullanım Verileri): Product Interaction (dokunmalar, ekran geçişleri), Advertising Data.

• Diagnostics (Tanılama): Crash Data, Performance Data (başlatma süresi, bellek sızıntıları).

Her bir veri türü seçildiğinde, sistem bu verinin ne amaçla kullanıldığını sorar:

1. Third-Party Advertising (Üçüncü Taraf Reklamcılığı)

2. Developer's Advertising or Marketing (Geliştiricinin Reklam/Pazarlaması)

3. Analytics (Analitik)

4. Product Personalization (Kişiselleştirme)

5. App Functionality (Uygulama İşlevselliği)

6. Other Purposes (Diğer Amaçlar)

Verilerin Kullanıcıyla İlişkilendirilmesi (Linked to User) Durumu

Seçilen her veri tipi için Apple şu kritik soruyu yöneltir: "Is this data linked to the user's identity?" (Bu veri kullanıcının kimliğiyle ilişkilendiriliyor mu?).

Bir verinin "Linked to User" sayılması için, kullanıcının doğrudan adıyla saklanması gerekmez. Eğer toplanan veri; bir kullanıcı hesabı (Account ID), benzersiz bir cihaz kimliği (Device ID), oturum jetonu (Session Token) veya IP adresi üzerinden belirli bir profille eşleştirilebiliyorsa, bu veri "Linked to You" (Sizinle İlişkilendirilen Veri) olarak işaretlenmelidir.

Verinin "Not Linked to User" (Sizinle İlişkilendirilmeyen Veri) sayılabilmesi için, sunucuya ulaşmadan önce tamamen anonimleştirilmesi (k-anonymity, differential privacy gibi tekniklerle) ve hiçbir şekilde belirli bir kullanıcı hesabına, cihaza veya IP'ye geri döndürülemeyecek şekilde parçalanması gerekir. Firebase Analytics veya Crashlytics gibi araçlar varsayılan kurulumda Device ID ve User Instance ID kullandığı için genellikle "Linked to User" kategorisinde beyan edilmelidir.

Takip (Tracking) ve App Tracking Transparency (ATT) Gereksinimleri

Apple terminolojisinde Tracking (Takip) kavramının çok katı ve net bir teknik tanımı vardır. Tracking; uygulamanızdan toplanan kullanıcı veya cihaz verilerinin (IDFA, e-posta karması, telefon numarası vb.), üçüncü taraflara ait diğer şirketlerin uygulamalarından, web sitelerinden veya çevrimdışı mülklerinden toplanan verilerle hedefli reklamcılık veya reklam ölçümlemesi amacıyla birleştirilmesi anlamına gelir.

Eğer uygulamanızda Facebook (Meta) SDK, Google AdMob, AppsFlyer veya Adjust gibi araçlar kullanılıyor ve bu araçlar IDFA üzerinden çapraz uygulama takibi yapıyorsa:

1. App Store Connect üzerinde ilgili veri tipleri için "Used for Tracking" seçeneği işaretlenmelidir.

2. Uygulama kodunda iOS AppTrackingTransparency entegre edilmeli ve kullanıcıya sistem düzeyindeki ATT izin istemi (requestTrackingAuthorization) gösterilmelidir.

3. Info.plist dosyasına NSUserTrackingUsageDescription anahtarı eklenerek kullanıcının neden takip edileceği açıkça yazılmalıdır.

4. Kullanıcı izin vermezse (denied), IDFA değeri tamamen sıfırlardan oluşur (00000000-0000-0000-0000-000000000000) ve geliştirici hiçbir alternatif cihaz parmak izi (fingerprinting) yöntemine başvuramaz.

Google Play Console Veri Güvenliği (Data Safety) Formu Nasıl Hazırlanır?

Google Play Store ekosisteminde gizlilik etiketleri, Google Play Console içerisinde yer alan Data Safety (Veri Güvenliği) formu aracılığıyla yönetilir. Google'ın yaklaşımı Apple'a oldukça benzemekle birlikte, özellikle "Veri Toplama" (Data Collection) ile "Veri Paylaşımı" (Data Sharing) arasındaki teknik ayrım ve "Veri Silme Mekanizmaları" (Data Deletion) konusunda kendine has katı kurallara sahiptir.

Google Play Console'da sol menünün en altında yer alan App content (Uygulama içeriği) > Data safety bölümünden forma erişilir. Google, geliştiricilere beyanlarının doğruluğunu denetlemek için Google Play SDK Index altyapısını kullanır. Projenizde yer alan bir SDK'nın (örneğin Firebase veya Facebook SDK) bilinen veri toplama pratikleri Google'ın sisteminde kayıtlıdır; bu nedenle SDK Index verileriyle çelişen bir form doldurulduğunda konsol uyarı verir ve güncelleme yayınlanmasını engeller.

Google Play Form Adımları ve Doğru Yanıt Beklentileri

Google Play Data Safety formu dört ana aşamadan oluşur:

1. Genel Bakış (Overview):

• Uygulamanız herhangi bir kullanıcı verisi topluyor veya paylaşıyor mu?

• Toplanan tüm veriler aktarım sırasında şifreleniyor mu (Encryption in transit)?

• Uygulamanız kullanıcılara hesap ve verilerinin silinmesini talep etme imkanı sunuyor mu?

1. Veri Toplama ve Paylaşım Türleri:

Google, verileri Konum, Kişisel Bilgiler, Finansal Bilgiler, Sağlık ve Fitness, Mesajlar, Fotoğraflar ve Videolar, Ses Dosyaları, Dosyalar ve Dokümanlar, Takvim, Kişiler, Uygulama Etkinliği, Web'de Tarama, Uygulama Bilgileri ve Performans, Cihaz veya Diğer Kimlikler olmak üzere kategorize eder.

1. Veri Kullanımı ve İşleme Detayları:

Seçilen her veri tipi için şu parametreler doldurulur:

• Toplanıyor mu? (Collected): Veri cihazdan harici bir sunucuya aktarılıyor mu? (Geçici/Ephemeral işlem hariç).

• Paylaşılıyor mu? (Shared): Veri üçüncü taraf bir şirkete veya hizmete aktarılıyor mu?

• İşleme Geçici mi? (Ephemeral Processing): Veri sunucuda yalnızca bellekte (RAM) anlık işlenip diske yazılmadan siliniyor mu?

• İsteğe Bağlı mı Zorunlu mu? (Optional vs Required): Kullanıcı bu veriyi vermeden uygulamayı kullanabilir mi?

1. Veri Koruma ve Güvenlik Standartları:

Uygulamanın bağımsız bir güvenlik denetiminden (MASVS - Mobile Application Security Verification Standard) geçip geçmediği beyan edilir.

Veri Şifreleme ve Silme Talebi (Data Deletion) Beyanları

Google Play politikalarının en kritik iki teknik bileşeni aktarım güvenliği ve veri silme mekanizmasıdır:

• Veri Aktarım Şifrelemesi (Encryption in Transit): Uygulamanızın cihazdan backend sunucularına veya üçüncü taraf API'lere gönderdiği tüm verilerin HTTPS / TLS 1.3 gibi endüstri standardı modern kriptografik protokollerle şifrelenmesi zorunludur. Formda "Verilerim aktarım sırasında şifreleniyor" kutusu işaretlenmelidir. Düz metin (HTTP cleartext) trafiği tespit edilen uygulamaların güncellemeleri durdurulur.

• Hesap ve Veri Silme Politikası (Data Deletion Requirement): 2024 başı itibarıyla Google Play, kullanıcıların uygulama içinden ve uygulama dışından (bir web URL'si aracılığıyla) hesap ve verilerinin silinmesini talep edebilmesini zorunlu kılmıştır. Formda bir "Data Deletion Request URL" (Veri Silme Talebi Bağlantısı) girilmelidir. Bu URL; kullanıcının uygulamayı cihazından silmiş olsa dahi tarayıcı üzerinden hesabının ve ilişkili verilerinin (örneğin işlem geçmişi, loglar, profil) silinmesini talep edebileceği çalışan bir web sayfası olmak zorundadır.

Sık Yapılan Hatalar ve Uygulama Reddi (Rejection) Nedenleri

Mobil uygulama geliştirme ve yayınlama süreçlerinde en sık karşılaşılan operasyonel darboğazlardan biri, gizlilik etiketleri uyumsuzluğu nedeniyle alınan App Store ve Google Play retleridir. Mağaza inceleme ekipleri, özellikle yeni bir sürüm yayınlanırken veya periyodik ekosistem taramalarında otomatik analiz araçları kullanır. Bu araçlar, uygulamanın binary dosyasını (IPA/AAB) decompile ederek içerisindeki API çağrılarını, string referanslarını ve ağ kütüphanelerini tarar.

Yapılan hatalar genellikle teknik ekipler ile ürün/hukuk ekipleri arasındaki iletişim kopukluğundan kaynaklanır. Örneğin yazılımcı, hata ayıklama amacıyla projeye geçici olarak eklediği bir crash loglama SDK'sını konsolda beyan etmeyi unutabilir veya pazarlama ekibinin entegre ettiği bir attribution kütüphanesinin IDFA topladığını fark etmeyebilir. Bu tür tutarsızlıklar, doğrudan uygulamanın mağazadan çıkarılmasına veya haftalarca süren inceleme süreçlerine (In Review Loop) takılmasına sebep olur.

Yanlış veya Eksik Beyanların Teknik Tespiti

Apple ve Google'ın otomatik denetim sistemlerinin en sık yakaladığı teknik uyuşmazlıklar şunlardır:

1. Info.plist / AndroidManifest.xml İzin Çelişkileri: Uygulamanın manifest dosyasında android.permission.ACCESS_FINE_LOCATION veya android.permission.CAMERA bulunmasına rağmen, konsol gizlilik formunda Konum veya Kamera verisinin "Toplanmıyor" olarak işaretlenmesi.

2. Device ID / IDFV / GAID Çelişkisi: Uygulamanın hiçbir veri toplamadığını iddia etmesi, ancak Firebase Installs veya OneSignal SDK'larının arka planda benzersiz donanım tanımlayıcılarını sunucuya göndermesi.

3. Takip İzni Almadan Takip Yapılması: ATT istemi kullanıcıya sunulmadan veya kullanıcı "Ask App not to Track" (Takip Etme) seçeneğini seçtikten sonra üçüncü taraf reklam SDK'sının IDFA veya parmak izi verisini ağ üzerinden dışarıya aktarması.

Gizlilik Politikası Linki Hataları ve Mağaza Uyuşmazlıkları

Gizlilik etiketleri kadar, konsola girilen Privacy Policy URL bağlantısının geçerliliği de kritik bir denetim konusudur:

• Çalışmayan / 404 Veren Bağlantılar: Gizlilik politikası linkinin erişilemez olması doğrudan ret sebebidir.

• Genel / Şablon Politikalar: Uygulamanın adını dahi içermeyen, internetten kopyalanmış jenerik gizlilik politikaları inceleme ekipleri tarafından reddedilir. Politika metni, konsolda işaretlenen tüm veri kategorilerini ve üçüncü taraf SDK iş ortaklarını isim isim listelemelidir.

• Mobil Uyumsuz Sayfalar: Gizlilik politikasının açıldığı web sayfasının mobil cihazlarda düzgün render edilmemesi veya PDF formatında doğrudan indirmeye zorlaması mağaza yönergelerine aykırıdır.