Bildirimler için opt-in kanıtı: kanal bazında onay modelleme

Onay ve opt-in kanıtı gerçekte ne anlama gelir

Onay, bir kişinin belirli bir kanalda belirli türde bir mesaj almayı açıkça kabul ettiği anlamına gelir. Bu ayrım önemlidir çünkü e-posta, SMS ve push bildirimleri kullanıcılar, operatörler, uygulama platformları veya gizlilik yasaları tarafından aynı şekilde ele alınmaz. Bir kişi e-posta ile gönderilen bir kargo güncellemesini memnuniyetle karşılayabilir, ama pazarlama amaçlı bir SMS ile şaşkına dönebilir.

Kanit ise daha sonra birisi "Neden bana mesaj gönderdiniz?" diye sorduğunda gösterebileceğiniz şeydir. Proof-of-opt-in bir formun ekran görüntüsü veya "kullanıcı abone oldu" gibi belirsiz bir not değildir. Kim onay verdi, neye onay verdi, ne zaman oldu ve nasıl yakalandığı izlenebilen bir kayıttır.

Kayıtlar zayıfsa, sorunlar hızla ortaya çıkar. Destek beklenmeyen mesajları açıklayamaz, geri ödemeler artar ve insanlar güvenini kaybeder. Bir şikayet büyürse, mesajı gönderdiğiniz anda onayın var olduğunu göstermekte zorlanabilirsiniz; bu genellikle en çok önem taşıyan detailyarından biridir.

Onay bir popup'tan daha fazlasıdır

Birçok ekip UI istemine (onay kutuları, anahtarlar, OS izin diyalogları) odaklanır ve bunun arkasındaki denetim izini unuturlar. Gerçek hedef güven ve izlenebilirliktir. Net bir onay modeli, personel değişse, sistemler taşınsa veya kullanıcılar fikrini değiştirse bile doğru şeyi her seferinde yapmayı kolaylaştırır.

Pratik bir onay kaydı şu temel soruları yanıtlamalıdır:

• Kim onayladı (kullanıcı tanımlayıcısı ve ilgili ise hedef: e-posta adresi veya telefon numarası)
• Ne onayladılar (kanal ve mesaj türü veya amaç)
• Ne zaman oldu (UTC zaman damgası veya zaman dilimiyle birlikte zaman damgası)
• Nasıl oldu (isteğin nerede gösterildiği ve kullanıcının ne gördüğü, versiyon ve dil dahil)
• Uyuşmazlıkları çözmeye yardımcı olacak bağlam (örneğin uygulama/cihaz bilgisi veya IP adresi)

Neden bu güven oluşturur

Kullanıcılar, rahatsız edici gelen anlara göre sizi yargılar: gece geç saat bir push, beklenmedik bir SMS ücreti, kaydolduğunu hatırlamadığı bir e-posta. Tam olarak hangi onay olayını gösterebiliyorsanız ve bunu sade bir dille açıklayabiliyorsanız, destek taleplerini sakince ve tutarlı şekilde çözebilirsiniz.

AppMaster gibi bir platformla inşa ediyorsanız, onayı ilk günden itibaren birincil veri olarak ele almak yardımcı olur: yapısal, aranabilir ve kazara üzerine yazılması zor.

Bildirim türleri ve neden kurallar farklıdır

Tüm bildirimler aynı şekilde değerlendirilmez çünkü amaçları farklıdır ve insanlara farklı yerlerde ulaşırlar. Bildirimler için güvenilir bir opt-in kanıtı istiyorsanız, mesajları niyet ve kanal olarak etiketleyerek başlayın.

İşlemsel vs pazarlama (düz anlamıyla)

İşlemsel mesajlar, kullanıcının yaptığı bir işlem veya hizmeti kullanmak için bilmesi gereken bir durum tarafından tetiklenir. Şifre sıfırlama, makbuzlar, güvenlik uyarıları veya hesap durumu değişiklikleri buna örnektir. İnsanlar bunları bekler ve bunların engellenmesi ürün deneyimini bozabilir.

