Ortakları takip eden, komisyon hesaplayan, ödemeleri onaylayan ve dolandırıcılığı engelleyen bir web uygulaması inşa etmek için adım adım plan—MVP kapsamı ve lansman ipuçları dahil.
Teknoloji yığını seçmeden veya ekran tasarlamadan önce ürünü kimin kullandığını ve “bitti”nin ne anlama geldiğini netleştirin. Çoğu afiliye program yazılımı özellik eksikliğinden değil, hayali bir kullanıcı ve belirsiz bir sonuç için inşa edildiği için başarısız olur.
Kısa bir rol listesi ve her rolün yapması gerekenleri yazın:
Her rol için 3–5 “günlük hayat” senaryosu yazın (madde halinde bile olsa). Bu senaryolar hem partner portalınızı hem de dahili araçları şekillendirir.
v1 için esas döngüye odaklanın:
Bu döngüyü desteklemeyen her şey “sonra” özelliğidir.
İş değerini yansıtan birkaç metrik seçin, örneğin:
Tek sayfada şunları listeleyin:
Bu MVP kapsamı, geliştirme sırasında gelen özellik isteklerini filtrelemenizi sağlar.
Ekranları veya takip kodunu yazmadan önce kim ödenecek, ne kadar ve ne zaman sorularını belirleyen kuralları tanımlayın. Açık kurallar ihtilafları azaltır, raporlamayı basitleştirir ve ilk sürümünüzü yönetilebilir tutar.
v1 için bir ana komisyon modeli seçin ve açıklaması kolay olsun:
Komisyonun neye göre belirleneceğini (brüt vs net, vergi/kargo dahil mi, iadeler/chargeback nasıl ele alınır) kararlaştırın. Emin değilseniz net ödenen tutar üzerinden başlayın ve iadeleri sonra düşün.
Atıf, birden fazla dokunuş olduğunda hangi ortağın kredi alacağını belirler.
v1 için tek bir kural seçin:
Kenar durumları erken belgeleyin: müşteri bir kupon kullanırsa veya bir affiliate tıklamasından sonra ücretli reklamla gelirse ne olur?
Çerez/referans penceresini (ör. 7/30/90 gün) ve tekrar satın alımların sayılıp sayılmayacağını tanımlayın:
Onay kuralları nakit akışı ve dolandırıcılık riskini etkiler:
Birçok program iadeler ve chargeback’leri kapsamak için dönüşümün ödenebilir hale gelmeden önce bir bekletme süresi (ör. 14–30 gün) kullanır. Statüleri açık tutun: pending → approved → payable → paid.
Temiz bir veri modeli, afiliye takibi ve ödemelerinin kenar durumlarla dolup taşmasını engeller. Ekranları yazmadan önce takip edeceğiniz “nesneleri” ve bunların olabileceği durumları tanımlayın ki raporlama ve komisyon yönetimi tutarlı kalsın.
En azından çoğu afiliye yazılımı şu varlıklara ihtiyaç duyar:
Tıklamalar ve dönüşümler için ID'leri kararlı ve değişmez tutun; böylece yeniden hesaplamalar analitiği bozmaz.
Paylaşılan statüleri erken tanımlayın ki UI, otomasyon ve destek ekibi aynı dili konuşsun:
Bu statüleri dönüşümlere ve komisyon kalemlerine tutarlı uygulayın. Ödemelerin kendileri de scheduled, processing, completed, failed gibi durumlara ihtiyaç duyar.
v1 tek para birimi olsa bile dönüşümlere ve ödemelere para birimi saklayın; ayrıca fx_rate, tax_withheld_amount ve tax_region gibi alanları düşünün. Bu, ödeme otomasyonu ve raporlamayı genişletilebilir kılar.
Son olarak bir audit log tablosu ekleyin: actor_type (admin/affiliate/system), actor_id, entity_type, entity_id, action, before, after, created_at. Bir komisyon approved'dan reversed'e döndüğünde kim neyi ne zaman değiştirdiğini bilmek isteyeceksiniz.
Kod yazmadan önce her rol için ekranları ve “mutlu yolları” (happy paths) taslaklayın. Afiliye programları kafa karıştırıcı iş akışları yüzünden daha sık başarısız olur; eksik özelliklerden değil. Her sayfanın bir soruya cevap vermesini hedefleyin: Sırada ne yapabilirim ve durum nedir?
Partner portalı birkaç dakika içinde tanıtım yapmayı kolaylaştırmalı.
Ana ekranlar:
Tasarım ipucu: bir komisyonun neden “pending” olduğunu (ör. “iade penceresi bekleniyor”) ve beklenen onay tarihini her zaman gösterin.
Yöneticiler hız ve kontrol ister.
Temel iş akışları:
Operasyonel yükü azaltmak için toplu işlemleri (50 dönüşümü onayla, birden fazla ortağı duraklat) ekleyin.
Finans ekranları tekrar eden ödeme döngülerini desteklemeli:
Hafif bir vaka görünümü oluşturun: ortak + dönüşüm + tıklama izi (varsa), notlar, ekler ve ihtilaf statüsü ile. Amaç, araçlar arasında arama yapmadan hızlı çözüm sağlamaktır.
Takip, herhangi bir afiliye programının temelidir: bir tıklamayı bir satın alma ile güvenilir şekilde eşleştiremezseniz, alt süreçler (komisyonlar, ödemeler, raporlama) gürültülü olur ve ihtilaflara yol açar.
Çoğu program şu karışımı destekler:
?aff_id=123&campaign=spring). Uygulaması kolaydır ve içerik ortakları için iyi çalışır.ALICE10). Influencerlar ve çevrimdışı paylaşım için kullanışlıdır; link parametreleri kaybolduğunda iyi bir yedek sağlar.Genellikle şunlardan biri tercih edilir:
Aşağıdaki durumlar genellikle “eksik dönüşüm” destek taleplerine yol açar:
order_id ile dedupe yapın.Ürün, mühendislik ve partnerler arasında basit bir sözleşme yazın:
Click (affiliate link) -> Store attribution (cookie + user/profile) ->
Conversion (order created) -> Validate/dedupe -> Create commission ->
Notify partner (optional webhook) -> Appear in partner portal
Bu dokümantasyon hata ayıklama, partner desteği ve gelecekteki entegrasyonlar için referansınız olur.
Komisyon motoru, takip verilerini paraya çeviren “gerçek kaynak”tır. Buna muhasebe gibi davranın: deterministik kurallar, açık statüler ve tam bir denetim izi.
Ne olduğunu ne ödediğinizden ayırarak başlayın. Pratik bir boru hattı şöyle görünür:
Her adımı açıkça saklayın ki destek ekipleri “neden ödenmedi?” sorusuna tahminde bulunmadan cevap verebilsin.
Gerçek programlar düzeltmelere ihtiyaç duyar. Destekleyin:
Bunları mümkünse orijinal dönüşüme bağlı ayrı defter girdileri olarak modelleyin; tarihçeyi düzenlemek yerine. Bu raporları tutarlı ve denetlenebilir kılar.
Afiliye takibi aynı dönüşümü tekrar gönderebilir. Gerektirilenler:
Benzersizliği veritabanı düzeyinde zorunlu kılın ve reddedilen kopyaları hata ayıklama için kaydedin.
Belirleyin ve belgeleyin:
Bu kuralları koda ve partner portalı UI'sine yazın ki ortaklar ihracatlar, faturalar ve ödemeler arasında tutarlı matematik görsün.
Ödemeler ortağınız için programınızı “gerçek” kılar—bu yüzden deneyim öngörülebilir, denetlenebilir ve desteklemesi kolay olmalı. v1'de basit başlayın, ama daha fazla ödeme yöntemi ve kontrol ekleyebilmek için iş akışını yeniden yazmadan genişletilebilir tasarlayın.
Ne sıklıkla ödeyeceğinize karar verin (haftalık veya aylık), sonra iki ana kontrol ekleyin:
Bu kuralları partner portalında görünür yapın ki ortaklar bir dönüşümün neden “onaylandı ama henüz ödenebilir değil” olduğunu anlasın.
İlk sürüm için operasyonel olarak basit kanalları seçin:
Hangi yolu seçerseniz seçin, ücretleri ve para birimi kısıtlarını açıkça modelleyin. Başta tek para birimi destekleseniz bile ödeme düzeyinde para birimi saklamak gelecekteki geçişleri kolaylaştırır.
Ödemeleri şu durumları geçiren partiler olarak ele alın:
draft → approved → processing → completed
“Draft” sistemin uygun komisyonları topladığı aşamadır. “Approved” insan onayıdır. “Processing” ödemeleri başlattığınız aşamadır (veya finansa talimat gönderdiğiniz). “Completed” kilitli, değişmez toplamlar ve zaman damgaları içerir.
Şunları sağlayın:
Bu, destek taleplerini azaltır ve ortaklara komisyon yönetiminizin tutarlı olduğunu gösterir.
Afiliye platformları para, kimlik ve performans verilerini tutar—bu yüzden güvenlik bir eklenti değil ürünün bir parçasıdır. Açık kurallar, mantıklı varsayılanlar ve sıkı erişim uygulayın.
Programı yürütmek için gerekli asgari verilerle başlayın:
Uyumluluk için gerçekten gerekiyorsa belgeler, adres veya telefon numarası istemekten kaçının. Daha az veri daha az risk ve daha az destek sorunu demektir.
Ödemelere bağlı her şey yüksek derecede hassas kabul edilmelidir:
Ayrıca analitik ihracatlarının yanlışlıkla ödeme detaylarını içermediğinden emin olun—“performans raporlama”yı “finans operasyonları”ndan ayırın.
Rol tabanlı erişim kontrolü ekiplerin verimli çalışmasını sağlar ancak fazla paylaşımı engeller.
Pratik bir bölünme:
Varsayılan olarak en az ayrıcalık prensibini uygulayın ve her hassas eylemde izin kontrolleri yapın (sadece UI'de değil).
Çekirdek stabil hale geldikten sonra şu kontrolleri ekleyin:
Bu adımlar hesap ele geçirme riskini azaltır ve denetimleri kolaylaştırır.
Dolandırıcılık kontrolleri ilk günden itibaren afiliye programınızın bir parçası olmalı, sonradan eklenmemeli. Amaç ortakları suçlamak değil—ödemeleri korumak, performans verilerini güvenilir tutmak ve onayları tahmin edilebilir kılmaktır.
Birkaç temel sinyalle çok sayıda suistimali yakalayabilirsiniz:
Eşikleri program bazında ayarlanabilir tutun (yeni ortaklar geçmiş oluşana kadar daha sıkı kurallara tabi olabilir).
Dönüşümleri anında reddetmek yerine bir inceleme kuyruğu oluşturun. Kurallar tetiklendiğinde olayları işaretleyin (ör. “aynı IP'den 2 dakika içinde 3+ dönüşüm”, “tipik değerlerin çok üstünde sipariş değeri”, “yeni hesap + yüksek hacim”). İnceleyen kişi şunları görmeli:
Bu yanlış negatifleri azaltır ve savunulabilir kararlar sunar.
Takip, sahte trafik için mıknatıs gibidir. Aşağıkileri ekleyin:
İhtilaflar olacaktır. Her hold veya reddetme için açık bir “neden” saklayın (kural adı, eşik, veri noktaları). Partner portalında görünen kısa bir neden destek taleplerinin tartışmaya dönüşmesini engeller ve dürüst ortakların sorunları hızlıca düzeltmesine yardımcı olur.
Raporlama afiliye programı yazılımının güven kazanmasını sağlar. Ortaklar “ne oldu” bilmek ister; yöneticiler ise “ne yapmalı”yı. Başlangıçta hem soruları yanıtlayan küçük bir metrik setiyle başlayın.
En azından takip edin ve gösterin:
Tanımları araç ipuçlarında görünür tutun ki herkes sayıları aynı şekilde yorumlasın.
Yöneticiler kontrol paneli görünümü ister: zaman içindeki eğilimler, en iyi ortaklar, en iyi kampanyalar ve tıklama/approval oranında anormallikler için uyarılar.
Ortaklar daha basit özetler ister: kendi tıklamaları, dönüşümleri, kazançları ve beklemede vs onaylanmış olanlar. Statülerin ne anlama geldiğini açıkça gösterin ki destek talepleri azalsın.
Her rapor şu filtrelerle sadeleştirilebilmeli:
Filtreler değiştiğinde toplamlar ve grafikler birlikte güncellenmeli—çakışan sayılar güveni hızla zedeler.
CSV ihracatları faydalıdır, ama MVP'yi yavaşlatmasın. İhracatlar ve zamanlanmış e‑posta raporları ikinci aşama özelliği olarak ekleyin.
Mimarinizi doğru seçmek, afiliye takibi ve ödemelerinin hacim arttıkça güvenilir kalıp kalmayacağını belirler. Amaç “mükemmel” yığın değil—ekibinizin işletip, hata ayıklayıp, korkmadan genişletebileceği bir yığın seçmektir.
Ekip zaten deneyimli olduğu ana akım web çerçevesini seçin (Rails, Django, Laravel, Express/Nest, ASP.NET). Çoğu afiliye yazılımı için ilişkisel veritabanı (PostgreSQL/MySQL) en güvenli varsayılandır; çünkü komisyon yönetimi tutarlı işlemler ve denetlenebilir geçmiş gerektirir.
Barındırma AWS/GCP/Azure veya yönetilen platformlar (Render/Fly/Heroku‑benzeri) olabilir. Yenilikten çok izlenebilirliği (logs, metrics, tracing) önceliklendirin—partnerler “neden bu dönüşüm sayılmadı?” diye sorduğunda buna ihtiyacınız olacak.
Eğer ürün şeklini hızlıca doğrulamak istiyorsanız (partner portal + admin konsolu + temel iş akışları) vibe‑kodlama platformu olarak Koder.ai prototipleme, planlama modu ve kaynak kod dışa aktarma ile size yardımcı olabilir. Bu, gereksinimler haftalık değişirken hızlı geri bildirim almak için özellikle faydalıdır.
En azından ayırın:
Takip uç noktalarını hafif tutmak promosyonlar ve e‑posta patlamaları gibi trafik artışlarının tüm portalı düşürmesini engeller.
Afiliye takibi sıkça zenginleştirme ve dedupe gerektirir. Pahalı görevleri kuyruk arkasına (SQS/RabbitMQ/Redis queues) koyun:
Çoğu ekip en azından şuna ihtiyaç duyar:
Her entegrasyonun hata modlarını (hız limitleri, tekrarlar, idempotentlik) belgeleyin. Sistemler düzgün çalışmadığında afiliye analitiğinin güvenilir kalmasını sağlayan bunlardır.
Test ve operasyonlar afiliye platformlarını ya güvenilir kılar ya da destek biletleri üreten sistemlere dönüştürür. Para işin içine girdiği için sadece çalıştığından emin olmak yetmez; gerçek ortaklar, gerçek trafik ve kenar durumlar geldiğinde de çalışmaya devam ettiğinden emin olmalısınız.
Bakiye değiştiren mantık etrafında testlere öncelik verin. İyi bir temel:
Bu testleri deterministik tutun: sabit zaman damgaları ve bilinen döviz kurları (veya FX stub'ları) kullanın ki sonuçlar dalgalanmasın.
Sadece “mutlu yol” verisi içeren bir staging yetersizdir. Beklenen gerçek program senaryolarını tohumlayın:
Bu veri setini destek iş akışlarını prova etmek için kullanın: bir komisyonun neden gerçekleştiğini açıklayabiliyor musunuz ve denetlenebilir bir şekilde düzeltme yapabiliyor musunuz?
Yayından önce izleme ekleyin, sonra değil. En azından:
Ayrıca arama yapabilen ID'lerle önemli olayları (dönüşüm oluşturuldu, komisyon onaylandı, ödeme gönderildi) kaydedin.
Pratik bir yayın kontrol listesi şunları içermelidir: program kuralları finalize edilmiş, test ödemeleri uçtan uca çalıştırılmış, e‑posta şablonları gözden geçirilmiş, partner onboarding metinleri yazılmış ve geri alma planı hazır.
v2 için basit bir yol haritası öğrenimlerinize dayanmalı: daha iyi dolandırıcılık sinyalleri, zenginleştirilmiş raporlama ve operasyonel manuel müdahaleyi azaltan yönetici araçları. Dokümantasyonunuz varsa partner portalından erişilebilir hale getirin ve sürümlü tutun (ör. /docs/affiliate-guidelines).
Başına 3–5 “günlük hayat” senaryosu yazın (admin/partner yöneticisi, finans/operasyon, ortak). Sonra bunları v1 döngüsüne çevirin:
Bu döngüyü desteklemeyen her şey “sonra” kategorisine gider, popüler olsa bile.
Tek sayfalık kapsam yazın:
Orta seviyede istek geldiğinde bunu karar filtresi olarak kullanın.
v1 için bir modeli seçin:
Tabanın net ödenen tutar olduğunu ve iade/chargeback durumlarının nasıl ele alınacağını açıkça belgeleyin. Emin değilseniz net ödenen tutar üzerine kurun ve iadeleri sonra çıkarın.
Bir atıf kuralı seçin ve bunu net ifadeyle uygulayın:
Sonra kupon kullanımı, affiliate tıklamasından sonra ücretli reklamların gelmesi veya eksik parametreler gibi kenar durumları belgeleyin. Net “kredi verme kuralları” destek yükünü, ekstra özelliklerden daha çok azaltır.
Asgari seti modelleyin:
Paylaşılan durumları erken tanımlayın (ör. , ayrıca ve ). Tıklamalar/dönüşümler için değişmez, sabit ID'ler saklayın ki raporlama yeniden hesaplamalarda bozulmasın.
Karışımı kullanın, ama bir kaynak seçin:
Ayrıca dedupe için /, eksik parametrelerde promo kod veya sunucu tarafında saklanan yönlendiriciye geri dönüş planlayın ve gizlilik kısıtlamalarını göz önünde bulundurun (PII'yi azaltın).
Komisyonları bir muhasebe defteri gibi ele alın: belirgin bir boru hattı oluşturun:
Düzeltmeleri birinci sınıf olarak destekleyin (bonuslar, cezalar, ters işlemler) ve bunları orijinal dönüşüme bağlayın. Veritabanı düzeyinde idempotentlik sağlayın ki webhook tekrarları çoğaltmasın.
Basit ve denetlenebilir tutun:
Ödemeleri taslak → onaylı → işleniyor → tamamlandı olarak modelleyin. Ortak portalında tarih aralığı, kalemler, düzenlemeler ve ödeme referansı gösteren makbuzlar sağlayın.
Sadece gerekli verileri toplayın:
Hassas alanları şifreleyin, gizli anahtarları bir secrets manager’da tutun ve mümkünse tokenizasyon tercih edin. Analitik ihracatlarına ödeme detaylarının karışmadığından emin olun—performans raporlamasını finans operasyonlarından ayırın.
Yüksek sinyalli, açıklanabilir kontrollerle başlayın:
Otomatik reddetme yerine işaretle ve incele modelini kullanın. Her hold/red kararına kısa bir sebep kodu ekleyin ve izleme ile kanıtları gösterin.
order_idevent_id