Savunuculuk ve Yönlendirme Takibi için Web Uygulaması Nasıl Oluşturulur

Hedefleri Netleştirin ve Ne Takip Edeceğinizi Belirleyin

Herhangi bir şey inşa etmeden önce, işletmenizde “savunuculuk”un ne anlama geldiğine karar verin. Bazı ekipler savunuculuğu yalnızca yönlendirmeler olarak ele alır. Diğerleri ürün incelemeleri, sosyal paylaşımlar, referans alıntıları, vaka çalışmaları, topluluk katılımı veya etkinlik konuşmaları gibi eylemleri de izler. Web uygulamanızın açık bir tanımı olmalı ki herkes aynı eylemleri aynı şekilde kaydetsin.

1–2 birincil hedef seçin

Yönlendirme programları farklı amaçlara hizmet edebilir ve çok fazla hedefi karıştırmak raporlamayı bulanıklaştırır. Bir veya iki birincil çıktı seçin; örneğin:

• Satış için daha nitelikli leadler
• Düşük müşteri edinme maliyeti (CAC)
• Sadık müşterileri ödüllendirerek daha yüksek tutma veya genişleme

Pratik bir test: CEO’ya aylık göstermek zorunda olsaydınız, tek grafik ne olurdu?

Uygulama içinde hesaplayacağınız başarı metriklerini belirleyin

Hedefler belirlendikten sonra, yönlendirme takip sisteminizin ilk günden hesaplaması gereken sayıları tanımlayın. Yaygın metrikler şunlardır:

• Yönlendirmeden kayıt olma oranı (yönlendirilen ziyaretçilerden kaçı kayıt oluyor)
• Yönlendirmeden ödeme yapan dönüşüm oranı (ya da satış odaklı akışlar için lead→fırsat oranı)
• Edinim başına ödül maliyeti (toplam ödüller + ücretler / kazanılan yeni müşteriler)

Tanımları açık yazın (ör. “dönüşüm 30 gün içinde sayılır”; “ödeme” iadeleri hariç tutar).

Paydaşlarla erken hizalanın

Müşteri savunuculuğu takibi birden fazla ekibi etkiler. Kuralları kim onaylıyor ve kimin erişimi olması gerektiğini belirleyin:

• Pazarlama: program konumlandırması, kanallar ve raporlama
• Satış: lead kalitesi ve yönlendirme beklentileri
• Destek/Başarı: savunucu deneyimi ve uç durumlar
• Finans: ödül bütçeleri, ödeme zamanlaması, vergi hususları

Bu kararları kısa bir şup içinde belgeleyin. Ekranlar ve atıf mantığı inşa etmeye başladığınızda yeniden çalışma yapmayı önler.

Kullanıcıları, İş Akışlarını ve Temel Ekranları Haritalandırın

Araçları veya veritabanı tablolarını seçmeden önce, sistemi kullanacak insanları ve beklenen “mutlu yol”u haritalandırın. Bir yönlendirme programı web uygulaması, savunucular için sezgisel ve işletme için kontrol edilebilir hissettiğinde başarılı olur.

Hedef kullanıcılar (ve ihtiyaçları)

Savunucular (müşteriler, ortaklar, çalışanlar): bir bağlantı veya davet paylaşmanın, yönlendirme durumunu görmenin ve ödül kazanıldığında nedenini anlamanın basit bir yolu.

Dahili yöneticiler (pazarlama, müşteri başarı, operasyonlar): kimlerin savunuculuk yaptığını, hangi yönlendirmelerin geçerli olduğunu ve hangi eylemlerin alınacağını (onayla, reddet, mesajı yeniden gönder) görme.

Finans / ödül onaycıları: ödemeler için net kanıt, denetim izi ve ödül otomasyonunu gerçek maliyetlerle uzlaştırmak için dışa aktarılabilir özetler.

Önce tasarlanması gereken temel kullanıcı yolculukları

1. Davet → kayıt → atıf → ödül
   Bir savunucu bir bağlantı veya davet paylaşır. Bir arkadaş kayıt olur. Yönlendirme takip sistemi dönüşümü savunucuya atfeder. Ödül tetiklenir (veya onay için sıraya alınır).