Pazarlama mesajları tanıtıcıdır. Bültenler, ürün teklifleri, kazan-kazan kampanyaları veya "yeni neler var" duyuruları gibi. Bunlar isteğe bağlı olmalı ve kullanıcılar "hayır" diyebilmeli; çekirdek özelliklere erişim kaybetmemelidir.

Pratik kural: mesaj, kullanıcının talep ettiği şeyi teslim etmek için gerekli ise muhtemelen işlemseldir. Eğer amaç kullanım veya satışları artırmaksa, pazarlamadır.

Kanallar: e-posta, SMS, push ve uygulama içi

Kanallar farklı davranır; bu yüzden onay ve kanıt genellikle bir global onay kutusu yerine kanal bazında takip edilir.

E-posta hem işlemsel hem pazarlama için sıkça kullanılır. Birçok ürün işlemsel e-postayı temel hizmetin parçası sayarken, pazarlama e-postası genellikle net bir "evet" ve durdurma yöntemi gerektirir.

SMS daha müdahaleci hissedilir, bazı kurulumlarda maliyeti olabilir ve operatör/sağlayıcı kurallarına tabidir. SMS onayını kendi başına bir karar olarak ele alın.

Push bildirimleri cihaz OS izni ve kullanıcı ayarlarıyla kontrol edilir. Uygulamanızın bir cihaz token'ı olabilir, ama kullanıcı her zaman push'u kapatabilir. Bu da ne gönderebileceğinizi etkiler.

Uygulama içi mesajlar ürün içinde görünür. Genellikle telekom kurallarından çok UX kurallarına uyarlar, ama kullanıcılar özellikle promosyon afişleri için kontrol bekler.

Gereksinimler ülkeye ve sağlayıcı politikasına göre değiştiği için birçok ekip basit bir temel tercih eder: her kanal için pazarlama onayı açık ve net olsun; tartışmaya açık her şey iyi belgelenmiş olsun.

"Yumuşak opt-in" (soft opt-in) yaygın bir gri alandır. Pratikte, genellikle var olan bir ilişki (örneğin müşteri olmak) üzerinden mesajlaşmayı ifade eder; kullanıcı özel bir pazarlama kutusu işaretlememiş olabilir. Yine de dokümantasyon önemlidir: ilişkinin ne olduğu, ne gönderildiği ve kişinin nasıl vazgeçebileceği kaydedilmelidir.

AppMaster ile bunu kuruyorsanız, modeli basit tutun: kullanıcı pazarlama e-postasına opt-in olabilir ama SMS'ten opt-out edebilir; yine de gerekli işlemsel uyarıları almaya devam eder. Bu ayrım hem uyumluluğu hem güveni kolaylaştırır.

Kanal bazlı opt-in'leri nasıl modellemeli (saklanması gereken veriler)

Bildirimler için güvenilir opt-in kanıtı istiyorsanız, veri modeliniz spesifik olmalı. "Kullanıcı onayladı" yeterli değildir. Onay kanal (e-posta, SMS, push) ve amaç (pazarlama, ürün güncellemeleri, güvenlik uyarıları) tarafından belirlenir.

Pratik yaklaşım: onayı kendi kaydı olarak ele alın; kullanıcı profiline gömülü bir onay kutusu değil. Bir kullanıcının birçok onay kaydı olabilir ve her kayıt tek bir kanal ve tek bir amaca eşlenmelidir.

Sorun çıkarmayan minimum alanlar

Consent kaydını şu şekilde başlatın: kullanıcı + kanal + amaç + durum. Daha sonra kaydı sonradan anlaşılır kılacak detayları ekleyin.

Çoğu ürünün en az şu alanlara ihtiyacı vardır:

• user_id
• channel (email, sms, push - sabit bir liste tutun)
• purpose (marketing, product_updates, account_security - sabit bir liste tutun)
• status (opted_in, opted_out, pending, unknown)
• opted_in_at / opted_out_at

Sonradan tahminde bulunmamak için nerede gerçekleştiğini ve en son ne zaman teyit edildiğini de yakalayın:

• source (signup_form, settings_page, checkout, support_action)
• last_confirmed_at (politika değişiklikleri sonrası faydalı)

