Savunucuların, yönlendirmelerin ve ödüllerin takibini yapacak bir web uygulaması nasıl kurulur — MVP özelliklerinden veri modeline, entegrasyonlara, analitiğe ve gizlilik temellerine kadar.
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.
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:
Pratik bir test: CEO’ya aylık göstermek zorunda olsaydınız, tek grafik ne olurdu?
Hedefler belirlendikten sonra, yönlendirme takip sisteminizin ilk günden hesaplaması gereken sayıları tanımlayın. Yaygın metrikler şunlardır:
Tanımları açık yazın (ör. “dönüşüm 30 gün içinde sayılır”; “ödeme” iadeleri hariç tutar).
Müşteri savunuculuğu takibi birden fazla ekibi etkiler. Kuralları kim onaylıyor ve kimin erişimi olması gerektiğini belirleyin:
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.
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.
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.
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).
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.
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.
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.
Bir web uygulaması MVP’si için ekranları minimal tutun:
Bu ekranlar savunucu yönetiminin bel kemiğini oluşturur ve ileride yönlendirme analitiği eklemeyi kolaylaştırır.
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’niz, gerçek bir programı uçtan uca minimum manuel işlemlerle çalıştırmanıza izin vermelidir. Pratik bir temel şunları içerir:
MVP’niz küçük bir pilotu elektronik tablolar olmadan idare edebiliyorsa “tamamlanmış” sayılabilir.
Değerli ama genellikle teslimatı yavaşlatan ve henüz neyin önemli olduğunu bilmeden karmaşıklık ekleyen özellikler:
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.
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.
En azından şu nesneleri açıkça modelleyin:
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ö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.
Ü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.
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.
Çoğu ekip başlangıçta 2–3 yöntemle başarılı olur:
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ı:
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.
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.
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.
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.
Operatörün her sabah sorduğu soruları cevaplayan basit bir pano ile başlayın:
Grafikleri hafif tutun—basitlik karmaşıklıktan iyidir.
Her yönlendirme için şu bilgileri içeren bir detay sayfası olmalı:
Bu, destek taleplerini çözerken loglarda gezinmeyi gereksiz kılar.
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.
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ü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.
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:
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.
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.
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, 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.
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.)
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.
Destek biletlerini azaltan ve güven artıran mesajları otomatikleştirin:
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.
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.
Gerçek çıktılara bağlanan metrikleri enstrümante edin:
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).
Her temel grafik için segmentasyon ekleyin:
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.
Gelirle bağlantısı olmayan “toplam paylaşımlar” gibi gösterge sayılarını önermeyin. İyi pano soruları:
Basit bir YG görünümü ekleyin: atfedilen gelir, ödül maliyeti, operasyonel maliyet (isteğe bağlı) ve net değer.
Program görünür kalması için güncellemeleri otomatikleştirin:
Zaten bir raporlama merkezi varsa, yönetici alanından oraya bağlantı verin (ör. /reports) ki ekipler self-serve yapabilsin.
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.
Her programda şu sorunlar sık görülür:
Basit başlayın, gerçek kötüye kullanım gördüğünüz yerlerde kuralları sıkılaştırın.
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.
“Güven ama doğrula” yaklaşımı temiz çalışır:
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.
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.
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:
Doğru anlarda açık rıza kutuları ekleyin:
Ş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.
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:
Dışa aktarma ve hassas ekranlara erişimi de kaydedin.
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.
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.
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 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.
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.
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.
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.
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.
Sezgilere güvenmeyin. Öğrenmeyi yapılandırılmış hale getirin:
Bu verileri haftalık yönlendirme analitiği ile birlikte gözden geçirin ki geri bildirim eyleme dönsün.
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.
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.
Önce işletmeniz için “savunuculuk”un ne anlama geldiğini tanımlayın (sadece yönlendirmeler mi yoksa incelemeler, referanslar, topluluk katılımı, etkinlik konuşmaları gibi diğer eylemler de mi). Ardından 1–2 ana hedef seçin (ör. nitelikli leadler, daha düşük CAC, daha yüksek müşteri tutma) ve metrik tanımlarını erken kilitleyin (dönüşüm penceresi, iade işlemleri, “ödeme”nin neyi kapsadığı).
İlk günden uygulamanın hesaplayabileceği metrikleri seçin:
(toplam ödüller + ücretler) / kazanılan yeni müşteriler“30 gün içinde dönüşüm” ve “ödeme iade/chargeback içermiyor” gibi kuralları açıkça belirtin.
Üç rol etrafında tasarlayın:
Böylece güzel görünen ama günlük işletime uygun olmayan bir portal inşa etmemiş olursunuz.
v1’de yalnızca çekirdek döngüyü destekleyecek özellikleri yayınlayın:
Pilotu elektronik tablolar kullanmadan çalıştırabiliyorsanız MVP’niz “tamam” demeye yeterlidir.
Başlangıç için:
Çoğu ekip önce bağımsız başlar, iş akışları doğrulandığında savunucu veya yönetici ekranlarını gömülü hale getirir.
Programı açıkça modelleyin; en azından bu varlıkları tutun:
Her kayda UUID ve zaman damgaları ekleyin; güncel durum alanları (ör. ) kullanın ve tüm geçmişi Event kayıtları olarak saklayın. Bu, raporlama ve denetimler için güvenilirlik sağlar.
Yönlendirmeler tek bir an değil, bir zaman çizelgesidir. Aşağıdaki gibi olayları yakalayın:
click → signup → purchase → refundBu, kararları açıklanabilir kılar (ör. “satın alma 14 gün içinde gerçekleşti”) ve iptaller, chargeback’ler ile gecikmiş dönüşümler gibi kenar durumları destekler.
Tekrarlanan webhook’ların çift sayım yapmaması için olay alımını idempotent yapın:
external_event_id ve source_system saklayın(source_system, external_event_id) üzerinde benzersizlik sağlayınBu, atıf toplamlarını korur ve çift ödeme riskini azaltır.
MVP için atıf yöntemlerini sınırlı tutun (2–3):
Kenar durumlarını belgeleyin: birden çok tıklama, cihaz değişimi, dönüşüm penceresi ve ilk/son dokunuş tercihleri. Her kararı kanıtla (tıklama ID’si, kupon, zaman damgaları) kaydedin.
Kullanıcıları cezalandırmayan hafif kontroller ekleyin:
Şüpheli vakaları otomatik reddetmek yerine inceleme kuyruğuna yönlendirin; ayrıca tüm yönetici eylemlerini denetim kaydına yazın.
pending → approved → paid