2. Savunucu kabulü → paylaşım seçenekleri → durum takibi
   Bir savunucu programa katılır (rıza, temel profil). Nasıl paylaşacaklarını seçer (bağlantı, e-posta, kod). Destekle iletişime geçmeden ilerlemeyi takip ederler.

3. Yönetici inceleme → istisna işlemleri → ödeme onayı
   Bir yönetici işaretlenmiş yönlendirmeleri inceler (çoğaltmalar, iadeler, kendi kendine yönlendirmeler). Finans ödemeleri onaylar. Savunucu onay mesajı alır.

Uygulamanın nerede yer alması gerektiği

Bağımsız bir portal daha hızlı başlatılır ve dışa paylaşması kolaydır. Ürününüzün içine gömülü bir deneyim ise sürtünmeyi azaltır ve kullanıcılar zaten kimlik doğrulaması yapmış olduğundan savunuculuk takibini iyileştirir. Birçok ekip önce bağımsız başlar, sonra temel ekranları gömülü hale getirir.

v1 için olmazsa olmaz ekranlar

Bir web uygulaması MVP’si için ekranları minimal tutun:

• Yönetici panosu: performans özeti, kuyruklar (bekleyen, işaretlenmiş), hızlı filtreler
• Savunucu profili (yönetici görünümlü): iletişim bilgileri, rıza durumu, kazanılan toplamlar, paylaşım varlıkları
• Yönlendirme detayları: atıf kaynağı, zaman damgaları, durum geçmişi, notlar ve ödül uygunluğu

Bu ekranlar savunucu yönetiminin bel kemiğini oluşturur ve ileride yönlendirme analitiği eklemeyi kolaylaştırır.

MVP Kapsamını Seçin vs Aşama 2 Özellikleri

Bir savunuculuk ve yönlendirme uygulaması hızla büyük bir ürüne dönüşebilir. Hızlıca işe yarar bir şey göndermenin en iyi yolu, temel döngüyü kanıtlayan bir MVP tanımlamaktır: bir savunucu paylaşır, bir arkadaş dönüşür ve doğru kişiye güvenle kredi ve ödül verebilirsiniz.

MVP için “tamamlanmış” ne anlama gelir

MVP’niz, gerçek bir programı uçtan uca minimum manuel işlemlerle çalıştırmanıza izin vermelidir. Pratik bir temel şunları içerir:

• Tahmin edilmesi zor, paylaşması kolay benzersiz yönlendirme bağlantıları veya kodlar
• Atıf: dönüşümü doğru savunucuya atayan açık kurallar
• Temel ödüller (sabit tutar veya tek bir ödül tipi) ve basit durum takibi
• Yönetici inceleme araçları: kenar durumları onaylama/reddetme, atıf geçersiz kılma ve sonuçları dışa aktarma

MVP’niz küçük bir pilotu elektronik tablolar olmadan idare edebiliyorsa “tamamlanmış” sayılabilir.

Erteleyebileceğiniz özellikler (Aşama 2)

Değerli ama genellikle teslimatı yavaşlatan ve henüz neyin önemli olduğunu bilmeden karmaşıklık ekleyen özellikler:

• Aşamalı ödüller (kilitlenme, çok adımlı açılımlar, VIP seviyeleri)
• Çoklu kampanya desteği (birden fazla program, marka, ülke, para birimi)
• A/B testleri (mesajlar, açılış sayfaları, teşvik yapıları için)
• Tam kendi kendine hizmet eden savunucu portalı (ödeme geçmişi, destek akışları, zengin profil yönetimi)

Taahhüt vermeden önce kısıtlar belirleyin

Zaman çizelgesi, ekip becerileri, bütçe ve uyumluluk ihtiyaçları (vergi, gizlilik, ödeme kuralları) gibi kapsam kararlarını şekillendirecek kısıtları yazın. Ödül otomasyonundan ve temiz bir yönetici iş akışından ödün vermek yerine izleme doğruluğunu önceliklendirin—bunlar sonradan düzeltmesi en zor olanlardır.

Savunucu ve Yönlendirmeler için Veri Modelini Tasarlayın

Bir yönlendirme uygulaması veri modeline bağlıdır. Varlıkları ve statüleri erken doğru kurarsanız, raporlama, ödemeler ve dolandırıcılık kontrolleri daha basit olur.

Temel varlıklardan başlayın

En azından şu nesneleri açıkça modelleyin:

• Advocate: programınıza kayıtlı kişi (profil ve paylaşım varlıklarına sahip)
• Referrer: bir yönlendirme oluşturan kaynak kimlik (çoğunlukla Advocate ile aynı olabilir ama örn. ortaklar için farklı olabilir)
• Referral: bir referrer ile yönlendirilen kullanıcı arasındaki ilişki (vaka dosyası)
• Reward: kazanılan şey (kupon, nakit, puan) ve yaşam döngüsü
• Campaign: program varyantı için kurallar ve uygunluk (tarihler, bölgeler, teşvikler)
• Event: izlenen her eylem (click, signup, purchase, refund)
• Payout: ödüllerin nasıl ödenip/nasıl verildiği (batch, yöntem, harici kimlikler)

Sonradan sorun çıkarmayacak kilit alanlar

Her kayda benzersiz bir tanımlayıcı (UUID vb.) ve zaman damgaları (created_at, updated_at) verin. Ödüller için pending → approved → paid gibi gerçek iş akışına uyan statü alanları ekleyin ve kaynak kanalını (email, link, QR, in-app, partner) saklayın.

Pratik bir desen: Referral/Reward üzerinde “güncel durum” alanları tutun, tam geçmişi ise Events olarak saklayın.

Yönlendirmeleri tek bir andan ziyade zaman çizelgesi olarak takip edin

Yönlendirmeler nadiren tek adımda gerçekleşir. Kronolojik bir zincir yakalayın:

click → signup → purchase → refund

Bu, atıfı açıklanabilir kılar ("onaylandı çünkü satın alma 14 gün içinde gerçekleşti") ve kısmi iadeler, iptaller gibi kenar durumları destekler.

Baştan itibaren idempotentliği planlayın

Ürün ve ödeme olayları tekrar gönderilir. Çoğaltmaları önlemek için Event yazımlarınızı idempotent yapın: external_event_id saklayın (ürün, ödeme sağlayıcısı ya da CRM’den) ve (source_system, external_event_id) gibi bir benzersizlik kuralı uygulayın. Aynı olay iki kez gelirse sistem “zaten işlendi” döndürmeli ve toplamları doğru tutmalıdır.

Gerçek Davranışa Uyan Atıf Kuralları Oluşturun

Atıf, kimin yönlendirme kredisi aldığı konusunda “gerçek” kaynaktır—ve çoğu yönlendirme uygulaması burada ya adil hisseder ya da sürekli destek biletleri yaratır. Hangi davranışları tanıyacağınızı seçin, sonra gerçek dünya karıştığında öngörülebilir davranan kurallar yazın.

Başlangıç için küçük bir atıf seti seçin

Çoğu ekip başlangıçta 2–3 yöntemle başarılı olur:

• Yönlendirme bağlantıları (varsayılan olarak en iyisi): her savunucuya özel URL
• Kupon kodları: çevrimdışı paylaşım veya influencer’lar için kullanışlı
• Davet e-postaları: alıcı adresi ve gönderim olayı ile izlenir
• Kayıttan sonra talep akışı: izleme başarısızsa “sizi kim yönlendirdi? kod/e-posta girin” yedeği

Kesinlikle göreceğiniz kenar durumlarını ele alın

Kullanıcılar birden çok bağlantıya tıklar, cihaz değiştirir, çerezleri temizler ve günler sonra dönüşür. Sisteminiz şu durumları ne şekilde ele alacağını tanımlamalı:

• Birden çok tıklama (aynı kullanıcı farklı savunucuların linklerine tıkladı)
• Birden çok cihaz (mobil tıklama → masaüstü satın alma)
• Gecikmiş dönüşümler (7/30/90 günlük dönüşüm penceresi gibi)

Pratik bir MVP kuralı: bir dönüşüm penceresi belirleyin, bu pencere içinde en son geçerli yönlendirmeyi saklayın ve yönetici aracında manuel geçersiz kılmalara izin verin.

Kredi verme modelini seçin (basit tutun)

Bir web uygulaması MVP’si için son dokunuş veya ilk dokunuş modellerinden birini seçin ve belgeleyin. Kredi bölme cazip olsa da ödül otomasyonu ve raporlama karmaşıklığını artırır.

Her karar için kanıt saklayın

