Net bir UX, denetim günlükleri, API'ler ve güçlü güvenlikle onay ve tercihleri yönetmek için bir web uygulaması tasarlama, inşa etme ve dağıtma adım adım rehberi.
Ekranları tasarlamadan veya kod yazmadan önce ne inşa ettiğiniz—ve neyi yapmadığınız—konusunda net olun. “Onay” ve “tercihler” benzer seslense de genellikle yasal ve operasyonel olarak farklı anlamlara sahiptir. Bu tanımları erken doğru yapmak, daha sonra kafa karıştıran UX ve kırılgan entegrasyonların önüne geçer.
Onay daha sonra kanıtlayabileceğiniz bir izindir (kim kabul etti, neye, ne zaman ve nasıl). Örnekler: pazarlama e-postası almayı kabul etmek veya izleme çerezlerine izin vermek.
Tercihler deneyimi veya sıklığı şekillendiren kullanıcı seçimleridir (haftalık vs aylık güncellemeler, ilgilenilen konular). Bunları da güvenilir şekilde saklamalısınız, ama genellikle hukuki bir onayla aynı değildir.
İlk günde neyi yöneteceğinizi yazın:
Yaygın bir tuzak pazarlama onayı ile işlemsel mesajları (fişler veya şifre sıfırlamalar gibi) karıştırmaktır. Bunları tanımlarınızda, veri modelinizde ve arayüzünüzde ayrı tutun.
Bir onay yönetimi web uygulaması birçok ekibi etkiler:
Kararlar için net bir sahip atayın ve kurallar, satıcılar veya mesajlaşma değiştiğinde güncellemeler için hafif bir süreç tanımlayın.
Birkaç ölçülebilir sonuç seçin; örneğin daha az spam şikayeti, kafa karışıklığından kaynaklanan daha az abonelik iptali, GDPR onay kayıtlarına daha hızlı erişim, abonelik tercihleriyle ilgili daha az destek bileti ve istenildiğinde onay kanıtı sağlama süresinin kısalması.
Gizlilik kurallarını pratik ürün gereksinimlerine çevirin. Bu bölüm yüksek düzey bir yönlendirmedir, yasal tavsiye değildir—özellikleri şekillendirmek için kullanın, sonra ayrıntılar için hukuki danışmanla doğrulayın.
Fonksiyonel olarak bir onay yönetimi web uygulaması genellikle şunları ele almalıdır:
Onay kayıtlarınız şunları yakalamalıdır:
Onay kayıtları ve denetim günlüğü için veri saklama politikalarını tanımlayın (genellikle pazarlama verilerinden daha uzun tutulur). Yalnızca gerektiği kadarını saklayın, koruyun ve saklama sürelerini belgeleyin. Emin değilseniz “hukuki karar gerekiyor” yer tutucusu ekleyin ve dahili politika dökümanlarınıza (veya /privacy eğer kamuysa) bağlayın.
Son politika kararları—özellikle “satış/paylaşma”nın ne sayıldığı, çerez sınıflandırması ve saklama—hukuki danışmanla gözden geçirilmelidir.
Bir onay yönetimi web uygulaması veri modeline bağlıdır. Şema “kim neye, ne zaman ve nasıl onay verdi?” sorusunu cevaplayamıyorsa, uyumluluk, müşteri desteği ve entegrasyonlarla zorlanırsınız.
Birkaç net yapı taşıyla başlayın:
Bu ayrım tercih merkezini esnek tutar ve temiz GDPR onay kayıtları ile CCPA opt-out sinyalleri üretmeyi sağlar.
Her karara bağlı olarak gösterilen bildirim/politika sürümünü saklayın:
notice_id ve notice_version (veya içerik hash'i)Böylece metin değiştiğinde eski onaylar kanıtlanabilir kalır.
Her onay olayı için risk seviyenize uygun delil kaydedin:
İnsanlar iki kere kayıt olur. Birden çok tanımlayıcıyı bir müşteriye bağlayarak ve birleştirme geçmişi kaydederek birleştirmeleri modelleyin.
Geri dönüşleri açıkça temsil edin:
status: granted / withdrawnwithdrawn_at ve sebep (kullanıcı eylemi, admin talebi)Bir tercih merkezi, insanların “Bana ne göndereceksiniz ve bunu nasıl değiştiririm?” sorusuna hızlıca cevap verebilmelidir. Zekâdan çok açıklık hedefleyin ve kararların geri alınabilir olmasını sağlayın.
Kullanıcıların sizi her etkileşimde kolayca bulmasını sağlayın:
/preferences)Aynı ifade ve yapıyı tüm üç yerde kullanın ki kullanıcılar farklı bir yerde olduklarını hissetmesin.
“Konu güncellemeleri” veya “İpuçları ve rehberler” gibi kısa etiketler kullanın ve gerektiğinde tek satırlık açıklama ekleyin. Hukuki dilden kaçının.
Yasal düzenlemeler veya platform kuralları açıkça zorunlu kılmadıkça önce işaretlenmiş kutular kullanmayın. Birden fazla izin istiyorsanız, bunları net şekilde ayırın (örn. pazarlama e-postaları vs SMS vs ortaklarla veri paylaşımı).
İnsanların konu bazında ve gerekli ise kanal bazında (Email, SMS, Push) tercih seçmelerine izin verin. Ayrıca her zaman görünür olan bir global abonelik iptali sağlayın.
İyi bir desen:
Email kayıtları için gerekliyse çift onay (double opt-in) kullanın: kullanıcı tercihleri seçtikten sonra, aboneliği etkinleştiren bağlantıya tıklanana kadar abonelik aktif olmasın. Sayfada sonraki adımın ne olduğunu açıklayın.
Her şey klavye ile kullanılabilir, net odak durumları olsun, yeterli kontrast sağlayın ve ekran okuyucuların yorumlayabileceği etiketler kullanın (örn. “Haftalık özet e-postası al: Açık/Kapalı”).
Backend API, müşterinin neyi kabul ettiğinin ve ne almak istediğinin tek kaynağıdır. Temiz, öngörülebilir bir API tercih merkezini email, SMS ve CRM araçlarına bağlamayı kolaylaştırır ve çelişkili durumları önler.
Yüzeyi küçük ve açık tutun. Tipik bir set:
GET /api/preferences (veya admin kullanımı için GET /api/users/{id}/preferences)PUT /api/preferences (mevcut seti değiştirmek için; kısmi güncellemeden daha net)POST /api/consents/{type}/withdraw (kazayla olmaması için “güncelle”den ayrı)Her onay türünün açıkça adlandırıldığından emin olun (örn. email_marketing, sms_marketing, data_sharing).
Tarayıcılar ve entegrasyonlar istekleri yeniden deneyebilir. Bir yeniden deneme ikinci bir “abonelik iptali” olayı yaratırsa denetim izi karmaşıklaşır. Idempotency-Key başlığı (veya request_id alanı) kabul ederek aynı isteğin aynı sonucu üretmesini sağlayın ve sonucu saklayın.
Savunamayacağınız hiçbir şeyi kabul etmeyin:
granted, denied, withdrawn) ve geçişleri zorunlu kılınTahmin edilebilir hata biçimleri döndürün (örn. code, message, field_errors) ve ayrıntı sızdırmaktan kaçının. Onay geri çekme ve hesap arama gibi hassas endpointleri kötüye kullanımı azaltmak için hız sınırlayın.
Frontend ve entegrasyonlar için kopyala-yapıştır istek ve yanıtlarla iç API referansı yayınlayın. Versiyonlamayı koruyun (örn. /api/v1/...) ki değişiklikler mevcut istemcileri boğmasın.
Güvenlik onayın parçasıdır: biri hesabı ele geçirirse veya isteği taklit ederse tercihleri izinsiz değiştirebilir. Önce kimliği koruyun, sonra onay değiştiren her eylemi kilitleyin.
Hedef kitlenize ve risk seviyenize uyan bir yaklaşım kullanın:
Ayrıca hesap ele geçirme koruması ekleyin: giriş denemelerini hız sınırlayın, hassas değişikliklerde kullanıcıyı bilgilendirin ve tüm kanallar için kritik ayar değişikliklerinde ek doğrulama düşünün.
UI'yi güvensiz kabul edin. Backend doğrulamalıdır:
Tarayıcıya açık endpointleri CSRF koruması, sıkı CORS ve kimliklerin yatay ayrıcalık yükseltmesini önleyen açık kontrollerle sertleştirin.
Veriyi taşınırken (HTTPS) ve saklanırken şifreleyin. Tercih merkezini çalıştırmak için gereken en küçük alan setini toplayın—çoğu durumda ham tanımlayıcıları saklamamak için dahili ID'ler veya hash'li arama anahtarları kullanılabilir. Eski loglar ve inaktif hesaplar için veri saklama politikalarını ayarlayın ve uygulayın.
Denetim kaydı şarttır ama logları güvenli tutun: tam oturum tokenları, magic-link tokenları veya gereksiz kişisel verileri saklamayın. Genel abonelik formlarına karşı bot kayıtlarını ve tercih manipülasyonunu azaltmak için CAPTCHA veya throttling ekleyin.
Denetim günlükleri, bir kişinin izin verip vermediğinin makbuzudur. Şikayet, düzenleyici soruşturma veya iç incelemede ne olduğunu açıklamanın yoludur.
Her onay veya tercih güncellemesi, eklenebilir-tek yönlü bir denetim olayı üretmelidir ve şunları yakalamalıdır:
Bu ayrıntı seviyesi tam geçmişi yeniden kurmanıza izin verir—sadece son durumu değil.
Operasyonel loglar (debug, performans, hatalar) hızlı döner ve filtrelenip düşürülebilir. Denetim logları kanıt olarak ele alınmalıdır:
Denetim izi yalnızca erişilebilir ise faydalıdır. Kullanıcı ID, email, olay türü, tarih aralığı ve aktör ile aranabilir görünümler sağlayın. İncelemeler için dışa aktarma (CSV/JSON) destekleyin—ancak dışa aktarmaları filigranlı ve izlenebilir tutun.
Denetim verileri genellikle tanımlayıcılar ve hassas bağlam içerir. Katı erişim kontrolleri belirleyin:
İyi yapıldığında denetim günlükleri onay yönetimini “doğru yaptığımızı düşünüyoruz”dan “işte kanıt”a çevirir.
Onay yönetimi web uygulamanız, her aşağı akış sisteminin (email, SMS, CRM, destek araçları) müşterinin en son tercihlerini güvenilir şekilde ihlal etmemesi durumunda işe yarar. Entegrasyon, sadece “API bağlamak” değil, tercihlerin zaman içinde kaymamasını sağlamaktır.
Tercih değişikliklerini tekrar oynatılabilir olaylar gibi ele alın. Payload tutarlı olsun ki her araç anlayabilsin. Pratik minimum:
Bu yapı hem onay kanıtı oluşturur hem de entegrasyonları basitleştirir.
Kullanıcı tercihlerini güncellediğinde değişikliği hemen email/SMS sağlayıcılarına ve CRM'e gönderin. Sağlayıcıların tam taksonominizi desteklememesi halinde, dahili konularınızı onların liste/segment modeline eşleyin ve bu eşlemeyi belgeleyin.
Hangi sistemin gerçek kaynak olduğunu kararlaştırın. Genellikle onay API'niz olmalı; ESP'ler ve CRM'ler ise cache rolünde olmalı.
Operasyonel detaylar önemlidir:
Webhooklar olsa bile sistemler sapabilir (başarısız istekler, manuel düzenlemeler, kesintiler). Günlük bir reconciliaton işi çalıştırarak onay kayıtlarınızı sağlayıcı durumlarıyla karşılaştırın ve uyuşmazlıkları düzeltin; otomatik düzeltmeler için bir denetim girdisi yazın.
Onay uygulamanız gerçek müşteri taleplerini güvenli şekilde ele alabilmelidir: “Sizde neler var gösterin”, “Beni silin” ve “Bunu düzeltin.” Bu GDPR erişim/düzeltme/silinme haklarıyla (ve CCPA tarzı haklarla) uyumludur.
Kullanıcının kendisinin erişebileceği ve hesabına erişemiyorsa destek ekibine kolayca sunabileceğiniz bir dışa aktarma sağlayın.
Dışa aktarmaya şunları dahil edin:
Formatı taşınabilir tutun (CSV/JSON) ve açık bir ad verin: “Onay geçmişi dışa aktarımı”.
Silme talebi geldiğinde, yasal uyumluluk veya yeniden iletişim engelleme için sınırlı kayıtları tutmanız gerekebilir. İki yol uygulayın:
Bunu veri saklama politikalarıyla eşleyin ki kanıt sonsuza dek tutulmasın.
Destek talepleri için yönetici araçları oluşturun: kullanıcı arama, mevcut tercihleri görüntüleme ve değişiklik gönderme. Her dışa aktarma, silme veya düzenleme öncesi açık bir kimlik doğrulama adımı (email meydan okuması, mevcut oturum kontrolü veya belgelenmiş manuel doğrulama) gerektirin.
Yüksek riskli eylemler için onay iş akışı (iki kişilik inceleme veya rol tabanlı onay) kullanın. Her eylemi ve onayı denetim izine kaydedin ki “kim neyi, ne zaman ve neden değiştirdi” sorusuna cevap verebilesiniz.
Onay yönetimi uygulamasını test etmek sadece “toggle hareket ediyor mu?” değildir. Her aşağı akış eyleminin (e-postalar, SMS, dışa aktarmalar, kitle senkleri) en son kullanıcı seçimini göz önünde bulundurduğunu kanıtlamaktır, stres ve uç durumlar dahil.
En yüksek riskli kurallar için otomatik testlerle başlayın—özellikle istenmeyen iletiyi tetikleyebilecek kurallar:
Yardımcı bir desen: “verilen onay durumu X ise, sistem eylemi Y izin verilir/engellenir” şeklinde karar mantığını test edin.
Onay değişiklikleri garip zamanlarda olur: iki sekme açık, kullanıcı iki kere tıklar, webhook bir destek edit ile aynı anda gelir.
Tercih merkezi hataların en kolay göründüğü yerdir:
Onay verisi hassastır ve kimlikle sıkı bağlıdır:
Uçtan uca testler en az bir “tam yol” betiği içermeli: kayıt → onayla (gerekliyse) → tercih değiştir → gönderimlerin engellenip/izin verildiğini doğrula → onay kanıtını dışa aktar.
Bir onay uygulaması “kurup unut” değildir. İnsanlar tercihlerinin her seferinde doğru yansıtılmasına güvenir. Güvenilirlik büyük ölçüde operasyoneldir: nasıl dağıttığınız, arızaları nasıl gözlemlediğiniz ve bir şey ters gittiğinde nasıl kurtarıldığınız.
dev, staging ve production arasında net ayrım kullanın. Staging production benzeri olmalı (aynı entegrasyonlar, aynı yapılandırma), ama gerçek kişisel verileri kopyalamaktan kaçının. Gerçekçi test yükleri gerekiyorsa sentetik kullanıcılar ve anonimleştirilmiş tanımlayıcılar kullanın.
Onay geçmişi yasal bir kayıt olduğundan, veritabanı migrationlarını dikkatle planlayın. Tarihsel satırları yeniden yazan veya çarpan değişikliklerden kaçının. Tercihen ekleyici migrationlar (yeni sütun/tablolar) ve orijinal olay izini koruyan geri doldurmalar kullanın.
Bir migration göndermeden önce doğrulayın:
Şunlar için izleme ve uyarılar kurun:
Uyarıları eyleme geçirilebilir yapın: entegrasyon adı, hata kodu ve hızlı hata ayıklama için örnek istek ID'si ekleyin.
Varsayılanları ters çeviren, tercih merkezini bozan veya opt-outleri yanlış yöneten sürümler için geri alma stratejiniz olsun. Yaygın desenler: özellik bayrakları, blue/green deploylar ve yazma işlemlerini durduran hızlı “disable writes” anahtarları.
Hızlı iterasyon döngüsünde bu tür özellikler özellikle faydalıdır. Örneğin Koder.ai üzerinde React tercih merkezi ve Go + PostgreSQL onay API prototipi oluşturup, onay yakalama veya denetim günlüklerini etkileyen bir değişiklik olursa güvenli şekilde geri alabilirsiniz.
Hafif dokümantasyon: sürüm adımları, uyarı anlamları, nöbetçi kontakları ve olay listeleri. Kısa bir runbook keskin bir kesintiyi öngörülebilir bir prosedüre çevirir ve hızlı ve tutarlı hareket ettiğinizi kanıtlamanıza yardımcı olur.
İyi kurulmuş bir onay yönetimi uygulaması bile ayrıntılarda başarısız olabilir. Bu tuzaklar genellikle geç (hukuki inceleme sırasında veya bir müşteri şikayetinden sonra) ortaya çıkar, bu yüzden erken tasarım aşamasında bunlara karşı önlem almak faydalıdır.
Yaygın bir hata, aşağı akış araçların tercihleri sessizce üzerine yazmasına izin vermektir—örn. ESP bir import sonrası kullanıcıyı tekrar “subscribed” yapar veya CRM iş akışı bağlam olmadan onay alanlarını günceller.
Bunu önlemek için uygulamanızı onay ve abonelik tercihleri için gerçek kaynak olarak belirleyin ve entegrasyonları dinleyici olarak ele alın. Durum bozucu periyodik senkronlar yerine olay tabanlı güncellemeleri tercih edin. Kim hangi sistemi ve hangi yetkiyle değiştirebilir açıkça kural koyun.
“İleride lazım olabilir” diye her şeyi kaydetmek cazip gelebilir, ama IP, cihaz parmak izi veya hassas konum gibi verileri toplamak uyumluluk yükünüzü ve riski artırır.
GDPR onay kayıtlarını, ispat için gerekenlerle sınırlayın: kullanıcı kimliği, amaç, zaman damgası, politika/sürüm, kanal ve eylem. IP/cihaz verisi saklıyorsanız nedenini belgeleyin, saklama süresini sınırlayın ve erişimi kısıtlayın.
Önceden işaretli kutular, kafa karıştırıcı togglelar, birleştirilmiş amaçlar (“pazarlama + ortaklar + profiling”) veya zor bulunan opt-outlar onayı geçersiz kılabilir ve güveni zedeler.
Açık etiketler, tarafsız tasarım ve güvenli varsayılanlar kullanın. Opt-out, opt-in kadar kolay olmalı. Çift onay kullanıyorsanız doğrulama adımının aynı amaç(lar)la ve politika metniyle bağlantılı olduğundan emin olun.
Politika metni, amaç açıklamaları veya satıcı listesi değişecektir. Sistem sürümleri takip edemiyorsa hangi kullanıcının neyi kabul ettiği bilinemez.
Her onay olayıyla politika/sürüm referansı saklayın. Önemli değişikliklerde yeniden onay tetikleyin ve eski kanıtı bozmadan muhafaza edin.
İnşa etmek kontrol verir ancak sürekli bakım (denetimler, uç durumlar, satıcı değişiklikleri) gerektirir. Satın almak süreyi kısaltabilir ama özelleştirmeyi sınırlayabilir.
Seçenekleri değerlendirirken önce gereksinimleri haritalayın, sonra toplam maliyeti ve operasyonel çabayı karşılaştırın. Hızla ilerleyip kod sahipliğini kaybetmek istemiyorsanız, Koder.ai gibi platformlar React tercih merkezi, backend servisleri (Go) ve PostgreSQL şeması ile hızlıca prototip oluşturmanıza yardım eder ve hazır olduğunuzda kaynak kodunu export etmenizi sağlar.
Eğer daha hızlı bir yol isterseniz, /pricing sayfasına bakın.
İlk olarak hukuki onayı (daha sonra ispat etmeniz gereken izin) tercihlerden (konular/frekans hakkındaki seçimler) ayırın. Ardından ilk gün kapsamını tanımlayın:
Son olarak sahiplik atayın (Product/Marketing/Legal) ve ölçülebilir başarı metrikleri seçin (daha az şikayet, daha hızlı onay kanıtı sağlama).
Onay, kimin, neye, ne zaman ve nasıl onay verdiğini kanıtlamanız gereken hukuki anlamlı bir izindir.
Tercihler ise deneyimi şekillendiren (konular, frekans) kullanıcı seçimleridir; güvenilir şekilde saklanmalı ama genellikle hukuki onayla aynı şey değildir.
Tanımları ve arayüzü ayrı tutun ki bir tercih geçerli bir onay gibi yanlış ele alınmasın.
Çoğu uygulama için asgari uyumluluk yetenekleri şunları içerir:
Bunları ürün gereksinimi olarak planlayın ve yasal yorumlar için hukuki danışmanla teyit edin.
Onay için kanıtlayıcı kayıt, genellikle şu beş W'yi kapsamalıdır:
Onayı olay (event) olarak modelleyin ve tercihleri mevcut durum olarak tutun. Tipik yapı:
Ayrıca tekrarlı kayıtlar için birleştirme geçmişi ve açık geri çekme alanları (withdrawn_at, sebep) ekleyin.
Kullanıcının karar verdiği metni tam olarak saklayın:
notice_id + notice_version (veya içerik hash'i)Bu sayede metin değiştiğinde eski onaylar ispatlanabilir kalır ve yalnızca önemli değişikliklerde yeniden onay istenebilir.
Tercih merkezinin anlaşılır olması için şu desenler işe yarar:
/preferences), uygulama içi ayarlar, gömülü widgetTüm kararlar geri alınabilir olmalı ve her yerde tutarlı dil kullanılmalı.
Pratik bir temel API seti:
GET /api/preferences mevcut durumu okumak içinPUT /api/preferences durumu açıkça değiştirmek için (kısmi güncellemeden ziyade yer değiştirme)POST /api/consents/{type}/withdraw geri çekme işlemleri için (kaza ile olmaması adına ayrı endpoint)Güncellemeleri idempotent yapın ( veya ) ve kabul ettiğiniz alanları/ durum geçişlerini doğrulayın.
Tercih değişikliklerini olay olarak kabul edin ve aşağıdaki payload minimumunu sağlayın:
Onay API'nizi gerçek kaynak (source of truth) olarak belirleyin, değişiklikleri anında ESP/SMS/CRM'e gönderin ve uyumsuzlukları düzeltmek için günlük bir reconciliaton işi çalıştırın (otomatik düzeltmeler için denetim kaydı yazın).
Katmanlı bir güvenlik yaklaşımı kullanın:
Güvenlik hataları, birinin tercihleri izinsiz değiştirmesine yol açabilir; bu nedenle güvenlik onaya dahildir.
Bu alanlar onayı sonradan savunulabilir kılar.
Idempotency-Keyrequest_id