Onay metni snapshot'ları (kullanıcının gördüğünü kanıtlamak için)

Onay sadece bir tıklama değildir; belirli sözcüklere yapılan onayı da içerir. Gösterilen metnin tam halini kanıtlamak için bir consent_text_version (veya kısa bir snapshot_id) saklayın.

Snapshot'u basit tutun: gösterilen mesaj, dil/locale ve aktif olduğu zaman. Kopya değişirse, eskisini düzenlemek yerine yeni bir versiyon oluşturun.

Kompakt bir örnek şöyle görünür:

{
  \"user_id\": \"u_123\",\n  \"channel\": \"sms\",\n  \"purpose\": \"marketing\",\n  \"status\": \"opted_in\",\n  \"opted_in_at\": \"2026-01-25T10:15:00Z\",\n  \"source\": \"checkout\",\n  \"consent_text_version\": \"sms_mkt_v3\",\n  \"last_confirmed_at\": \"2026-01-25T10:15:00Z\"\n}

AppMaster ile kurarsanız, bu Consent ve ConsentTextSnapshot modelleri Data Designer'a temizce eşlenir ve Business Process Editor'da basit mantıkla yönetilir. Önemli olan tutarlılıktır: her kanal ve amaç aynı yapıyı takip etsin ki raporlama ve denetimler telaşa dönüşmesin.

Kanıt sayılan şeyler ve nelerin yakalanacağı

"Kanıt" daha sonra iki soruyu yanıtlamanızı sağlayan her şeydir: kullanıcının neye onay verdiği ve nasıl onay verdiği. Bildirimler için opt-in kanıtı, spesifik, zaman damgalı ve gerçek bir kullanıcı eylemine bağlı kayıtlar olmalıdır (sadece "consent = true" gibi tek bir değer değil).

Eylemden başlayın. Eğer onay bir onay kutusuyla, anahtarla veya çift opt-in linkiyle verildiyse, etkileşimi ve kullanıcının gördüğü kesin metni (veya bir versiyon ID'sini) saklayın. Ekran görüntüleri ölçeklendirmez; bir onay kopyası/versiyon etiketi daha kullanışlıdır.

Olayı yeniden üretilebilir kılmak için yeterli detayı yakalayın:

• eylem türü (kutuyu işaretledi, anahtarı açtı, onay linkine tıkladı)
• UTC zaman damgası
• kanal ve amaç
• onay metni versiyonu veya politika/versiyon kimliği
• sayfa veya ekran adı ve dil

Teknik bağlamı dikkatli ekleyin. Tartışmaları çözmede yardımcı olabilir, ancak gizlilik riskini de artırır. Web için IP ve user agent gerektiğinde faydalı olabilir. Mobilde, zaten kimlik modelinizin bir parçası olan cihaz ID'sini düşünün; ama "şans olsun" diye ekstra tanımlayıcılar toplamayın.

Sağlayıcılar üzerinden gönderim yapıyorsanız, onların kimliklerini de saklayın. Sağlayıcı mesaj ID'leri (e-posta, SMS, push) bir şikayet veya teslim edilebilirlik sorununun incelenmesinde belirli bir gönderinin hangi onay kaydıyla ilişkilendirildiğini göstermenize yardımcı olur.

Son olarak, ne saklamayacağınıza karar verin. İyi kanıt her şeyi toplamak demek değildir. Şablonlar yeterliyse mesaj içeriğinin tamamını saklamaktan kaçının ve alakasız cihaz verilerini depolamayın. AppMaster'da bu alanları hassas kabul edin: tutarlı tutun ve yalnızca yetkili rollerin denetim ayrıntılarına erişmesini sağlayın.

Adım adım: onay ve kanıt akışı kurma

Önce ne için izin isteyeceğinize karar verin. Onay sadece "bildirimler evet/hayır" değildir. İnsanlar genellikle makbuzları ister ama promosyonları istemez. Bildirim amaçlarınızı sade dilde yazın, sonra her amacı kullanacağınız kanallara eşleyin.

Onay ekranlarını karışık bir istem yerine kanal bazında tasarlayın. Her ekran ne gönderileceğini ve daha sonra nasıl değiştirileceğini söylemeli. Dil açık olsun: “Sipariş makbuzları e-posta ile” "İşlemsel mesajlar" demekten daha nettir.

Pratik bir akış şöyle görünür:

• amaçları tanımlayın ve hangilerinin opt-in gerektirdiğini belirleyin (örneğin pazarlama vs makbuzlar)
• uygun anda sorun (makbuzlar için checkout, ipuçları için onboarding sonrası)
• güvenli varsayılanlar seçin (pazarlama kapalı; hizmeti teslim etmek için gerekenler açık olsun)
• kullanıcı bir toggle değiştirdiğinde hemen bir olay kaydı yazın (kim, ne değişti, ne zaman ve nerede)
• gönderim yoluna onay kontrolleri koyun, böylece admin araçları veya otomatik işler atlanmasın

O olay kaydı ileride onayı kanıtlayan şeydir. Banka makbuzu gibi ele alın: eklenebilir (append-only) ve sonradan düzenlenmesi zor. AppMaster'da ekipler genellikle hızlı kontroller için bir current-state tablosu tutar ve her güncelleme Business Process aracılığıyla bir eşlik eden denetim girdisi oluşturur.

Yayına almadan önce opt-out ve uç durumları test edin. Web, mobil veya hesap silme akışı üzerinden ayarlar değiştiğinde aynı sonucu aldığınızdan emin olun. Özellikle dikkat edin:

• başka bir cihazda oturum açıyken bir cihazda opt-out yapılması
• telefon numarası veya e-posta değişikliği
• uygulamanın yeniden kurulması (push token'ları değişir)
• misafir checkout vs giriş yapmış kullanıcılar
• silinmiş veya devre dışı bırakılmış hesaplar (gönderim yapılmamalı, ancak gerekli kanıt saklanmalı)

Opt-out, değişiklikler ve hesap yaşam döngüsünü yönetme

Opt-in işin sadece yarısıdır. İnsanlar fikrini değiştirir, cihaz değiştirir, bir e-postaya erişimini kaybedebilir veya destekten ayarları düzeltmesini isteyebilir. Opt-out zor yapılırsa kullanıcılar bunu hemen fark eder ve sizin "kanıtınız" şüpheli görünmeye başlar.

Opt-out'u opt-in kadar kolay yapın. İnsanların beklediği yerlerde koyun: bildirim ayarları, pazarlama e-postalarının altbilgisi ve gerekliyse SMS için açık STOP talimatları. "Destekle iletişime geçin" gibi adımların arkasına saklamayın.

Onay doğrulama mesajı gönderiyorsanız, gerektiyse veya yasal olarak gerekiyorsa minimal tutun. Tek bir “Abonelikten çıktınız” e-postası yardımcı olabilir. Tekrarlayan "Emin misiniz?" takipleri spam gibi hissedilebilir. SMS için STOP sonrası tek bir onay genellikle beklenir. Push için sessiz bir uygulama içi durum değişikliği genelde yeterlidir.

Hesap yaşam döngüsü çoğu onay sisteminin bozulduğu yerdir. Bu durumlar için erken plan yapın:

• Oturum kapatılmış kullanıcılar: Bir kişi oturum açık değilken e-postadan çıkış yaparsa, bunu sadece oturum verisine değil e-posta adresine karşı kaydedin.
• Silinmiş hesaplar: Silme taleplerine uyun, ama aynı zamanda yanlışlıkla yeniden eklenmemeleri için izin verildiğinde minimal bir iletme-yapma (do-not-contact) kaydı tutun.
• Birleştirilmiş hesaplar: Onayın otomatik aktarılacağını varsaymayın; çelişkileri en gizliliğe duyarlı tercih ile çözün.
• Cihaz değişiklikleri: Yeni telefon yeni bir push token üretir; token teknik veri olarak görülsün ve kullanıcının push onayı yönetim kuralı olarak ele alınsın.

Saklama kurallarını yazılı hale getirin ve tutarlı uygulayın. Şikayetleri, denetimleri veya chargeback'leri cevaplayabilecek kadar uzun süre onay günlüklerini saklayın, ama ihtiyaçtan fazla kişisel veri tutmayın. Eğer kullanıcı verisini silmeniz gerekirse, hangi verinin anonimleştirilebileceğine (örneğin e-postayı hash'leme) karar verin ki olay geçmişi yine işe yarasın.

Destek kaynaklı değişikliklerin net bir iç süreci olsun. Kimlerin onayı düzenleyebileceğini sınırlayın, bir sebep kodu (ör. "kullanıcı sohbet yoluyla istedi") isteyin ve değişikliği yapanın kim olduğunu ve zamanı kayıt altına alın. AppMaster'da ekipler genellikle küçük bir PostgreSQL tablosunda consent event'leri ve destek eylemleri için ikinci bir tablo tutar; ardından Business Process ile değişiklik uygulatıp her seferinde bir denetim girdisi yazarlar.

Güveni (ve denetim izini) bozan yaygın hatalar

Birçok ekip bir onay anahtarı ekler, sonra kestirme yollarla bunu sessizce bozar. Sonuç tahmin edilebilir: kullanıcılar kandırılmış hisseder ve onay kanıtı gerektiğinde kayıtlar dayanmaz.

Yaygın tuzaklardan biri onayı tek bir global evet/hayır olarak ele almaktır. E-posta, SMS ve push farklı beklentilere ve yasalara sahip olabilir. marketing_ok=true gibi tek bir bayrak, kullanıcının onaylamadığı bir kanala mesaj göndermeyi çok kolay hale getirir.

Bir diğer güven katili, belirsiz seçim tasarımıdır. Ön işaretli kutular, küçük uyarılar veya birden fazla amacı birleştiren kontroller ("Ürün güncellemeleri ve teklifler") kullanıcıları kafa karışıklığına iter. Veritabanınız "onaylandı" diyebilir ama destek kutunuz farklı bir hikâye anlatır.

Güveni ve kanıtı en çok bozan hatalar şunlardır:

• sadece en son onay durumunu kaydetmek ve geçmişi silmek
• kullanıcının kabul ettiği tam onay metnini (ve versiyonunu) saklamamak
• "kullanıcı opt-in oldu" kaydı atıp kanal, zaman damgası ve kaynağı saklamamak
• kampanyaların onay kontrollerini atlamasına izin vermek
• yanlış ayarı düzeltmek için veritabanını düzenlemek, böylece ne olduğunun kaydını silmek

Tipik bir başarısızlık şöyle görünür: kullanıcı onboarding sırasında push'u açar, sonra ayarlarda pazarlama SMS'ini kapatır ve sonrasında istenmeyen bir SMS hakkında şikayet eder. Eğer sistem eski kaydı üzerine yazdıysa, kullanıcının ne gördüğünü veya ne zaman opt-out yaptığını gösteremezsiniz. Daha kötüsü, SMS onayının hiç var olmadığını kanıtlayamazsınız.

Onayı finansal geçmiş gibi ele alın: hızlı kontroller için güncel durumu ayrı tutun, ama geçmişi kaybetmeyin. Yardımcı guardrail'lar basittir: kanal ve amaç bazlı ayrım, onay metni ID'si ve locale saklama, her gönderim yolunun aynı onay kontrolü adımından geçirilmesi ve yeni olaylar yazılması (eski kayıtların düzenlenmemesi).

AppMaster'da inşa ediyorsanız, consent event'lerini kendi tablosu olarak modelleyin ve ortak Business Process içinde kontrolü zorunlu kılın ki otomatik bildirimler ve operatör aksiyonları aynı kurallara uysun.

Yayına almadan önce hızlı kontroller

Gerçek bildirimleri göndermeden önce onay izini ödemeler gibi test edin. Kim, hangi kanala ve hangi ifadeyle opt-in oldu diyemiyorsanız, güveni tahmine bırakıyorsunuz demektir.

Her kanal (e-posta, SMS, push) için kullanıcının opt-in olduğu anı ve nerede olduğunu gösterebildiğinizden emin olun. "Neresi" diye bahsederken belli bir ekran veya form adı ve bunun signup, ayarlar, checkout veya destek üzerinden olup olmadığını belirtin.

Ayrıca onay metnini tekrar oynatabildiğinizden emin olun. Sadece "marketing=true" saklamak yetmez. Gösterilen metin versiyonunu (veya şablon ID'sini) ve kullanıcının gördüğü dili saklayın. Metin daha sonra değişse bile, önceki onaylar için eski ifade gerektiğinde gösterilebilmelidir.

Çoğu sorunu yakalayan kısa bir ön-yayın kontrol listesi:

• Her opt-in için zaman damgası, kaynak (web, iOS, Android) ve UI yeri gösterilebiliyor.
• Gösterilen kesin onay metni ve dil geri getirilebiliyor.
• En son opt-out her şeyi geçersiz kılar ve her yerde (kuyruk işler dahil) yansır.
• Destek, "neden bana bunu gönderdiniz?" sorusunu tek bir kullanıcı görünümünden 2 dakikadan kısa sürede yanıtlayabiliyor.
• Onay günlükleri düzenlenemez ve erişim yetkili rollere sınırlıdır.

Bir tatbikat yapın: bir ekip arkadaşı webde opt-in olsun, mobilde opt-out olsun, sonra destekten açıklama isteyin. Cevap ham tablolar veya birden fazla araç arasında kazma gerektiriyorsa, kullanıcılar da aynı sürtüşmeyi hisseder.

AppMaster üzerinde kuruyorsanız, onay kanıtını kendi veri modeli ve süreciniz olarak ele alın, yan etki değil. Bir consent log varlığı ve destek/denetçiler için basit bir iç görünüm büyük fayda sağlar; özellikle de kimlerin erişebileceğini kısıtlarsanız.

Örnek senaryo: bir kullanıcı, üç kanal, değişen tercihleri

Mina sitenizde bir hesap oluşturur ve siparişleri takip etmek ister. Kayıt sırasında e-posta, SMS ve push için ayrı tercihler görür. Push bildirimlerini (uygulamayı yüklediğinde) sipariş güncellemeleri için kabul eder, pazarlama e-postasını kapalı bırakır ve SMS'i işaretlemez.

Bir hafta sonra mobil uygulamayı yükler ve giriş yapar. Uygulama OS seviyesinde push izni ister ve Mina kabul eder. Burada birçok ekip karışıklık yaşar: OS izni işinizin özel amaçları için verilmiş iş onayının aynısı değildir. Hem OS iznini hem de iş onayını ayrı ayrı kaydetmek istersiniz ki denetimde opt-in kanıtınız net kalsın.

Mina'nın hikâyesi zamanla nasıl evrilir ve destek hangi temiz zaman çizelgesini görmeli:

Zaman çizelgesi ve kanıt snapshot'ları

1. Web kayıt (Gün 1)

Webde ne seçtiğini (veya seçmediğini) ve isteğin bağlamını kaydedersiniz.

2. Mobil kurulum ve push izni (Gün 8)

Cihaz token'ını ve OS izin sonucunu Mina'nın hesabına bağlı olarak, uygulamada gösterilen prompt versiyonu ile birlikte saklarsınız.

3. Telefon numarası değişikliği (Gün 20)

Teslimat koordinasyonu için yeni telefon numarası ekler. Bunu yeni bir SMS hedefi olarak ele alın ve taze bir SMS opt-in isteyin. Eski numaradan onay otomatik olarak taşınmasın.

4. SMS iptali (Gün 35)

STOP yanıtı verir veya ayarlarda SMS'i kapatır. Opt-out olayını kaydedin ve derhal gönderimi durdurun.

Kanıt kaydının nasıl görünebileceğine dair örnek

Aşağıda Mina "SMS'e asla izin vermedim" dediğinde desteğin okuyabileceği basitleştirilmiş bir denetim izi örneği var:

[
  {
    \"ts\": \"2026-01-02T10:14:22Z\",\n    \"user_id\": \"u_123\",\n    \"channel\": \"email\",\n    \"purpose\": \"marketing\",\n    \"action\": \"no_opt_in\",\n    \"capture\": {\"surface\": \"web_signup\", \"form_version\": \"signup_v3\"},\n    \"evidence\": {\"ip\": \"203.0.113.10\", \"user_agent\": \"Chrome\"}\n  },\n  {
    \"ts\": \"2026-01-09T08:03:11Z\",\n    \"user_id\": \"u_123\",\n    \"channel\": \"push\",\n    \"purpose\": \"order_updates\",\n    \"action\": \"opt_in\",\n    \"capture\": {\"surface\": \"ios_app\", \"prompt_version\": \"push_prompt_v2\"},\n    \"evidence\": {\"device_id\": \"d_77\", \"os_permission\": \"granted\", \"push_token\": \"...\"}\n  },\n  {
    \"ts\": \"2026-01-21T16:40:05Z\",\n    \"user_id\": \"u_123\",\n    \"channel\": \"sms\",\n    \"purpose\": \"delivery_updates\",\n    \"action\": \"opt_in\",\n    \"capture\": {\"surface\": \"account_settings\", \"form_version\": \"sms_optin_v1\"},\n    \"evidence\": {\"phone\": \"+15551234567\", \"verification\": \"code_confirmed\"}\n  },\n  {
    \"ts\": \"2026-02-05T09:12:44Z\",\n    \"user_id\": \"u_123\",\n    \"channel\": \"sms\",\n    \"purpose\": \"delivery_updates\",\n    \"action\": \"opt_out\",\n    \"capture\": {\"surface\": \"sms_reply\", \"keyword\": \"STOP\"},\n    \"evidence\": {\"phone\": \"+15551234567\"}\n  }
]

AppMaster gibi bir platformda inşa ederseniz, consent event'lerini Data Designer'da modelleyip her toggle, doğrulama kodu onayı veya uygulamanın izin sonucu almasıyla Business Process akışları üzerinden eklemeniz mümkün. Önemli olan destek ekibinin tarihler, yüzeyler ve kesin seçimlerle cevap verebilmesidir; tahminlerle değil.

Sonraki adımlar: ürüne iş akışı olarak entegre etme

Onayı bir onay kutusu değil bir ürün özelliği olarak ele alın. Bildirimler için opt-in kanıtını korumanın en kolay yolu, bunu mesaj gönderme, destek biletleri ve denetimler için kullandığınız aynı iş akışına yerleştirmektir.

Basitçe güncel tercih ile tarihli kanıt ayıran minimal bir modelle başlayın. Çoğu ürün için işe yarayan temel şema:

• Users (kimlik ve hesap durumu)
• ConsentPreferences (kanal başına güncel açık/kapalı; amaç bazında gerekirse)
• ConsentEvents (her değişiklik, zaman damgaları ve bağlamla)
• MessageSends (her gönderim denemesi, gönderim anındaki onay kararı dahil)

Kim görebilir ona karar verin. Onay kanıtı IP adresi, user agent, telefon numarası veya diğer hassas detayları içerebilir; bu yüzden role-dayalı erişim ile kilitleyin. Destek genellikle bir onay zaman çizelgesi görünümüne ihtiyaç duyar, ama yalnızca küçük bir grup bunu dışa aktarabilmelidir.

Hızlıca "Neden bu kullanıcıya ulaştık?" sorusunu yanıtlayacak küçük bir iç görünüm inşa edin. Kullanıcıya göre arama, kanala göre filtreleme ve gerektiğinde zaman çizelgesini dışa aktarmayı kolaylaştırın.

Sonra onay kontrollerini otomatik hale getirin. Her gönderim aynı mantığı çağırmalı: en son ConsentPreferences'i kontrol et, o kanal ve amaç için geçerli bir ConsentEvent olup olmadığını doğrula ve MessageSends içinde kararı (engellense bile) kaydet.

AppMaster kullanıyorsanız, pratik bir desen consent tablolarını Data Designer'da tutmak ve gönderimden önce ortak bir Business Process içinde onay kapısını çalıştırmaktır. Böylece kurallar web uygulamaları, backend işler ve native mobil uygulamalar arasında tutarlı kalır.

Basit bir kural uzun vadede işe yarar: birisi onay kontrolünden geçmeden bildirim gönderebiliyorsa, bir gün hata çıkacaktır.