Bir yönlendirmeye kredi verdiğinizde bir denetim izi (tıklama ID’si, zaman damgası, açılış sayfası, kullanılan kupon, davet e-posta ID’si, kullanıcı aracısı ve form girdileri) saklayın. Bu, savunucu yönetimini, dolandırıcılık incelemelerini ve anlaşmazlık çözümünü kolaylaştırır.

Yönetici Panosunu ve Yönetim Araçlarını Oluşturun

Programınız günlük işletim yapılmadan çalışmaz. Yönetici alanı ham yönlendirme olaylarını kararlara çevirdiğiniz yerdir: kim ödüllendirilecek, ne yapılmalı ve sayılar sağlıklı mı. Bu nedenle yönetici alanına yatırım yapın.

Pano: net bir “kontrol merkezi”

Operatörün her sabah sorduğu soruları cevaplayan basit bir pano ile başlayın:

• Toplamlar ve eğilimler: yeni savunucular, yeni yönlendirmeler, dönüşüm oranı, verilen/bekleyen ödüller
• Bekleyen onaylar: inceleme bekleyen öğeler, yaşlanma (örn. “7+ gündür bekleyen”)
• En iyi savunucular: nitelikli yönlendirme veya atfedilen gelir sıralaması
• İşaretlenmiş etkinlikler: ani sıçramalar, tekrar eden self-referral’ler, aynı cihaz/IP’den çoklu kayıtlar veya şüpheli desenler

Grafikleri hafif tutun—basitlik karmaşıklıktan iyidir.

Yönlendirme detay görünümü: tek yerde denetlenebilirlik

Her yönlendirme için şu bilgileri içeren bir detay sayfası olmalı:

• Kim kime yönlendirdi (ana kimlik bilgileri ile)
• Güncel durum (clicked → signed up → qualified → rewarded)
• Olay zaman çizelgesi
• Ödül uygunluğu ve bunu tetikleyen kural

Bu, destek taleplerini çözerken loglarda gezinmeyi gereksiz kılar.

Savunucu profilleri: sadece linklerle değil ilişkilerle ilgilenin

Her savunucu profili iletişim bilgileri, yönlendirme linki/kodu, tam geçmiş, ayrıca notlar ve etiketler (örn. “VIP”, “iletişim gerekli”, “ortak”) içermeli. Bu yer manuel ayarlamalar ve iletişim takibi için de uygundur.

Dışa aktarmalar ve erişim kontrolü

Ekiplerin raporlayıp uzlaştırma yapabilmesi için savunucular, yönlendirmeler ve ödüller için temel CSV dışa aktarmaları ekleyin.

Rol tabanlı erişim uygulayın: admin (düzenle, onayla, öde) vs yalnızca görüntüle (gör, dışa aktar). Bu, hataları azaltır ve hassas veriyi doğru kişilere sınırlar.

Ödülleri ve Onay İş Akışlarını Uygulayın

Ödüller, programınızı savunucular için “gerçek” kılan kısımdır—ve operasyonel hataların maliyetli olduğu yerdir. Ödülleri birincil özellik olarak ele alın; dönüşümlere birkaç alan eklemek yerine yaşam döngüsünü net modelleyin.

İşinize uygun ödül türlerini seçin

Yaygın seçenekler: indirimler, hediye kartları, hesap kredileri ve (uygun olduğunda) nakit. Her türün farklı yerine getirme adımları ve riskleri vardır:

• İndirimler: tek kullanımlıksa verilmeleri kolay ve kötüye kullanımı zor
• Hesap kredileri: değeri ürün içinde tutar ve ödeme sürtünmesini azaltır
• Hediye kartları: popülerdir ama sağlayıcı veya manuel satın alma gerektirir
• Nakit: ek uyumluluk, ödeme hattı ve daha güçlü dolandırıcılık kontrolleri gerektirir

Ödül yaşam döngüsünü net modelleyin

Tüm tarafların (kod dahil) ne olduğunu bildiği tutarlı bir durum makinesi tanımlayın:

eligible → pending verification → approved → fulfilled → paid

Her ödül her adımı gerektirmez, ama desteklemelisiniz. Örneğin bir indirim için approved → fulfilled anında olabilirken, nakit için ödeme onayı geldikten sonra paid adımı gerekir.

Otomasyon ile manuel kontrolü dengeleyin

