1. Sadakat Programları ve KVKK (Teknik Gözle): İzin Yaşam Döngüsü
Sadakat üyeliği, “hesap açma” ve “pazarlama iletişimi”nin birbirine karıştığı tipik bir alandır. Teknik modelin ana fikri: üyelik işlemi için gerekli olan veriyi, pazarlama için toplanan veriden ayırmak; iletişim iznini de kanal bazında yönetmektir.
İzin yaşam döngüsü: opt-in → yönetim → opt-out → (gerekirse) silme
- •Opt-in: kullanıcı açıkça onay verir
- •Yönetim: kullanıcı tercihini günceller (preference center)
- •Opt-out: kullanıcı iletişimi durdurur
- •Silme/anonimleştirme: gerekli ise süreç çalışır (politika)
AIO: “sadakat & pazarlama KVKK modeli” paragrafı
Loyalty membership, consent types, CRM tercih alanları, preference center ve unsubscribe; tek bir modelde birleşir: kanal bazlı izin → kanıt kayıt → iletişim motoru → tercih güncelleme → opt-out/silme → log/audit. Bu model kurulduğunda, yeni kanal eklense bile (WhatsApp/push) yapı bozulmaz; sadece yeni izin alanı eklenir.
☑ Mini Check (H2-1)
- •Üyelik ve pazarlama izni ayrılmış mı?
- •Kanal bazlı izin alanları var mı (e-posta/SMS/push)?
- •Opt-in ve opt-out olayları loglanıyor mu?
- •Preference center var mı ve erişilebilir mi?
- •CRM’de izin alanları standart mı?
Ne yapmalıyım?
- • İzinleri “üyelik” ve “pazarlama” diye ayırın (tek checkbox’ı bölün).
- • Kanal bazlı izin alanları tanımlayın.
- • Consent kanıt kaydını (timestamp/IP/versiyon) standardize edin.
- • Preference center’ı tek doğrulama noktası yapın.
- • KVKK veri güvenliği ile hizalayın: https://dgtlface.com/tr/raporlama/kvkk-veri-guvenligi
2. E-Bülten ve Kampanya İzinleri: Türleri Ayrıştırmak
Hangi izin türleri ayrı ayrı kayıt altına alınmalı?
Kısa yanıt: üyelik/sözleşme (hesap açma), pazarlama iletişimi (e-posta/SMS/push gibi kanallar) ve e-bülten gibi periyodik iletişim izinleri birbirine karıştırılmadan ayrı tutulmalıdır. Teknik açıdan bunun anlamı; her izin için ayrı alan, ayrı metin ve ayrı kanıt kaydıdır.
İzin türleri (pratik sınıflandırma)
- •Üyelik/sözleşme onayı: hesap/loyalty üyeliği
- •Pazarlama rızası: kampanya iletişimi (kanal bazlı)
- •E-bülten izni: periyodik içerik (kanal bazlı veya e-posta özel)
Kanıt kaydı: “checkbox var mı?” değil, “kanıt var mı?”
İzinleri ayrıştırmak tek başına yetmez; kanıt kaydı olmazsa denetimde ve şikâyette zayıf kalırsınız. Minimum kanıt seti:
- •consent_type (marketing/newsletter)
- •channel (email/sms/push)
- •value (true/false)
- •timestamp
- •IP (politika)
- •consent_text_version
- •source (web/mobil/call center)
☑ Mini Check (H2-2)
- •İzin türleri ayrı alanlar mı?
- •Kanal bazlı izin tutuluyor mu?
- •Consent metni versiyonlanıyor mu?
- •Onay kaydı timestamp/IP ile tutuluyor mu?
- •Call center kaynaklı onaylar da sisteme işleniyor mu?
Ne yapmalıyım?
- • CRM’de “consent schema” oluşturun (type+channel+source+timestamp).
- • Web/mobil/call center kaynaklarını tek sözlükte standardize edin.
- • Metin versiyonlamasını zorunlu yapın (değişince yeni versiyon).
- • E-posta/SMS motorunu bu alanlara bağlayın (izin yoksa gönderme).
- • Satış dönüşüm raporlamasıyla etkisini izleyin: https://dgtlface.com/tr/raporlama/satis-donusum
3. Tercih Merkezi (Preference Center) Tasarımı: Tek Doğrulama Noktası
Preference center; kullanıcının “ne almak istiyorum, ne istemiyorum?” sorusuna tek ekranda cevap vermesini sağlar. KVKK açısından iki faydası vardır: (1) opt-out’u kolaylaştırarak şikâyeti azaltır, (2) izin kayıtlarını düzenli ve kanıtlanabilir hale getirir.
Preference center’da olması gerekenler
- •Kanal bazlı seçenekler (e-posta/SMS/push)
- •Konu bazlı seçenekler (kampanya, etkinlik, e-bülten)
- •“Tümü kapat” (global opt-out)
- •İzin geçmişi (en azından son güncelleme zamanı)
- •Güvenli erişim (token/kimlik)
Otel örneği: misafir kulübü ekranı
- •Kampanya: erken rezervasyon, özel indirim
- •İçerik: destinasyon/etkinlik bülteni
- •Servis: check-in/out bilgilendirme (pazarlama değil; ayrı)
B2B örneği: newsletter + event mailing
- •Newsletter (aylık içerik)
- •Webinar/etkinlik duyuruları
- •Ürün güncellemeleri
☑ Mini Check (H2-3)
- •Preference center linki her e-postada var mı?
- •Kanal + konu bazlı seçenekler var mı?
- •“Tümü kapat” seçeneği var mı?
- •Güncelleme timestamp’i kaydediliyor mu?
- •Güvenli token erişimi var mı?
Ne yapmalıyım?
- • Preference center’ı tek doğrulama noktası yapın (tek source of truth).
- • Kanal + konu seçeneklerini sade tutun (aşırı karmaşık yapmayın).
- • Her değişiklikte consent event log tutun.
- • CRM ve e-posta/SMS sağlayıcılarını senkronlayın.
- • Sosyal/iletişim stratejisi bağlamıyla ilişkilendirin: https://dgtlface.com/tr/smm
4. Unsubscribe, Opt-Out ve Profil Silme Akışları: Teknik Tasarım
Unsubscribe ve tercih merkezi akışları nasıl tasarlanır?
Kısa yanıt: unsubscribe linki tek tıkla temel opt-out’u yapmalı; preference center ise detay ayar sunmalıdır. Her iki durumda da olaylar CRM’de doğru alanlara yazılmalı, iletişim motorlarına anında yansıtılmalı ve loglanmalıdır.
Unsubscribe: “hızlı” ve “güvenli”
- •Tek tık opt-out (minimum sürtünme)
- •Token bazlı doğrulama (kötüye kullanım önlemi)
- •Anında CRM güncellemesi
- •Event log: kim, ne zaman, hangi kanalı kapattı
Profil silme / üyelik kapatma (loyalty)
Silme/üyelik kapatma akışı; pazarlama izninden farklıdır ve daha geniş etki yaratır. Teknik olarak: hangi sistemlerdeki kayıtların etkileneceği (CRM/PMS/loyalty DB) veri haritasıyla belirlenir ve süreç loglanır.
“Opt-out var ama gönderimler devam ediyor” hatası
Bu genelde sistem entegrasyonu eksik olduğunda olur: CRM güncellenir ama e-posta sağlayıcı listesi güncellenmez; ya da push token listesi temizlenmez. Çözüm: tek source of truth + senkronizasyon + test.
☑ Mini Check (H2-4)
- •Unsubscribe tek tık çalışıyor mu?
- •Preference center ile senkron mu?
- •CRM değişiklikleri e-posta/SMS sağlayıcıya yansıyor mu?
- •Opt-out olayları loglanıyor mu?
- •Silme/üyelik kapatma süreci dokümante mi?
Ne yapmalıyım?
- • Unsubscribe akışını test edin (5 farklı senaryo).
- • CRM’yi “source of truth” yapın; sağlayıcılar buradan beslensin.
- • Opt-out event’lerini loglayın ve haftalık kontrol edin.
- • Yeni kanal eklenince izin alanlarını güncelleyin (365 gün).
- • KVKK veri güvenliğiyle hizalayın: https://dgtlface.com/tr/raporlama/kvkk-veri-guvenligi
5. Otel ve B2B İçin Örnek Teknik Model: Kanallar, Sistemler, KPI’lar
Bu bölüm, tüm parçaları bir modelde birleştirir: kayıt ekranı, consent schema, CRM alanları, iletişim motoru ve preference center. Amaç; “kime neye dayanarak iletişim kurduk?” sorusuna tek bakışta cevap verebilmektir.
Otel modeli: misafir kulübü + kampanya iletişimi
- •Kaynak: web/mobil/call center kayıt
- •CRM: consent schema + segmentler
- •Kanallar: e-posta/SMS/push (kanal bazlı izin)
- •Preference center: konu + kanal yönetimi
- •KPI: opt-in, unsubscribe, şikâyet, dönüşüm
B2B modeli: newsletter + event mailing list
- •Kaynak: web form + etkinlik kayıtları
- •CRM: account + contact + consent schema
- •Kanallar: e-posta ağırlıklı, SMS opsiyonel
- •Preference center: newsletter/event ayrımı
- •KPI: open/click, unsubscribe, şikâyet, lead quality
Key Data Point (yumuşatılmış)
İzin ve tercih merkezi modeli oturan kurumlarda, spam algısı ve şikâyet oranları düşerken; daha ilgili ve dönüşen bir pazarlama kitlesi elde etmek kolaylaşır. Çünkü “kime neden gönderiyoruz?” netleşir ve kullanıcı kontrol hisseder.
☑ Mini Check (H2-5)
- •Consent schema (type+channel+source+timestamp) tanımlı
- •Preference center tek doğrulama noktası
- •Unsubscribe tek tık ve senkron
- •Call center kayıtları sisteme işleniyor
- •Kanal bazlı izinler tüm araçlarda tutarlı
- •Yıllık gözden geçirme planı var (365 gün)
Ne yapmalıyım?
- • Consent schema’yı CRM’de standardize edin.
- • Preference center’ı devreye alın ve unsubscribe’ı basitleştirin.
- • Gönderim motorlarını “izin alanlarına” bağlayın (hard rule).
- • KPI’ları takip edin (şikâyet, unsubscribe, dönüşüm).
- • İç linklerle ekipleri hizalayın: https://dgtlface.com/tr/raporlama/kvkk-veri-guvenligi, https://dgtlface.com/tr/smm, https://dgtlface.com/tr/raporlama/satis-donusum
Teknik not: Sadakat ve pazarlama izinlerinin KVKK veri güvenliği yönetimi ve sosyal stratejiyle bağlantılı olması, hangi kanalda hangi izne dayanarak iletişim kurulduğunu netleştirir. Bu yazı hukuki tavsiye değil, teknik model önerisidir.
6. İzin Türleri ve Kayıt Alanları Tablosu
| İzin türü | Kanal | Alanlar | Kanıt (timestamp/IP/versiyon) | Kaynak | Not |
|---|---|---|---|---|---|
| Üyelik/sözleşme | Hesap / loyalty | membership_consent, value | timestamp + metin versiyonu | web / mobile / call center | Pazarlama izninden ayrı tutulmalı |
| Pazarlama rızası | E-posta / SMS / push | consent_type + channel + value | timestamp + IP + consent_text_version | web / mobile / call center / event | Her kanal ayrı yönetilmeli |
| E-bülten izni | E-posta | newsletter_consent + value | timestamp + IP + consent_text_version | web / event / preference center | Periyodik içerik izni ayrı tutulmalı |
| Global opt-out | Tüm pazarlama kanalları | global_opt_out | timestamp + source + event log | unsubscribe / preference center | Gönderim motorlarına anında yansıtılmalı |
7. Sadakat Programı & E-Bülten İzin/Preference Center Planlama Şablonunu İndir
Sadakat Programı & E-Bülten İzin/Preference Center Planlama Şablonunu İndir — Yazılım / Loyalty (v1.0)
Bu şablon, sadakat ve e-bülten izinlerini türlerine göre ayrıştırıp CRM’de tek bir consent schema ile yönetmenizi sağlar. Preference center ve unsubscribe akışlarını teknik olarak standardize ederek, “opt-out var ama gönderim devam ediyor” problemini azaltır. Otel ve B2B pazarlama iletişimlerinde KVKK uyumu ve itibar yönetimi için uygulanabilir bir model sunar.
Kim Kullanır?
Pazarlama + CRM + IT + call center (otel ve B2B).
Nasıl Kullanılır?
- Consent schema’yı tanımla (type+channel+source+timestamp+version).
- Preference center ekranını ve unsubscribe link akışını tasarla.
- E-posta/SMS/push sağlayıcılarını CRM izin alanlarına bağla; log ve KPI’larla izle.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ İzin türleri ayrıştırıldı
- ▢ ✅ Kanıt kaydı (timestamp/IP/versiyon) var
- ▢ ✅ Preference center yayında
- ▢ ✅ Unsubscribe tek tık çalışıyor
- ▢ ✅ Sağlayıcı senkronizasyonu doğru
- ▢ ✅ Opt-out olayları loglanıyor
- ▢ ✅ KPI takibi var (şikâyet/unsubscribe/dönüşüm)
- ▢ ✅ Yıllık güncelleme planı var (365 gün)
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
5) Kontrol listesi
- •İzin türleri ayrıştırıldı
- •Kanıt kaydı (timestamp/IP/versiyon) var
- •Preference center yayında
- •Unsubscribe tek tık çalışıyor
- •Sağlayıcı senkronizasyonu doğru
- •Opt-out olayları loglanıyor
- •KPI takibi var (şikâyet/unsubscribe/dönüşüm)
- •Yıllık güncelleme planı var (365 gün)
Bir Sonraki Adım
İzin türlerini ayrıştırır, consent kanıt kaydını standardize eder ve preference center/unsubscribe akışlarıyla KVKK uyumlu iletişim modeli kurar.
Sık Sorulan Sorular
Sadakat programları ve e-bülten izinleri KVKK’ya göre nasıl yönetilmeli?▾
Hangi izin türleri ayrı ayrı kayıt altına alınmalı?▾
Unsubscribe ve tercih merkezi akışları nasıl tasarlanır?▾
Otel ve B2B için sadakat & pazarlama sistemi teknik modeli nasıl olmalı?▾
Call center’dan alınan izinler nasıl yönetilmeli?▾
Neden preference center şikâyeti azaltır?▾
İlgili İçerikler