02 Oca 2026·7 dk
Sadece davetli beta lansmanı: minimal bir davet sistemi kurun
Basit bir bekleme listesi, davet kodları ve oran limitleriyle davetli beta lansmanınızı planlayın; spamı durdurun ve onboarding hızını güvenli şekilde ayarlayın.
Basit bir bekleme listesi, davet kodları ve oran limitleriyle davetli beta lansmanınızı planlayın; spamı durdurun ve onboarding hızını güvenli şekilde ayarlayın.
Sadece davetli bir beta basit bir vaat demektir: insanlar ürününüzü deneyebilir, ama yalnızca hazır olduğunuzda. Ekipler bunu genellikle iki şeyi korumak için kullanır: sisteminiz ve zamanınız — ki ilk bozulan şeyler genellikle bunlardır.
İlk baskı spamdir. Kıtlık olduğunda (sınırlı kontenjan, erken erişim, ayrıcalıklar) botlar ve kötü niyetliler ortaya çıkar. Binlerce hesap yaratmaya, kod tahmin etmeye veya formlarınızı doldurmaya çalışırlar. Bazen kasıtlı bile değildir: tek bir viral paylaşım “kazara spam” yaratabilir; gerçek insanlar aynı anda kayıt akışına yüklenir.
İkinci baskı onboarding kapasitesidir. Sunucularınız kayıtları kaldırsa bile, ekibiniz kaldırmayabilir. Erken kullanıcılar sıfırlamalar, fatura düzeltmeleri, hata raporları ve temel rehberlik ister. Destekleyebileceğinizden fazla kişiyi kabul ederseniz, yavaş yanıtlar, hayal kırıklığı ve gerçek sorunları gizleyen gürültülü geri bildirimler alırsınız.
“Minimal” dikkatsiz demek değildir. Daha az hareketli parça ama net kurallar demektir; böylece açıklaması, testi ve değişikliği kolay olur.
Minimal bir davet sistemi genellikle sadece dört kontrol gerektirir:
Günde rahatça 50 kullanıcı alabiliyorsanız, sisteminiz bu tempoyu zorlamalı. Kontrol olmadan bir bot gece boyunca 5.000 bekleme girişi gönderebilir ve gerçek insanları gömebilir. Minimal bir sistem ile günlük davetleri sınırlar, yeniden denemeleri yavaşlatır ve onboarding’i ekibinizin gerçekten idare edebileceği seviyede tutarsınız.
Sadece davetli bir beta ayrıcalıklı hissettirmekle ilgili değildir. Spamı ve destek yükünü kontrol etmekle ilgilidir. Bunu, her parça bir soruya yanıt verdiği sürece küçük bir parça setiyle yapabilirsiniz: kim bekliyor, kim içeri girebilir ve kim davet etti.
Bir identifier (genellikle e-posta, bazen telefon) toplayan bir bekleme listesi ile başlayın. Formu kısa tutun, sonra insanların geçmesi kolay ama botların sevmediği bir sürtünme ekleyin. E-posta doğrulaması iyi çalışır. Kaydedin: identifier, kayıt zamanı, bir IP karması ve basit bir durum (waiting, approved, invited, blocked veya benzeri).
Sonra onay. İlk başta manuel onay yeterlidir. Sonrasında basit otomatik kurallar ekleyebilirsiniz: “ilk 200 doğrulanmış kaydı onayla” veya “günde 20 onayla” gibi. Önemli olan hızlandırma değil, tempoyu korumaktır.
Davet kodları onaydan sonra gelir. Sadece onaylı kullanıcılar için bir kod üretin ve bunu kullanmak için oturum açma (veya doğrulanmış e-posta) şartı koyun. Kodu kim oluşturdu ve kim kullandı takip edin; böylece her zaman net bir davet zincirine sahip olursunuz.
Yönetici görünümünüz gösterişli olmak zorunda değil. Bir tablo yeterlidir; hızlıca cevap verebildiğiniz sürece:
Son olarak, oran limitleri ve birkaç kötüye kullanım kontrolü ekleyin. IP ve identifier başına kayıt denemelerini sınırlayın, başarısız doğrulamaları yavaşlatın ve bariz geçici desenleri engelleyin. Birisi limitleri tetiklerse, sakin bir mesaj gösterin ve onların sıradaki yerini koruyun — sert bir başarısızlık vermeyin.
Eğer Koder.ai yeni bir özelliği betaya açsaydı, basit bir kurulum şöyle olabilir: her sabah 50 kullanıcı onayla, onaylanan her kullanıcıya iki davet kodu ver ve saatlik redemeleri sabit bir oranda sınırlayın. Böylece bir kod büyük bir grup sohbetine sızsa bile büyüme öngörülebilir kalır.
Bekleme listesi sıkıcı olduğunda en iyi çalışır. Ne kadar çok alan isterseniz, o kadar çok sahte giriş, yazım hatası ve destek işi davet edersiniz. Davetli bir beta için tek gerekli alan (e-posta) genellikle yeterlidir. Bağlam istiyorsanız bir not kutusu ekleyin ama bunun hızlandırmayacağını açıkça belirtin.
Sadece e-posta ayrıca veriyi temiz tutmayı kolaylaştırır. Her e-posta için bir satır zorunlu kılabilirsiniz ve sadece önemli soruyu cevaplayabilirsiniz: kim bekliyor ve kim zaten içeride?
Tek adımlı kayıt (form gönderildiğinde “listedesiniz” mesajı) akıcı hissettirir ama kötüye kullanımı kolaydır. Çift onay (gönder, sonra e-posta ile onayla) spamı ciddi şekilde azaltır çünkü botlar ve atıl adresler genellikle ikinci adımı tamamlamaz.
Düşüşten endişe ediyorsanız, çift onayı koruyun ama beklentileri ayarlayın: “Onayla yerinizi tutmak için.” Yine de insanları sonradan onaylayabilirsiniz, ama yalnızca onaylanmış e-postalar davet almalıdır.
Bekleme listesini küçük bir durum makinesi gibi ele alın. Dört durum çoğu durumu karmaşıklık olmadan kapsar: pending (kayıt oldu, incelenmedi), approved (davet almaya hak kazandı), invited (kod gönderildi), joined (hesap oluşturuldu).
Bu, desteği basitleştirir. Birisi “Hiç giremedim” derse, pending’de mi sıkışmış, hiç onaylamamış mı yoksa zaten joined mi olduğunu görebilirsiniz.
Çoğaltmaları ve atıl girişleri azaltmak için birkaç temel kural uygulayın: e-postaları normalleştirin (küçük harf, boşluk kırpma), benzersizliği zorunlu kılın, pending’den öteye gitmeden önce onayı şart koşun, ilk görüldüğü ve son deneme zaman damgalarını saklayın ve birisi tekrar denese bile tek bir kayıt saklayın.
Eğer Koder.ai sohbet tabanlı uygulama oluşturucu için bir beta açsaydı, çift onay artı net durumlar ekibin sahte kayıtlar ve “davetim nerede?” e-postalarıyla boğulmadan haftada birkaç yüz kullanıcı davet etmesine izin verirdi.
Davet kodları valftir. Her yeni kullanıcı izlenebilir, öngörülebilir ve bir şey ters giderse durdurması kolay olmalıdır.
İlk olarak, onaylı kişiye kaç davet verileceğine karar verin. Çoğu beta için kullanıcı başına 1–3 davet yeterlidir. Daha hızlı büyüme istiyorsanız, yalnızca destek ve altyapının bir hafta boyunca sakin kaldığını gördükten sonra davetleri artırın.
Tek kullanımlık kodlar en güvenli varsayılandır. Suistimali görünür kılar ve rakamlarınızı doğru tutar. Çok kullanımlık kodlar kontrollü kanallar için (bir ortak topluluk veya dahili ekip) işe yarayabilir, ama günlük redemeleri de sınırlayın.
Davet kodlarını spam kaynağı olmaktan uzak tutmak için birkaç kural:
E-posta bağlı davetler dolandırıcılığı azaltır ama sürtünme ekler. İyi bir orta yol, açık redemtion artı doğrulama (e-posta veya telefon) ve güçlü oran limitleri uygulamaktır.
Ayrıca kaynağı izleyin. Kod oluşturulduğunda davet eden, zaman damgası ve herhangi bir kampanya etiketi kaydedin. Bir kaynaktan birdenbire çok sayıda başarısız kayıt gelirse, o yolu durdurup diğerlerini yavaşlatmadan inceleyebilirsiniz.
Oran limitleme emniyet kemerinizdir. Kafa karıştırıcı olmasına gerek yok. Otomatik suistimali pahalı hale getirmeli, normal kullanıcıların hareketini kesmemelidir.
Birden fazla sinyale göre limit koyun. Sadece IP gürültülüdür (paylaşılan Wi‑Fi, mobil ağlar). Sadece e‑posta kolayca döndürülebilir. Küçük bir kombinasyon kullanın: IP + e‑posta + cihaz ipucu (çerez, local storage ID veya hafif bir parmak izi).
Farklı eylemler için farklı limitler kullanın, çünkü saldırganlar farklı yollarla vurur. Bekleme listesi kaydı botlar için ucuzdur, bu yüzden IP ve cihaz başına sıkı tutun. Davet kodu oluşturma ayrıcalıklıdır, bu yüzden kullanıcı başına günde çok az izin verin. Kod reddi de limitlenmeli; kod tahmini ve toplu paylaşımı durdurmak için. Giriş daha toleranslı olabilir, ama tekrarlanan başarısızlıklar yine de yavaşlatma tetiklemeli.
Başarısız denemeler için ayrı bir soğutma olmalı. Birisi bir dakikada 10 kötü kod veya parola gönderirse, IP + cihaz bazlı kısa bir kilit (örneğin 5–15 dakika) ekleyin. Bu kaba kuvveti keser ama normal kullanıcıları cezalandırmaz.
Bir limit tetiklendiğinde, sonraki adımı net ve sakin tutun:
Bir bot bir IP’den 500 davet kodu denese, redemtion limiti onu hızlıca durdurmalıdır. Aynı ağdaki gerçek kullanıcılar yine bekleme listesine katılabilir ve daha sonra tekrar deneyebilir; destek bileti açmak zorunda kalmamalılar.
Ne olduğunu göremiyorsanız, desteğiniz dolana kadar suistimali fark etmezsiniz. Temel izleme, tempoyu sabit tutmanızı ve tahmin yerine gerçek verilere dayanmanızı sağlar.
Derin analizlere gerek yok. Güvenilir bir iz yoluna ihtiyacınız var.
Ana olaylarda tutarlı bir alan seti kaydedin (bekleme kaydı, davet oluşturma, davet reddi, giriş): zaman damgası ve olay tipi; kullanıcı kimliği (veya e‑posta karması), davet kodu ID’si ve yönlendiren (varsa); IP (kısaltılmış saklayın), ülke ve user agent; sonuç (başarılı/ başarısız) ve hatanın nedeni; oran-limit kararı ve hangi kuralın tetiklendiği.
Sonra erken yakalayan birkaç uyarı eşiği koyun. Bekleme kaydı sıçramaları, dakika başına davet redemtionları, tekrarlanan başarısızlıklar (kötü kod, süresi geçmiş kod) ve tek bir IP veya cihaz parmak izinden çok sayıda deneme gibi durumları izleyin. Bu desenler genellikle her şey kötüleşmeden saatler önce ortaya çıkar.
Gösterge tablonuz basit olabilir: gönderilen davetler, kullanılan davetler ve “kod girildi” ile “hesap oluşturuldu” arasındaki düşüş. Düşüş artarsa, bot baskısı altında olabilirsiniz ya da akışınız bozuluyor olabilir.
Sızıntılar için geri alma planınız olsun: tek bir kodu devre dışı bırakın, sonra tüm partiyi kapatın, sonra yeni hesaplar için redemtionları duraklatın. Platformunuz Koder.ai gibiyse, anlık görüntüler ve geri alma temiz bir duruma dönmenize yardımcı olur.
İlk olarak güvenle hangi sayıda kullanıcıyı idare edebileceğinize karar verin. Destek, altyapı veya kendi odağınızı bozmadan alabileceğiniz günlük veya haftalık yeni kullanıcı sayısını seçin. Bu sayı yayın valfiniz olur.
Her parçanın tek bir amacı olacak şekilde bu sırayla inşa edin, böylece erken karmaşıklık eklemezsiniz:
Akış uçtan uca çalıştıktan sonra iç test yapın. Normal davranışı deneyin (tek bir kayıt) ve kötüye kullanımı (çok sayıda kayıt, tekrar eden kod tahminleri, hızlı yeniden gönderme istekleri). Gerçek insanları davet etmeden kuralları sıkılaştırın.
Platformunuz günde 20 yeni proje rahatça kabul ediyorsa, bekleme listesi daha hızlı büyüse bile günde sadece 20 davet üretin. Koder.ai üzerinde bu tür bir tempo özellikle faydalıdır çünkü yeni kullanıcılar genellikle ilk bir oluşturma, kaynak kodu dışa aktarma veya dağıtım konusunda biraz yardıma ihtiyaç duyar.
Çoğu spam ve aşırı yük problemi kendi yaptığınız hatalardan kaynaklanır. Küçük bir davet sistemi iyi çalışır, ama birkaç “yardımcı” tercih saldırıya açık veya trafik patladığında çalışması zor bir yapı oluşturur.
Yaygın hatalardan biri kamuya çok fazla ayrıntı veren hata mesajlarıdır. API’nız “kod var ama süresi dolmuş” veya “e-posta zaten listede” diyorsa, saldırganlara ne deneyeceklerini öğretiyorsunuz. Genel halka yönelik mesajları basit tutun ve ayrıntıları özel olarak kaydedin.
Bir diğer sık sorun süresiz davetler veya asla ölmeyen kodlar vermektir. Uzun ömürlü, yeniden kullanılabilir kodlar grup sohbetlerine kopyalanır ve bot listelerine kazınır. Kodları kısa ömürlü tutun, bir kişiye bağlayın ve her kodun oluşturabileceği hesap sayısını sınırlayın.
Benzer bir boşluk ise durdurma düğmesi olmamasıdır. Bir kodu iptal edemiyorsanız, bir partiyi süresiz geçersiz kılamıyorsanız veya bir kullanıcı için davetleri devre dışı bırakamıyorsanız, oyunu kovalayan fare olursunuz. Temel yönetici eylemlerini erken oluşturun, basit bir dahili sayfa bile yeterlidir.
Ayrıca bekleme formunuza dikkat edin. Çok fazla şey sorduğunuzda gerçek insanlar vazgeçer ama botlar yine doldurur. Önce minimumu toplayın, sonra zenginleştirin.
Yük patlamaları genellikle sessiz birkaç hatadan gelir: bekleme kaydı ve kod doğrulama gibi “düşük riskli” uç noktalarda oran limitleri atlamak, aynı kod veya e-posta üzerinde sınırsız yeniden denemelere izin vermek, bir IP veya cihazın sonsuz yeniden gönderme isteme hakkı olması ve her denemede anında e-posta göndermek (kolayca suistimal edilir).
Koder.ai gibi bir platformda kurulum sohbet tabanlı ise, elle yazılan kodu ele aldığınız gibi davranın: rate limitleri ve iptal/süre sonu kurallarını, daha fazla kullanıcı açmadan önce uygulayın.
Minimal bir davet sistemi, insanlar kuralları anladığında en iyi çalışır. Bir katılma politikası seçin ve açıkça ifade edin: geleneksel sıralama (ilk gelen ilk alır); öncelikli liste (örneğin, ekipler, öğrenciler, belirli bölgeler); veya yüksek riskli kayıtlar için manuel inceleme. Politikaları açıklamadan karıştırmak sinirli e-postalara ve tekrar denemelere yol açar.
Davet mesajınız kullanıcı tıklamadan önce beklentileri belirtmelidir. Şu anda neler yapabileceklerini, neyin kısıtlı olduğunu ve hiçbir şey yapmazlarsa ne olacağını yazın. Koddun ne kadar süre geçerli olduğunu ve günlük yeni hesap sınırı olup olmadığını söyleyin.
Birisi kodunu ilettiğinde ne olacağına karar verin ve yazılı hale getirin. İletilmesine izin veriliyorsa belirtin ve kod başına bir sınır koyun. İzin verilmiyorsa bunun e-postaya bağlı olduğunu ve başka yerde çalışmayacağını açıklayın. İnsanlar genellikle iyi niyetle davetleri iletir; tonu sakin tutun.
Destek için basit bir senaryo cevabı tutarlı yanıtlar sağlar. Yaygın durumlardaki işlemler:
Koder.ai’de küçük bir grup uygulama oluşturmayı davet ediyorsanız, davet e-postasında hesapların günlük partiler halinde etkinleştirildiğini, böylece desteğin yanıt verebilir kaldığını ve iletilen kodların davet edilen e-posta ile uyuşmuyorsa reddedilebileceğini açıklayabilirsiniz.
Bekleme listenizi her yere koymadan önce “iyi gün”ün nasıl göründüğüne karar verin. Amaç, destekleyebileceğiniz istikrarlı onboarding; en hızlı büyüme değil.
Açmadan önce şu öğeleri kontrol edin:
Bunlardan herhangi biri manuel dedektiflik gerektiriyorsa veya geri alma zor ise, şimdi düzeltin. Bu genellikle küçük bir sıçramayı uzun bir geceye dönüştüren şeydir.
Davetli bir beta yönetiyorsunuz. Günde iki saat desteğiniz var ve geçmiş lansmanlara dayanarak günde kabaca 50 aktif yeni kullanıcıyı idare edebileceğinizi biliyorsunuz (hatalar birikmesi, yavaş yanıtlar, aceleci düzeltmeler olmadan).
Hafta planı: bekleme listesinden 200 kişiyi onaylayın, ama kontrollü partiler halinde yapın. Her onaylanan kullanıcıya tam olarak bir davet kodu verin. Bu, biri ürünü bir arkadaşıyla paylaşsa bile büyümeyi sabit tutar. Günlük olarak iki sayıyı izlersiniz: kaç davet kullanıldı ve kaç destek talebi geldi.
günde kodların yalnızca %60’ı kullanıldığını fark ediyorsunuz. Bu normaldir. İnsanlar meşgul olur, mailler spam klasörüne gider veya fikrini değiştirir. Panik yapıp kapıları açmayın. Bunun yerine ertesi gün küçük bir parti daha onaylayın ve hedefiniz olan ~50 yeni kullanıcıyı koruyun.
Sonra bir kod sızıntısı olur: aynı ağ aralığından onlarca kullanım ve başarısız kayıt sıçraması görürsünüz. Hızla şu adımları atarsınız:
Bundan sonra, gerçek yüklemeye göre tempoyu ayarlayın. Destek sakinse onayları artırın. Destek aşırı yükleniyorsa onayları yavaşlatın ve kullanıcı başına davet sayısını azaltın. Amaç her gün gerçek kullanıcılardan öğrenmek ve haftanızı yangın söndürmeyle harcamamak.
Davetli beta lansmanı, bir düğme gibi davranıldığında en iyi çalışır. İlk başta güvenle yürütebileceğiniz en küçük sürümü çalıştırın, sonra gerçek kullanıcı davranışını (ve gerçek suistimal girişimlerini) gördükten sonra otomasyon ekleyin.
İlk başta onayları manuel tutun. Onaylama, duraklatma veya reddetme yapabileceğiniz basit bir yönetici görünümü size öğrenme sürecinde kontrol verir. Bir haftalık onboarding yükünü tahmin edebildiğinizde, birer küçük otomatik kural ekleyin: doğrulanmış bir etki alanından gelenleri otomatik onayla veya destekleyebileceğiniz birkaç ülke listesinden gelenleri önceliklendir gibi.
Hacmi yavaşça değiştirin. Gece boyunca davet kapasitenizi ikiye katlarsanız, destek yükü ve hata raporları 2x’ten fazla artabilir. Haftalık olarak küçük bir metrik setini gözden geçirin (teslim edilebilirlik, etkinleşme oranı, destek biletleri, bot girişimleri) ve davet sayılarını küçük adımlarla ayarlayın.
Kuralları yazılı hale getirin ki ekip üyeleri rastgele onay kararı vermesin. Kısa tutun: kim önce onaylanır (ve neden), kişi başına kaç davet verilir (ve ne zaman değişir), ne tetikler duraklamayı (spam sıçraması, hata oranı, destek birikimi) ve kenar durumları nasıl ele alırsınız (kaybolan kodlar, yinelenen e-postalar).
Daha karmaşık olmadan daha hızlı gitmek istiyorsanız, akışları Koder.ai içinde oluşturup yineleyebilirsiniz. Planning modunda bekleme listesi, davet-kodu kontrolleri ve temel oran limitlerini eşleyebilir ve akışlar çalışınca kaynak kodunu dışa aktarabilirsiniz.
Amaç sıkıcı güvenilirliktir. Minimal akışınız birkaç döngü boyunca stabil kaldığında, otomasyon daha güvenli hale gelir ve kontrolü kaybetmeden eklenebilir.
Start with one required field (usually email) and a confirmation step.
Use double opt-in by default.
It blocks most bot signups because they don’t complete email confirmation. If you worry about drop-off, keep the copy simple: “Confirm to hold your spot,” and only invite confirmed emails.
Use a tiny state machine so every record is easy to understand:
pending (signed up, not confirmed/reviewed)approved (cleared to receive invites)invited (code sent/created)joined (account created)This prevents guesswork when someone says they never got in.
Start with single-use codes generated only for approved users.
Single-use invites make growth predictable and abuse obvious. If you need multi-use codes (partners, internal groups), add a daily redemption cap so one leak can’t flood you.
Use three rules as a baseline:
That’s usually enough to keep invites from turning into permanent “free access” tokens.
Default: open redemption + verification.
Binding a code to a specific email is tighter, but adds friction and support work (wrong email, forwarded invites). A practical middle ground is:
Rate-limit on more than one signal, because any single signal can be noisy.
A simple combo works well:
Then set separate limits for signup, code redemption, and repeated failures.
Keep it calm and specific, and block only the abused action.
Log the same small set of fields on key events (signup, confirm, invite create, redeem, login):
That’s enough to spot spikes and trace “who invited whom” without heavy analytics.
Use a fast “stop the bleeding” sequence:
The key is having revocation and batch invalidation ready before launch.