Programı hızlı tutmak için otomatik eşikler belirleyin (örn. belirli bir değerin altındaki ödülleri otomatik onayla ya da iade olmazsa X gün sonra otomatik onayla). Yüksek değerli ödüller, sıra dışı etkinlikler veya kurumsal hesaplar için manuel inceleme ekleyin.

Pratik bir yaklaşım: “varsayılan olarak otomatik onayla, kurallarla yükselt”—bu savunucuları memnun ederken bütçenizi korur.

İlk günden denetim kayıtlarını ekleyin

Her onay, düzenleme, ters çevirme veya yerine getirme eylemi bir denetim olayı yazmalıdır: kim değiştirdi, ne değişti ve ne zaman. Denetim kayıtları anlaşmazlıkların çözülmesini kolaylaştırır ve çift ödeme ya da yanlış yapılandırılmış kurallar gibi sorunları debug etmeyi sağlar.

İsterseniz, ödül detay ekranından denetim izine bağlantı verin ki destek mühendislik olmadan soruları yanıtlayabilsin.

Entegrasyonları Bağlayın: Ürün Olayları, CRM ve Mesajlaşma

Entegrasyonlar, yönlendirme programınızı “başka bir araç” olmaktan çıkarıp günlük iş akışınızın parçası yapar. Amaç basit: gerçek ürün etkinliğini yakalamak, müşteri kayıtlarını tutarlı tutmak ve olan biteni otomatik olarak iletişimle bildirmek—manuel kopyala/yapıştır olmadan.

Ürün olayları: kayıtlar, yükseltmeler, satın almalar

Programınız için gerçekten başarıyı tanımlayan olaylarla entegrasyon yapın (ör. hesap oluşturuldu, abonelik başladı, sipariş ödendi). Çoğu ekip bunu webhook veya olay izleme boru hattı ile yapar.

Olay sözleşmesini küçük tutun: harici kullanıcı/müşteri ID’si, olay adı, zaman damgası ve ilgili değer (plan, gelir, para birimi). Bu, daha sonra atıf ve ödül uygunluğunu tetikleyecek kadar bilgidir.

{
  "event": "purchase_completed",
  "user_id": "usr_123",
  "occurred_at": "2025-12-26T10:12:00Z",
  "value": 99,
  "currency": "USD"
}

(Yukarıdaki kod bloğu aynen korunmalıdır.)

CRM senkronizasyonu: müşteri ve fırsatlar karışıklığı olmadan

Bir CRM kullanıyorsanız, insanları ve sonuçları tanımlamak için gereken minimum alanları eşleyin (contact ID, email, company, deal stage, revenue). İlk günden her özel alanı eşlemeye çalışmayın.

Alan eşlemesini bir yerde belgeleyin ve bunu bir sözleşme gibi ele alın: hangi sistem e-posta için “kaynak”tır, şirket ismini kim yönetir, kayıtlar birleştirildiğinde ne olur ve bir kişi birleştirildiğinde nasıl davranılır.

Mesajlaşma: savunucuları ilgili tutan e-posta/SMS

Destek biletlerini azaltan ve güven artıran mesajları otomatikleştirin:

• Yönlendirme daveti (paylaşım bağlantısı + yönergeler)
• Durum güncellemeleri (tıklandı, kayıt oldu, satın alma onaylandı)
• Ödül onayı (ne kazandıkları, ne zaman geleceği ve sonraki adımlar)

Birkaç değişken içeren şablonlar kullanın (isim, yönlendirme bağlantısı, ödül miktarı) ki ton tutarlı kalsın.

Eğer hazır bağlantı noktalarını veya yönetilen planları değerlendiriyorsanız, hangi entegrasyonların desteklendiğini ekiplerin doğrulayabilmesi için ürün sayfalarına (ör. /integrations, /pricing) açık yollar gösterin.

Performansı ve YG’yi Açıklayan Analitikler Ekleyin

Analitikler tek soruyu yanıtlamalı: “Program kârlı şekilde ek gelir yaratıyor mu?” Paylaşımlar veya tıklamalar yerine tam huni izlemeye odaklanın.

Huniyi uçtan uca izleyin

Gerçek çıktılara bağlanan metrikleri enstrümante edin:

• Tıklamalar → kayıtlar → nitelikli leadler → satın almalar → tutulan müşteriler

