E-posta Kampanyaları ve Teslim Edilebilirlik İçin Web Uygulaması Nasıl Oluşturulur

Uygulamanın Yapması Gerekenler (Kapsam ve Hedefler)

Bir sağlayıcı seçmeden, veritabanınızı tasarlamadan veya bir gönderim kuyruğu inşa etmeden önce, e-posta kampanya yönetimi uygulamanız için “başarı”nın nasıl görüneceğini tanımlayın. Net bir kapsam, ürünü pazarlamacılar için faydalı ve teslim edilebilirlik açısından güvenli tutar.

Temel amaç: kampanyaları teslimiyatı bozmayacak şekilde göndermek

En azından uygulama bir ekibin e-posta kampanyaları oluşturmasına, zamanlamasına, göndermesine ve analiz etmesine izin vermeli ve yanlış gönderim davranışlarını engelleyecek korumalar uygulamalıdır (kaza ile geniş bir blast atma, opt-out'ları görmezden gelme veya sürekli olarak bounce olan adreslere tekrar gönderme gibi).

Sonucu şu şekilde düşünün: güvenilir teslimat + güvenilir raporlama + tutarlı uyumluluk.

Gönderici tiplerini netleştirin (farklı davranırlar)

Kapsamınız şunları açıkça içermeli (veya hariç bırakmalı), çünkü içerik ihtiyaçları, sıklık ve riskleri farklıdır:

• Pazarlama blastları: promosyonlar, bültenler, geniş kitlelere duyurular.
• Ürün güncellemeleri: özellik yayınları, bakım bildirimleri, topluluk mesajları.
• Transactional (işlemsel): fişler, parola sıfırlama, güvenlik uyarıları (genelde hızlı ve çok güvenilir olmalı).
• Yaşam döngüsü (lifecycle): onboarding, yeniden etkileşim, davranışa dayalı nurture dizileri.

Birden fazla tipi destekliyorsanız, erken karar verin: aynı gönderici kimliğini ve engelleme kurallarını mı paylaşacaklar yoksa ayrı konfigürasyonlar mı gerekecek.

Önemli rolleri belirleyin ve her birinin ne yapması gerektiğini tanımlayın

İzinleri basit terimlerle tanımlayın ki ekipler birbirinin işine girmesin:

• Admin: domain/gönderici yönetimi, uyumluluk ayarları, kullanıcı erişimleri ve entegrasyonlar.
• Pazarlamacı: hedef kitleleri oluşturur, içerik hazırlar, zamanlama yapar, A/B testleri yürütür.
• Analist: raporları okur, veri ihraç eder, atıf ve eğilimleri doğrular.
• Destek: “e-postam neden gelmedi?” sorusunu araştırır, şikayetleri ele alır, abonelikten çıkışları çözer.

Gerçek sonuçlara bağlanan başarı metrikleri seçin

Yalnızca gösteriş amaçlı metriklerden kaçının. Hem teslimat hem iş etkisini yansıtan küçük bir metrik seti takip edin:

• Gelen kutusu oranı / yerleşim sinyalleri (mümkün olduğunca) ve teslimat başarısı
• Şikayet oranı ve abonelikten çıkma oranı
• Bounce oranı (hard vs. soft)
• Etkileşim (açılma/tıklama; sınırlamalarla birlikte)
• Gelir veya dönüşüm atfı, uygulanabiliyorsa

Mimarinin gerçeğe uymasını sağlamak için kısıtları baştan koyun

Sınırlarınızı şimdi yazın:

• Bütçe (sağlayıcı maliyetleri, veri depolama, analizler)
• Ekip boyutu ve beceriler (24/7 hangi düzeyde işletme yapabilirsiniz?)
• Uyumluluk ihtiyaçları (abonelikten çıkma kuralları, rıza takibi, saklama)
• Gönderim hacmi ve büyüme (bugün vs. 12 ay sonra)

Bu bölüm için pratik bir çıktı, uygulamanın kim için olduğunu, hangi tür mesajlar gönderdiğini ve hangi metriklerin başarıyı tanımladığını belirten tek sayfalık bir “ürün kontratı”dır.

Temel Mimari ve İnşa mi Satın Alma Kararları

Kutu çizmeden önce ne yaptığınıza karar verin: bir kampanya yöneticisi (UI + zamanlama + raporlama) mı yoksa bir e-posta teslim sistemi (MTA düzeyinde sorumluluk) mı. Çoğu ekip, ürün deneyimini inşa edip uzman altyapıya entegre olarak başarılı olur.

İnşa et vs. entegre et (neyi dış kaynak kullanacaksınız)

Gönderim: Özel bir deliverability ekibiniz yoksa bir e-posta API/SMTP sağlayıcısı kullanın (SES, Mailgun, SendGrid, Postmark vb.). Sağlayıcılar IP itibarı, feedback loop'lar, warm-up araçları ve webhook olay akışlarını yönetir.

Link takibi ve analiz: Birçok sağlayıcı tıklama/açılma takibi sunar, fakat tutarlı raporlama için kendi yönlendirme alan adınızı ve tıklama kayıtlarınızı tutmak isteyebilirsiniz. İzlemeyi kurarsanız basit tutun: bir yönlendirme servisi artı olay alımı yeterlidir.

Şablonlar: Düzenleme iş akışını inşa edin ama olgun bir HTML e-posta editörünü entegre etmeyi düşünün (veya en azından MJML render). E-posta HTML'i affetmez; editörü dış kaynak kullanmak destek yükünü azaltır.

Temel mimari: monolit + kuyruk vs. servisler

MVP için modüler bir monolit iyi çalışır:

• Web uygulaması (admin UI + genel uç noktalar)
• Arka plan işleri için worker process
• Gönderim işleri ve webhook'lar için mesaj kuyruğu

Sadece ölçek veya organizasyon sınırları gerekirse hizmetlere böleceksiniz (ör: özel bir izleme servisi veya webhook alma servisi).

Veri depoları: “gerçek kaynağı” vs. olay akışı

Kiracılar, kullanıcılar, audience'lar, kampanyalar, şablonlar, zamanlamalar ve engelleme durumu için ilişkisel bir veritabanı ana kayıt olarak kullanın.

Gönderim ve takip olayları için bir append-only event store/log planlayın (örn. gün bazlı partitionlanmış ayrı tablo veya bir log sistemi). Amaç, yüksek hacimli olayları ana CRUD'u yavaşlatmadan almak.

Planlamanız gereken arka plan işleri

• Zamanlama (kampanya alıcılarını send görevlerine dağıtma)
• Hız kontrolü ve sağlayıcı sınırlamaları
• Backoff ile yeniden denemeler ve idempotency anahtarları
• Webhook'lardan bounce/şikayet işleme
• Günlük rolluplar (teslim edilebilirlik ve kampanya özetleri)

Çoklu kiracı (multi-tenant) kararları

Birden fazla marka/müşteri destekliyorsanız, erken tenant kararlarını tanımlayın: tenant-odaklı veri erişimi, tenant başına gönderim domainleri ve tenant başına engelleme kuralları. Tek kiracı ile başlasanız bile şemanızı tenant_id eklemek ileride yeniden yazmayı önleyecek şekilde tasarlayın.

Kilitlenmeden hızlıca inşa etmek

Hedefiniz hızlı bir kampanya yöneticisi (UI, veritabanı, arka plan işçileri ve webhook uç noktaları) göndermekse, Koder.ai gibi sohbet odaklı prototipleme platformları size yardımcı olabilir. Planlama modunda sistemi tanımlayıp React tabanlı bir web uygulaması ile Go + PostgreSQL backend üretebilir, hazır olduğunuzda kaynak kodunu dışa aktarabilirsiniz.

Bu, admin UI, segmentasyon CRUD, kuyruk destekli gönderim işleri ve webhook alma gibi “yapıştırıcı” parçaları hızlıca kurarken uzman bir e-posta sağlayıcısına güvenmeye devam etmenizi sağlar.

Kişiler, Kampanyalar ve Olaylar için Veri Modeli

Net bir veri modeli “e-posta gönderildi” ile “tam olarak ne oldu, kime ve neden” arasındaki farkı yaratır. Segmentasyon, uyumluluk ve güvenilir olay işleme destekleyen varlıklar istiyorsunuz—sizi köşeye sıkıştırmadan.

Temel varlıklar (ve nasıl ilişkilendikleri)

En azından şu tabloları/kolleksiyonları birinci sınıf olarak modelleyin:

• Users: giriş yapan kişiler.
• Workspaces: hesaplar/organizasyonlar. Çoğu nesne bir workspace'e aittir.
• Audiences: mantıksal listeler (örn. “Bülten”, “Müşteriler”).
• Contacts: bireysel alıcılar.
• Segments: bir audience içinden kontak seçen kaydedilmiş kurallar.
• Campaigns: "göndermeyi planladığımız" şey (içerik + ayarlar).
• Sends: belirli bir kampanya çalıştırması için yürütme kaydı.
• Events: olan bitenin zaman çizelgesi (teslim, bounce, abonelikten çıkma vb.).

Yaygın bir desen: Workspace → Audience → Contact, ve Campaign → Send → Event, burada Send ayrıca kullanılan audience/segment anlık görüntüsüne referans verir.

Contact alanları: kimliği stabil tutun, geçmişi açıkça saklayın

Önerilen contact alanları:

• email (normalize edilmiş + küçük harf), isteğe bağlı name
• status (örn. active, unsubscribed, bounced, complained, blocked)
• source (import, API, form adı, entegrasyon)
• consent (sadece boolean'dan daha fazlası): consent_status, consent_timestamp, consent_source
• attributes (segmentasyon için JSON/özel alanlar: plan, şehir, etiketler)
• zaman damgaları: created_at, updated_at, tercihen last_seen_at / last_engaged_at

“Temizlik” için kişileri silmekten kaçının. Bunun yerine statüyü değiştirin ve uyumluluk ile raporlama için kayıtları saklayın.

Campaign ve send alanları: içeriği çalıştırmadan ayırın

Kampanyalar için izleyin:

• subject, from_name, from_email, reply_to
• template_version (değiştirilemez anlık görüntü referansı)
• tracking_options (açma/tıklama takibi açık/kapalı, UTM varsayılanları)

Operasyonel detaylar için bir send kaydı kullanın:

• scheduled_at, started_at, completed_at
• hedef tanımı: audience id + segment id ve saklanmış “segment query” anlık görüntüsü
• sayımlar: hedeflenen alıcı sayısı, gönderilen, teslim edilen, başarısız

Olay modeli: tek tablo, birçok tip, katı denetlenebilirlik

Olayları append-only bir akış olarak tutun ve tutarlı bir biçim kullanın:

• event_type: delivered, opened, clicked, bounced, complained, unsubscribed
• yabancı anahtarlar: send_id, contact_id (isteğe bağlı message_id)
• meta: zaman damgası, IP/user-agent (uygunsa), bounce kodları, tıklanan URL
• idempotency alanları: sağlayıcı olay id'si + hash ile çoğaltmaları önleyin

Denetlenebilirlik için tasarım

Ana nesnelere (contacts, campaigns, segments) created_by, updated_by ekleyin ve kimin neyi ne zaman değiştirdiğini, önce/sonra değerlerini alan küçük bir değişiklik günlüğü tablosu düşünün. Bu, destek, uyumluluk talepleri ve deliverability araştırmalarını çok daha kolay hale getirir.

Audience Yönetimi, Segmentasyon ve Rıza

Audience yönetimi, bir e-posta kampanya uygulamasının ya güven kazanmasını sağlar ya da sorun yaratır. Kontaktları uzun ömürlü kayıtlar olarak görün ve ekleme/güncelleme/gönderim izinleri için net kurallar belirleyin.

Listelerinizi kirletmeyen importlar

CSV import kullanıcı için basit hissettirmeli ama arka planda sıkı olmalı.

Gerekli alanları doğrulayın (en azından email), büyük/küçük harf/boşluk normalizasyonu yapın ve bariz geçersiz adresleri erken reddedin. Genellikle normalize edilmiş email'e göre çoğaltma önleme uygulayın ve çatışma durumunda ne olacağını belirleyin: yalnızca boş alanları güncelle, her zaman üzerine yaz veya “import sırasında sor” seçenekleri.

Alan eşleştirme önemlidir; gerçek dünya tabloları dağınıktır. Kullanıcılara sütunları bilinen alanlara eşleme ve gerektiğinde özel alan oluşturma izni verin.

Segmentasyon: kopyalar değil kurallar

Segmentasyon, otomatik güncellenen kaydedilmiş kurallar olarak daha iyi çalışır. Aşağıdaki filtreleri destekleyin:

• Nitelikler (lokasyon, plan, kayıt kaynağı)
• Etkileşim (son 30 gün içinde açtı, X kampanyasını tıkladı)
• Etiketler (VIP, webinar-kaydolan)
• Özel filtreler (herhangi bir özel alan + operatörler)

Segmentleri anlaşılır tutun: bir önizleme sayısı gösterin ve bir örnek kontakt için “neden dahil” açılabilir detayı sunun.

Her kontakt için rıza ve tercihlerin saklanması

Rızayı birinci sınıf veri olarak saklayın: durum (opted-in, opted-out), zaman damgası, kaynak (form, import, API) ve ilgiliyse hangi liste veya amaç için geçerli olduğu.

Tercih merkezi insanlara belirli kategorilerden çıkma, diğerlerine aboneliği sürdürme imkanı vermeli ve her değişiklik denetlenebilir olmalıdır. Tercih iş akışınıza atıfta /blog/compliance-unsubscribe gibi görünen metinleri koruyun.

Hataları azaltan uluslararasılaştırma detayları

İsimler ve adresler tek tip değildir. Unicode destekleyin, esnek isim alanları, ülkeye duyarlı adres formatları ve “yerel saatle 09:00” gönderimler için kontakt düzeyinde zaman dilimi desteği sağlayın.

Her gönderimden önce uygunluk kontrolleri

Alıcıları kuyruklamadan önce yalnızca uygun kontakları filtreleyin: abonelikten çıkmamış, engelleme listesinde değil ve o mesaj tipi için geçerli rızası var. Kuralı UI'da görünür yaparak kullanıcıların neden bazı kontakların gönderiye dahil olmadığını anlamasını sağlayın.

E-posta İçerik Oluşturma: Şablonlar, Önizlemeler ve İçerik QA

Mükemmel bir gönderim hattı olsa bile içerik okunması zor, tutarsız veya gerekli öğelerden yoksun ise performans kötü olur. Oluşturmayı bir ürün özelliği olarak ele alın: “iyi e-posta”yı varsayılan yapmalı.

Ölçeklenen şablonlar (bloklar + versiyonlama)

Başlangıçta yeniden kullanılabilir bloklardan oluşan bir şablon sistemi kullanın—header, hero, metin, buton, ürün ızgarası, footer—böylece kampanyalar ekipler arasında tutarlı olur.

Şablonlar ve bloklar için versiyonlama ekleyin. Editörler şunları yapabilmeli:

• eskiyi ezmeden yeni bir versiyon oluşturmak (“Holiday footer v3”)
• bir bloğun nerede kullanıldığını görmek (“12 şablonda kullanılmış”)
• bir değişiklik rendering'i bozduğunda geri almak

Hem şablon hem kampanya taslakları için test gönderimleri sağlayın: önce bir şablonu kendinize gönderin, sonra kampanya taslağını küçük dahili bir listeye gönderin.

Editör seçenekleri: kullanıcılarınıza göre seçin

Çoğu uygulama birden fazla düzenleme modu destekler:

• Temel HTML güç kullanıcılar ve ithal tasarımlar için
• Sürükle-bırak hızlı ve sınırlayıcı yapılar için
• Markdown-to-HTML içerik ağırlıklı bültenler için (hızlı yazma, tahmin edilebilir çıktı)

Hangi modu seçerseniz seçin, “kaynak”ı (HTML/Markdown/JSON blokları) ve render edilmiş HTML'i ayrı saklayın ki hata düzeltmelerinden sonra yeniden render edebilin.

Önizlemeler ve düz metin

Yaygın breakpoints (masaüstü/mobil) ve ana istemci uyumsuzlukları için önizlemeler sağlayın. Basit araçlar işe yarar: viewport anahtarları, koyu mod simülasyonu, “tablo kenarlarını göster” seçeneği.

Her zaman bir düz metin (plain-text) versiyon oluşturun ve düzenlemeye izin verin. Bu erişilebilirlik için yardımcıdır, bazı spam filtreleriyle sürtünmeyi azaltır ve metin tercih eden kullanıcılar için okunurluğu artırır.

Link yeniden yazma + içerik QA

Tıklama izliyorsanız, linkleri okunabilir tutarak yeniden yazın (örn. UTM parametrelerini koruyun ve hedefi hover'da gösterin). Uygulama UI'sındaki dahili linkleri göreli tutun (örn. /blog/template-guide gibi görsel metinleri koruyun).

Göndermeyi etkinleştirmeden önce kontroller çalıştırın:

• spam tetikleyen ifadeler ve aşırı noktalama/çok büyük harfler
• kırık linkler ve önemli resimlerde alt metin eksikliği
• eksik abonelikten çıkma adresi ve şirket footer bilgileri
• kampanya ayarları ile tutarsız "from" isim/adresi

Denetleyiciyi eyleme geçirilebilir yapın: hatalı bloğu vurgulayın, düzeltme önerin ve sorunları “zorunlu düzeltme” veya “uyarı” olarak sınıflandırın.

Gönderim Hattı: Kuyruklar, Zamanlama ve Hız Kontrolü

Bir gönderim hattı uygulamanızın “trafik sistemi”dir: postaların nasıl gönderileceğine, ne zaman salınacağına ve itibar zedelemeden ne kadar hızlı artacağına karar verir.

Gönderim yöntemini seçin

Çoğu uygulama ölçek ve geri bildirim webhook'ları sağladığı için bir sağlayıcı API ile başlar (SendGrid, Mailgun, SES, Postmark). SMTP relay'ler mevcut sistemlerle uyumluluk istendiğinde işe yarar. Kendi MTA'nız maksimum kontrol sağlar ama operasyonel iş yükü (IP warm-up, bounce işlemleri, kötüye kullanım yönetimi, izleme) ekler.

Veri modeliniz göndericiyi yapılandırılabilir bir “teslim kanalı” olarak ele almalı ki yöntemleri değiştirmek kampanyaları yeniden yazmayı gerektirmesin.

Kuyruk-öncelikli mimari (güvenlik raylarıyla)

Web isteğinden doğrudan göndermeyin. Bunun yerine alıcı düzeyinde işleri (veya küçük partileri) kuyruğa atın ve worker'ların bunları teslim etmesine izin verin.

Ana mekanikler:

• Hız sınırlama: global limitler artı gönderici, kampanya ve domain başına limitler.
• Backoff ve yeniden deneme: geçici hatalar (4xx, zaman aşımı) exponential backoff ile yeniden denenmeli; kalıcı hatalar (5xx, hard bounce) durdurulmalı.
• Idempotency anahtarları: bir iş yeniden oynatıldığında çoğaltmayı önleyin. Örnek anahtar: {campaign_id}:{recipient_id}:{variant_id}.

Gelen kutulara saygılı zamanlama ve throttling

Zamanlama zaman dilimlerini desteklemeli (kullanıcının tercih ettiği bölgeyi saklayın; yürütme için UTC'ye çevirin). Teslim edilebilirlik açısından, alıcı domainine göre (örn. gmail.com, yahoo.com) throttle uygulayın. Böylece “sıcak” domainleri yavaşlatıp tüm kampanyayı bloklamamış olursunuz.

Pratik bir yaklaşım domain kovalarını (domain buckets) bağımsız token-bucket limitleriyle yönetmek ve ertelemeler görüldüğünde dinamik ayarlamaktır.

İtibar korumak için ayrı akışlar

Transactional ve marketing gönderimleri ayrı akışlarda tutun (idealde ayrı alt domainler ve/veya IP havuzları). Böylece yüksek hacimli bir kampanya parola sıfırlamalarını veya sipariş onaylarını geciktirmez.

Alıcı başına sonuçları kaydedin

Alıcı için değiştirilemez bir olay izi saklayın: queued → sent → delivered/soft bounce/hard bounce/complaint/unsubscribe. Bu, destek sorgularını, uyumluluk denetimlerini ve gelecekte doğru engelleme davranışını sağlar.

Teslim Edilebilirlik Temelleri: SPF, DKIM, DMARC ve Domainler

E-posta teslim edilebilirliği, posta kutusu sağlayıcılarına sizin o domain adına gönderme yetkiniz olduğunu kanıtlamakla başlar. Üç temel kontrol SPF, DKIM ve DMARC'tır—ve domainlerin nasıl yapılandırıldığı önemlidir.

SPF (kim gönderebilir)

SPF, domaininiz adına hangi sunucuların mail gönderebileceğini listeleyen bir DNS kaydıdır. Pratik çıkarım: uygulamanız (veya ESP'niz) yourbrand.com üzerinden gönderiyorsa SPF, kullandığınız sağlayıcıyı içermelidir.

UI'nız bir SPF değeri (veya bir “include” snippet'i) üretmeli ve kullanıcıları birden fazla SPF kaydı oluşturmamaları konusunda açıkça uyarmalıdır.

DKIM (mesaj bütünlüğü)

DKIM her e-postaya kriptografik bir imza ekler. Açık anahtar DNS'te tutulur; sağlayıcı mesajın değiştirilmediğini ve domainle ilişkilendirildiğini doğrular.

Uygulamada her gönderim domaini için “DKIM oluştur” seçeneği sunun ve DNS'e kopyala-yapıştır yapılacak tam host/değer bilgilerini gösterin.

DMARC (politikalar + raporlama)

DMARC SPF/DKIM başarısız olduğunda inbox'ların ne yapacağını ve raporların nereye gönderileceğini belirtir. Önce izleme politikası (p=none) ile başlayın, raporları toplayın ve her şey stabil olunca quarantine veya reject seviyesine geçin.

DMARC'ta hizalama (alignment) önemlidir: görünür “From” adresindeki domain SPF ve/veya DKIM ile hizalanmalıdır.

Domain hizalaması, return-path ve izleme alanları

Kullanıcıları From domain'i kimlik doğrulanmış domainle hizalı tutmaya teşvik edin. Sağlayıcınız custom return-path (bounce domain) yapılandırma izni veriyorsa, kullanıcıları aynı organizasyon domainine yönlendirin (örn. mail.yourbrand.com) ki güven sorunları azalsın.

Tıklama/açılma takibi için özel bir tracking domain (CNAME örn. track.yourbrand.com) destekleyin. TLS (HTTPS) zorunlu kılın ve sertifika durumunu otomatik kontrol edin ki kırık linkler veya tarayıcı uyarıları olmasın.

Otomatik doğrulama + uyarılar

Bir “Verify DNS” butonu oluşturun ve propagation'u kontrol edip şu durumları işaretleyin:

• Eksik SPF/DKIM/DMARC
• Birden fazla SPF kaydı
• DMARC var fakat hizalama yok
• Tracking domain yanlış yapılandırılmış veya TLS yok

Hızlı sorun giderme için kullanıcıya bir kurulum kontrol listesi metni gösterin (ör. /blog/domain-authentication-checklist).

Bounce, Şikayet ve Abonelikten Çıkma İşleme

Bounce, şikayet ve abonelikten çıkmaları birinci sınıf özellik olarak ele almazsanız, bunlar sessizce teslim edilebilirliğinizi tüketir. Amaç basit: sağlayıcınızdan gelen her olayı alın, tek bir iç şemaya çevirin ve engelleme kurallarını otomatik ve hızlı uygulayın.

Webhook'larla olay alma (ve kopya bekleme)

Çoğu sağlayıcı delivered, bounced, complained, unsubscribed gibi webhook'lar gönderir. Webhook uç noktanız:

• Idempotent olmalı: aynı olay birkaç kez, sıraya girmeden veya yeniden denenmiş şekilde gelebilir.
• Hızlı olmalı: sağlayıcıyı çabuk acknowledge edin, sonra asenkron işlem yapın.

Yaygın yaklaşım benzersiz bir sağlayıcı olay ID'si (veya stabil alanların hash'i) saklamak ve tekrarı görmezden gelmektir. Ham payload'u denetim ve hata ayıklama için kaydedin.

Sağlayıcı olaylarını tek bir şemaya normalleştirin

Farklı sağlayıcılar aynı şeyi farklı isimlendirir. İç olay modeline normalleştirin, örneğin:

• event_type: delivered | bounce | complaint | unsubscribe
• occurred_at
• provider, provider_message_id, provider_event_id
• contact_id (veya email), campaign_id, send_id
• bounce_type: soft | hard (uygunsa)
• reason / smtp_code / category

Böylece sağlayıcı değişse bile raporlama ve engelleme mantığı tutarlı kalır.

Engelleme kuralları: soft vs. hard bounce

Hard bounce (geçersiz adres, olmayan domain) durumunu anında engelleme olarak ele alın. Soft bounce (posta kutusu dolu, geçici hata) için eşik belirleyin—ör. "7 gün içinde 3 soft bounce"—sonra soğutma veya kalıcı engelleme politikasına göre hareket edin.

Engellemeyi e-posta kimliği düzeyinde tutun (email + domain), sadece kampanya bazlı değil; böylece kötü bir adres tekrar denenmez.

Şikayetler ve abonelikten çıkmalar: anında engelle

Feedback loop'lardan gelen şikayetler güçlü negatif sinyaldir. Anında engelleme uygulayın ve o adrese tüm gelecekteki gönderimleri durdurun.

Abonelikten çıkmalar da söz verdiğiniz kapsam için global olarak anında uygulanmalıdır. Destek için "neden artık mail almıyorum?" sorusuna cevap verebilmek adına abonelikten çıkma meta verisini (kaynak, zaman damgası, kampanya) saklayın.

Engelleme davranışını kullanıcı tarafındaki ayarlar sayfasıyla ilişkilendirmek isteyebilirsiniz (ör. /settings/suppression) ki ekipler arka planda ne olduğunu anlasın.

Açılma, Tıklama ve Dönüşüm Takibi (Uyarılarla)

Takip size kampanyaları karşılaştırma ve sorunları tespit etme imkanı verir, ama rakamları fazla yorumlamak kolaydır. Karar vermeyi destekleyen ve belirsizliği dürüstçe gösteren analizler oluşturun.

Açılma takibi: yardımcı ama giderek bulanık

Açılma takibi tipik olarak küçük bir "pixel" ile yapılır. İstemci bu görüntüyü yüklediğinde bir açılma kaydı alırsınız.

Sınırlılıklar:

• Birçok istemci görüntüleri varsayılan olarak engeller; gerçek bir okuma açılma olarak görünmeyebilir.
• Apple Mail Privacy Protection gibi gizlilik özellikleri görüntüleri önceden getirerek gerçek okumayı göstermeyen açılmalara neden olabilir.

Pratik yaklaşım: açılmaları yön gösterici sinyal olarak kullanın (örn. “bu konu satırı daha iyi performans gösterdi”), dikkat kanıtı olarak değil.

Tıklama takibi: yönlendirmeler, UTM'ler ve bot filtresi

Tıklama takibi daha eyleme dönüştürülebilir. Yaygın desen: linkleri izleme URL'siyle değiştirin (yönlendirme servisi), sonra son hedefe yönlendirin.

En iyi uygulamalar:

• UTM parametreleri ekleyin (source, medium, campaign) ki analytics araçları trafiği atfedebilsin
• Temel bot filtrelemesi ekleyin (bilinen tarayıcı ajanları, teslimattan hemen sonra tıklama, çerez olmadan tekrar eden vuruşlar)

Tamamen yakalayamasanız da bariz şişirmeyi azaltabilirsiniz.

Link istatistikleri ve etkileşim zaman çizelgeleri saklayın

Analitiği iki düzeyde modelleyin:

• Link başına istatistikler (unique clicks, total clicks, ilk/son tıklama zamanları) kampanya raporlaması için
• Alıcı başına etkileşim zaman çizelgesi (delivered → açıldı? → tıklandı → dönüştü) segmentasyon ve takipler için

UI'da net olun: "unique" en iyi çabayı ifade eder ve "open rate" gerçek okuma oranı değildir.

Dönüşümler ve metriklerin kanıtlayamadıkları

Dönüşümleri (satın alma, kayıt) izliyorsanız UTM parametreleri veya hafif bir sunucu tarafı uç nokta ile bağlayın. Buna rağmen atıf kusursuz değildir (çoklu cihazlar, gecikmeli aksiyonlar, reklam engelleyiciler).

İhracatlar ve API erişimi

Takımların BI araçlarında kullanması için CSV ihracatları ve olaylar/özet istatistikler için bir API sağlayın. Uç noktaları basit tutun (kampanya, tarih aralığı, alıcı bazlı) ve rate limitleri dokümante edin (metin olarak /docs/api).

İzleme, Raporlama ve Teslim Edilebilirlik Uyarıları

Teslim edilebilirliği iyileştiremezsiniz eğer olan biteni göremiyorsanız. İzleme iki soruyu hızla yanıtlamalı: postalar mailbox sağlayıcıları tarafından kabul ediliyor mu ve alıcılar etkileşime giriyor mu. Pazarlamacı olmayan birinin sorunları dakikalar içinde fark edebileceği raporlar oluşturun.

Doğruyu söyleyen panolar

Basit bir “teslim edilebilirlik sağlığı” paneli ile başlayın, şu öğeleri birleştirin:

• Teslimat oranı (kabul edilen vs. bounce)
• Şikayet oranı (spam raporları)
• Abonelikten çıkma oranı
• Etkileşim eğilimleri (mevcutsa açılma/tıklama)
• Hafta bazında en çok öne çıkan kampanyalar ve büyük oynayanlar

Gösteriş amaçlı grafiklerden kaçının. Yüksek açılma ama artan şikayetler olan bir kampanya ileride bloklanma riski taşır.

Gelen kutusu yerleşim sinyalleri (iddialı olmadan)

Gerçek gelen kutusu yerleşimi doğrudan ölçmesi zordur. Güçlü korelasyon gösteren vekil metrikler kullanın:

• Hard bounce sıçramaları (kötü liste kalitesi veya ani bloklama)
• Şikayet sıçramaları (içerik veya hedefleme sorunları)
• Ertelenmeler/throttling (sağlayıcı sizi yavaşlatıyor)

Sağlayıcı feedback loop veya postmaster araçları entegre ediyorsanız, bunları “sinyal” olarak değerlendirin, mutlak gerçek olarak değil.

Doğru kişiyi uyandıran uyarılar

Uyarılar eyleme geçirilebilir olmalı ve eşiklere/denge pencerelerine bağlı olmalı:

• Kampanya veya gönderici domain için bounce sıçraması
• Şikayet sıçraması (hacme bağlı olarak %0.1 üzerinde alarm)
• Kimlik doğrulama hataları (SPF/DKIM/DMARC uyumsuzluğu)
• Webhook kesintisi veya olay birikmesi (izleme boşlukları olayları gizleyebilir)

Uyarıları e-posta + Slack'e gönderin ve doğrudan filtrelenmiş bir görünüme bağlayın (ör. /reports?domain=gmail.com&window=24h).

Domain bazlı performans görünümleri

Metrikleri alıcı domain (gmail.com, outlook.com, yahoo.com) bazında kırın. Throttling veya bloklama genellikle tek bir sağlayıcıyla başlar. Alan başına gönderim hızı, ertelemeler, bounce ve şikayetleri gösterin ki nerede yavaşlatmanız veya durdurmanız gerektiğini belirleyin.

Kurumsal hafıza için olay günlüğü

Zaman damgaları, kapsam (kampanya/domain), semptomlar, şüphelenilen neden, alınan aksiyonlar ve sonuç ile bir olay günlüğü ekleyin. Zamanla bu playbook'unuz olur ve “bir kez düzeltmiştik” bilgisi tekrarlanabilir hale gelir.

Güvenlik, Gizlilik ve Uyumluluk Koruması

Güvenlik ve uyumluluk bir e-posta kampanya yönetimi uygulaması için eklenti değil—veriyi nasıl sakladığınızı, nasıl gönderdiğinizi ve alıcı bilgileri ile ne yapabileceğinizi belirler.

Hesap güvenliği (kim ne yapabilir)

Başlangıç için açık roller ve izinler oluşturun: örn. Owner, Admin, Campaign Creator, Viewer ve sınırlı API-only rolü. Riskli eylemleri (kontakt ihracı, gönderim domaini değiştirme, engelleme listesi düzenleme) açık ve denetlenebilir yapın.

İnteraktif kullanıcılar için 2FA ekleyin; API erişimini kapsamlı anahtarlar, rotasyon, sonlanma ve anahtar başına izinlerle yönetin. Kurumsal müşteriler için IP allowlist özelliğini (hem admin UI hem API için) dahil edin.

Veri güvenliği (sakladığınız veriyi koruma)

Duyarlı verileri dinamik/isteğe bağlı olarak şifreleyin (özellikle kontakt tanımlayıcıları, rıza meta verileri ve özel alanlar). Gizli bilgileri veritabanında tutmamaya çalışın: SMTP kimlik bilgileri, webhook imzalama sırları ve şifreleme anahtarları için bir secrets manager kullanın.

En az ayrıcalık (least privilege) prensibini uygulayın: gönderim servisi tam kontakt ihracını okuyamamalı; raporlama işleri fatura yazma yetkisine sahip olmamalı. Hassas uç noktalara erişimi ve ihracatları loglayın ki müşteriler şüpheli etkinliği araştırabilsin.

Gizlilik ve uyumluluk (uymanız gerekenler)

Abonelikten çıkma işlemi anında ve güvenilir olmalı. Engelleme kayıtlarını (abonelikten çıkma, bounce, şikayet) kalıcı bir suppression listesinde tutun, yanlışlıkla yeniden posta göndermemek için yeterince uzun saklayın ve kanıt saklayın: zaman damgası, kaynak (link tıklama, webhook olayı, admin eylemi) ve kampanya.

Rızayı kanıtlayacak şekilde izleyin: kullanıcı neye onay verdi, ne zaman ve nasıl (form, import, API). Kimlik doğrulama temellerine dair daha fazla için metinleri saklayın (örn. /blog/email-authentication-basics).

Güvenli gönderim varsayılanları (yeni göndericileri koru)

Yeni hesaplar için “güvenli mod” uygulayın: daha düşük günlük sınırlar, zorunlu warm-up programları ve büyük blast'lardan önce uyarılar. Bunları açık plan limitleri ve yükseltme yollarıyla eşleştirin (/pricing).

MVP'den Üretime: Test, Lansman ve Sonraki Özellikler

İlk sürümünüz tam döngüyü kanıtlamalı: bir audience oluşturun, gerçek bir kampanya gönderin ve sonrasında olan biteni düzgünce işleyin. Olay akışına (bounce, şikayet, abonelikten çıkma) güvenemiyorsanız, üretim sistemine sahip değilsiniz demektir.

MVP kontrol listesi ("minimum tamam" döngüsü)

Gerçek kullanım destekleyecek sıkı bir özellik seti hedefleyin:

• Kontak importu (CSV + temel doğrulama), rıza durumu saklama ve bir engelleme listesi uygulama
• Bir şablon oluşturma, önizleme ve kendinize test gönderimi yapma
• Kuyruk + hız kontrolü ile kampanya zamanlama ve gönderme
• Sağlayıcı webhook'larını almak (bounce, şikayet, unsubscribe) ve kontak durumunu güncelleme
• Basit raporlar: gönderildi, teslim edildi, bounce, şikayet, abonelikten çıkma (kampanya bazında)

Ağır sürprizleri önleyen test planı

Segmentasyon ve webhook işleme kritik kabul edilmelidir.

• Birim testleri: segmentasyon kuralları, rıza mantığı, engelleme öncelikleri, abonelikten çıkma işleme
• Entegrasyon testleri: webhook imzaları, idempotentlik (çoğaltılmış olaylar), sağlayıcı olaylarını iç şemaya eşleme
• Yük testleri: kuyruk throughput'u, eşzamanlılık limitleri, veritabanı hotspot'ları, sağlayıcı yavaşlaması sırasında yeniden deneme davranışı

Operasyonel plan (sağlıklı tutan şeyler)

Prod stabilitesi büyük ölçüde operasyoneldir:

• Korelasyon ID'leri ile yapılandırılmış loglama (campaign_id, message_id)
• Metrikler ve uyarılar (kuyruk derinliği, gönderim hızları, hata oranları, webhook gecikmesi)
• Birincil veritabanı için yedekler ve geri yükleme tatbikatları
• Yeniden deneme politikaları ve zehirli mesajlar için dead-letter kuyrukları
• Çalışma kitapları: “webhook backlog”, “gönderim durdu”, “yüksek şikayet oranı”, “ani bounce sıçraması”

Yayılma yaklaşımı ve güvenli ölçeklendirme

İç kampanyalarla başlayın, sonra küçük bir pilot kohortu ile ramp up yapın. İlk etapta muhafazakar hız limitleri uygulayın ve sadece bounce/şikayet oranları hedeflerde kalırsa genişletin. Küresel bir “kill switch” ile tüm gönderimleri durdurma imkanı bulundurun.

Lansman sonrası planlanacak (ama çıkışı engellemeyecek) özellikler

Çekirdek döngü güvenilir olduktan sonra A/B testleri, otomasyon yolculukları, tercih merkezi ve çoklu dil şablonları ekleyin. Yeni göndericilerin hatalarını azaltmak için hafif bir onboarding rehberi sağlamak da faydalıdır (/blog/deliverability-basics).

Hızla yineleme yapıyorsanız, snapshot ve rollback gibi özellikler segmentasyon, engelleme mantığı veya webhook işleme değişikliklerinde riski azaltır. Örneğin, Koder.ai snapshot desteği ile ekiplerin regresyon sonrası hızlıca geri dönmesini sağlar—MVP'den üretime ölçeklenirken kullanışlıdır.