Bu, yönlendirmelerin nerede takıldığını görmenizi sağlar (ör. yüksek tıklama ama düşük nitelikli lead, hedefleme veya teklif uyumsuzluğunu gösterir). Her adımın net bir tanımı olduğundan emin olun (ör. “nitelikli” ne sayılır, hangi zaman penceresi geçerli).

Sonuçları segmentlere ayırın ki aksiyon alınabilsin

Her temel grafik için segmentasyon ekleyin:

• Kampanya (örn. “Bahar promosyonu”)
• Kanal (e-posta, üründeki bildirim, sosyal, ortak)
• Savunucu kohortu (katılma tarihi veya ilk yönlendirme tarihi)
• Coğrafya (sadece gerçekten topluyorsanız)

Segmentler, “program düşüyor” yerine “sosyal yönlendirmeler iyi dönüşüm sağlıyor ama düşük tutma oranı var” gibi eyleme dönüştürülebilir içgörüler verir.

İş sorularını cevaplayan panolar

Gelirle bağlantısı olmayan “toplam paylaşımlar” gibi gösterge sayılarını önermeyin. İyi pano soruları:

• Hangi savunucular nitelikli dönüşümler getiriyor?
• Kanal bazında dönüşüm oranı ve dönüşüm süresi nedir?
• Ödüller karşılığında ne kadar ödendi vs ne kadar gelir atfedildi?
• Kampanya bazında YG ve geri ödeme süresi nedir?

Basit bir YG görünümü ekleyin: atfedilen gelir, ödül maliyeti, operasyonel maliyet (isteğe bağlı) ve net değer.

Paydaşlar için raporlama takvimi

Program görünür kalması için güncellemeleri otomatikleştirin:

• Haftalık özet: hacim, dönüşüm, en iyi savunucular, anomaliler
• Aylık YG incelemesi: segment bazlı performans, maliyetler, tutma, öneriler

Zaten bir raporlama merkezi varsa, yönetici alanından oraya bağlantı verin (ör. /reports) ki ekipler self-serve yapabilsin.

Dolandırıcılığı Azaltın ve Programı Adil Tutun

Yönlendirme programları dürüst savunucuların “oynanmasını” hissetmemesi gerektiğinde en iyi çalışır. Dolandırıcılık kontrolleri cezalandırıcı değil—hatta görünmeden açık kötüye kullanımı kaldırmalı ve meşru yönlendirmelerin akışını engellememelidir.

Sık görülen dolandırıcılık desenleri

Her programda şu sorunlar sık görülür:

• Self-referral (savunucu başka bir e-posta veya cihazla kendini yönlendirir)
• Çoğaltılmış hesaplar (bonus toplamak için çoklu kayıtlar)
• Kupon suistimali (tek kullanımlık kodun halka açık paylaşılması veya kuponların üst üste kullanılması)
• Bot tıklamaları ve sahte trafik (satın alma niyeti olmayan şişirilmiş tıklamalar)

Kullanıcıları rahatsız etmeyecek hafif korumalar

Basit başlayın, gerçek kötüye kullanım gördüğünüz yerlerde kuralları sıkılaştırın.

• “Oluşturma yönlendirme”, “kod kullanımı”, “ödeme talebi” gibi olaylarda oran sınırlamaları
• Temel anomali tespiti (tek IP aralığından ani sıçramalar, olağandışı tıklama→kayıt oranları)
• Eğer cihaz/ tarayıcı fingerprinting kullanacaksanız, şeffaf olun ve gerekli durumlarda rıza alın—aksi halde gizlilik sorunları doğurabilirsiniz

Ayrıca yönetici alanında “muhtemel çoğaltma”, “kupon sızdı”, “inceleme gerekli” gibi manuel bayraklar verin ki destek mühendislik yardımı olmadan müdahale edebilsin.

Ödülleri onaylamadan önce doğrulayın

“Güven ama doğrula” yaklaşımı temiz çalışır:

• Ödüllerin ödenebilir hale gelmeden önce bir bekleme süresi uygulayın
• Asgari satın alma eşikleri belirleyin (deneme veya iade edilen siparişleri hariç tutun)
• Nihai onaydan önce iade/chargeback kontrolleri çalıştırın

Sert engelleme yerine bir inceleme kuyruğu ekleyin

Bir şey şüpheli göründüğünde otomatik reddetmek yerine inceleme kuyruğuna gönderin. Bu, ortak hane, kurumsal ağlar veya meşru uç durumlar yüzünden iyi savunucuları cezalandırmanızı önler.

Gizlilik, Rıza ve Veri Saklama Kurallarını Ele Alın

Yönlendirme takibi kişiseldir: bir savunucuyu davet ettiği kişiye bağlıyorsunuz. Gizliliği hukukun sonrasında değil, bir ürün özelliği olarak ele alın.

Yalnızca gerekli olanı toplayın

Programı yürütmek için gerekli minimum alanları yazın (ve fazlasını toplamayın). Birçok ekip şu alanlarla çalışabilir: savunucu ID/e-posta, yönlendirme linki veya kodu, yönlendirilen kullanıcı tanımlayıcısı, zaman damgaları ve ödül durumu.

Saklama sürelerini önceden tanımlayın ve belgeleyin. Basit bir yaklaşım:

• Yönlendirme olay verisi: anlaşmazlıkları çözmek ve performansı ölçmek için yeterli süre (örn. 12–24 ay)
• Ödeme ve muhasebe kayıtları: vergi/finans kurallarına göre gerektiği kadar saklanır (genellikle daha uzun)
• Etkisiz savunucular: belirli bir süre sonra arşivle, ardından sil

Rıza ve şartları UI’da görünür yapın

Doğru anlarda açık rıza kutuları ekleyin:

• Savunucu kaydı (program şartları, veri işleme onayı)
• Paylaşım akışı (hangi bilgilerin atıf için kullanılacağı bildirimi)
• Yönlendirilen kullanıcı kayıt/ödeme akışı (bir yönlendirme kredilendirilebileceği bildirimi)

Şartları okunabilir tutun ve yakınında görünür bağlantılar verin (ör. /terms ve /privacy) —uygun yerlerde uygun bağlantılar göstermeye devam edin— ve uygunluk, ödül limitleri veya onay gecikmeleri gibi kilit koşulları saklamayın.

Kim neyi görebilir kararını verin

Hangi rollerin savunucu ve yönlendirilen kullanıcı bilgilerini görebileceğini belirleyin. Çoğu ekip için rol tabanlı erişim yararlıdır:

• Destek: yönlendirme durumunu görme, sınırlı kişisel bilgi
• Finans: ödeme geçmişini görme
• Admin: tam erişim + dışa aktarma

Dışa aktarma ve hassas ekranlara erişimi de kaydedin.

Silme talepleri için bir süreç planlayın

Gizlilik hakları talepleri (GDPR/UK GDPR, CCPA/CPRA ve yerel kurallar) için basit bir süreç oluşturun: kimliği doğrulayın, kişisel tanımlayıcıları silin ve yalnızca muhasebe veya dolandırıcılık önleme için gerekli olanları saklayın—bunları açıkça işaretlenmiş ve zaman sınırlı tutun.

Basit Bir Teknoloji Yığını Seçin ve Güvenle İnşa Edin

Bir yönlendirme web uygulaması egzotik bir yığına ihtiyaç duymaz. Amaç öngörülebilir geliştirme, kolay barındırma ve atıfı bozabilecek az sayıda hareketli parça.

Basit, pratik bir yığın

• Modern web framework: UI ve sunucu rotaları için Next.js (React) veya Remix
• Veritabanı: güvenilir bir yönlendirme takibi için Postgres (Supabase, Neon veya RDS üzerinde barındırma)
• Barındırılan kimlik doğrulama: Auth0, Clerk veya Supabase Auth
• Arka plan işleri: yönetilen bir kuyruk (ör. Cloud Tasks) veya ödül otomasyonu ve webhook tekrarları için basit bir worker

Daha hızlı göndermek istiyorsanız ve küçük bir ekibiniz varsa, Koder.ai gibi sohbet tabanlı prototipleme platformları admin paneli, çekirdek iş akışları ve entegrasyonlar için hızlı prototip üretmeye yardımcı olabilir—önden React, arkadan Go + PostgreSQL çıktısı veren ve dağıtım/barındırma, özel alan adları ve snapshot ile rollback destekleyen yaklaşımlar dahil.

Frontend vs backend (anlaşılır dille)

Frontend yöneticiler ve savunucuların gördüğü kısımdır: formlar, panolar, yönlendirme bağlantıları ve durum sayfaları.

Backend ise kural kitabı ve kayıt tutucudur: advocate’ları ve yönlendirmeleri depolar, atıf kurallarını uygular, olayları doğrular ve ödül kazanıldığında karar verir. İyi bir uygulamada “gerçek” çoğunlukla backend’te saklanmalıdır.

Atlanmaması gereken güvenlik temelleri

Kim olduğunuzu doğrulamak için kimlik doğrulama, hangi işlemleri yapabileceğinizi denetlemek için yetkilendirme ve veri iletimi sırasında şifreleme (HTTPS her yerde) kullanın.

Sırlar (API anahtarları, webhook imzalama sırları) uygun bir gizli yöneticide veya barındırıcınızın şifreli çevresel değişkenlerinde saklanmalı—asla koda veya istemci tarafı dosyalara koymayın.

Hafif bir test planı

Atıf mantığı için unit testleri yazın (örn. son dokunuş vs ilk dokunuş, self-referral engelleme). Temel yönlendirme akışı için uçtan uca testler ekleyin: savunucu oluştur → bağlantı paylaş → kayıt/satınalma → ödül uygunluğu → yönetici onay/red.

Bu, MVP genişledikçe değişiklikleri güvenli hale getirir.

Başlatın, Öğrenin ve Zamanla Uygulamayı İyileştirin

Bir yönlendirme web uygulaması genellikle ilk günden mükemmel çalışmaz. En iyi yaklaşım kontrollü adımlarla başlatmak, gerçek kullanım sinyallerini toplamak ve hem savunucular hem de yöneticiler için takip etmeyi kolaylaştıran küçük iyileştirmeler göndermektir.

Aşamalar halinde yaygınlaştırma

Temelleri doğrulamak için önce dahili testle başlayın: yönlendirme bağlantıları, atıf, ödül otomasyonu ve yönetici eylemleri. Sonra küçük bir kohorta (ör. 20–50 güvenilir müşteri) genişletin, ardından tam lansmana geçin.

Her aşamada “go/no-go” kontrol listesi belirleyin: yönlendirmeler doğru kaydediliyor mu, ödüller beklediğiniz şekilde sıraya alınıyor mu ve destek uç durumları hızlı çözülebiliyor mu? Bu, sistem stabilken kullanımın büyümesini sağlar.

Gerçekten kullandığınız bir geri bildirim döngüsü kurun

Sezgilere güvenmeyin. Öğrenmeyi yapılandırılmış hale getirin:

• Yönlendirme sorunları için destek etiketleri (kredi eksik, çoğaltma, ödeme soruları)
• Kısa savunucu anketleri (neden paylaştılar, ne engelledi, ödül algılanan değeri)
• Savunucu/yönlendirme seviyesinde yönetici notları (tekrar eden desenler, şüpheli davranış, özel işlem)

Bu verileri haftalık yönlendirme analitiği ile birlikte gözden geçirin ki geri bildirim eyleme dönsün.

Açık bir yol haritası ile yineleyin

MVP oturduktan sonra, manuel işi azaltan ve katılımı artıran özellikleri önceliklendirin. Yaygın sonraki adımlar: aşamalı ödüller, çoklu dil desteği, daha eksiksiz kendi kendine hizmet portalı ve CRM entegrasyonu/ortak araçlar için API erişimi.

Aşama 2 özelliklerini feature flag’lerin arkasında tutun ki bunları sadece bir alt kümeyle güvenle test edebilin.

Eğer açık şekilde inşa ediyorsanız, benimseme ve geri bildirim teşviki için örneğin Koder.ai’nin içerik oluşturma ve yönlendirme programlarına benzer mekanikler sunmayı düşünebilirsiniz—kendi uygulamanızda uyguladığınız aynı savunucu yönetimi ilkelerini burada da kullanabilirsiniz.

Etkiyi ölçün ve genişletmeye karar verin

Sadece etkinlik değil, YG’yi yansıtan çıktıları takip edin: kanal bazlı dönüşüm oranı, ilk yönlendirmeye kadar geçen süre, edinim başına maliyet ve ödül maliyeti/gelire oranı.

Performans iyiyse, müşteriler dışına partnerlar veya affiliate’lere genişlemeyi düşünebilirsiniz—ama yalnızca atıf, dolandırıcılık önleme ve gizlilik/onay işleyişinin ölçeklenebildiğini doğruladıktan sonra.