Partner Gelir Ataması için Web Uygulaması Nasıl Kurulur

Partner Gelir Atamasının Yapması Gerekenler

Partner gelir ataması, basit bir soruyu yanıtlayan sistemdir: hangi partner bir gelir olayına kredi (ve ne kadar) almalı? Bir web uygulamasında bu, sadece tıklamaları saymak değil—partnerin yönlendirmesini daha sonra bir dönüşümle bağlamak, bunu net bir gelir rakamına dönüştürmek ve denetlenebilir kılmaktır.

İşiniz için “partner gelir ataması”nı tanımlayın

Başlangıç olarak (1) neyin atandığını, (2) kime, ve (3) hangi kurallar altında içeren bir cümlelik tanım yazın. Örnekler:

• “Abonelik gelirini, 30 gün içinde yapılan ilk uygun tıklamaya atayın.”
• “İlk ücretli siparişi, kupon-only dönüşümler hariç, partnerin referans linkine atayın.”

Bu tanım gereksinimlerinizin, veri modelinizin ve ileride çözmeniz gereken itirazların temelini oluşturur.

Partner kimleri kapsar, netleştirin

“Partner” genellikle farklı beklenti ve iş akışlarına sahip birkaç grubu içerir:

• Affiliate'ler: yüksek hacim, link tabanlı takip, sık ödemeler.
• Ajanslar: daha az anlaşma, daha uzun satış döngüleri, bazen pazarlıklı koşullar.
• Bayi/yeniden satıcılar: hesabı “sahiplenebilir”, genellikle otomatik ödemeler yerine faturalama gerektirebilir.
• Influencer'lar/creatörler: kodlar, kısa linkler ve mobil-öncelikli raporlamayı tercih edebilir.

Hepsini çok erken tek bir iş akışına zorlamayın. Yine de ortak bir sistem (partnerler, programlar, sözleşmeler) kullanırken birden fazla yönlendirme yöntemini (linkler, kodlar, manuel anlaşmalar) destekleyebilirsiniz.

Desteklemeniz gereken çıktılar

Pratik bir partner gelir atama web uygulaması güvenilir şekilde dört çıktıyı sağlamalıdır:

1. Takip: partner dokunuş noktalarını (tıklamalar, kod kullanımları, referanslar) yakalayın ve bunları dönüşümlere bağlayın.
2. Raporlama: partnerlere ve ekibinize ne olduğunu gösterin—tıklamalar, dönüşümler, gelir ve durum (pending/approved/paid).
3. Ödemeler: komisyonları hesaplayın, bekletmeleri/iade işlemlerini yönetin ve ödeme hazır tablolar üretin.
4. İtirazlar: “neden bu dönüşüm atandı/atanmadı” sorusunu açıklayın; anlaşmazlıkları çözmeye yetecek detayda bilgi verin.

Bu alanlardan herhangi biri zayıfsa, partnerler rakamlara güvenmez—matematik doğru olsa bile.

Bu kılavuz için hedefi belirleyin (ve ilk sürüm için)

Eyleme geçirilebilir bir kılavuzun hedefi atama felsefesini tartışmak değil—çalışan bir sistemi göndermenize yardım etmektir. Gerçekçi bir ilk sürüm şunları yapmalıdır:

• Link/tıklama ID'lerini izleyip kayıt halinde tutmak ve kayıt/ödeme sürecinde sürdürmek
• Mümkünse dönüşümleri sunucu tarafında kaydetmek
• Açık bir atama kuralı uygulamak (basit bir kural bile)
• Partner tarafı raporlama ve iç mutabakat üretmek

Gelişmiş özellikleri (çoklu-dokunuş atama, cihazlar arası eşleme, karmaşık dolandırıcılık skoru) temeller güvenilir ve test edilebilir hale geldikten sonra ekleyin.

Gereksinimler ve Cevaplanması Gereken Temel Sorular

Bir atama modeli veya veritabanı tasarlamadan önce, uygulamanın işletmeye neyi kanıtlaması gerektiğini netleştirin. Partner gelir ataması nihai olarak insanların para ödemeye yetecek kadar güven duyduğu cevaplar setidir.

Kullanıcılarınızı tanımlayın (ve her biri için “başarı” ne demek)

Çoğu ekip önce “partnerler” için inşa eder ve sonra finans veya destek hiçbir şeyi doğrulayamaz. Birincil kullanıcılarınızı ve aldıkları kararları listeleyin:

• Partner (affiliate/referer): atanan dönüşümleri, geliri ve ödeme durumunu görmek ister.
• Pazarlama/Büyüme: hangi partnerlerin performans gösterdiğini ve nereye yatırım yapılacağını bilmek ister.
• Finans: denetlenebilir ödeme hesaplamaları ve gerçek gelirle mutabakat ister.
• Destek/Partner yöneticileri: bir dönüşümün neden atandığını veya atanmamasını açıklamak ister.
• Mühendislik/Veri: güvenilir event'ler, net kurallar ve düşük bakım operasyonu ister.

Uygulamanızın yanıtlaması gereken 5–8 temel soru

UI ve raporlarınızın desteklemesi gereken düz dilde sorguları yazın:

1. Bu siparişi/aboneliği hangi partner (varsa) yönlendirdi?
2. Dönüşümü partnere bağlayan kanıt nedir? (click ID, kupon, referans kodu vb.)
3. Tıklama/lead dönüşüme göre ne zaman gerçekleşti? (izin verilen pencere içinde mi?)
4. Bu dönüşüm komisyona uygun mu? (sadece yeni müşteri, ürün hariçleri, minimum harcama)
5. Komisyon tutarı ve oranı nedir, hangi kural bunu belirledi?
6. Dönüşüm sonradan değişti mi? (iade, chargeback, iptal, downgrade)
7. Belirli bir dönem için her partnerin bize ne borcu var ve ne ödendi?
8. Partner tarafından yönlendirilen dönüşümler diğer kanallarla nasıl karşılaştırılır? (pazarlama raporlaması için)

Yakalamanız gereken event'leri tanımlayın

En azından planlayın: tıklama, lead, deneme başlangıcı, satın alma, yenileme ve iade/chargeback. Hangi event'lerin “komisyonlanabilir” ve hangilerinin destekleyici kanıt olduğu kararını verin.

İlk olarak hangi atama türlerini destekleyeceğinize karar verin

Önce tek bir net kural setiyle başlayın—genellikle konfigüre edilebilir bir pencerede son tıklama (last-touch)—sonra ancak güçlü raporlama ihtiyaçlarınız ve temiz veriniz olduğunda çoklu-dokunuş ekleyin. İlk sürümü açıklaması ve denetlenmesi kolay tutun.

Bir Atama Modeli ve Kurallar Seçin

Herhangi bir koda başlamadan önce “kim kredi alır” ve bu kredinin ne zaman sona erdiğini kararlaştırın. Kuralları önceden belirlemezseniz, her ödeme döneminde kenar durumlar (ve partner şikayetleri) üzerine tartışmak zorunda kalırsınız.

Yaygın atama modelleri (üst düzey)

Son tıklama (Last click) dönüşümden önceki en son partner tıklamasına %100 kredi verir. Basit ve yaygın anlaşılırdır, ancak geç aşama kupon trafiğini fazla ödüllendirebilir.

İlk tıklama (First click) müşteriyi ilk tanıtan partnera %100 kredi verir. Keşif partnerlerini öne çıkarır ama anlaşmayı kapatmaya yardımcı olan partnerleri az ödüllendirebilir.

Lineer (Linear) pencere içindeki tüm nitelikli partner dokunuşlarını eşit olarak böler. “Adil” hissettirebilir ama açıklaması daha zordur ve teşvikleri seyreltebilir.

Zamana göre azalan (Time-decay) dönüşüme daha yakın dokunuşlara daha fazla kredi verir, aynı zamanda erken etkileri de tanır. Orta yol sağlar ama daha fazla matematik ve daha net raporlama gerektirir.

Bir varsayılan seçin, sonra istisnaları belgeleyin

Çoğu dönüşüm için bir varsayılan model seçin (birçok uygulama son tıklama ile başlar çünkü açıklaması ve mutabakatı kolaydır). Sonra destek ve finansın tutarlı şekilde uygulayabilmesi için istisnaları açıkça belgeleyin:

• Kupon kodları: geçerli bir partner kuponunun tıklama geçmişinin yerine geçip geçmeyeceğine, krediyi paylaşıp paylaşmayacağına veya sadece partner tıklamasını da sürdürüyorsa uygulanıp uygulanmayacağına karar verin.
• Direkt trafik: direkt ziyaretlerin zinciri “kırıp kırmadığını” (atanmayı sıfırlama) ya da sadece dokunuş sayılmadığını netleştirin.
• Yenilemeler: tekrar eden abonelik yenilemelerinin orijinal partneri ödemeye devam edip etmeyeceğini, sınırlı süreyle ödeyip ödemeyeceğini veya yeniden etkileşim gerektirip gerektirmeyeceğini kararlaştırın.

Atama pencerelerini ve yeniden etkileşim kurallarını tanımlayın

7 / 30 / 90 gün gibi bir veya birden fazla pencere belirleyin. Pratik bir yaklaşım standart bir pencere (ör. 30 gün) ve gerekirse kupon partnerleri için daha kısa pencerelerdir.

Ayrıca yeniden etkileşim kurallarını tanımlayın: bir müşteri pencere içinde farklı bir partner linkine tıklarsa, krediyi hemen değiştirir misiniz (son tıklama), krediyi böler misiniz yoksa orijinal partneri tutar mısınız (örneğin 24 saatlik “yakın pencere” içinde yeni tıklama olmadıkça)?

Yükseltmeler, düşürmeler, iadeler ve chargeback'lerle başa çıkın

Ne atayacağınıza karar verin: sadece ilk satın alma mı, yoksa zaman içinde net gelir mi?

• Yükseltmeler: tipik olarak komisyonlanabilir; delta üzerinden mi yoksa yeni planın tümü üzerinden mi ödeme yapılacağını belirtin.
• Düşürmeler: genellikle gelecekteki komisyonları azaltır; geçmiş ödemeleri geri alma (claw back) konusunda kural belirleyin.
• İadeler/chargeback'ler: geri alma politikası belirleyin (tam tersini mi yoksa kısmi mi) ve zamanlamasını (hemen mi yoksa bir sonraki ödeme döngüsünde mi).

Bu kuralları kısa bir “Attribution Policy” dokümanına yazın ve partner portalınızda yayınlayın ki sistem davranışı partner beklentileriyle eşleşsin.

Atama için Veri Modelini Tasarlayın

Temiz bir veri modeli “bizce bu partner satışı yönlendirdi” yerine “kanıtlayabiliyoruz, mutabakat yapabiliyoruz ve doğru ödeme yapabiliyoruz” farkı yaratır. Küçük bir çekirdek varlık setiyle başlayın ve ilişkileri değiştirilemez ID'ler aracılığıyla açıkça belirtin.

Çekirdek varlıklar (ve neyi temsil ettikleri)

• Partner: ödeme yaptığınız taraf (yayıncı, influencer, ajans). partner_id, durum, ödeme koşulları, varsayılan para birimi saklayın.
• Campaign: raporlama ve kurallar için gruplayıcı (sezon promosyonu, ürün hattı). Anahtar: campaign_id, başlangıç/bitiş tarihleri.
• Link: partnere verilen izlenebilir URL. Anahtar: link_id, partner_id'ye ve isteğe bağlı olarak campaign_id'ye ait.
• Click: tek bir takip etkileşimi. Anahtar: click_id, link_id ve partner_id referans eder.
• Visitor: oturumlar arasında tanıyabildiğiniz kimlik. Anahtar: visitor_id (çoğunlukla birinci taraf cookie ID'sinden türetilir).
• Conversion: atanan olay (lead, kayıt, satın alma). Anahtar: conversion_id, click_id (varsa) ve visitor_id referans eder.
• Order: para ile ilgili kayıt. Anahtar: order_id, customer_id'ye referans ve conversion_id ile bağlantılı.
• Payout: ne ödemeniz gerektiği ve ne zaman. Anahtar: payout_id, partner_id'ye referans ve uygun siparişleri toplar.

ID'lerin nasıl bağlandığı ("zincir")

Altın yolunuz:

partner_id → link_id → click_id → visitor_id → conversion_id → order_id → payout_id

Tekrarlayan satın alımlar için customer_id'yi order_id ile birlikte tutun (ör. “sadece ilk satın alma” vs “ömür boyu”). Mutabakat için hem dahili hem harici ID'leri (ör. shopify_order_id) saklayın.

Para alanları ve düzeltmeler

Siparişler değişir. Bunu açıkça modelleyin:

• Tutarları küçük birimlerde tamsayı olarak saklayın (ör. cent): gross_amount, tax_amount, shipping_amount, fee_amount, discount_amount.
• currency_code artı bir fx_rate_to_payout_currency (ve oran zaman damgası/kaynağı) ekleyin.
• İadeleri/chargeback'leri order_id'ye bağlı düzeltme satırları (örn. order_adjustment_id, type = partial_refund) olarak temsil edin. Bu denetlenebilir bir geçmiş korur ve toplamları yeniden yazmaktan kaçınır.

Denetlenebilirlik ve veri kalitesi

Her yerde created_at, updated_at, ingested_at, source (web, server-to-server, import) ve değiştirilemez tanımlayıcılar ekleyin.

Hassas kişisel veriler saklamadan dolandırıcılık analizleri için ip_hash ve user_agent_hash gibi hashlenmiş alanlar saklayın. Son olarak, ödeme kararlarının açıklanmasını sağlamak için hafif bir değişiklik günlüğü (entity, entity_id, eski/yeni değerler, aktör) tutun.

Tıklama Takibi ve Partner Linklerini Uygulayın

Tıklama takibi partner gelir atamasının temelidir: her partner linki kalıcı bir “click kaydı” oluşturmalı ki daha sonra dönüşüme bağlanabilsin.

Net bir link yapısı tanımlayın (ve tahmin edilebilir tutun)

Partnerin kopyalayıp yapıştırabileceği tek bir kanonik link formatı kullanın. Çoğu sistemde partnere gösterilen link click_id içermemelidir—sunucunuz bunu üretir.

Temiz bir desen:

/r/{partner_id}?campaign_id=...&utm_source=...&utm_medium=partner&utm_campaign=...

Pratik parametre rehberi:

• partner_id: zorunlu; tıklamanın birincil sahibi.
• campaign_id: isteğe bağlı ama önerilir; teklifleri, yerleşimleri veya promosyonları ayırır.
• utm_*: analytics araçları ve pazarlama raporlaması için tutun. Bunları doğruluk kaynağı değil, metadata olarak değerlendirin.

Sunucu tarafı yönlendirme (redirect) ile takip tercih edin

Tüm partner trafiğini bir redirect uç noktasından (ör. /r/{partner_id}) geçirin:

1. Gelen isteği alın ve parametreleri okuyun.
2. Benzersiz bir click_id (UUID/ULID) oluşturun ve bir click satırı sunucu tarafında saklayın (partner_id, campaign_id, user agent, IP hash, timestamp, landing URL).
3. Bir birinci taraf cookie (ve isteğe bağlı olarak localStorage) içine click_id koyun.
4. 302 ile nihai iniş sayfasına yönlendirin.

Bu, click oluşturmayı tutarlı kılar, partnerlerin click ID'yi sahtelemesini önler ve kural uygulamayı merkezileştirir.

Cookie vs localStorage vs sunucu tarafı oturumları

• Cookies: her istekte gönderilir; sunucu tarafı eşleme için en uygunu. Tarayıcılar ve onay kuralları tarafından engellenebilir veya kısıtlanabilir.
• localStorage: sayfa içinde kalıcıdır ancak otomatik olarak sunucuya gönderilmez; istemci tarafında okunması gerekir.
• Sunucu tarafı oturum depolama: tarayıcı oturum tanımlayıcısı tuttuğunda çalışır; kısa pencereler için iyidir, uzun atama pencereleri için zayıftır.

Çoğu ekip cookie'yi birincil, localStorage'ı yedek ve sunucu tarafı oturumları sadece kısa akışlar için kullanır.

Mobil ve uygulamadan web'e dikkat

Mobil web için cookie'ler daha az güvenilir olabilir; bu yüzden redirect uç noktasını kullanın ve click_id'yi hem cookie hem localStorage içinde saklayın.

App-to-web senaryoları için destekleyin:

• Deep link'ler (partner bağlamıyla uygulamayı açma).
• Deferred attribution temelleri: uygulama yüklü değilse web/app store'a yönlendirip, ilk uygulama başlatmasında orijinal click_id ile takası yapılacak kısa ömürlü bir token geçirin.

Link kurallarını partner portalında belgeleyin (ör. "/blog/partner-links") ki partnerler parametrelerle aşırı yaratıcı davranmasın.

Dönüşümleri Güvenilir Şekilde Yakalayın

Dönüşüm takibi, atama sistemlerinin ya güven kazandığı ya da sessizce güven kaybettiği yerdir. Hedefiniz gerçek bir satın alma (veya kayıt) için tek, kanonik bir “dönüşüm” event'i kaydetmek ve partner tıklamasıyla bağlamak için yeterli bağlamı sağlamaktır.

Dönüşüm kaynaklarını seçin (ve kanonik bir kaynağı tercih edin)

Çoğu ürün dönüşümleri birkaç yerden gözlemleyebilir:

• Checkout “thank you” sayfası (istemci tarafı): uygulaması kolay, fakat engellenebilir, düşebilir veya iki kere tetiklenebilir.
• Backend sipariş servisi (sunucu tarafı): sistemin kayıt defteri olduğu için en güvenilir kaynaktır.
• Ödeme sağlayıcı webhook'ları (sunucu tarafı): ödeme doğrulaması asenkron olduğunda (ör. 3DS, banka transferleri) faydalıdır; tekrarları yönetmelisiniz.

Öneri: backend sipariş servisini kanonik dönüşüm kaydedicisi olarak ele alın ve ödeme webhook'larını doğrulama/güncelleme sinyali (ör. pending → paid) olarak kullanın. İstemci tarafı event'leri hata ayıklama veya funnel analitiği için kullanılabilir, ödeme-düzeyinde atama için değil.

Dönüşümleri sunucu tarafında kaydedin (ve atama bağlamını saklayın)

Geliri sonra atamak için, dönüşüm event'inin stabil bir ID'si olmalı ve bir tıklamaya bağlanma yolu bulunmalıdır.

Yaygın yaklaşım:

1. Birisi partner linkiyle geldiğinde bir click_id oluşturup/saklayın.
2. Bunu bir birinci taraf cookie içinde ve/veya veritabanınızda oturum/kullanıcıyla ilişkilendirin.
3. Satın alma anında backend, click_id'yi siparişe eklesin (ör. oturum durumu, müşteri kaydı veya istemciden gönderilen imzalı token aracılığıyla).

Dönüşümleri click'lere eşle (açık yedek kurallarıyla)

Birincil join şu olmalıdır: conversion.click_id → click.id. Eğer click_id eksikse, açık yedek kurallar tanımlayın:

• Kullanıcı giriş yaptıysa: kullanıcı için atama penceresi içinde en son uygun click'i kullanın.
• Aksi halde: oturum için en son uygun click'i kullanın.
• Birden fazla click varsa: önceden son tıklama mı kazanır yoksa çoklu-dokunuş mu kullanacağınızı kararlaştırın.

Bu yedekleri yönetici aracında görünür kılın ki destek ekipleri sonuçları tahmin etmeden açıklayabilsin.

Tekrarlamalar ve çoğaltmalarla idempotent şekilde başa çıkın

Webhook'lar ve istemci çağrıları yeniden deneyecektir. Aynı dönüşümü birden çok kez alabilmelisiniz ama çift sayım yapmamalısınız.

Idempotency anahtarları uygulayın; kararlı benzersiz değerler örnekleri:

• order_id (en iyisi, küresel olarak benzersizse)
• veya payment_provider_charge_id

Dönüşüm kaydına anahtarı benzersiz kısıtlama ile saklayın. Yeniden denemede başarı döndürün ve ikinci bir dönüşüm oluşturmayın. Bu, yaygın “hayalet gelir” ödeme hatalarını önler.

Gelir Hesaplama, Mutabakat ve Ödeme Mantığı

Burada takip paraya dönüşür. Uygulamanız bir izlenen olaydan ödeyebileceğiniz net bir tutara giden, denetlenebilir bir yol sağlayacak—ayrıca finansın geliri ölçme biçimiyle uyumlu kalacaktır.

Temel uçtan uca akış

Pratik bir yaşam döngüsü şöyle görünür:

1. Click: partner + click ID ve kampanya bağlamını saklarsınız.
2. Beklemede dönüşüm: dönüşüm kaydedilir, bir click/partnere atanır ama henüz kesin değildir (örn. iade penceresi içinde).
3. Onaylı dönüşüm: doğrulama kontrolleri ve onay kurallarından sonra dönüşüm “kilitlenir”.
4. Ödemeye uygun gelir: onaylı dönüşümler bir ödeme dönemine dahil edilir ve ödeme almaya hak kazanır.

Her durum değişikliği için zaman damgalarını tutun ki bir dönüşümün ne zaman ve neden ödemeye uygun hale geldiğini açıklayabilesiniz.

Gelir matematiği: brüt vs net, abonelikler ve düzeltmeler

Sistemde “gelir”in ne anlama geldiğine karar verin ve bunu açıkça saklayın:

• Brüt vs net: brüt tahsil edilen tutardır; net indirimler, vergiler, kargo, ücretler düşüldükten sonraki tutardır (uygulananı seçin ve tutarlı olun).
• İadeler ve chargeback'ler: bunları orijinal dönüşüme bağlı düzeltmeler olarak modelleyin. Onay sonrası iade olursa bir sonraki ödeme döngüsünde negatif satır oluşturabilirsiniz.
• Abonelik yenilemeleri: her yenilemeyi politika izin veriyorsa orijinal müşteri ve partnerle bağlantılı yeni bir dönüşüm olarak ele alın veya atamayı tanımlı bir süreyle sınırlayın.

Ödeme takvimleri ve eşikler (seçenekler)

Sabit bir politika zorlamadan destekleyebileceğiniz yaygın yapı:

• Takvimler: aylık, iki haftada bir, haftalık veya “onaydan X gün sonra” gibi kayan yöntemler.
• Eşikler: minimum ödenebilir bakiye (ör. partner belirli bir tutara ulaşana kadar ödeme yapmayın).
• Bekletme süreleri: iade riskini azaltmak için N gün gecikme.

Finans için ihracatlar ve denetlenebilirlik

Finans ekipleri mutabakat edebilecekleri verilere ihtiyaç duyar:

• CSV ihracatları: dönüşümler, düzeltmeler ve ödeme özetleri.
• API erişimi: muhasebe sistemlerine ödemeleri ve kalemleri çekmek için.
• Ledger tarzı raporlar: her finansal olay için bir satır (onay, iade, chargeback, ödeme) ve kaynak dönüşüme referans veren değiştirilemez ID'ler.

Partner Portalı ve Admin Panosunu Oluşturun

Bir partner programı güven üzerine kurulur veya çöker. Portalınız partnerlerin tıklamaların dönüşümlere ve dönüşümlerin paraya dönüştüğünü doğruladığı yerdir. Admin panonuz programı temiz, hızlı ve adil tutmak için ekibinizin kullandığı yerdir.

Partner portalı temel öğeleri

Günlük olarak partnerlerin sorduğu soruları cevaplayan küçük ekran setiyle başlayın:

• Link al: her partner için referans link(ler), desteklenen UTM şablonları ve gerekli parametreleri gösterin. Kopyalamayı kolaylaştırın.
• Performans özeti: zaman içinde tıklamalar, dönüşümler ve atanan gelir için basit bir grafik; top kampanyalar.
• Dönüşüm listesi: durum ve zaman damgalarıyla bir tablo; partnerin denetleyebilmesi için.
• Ödeme durumu: kazanç özeti (pending, approved, paid), ödeme geçmişi ve bir sonraki ödeme tarihi.

Dönüşüm listesi için destek taleplerini azaltacak sütunları ekleyin: dönüşüm zamanı, sipariş ID (maskelenmiş), atanan tutar, komisyon oranı, durum (pending/approved/rejected/paid) ve reddedildiğinde kısa bir “neden” alanı.

Gerçekten işe yarayan filtreler

Partnerler ve yöneticiler sonuçları hızlıca dilimlemek ister; dışa aktarmaya ihtiyaç olmadan şu filtrelere öncelik verin:

• Tarih aralığı (ön ayarlar: son 7/30/90 gün)
• Kampanya (veya link adı)
• Durum (pending/approved/rejected/paid)
• Cihaz (desktop/mobile/tablet)
• Ülke/bölge

Birden fazla ürün veya plan izliyorsanız, temel işler stabil olduktan sonra ürün filtresi ekleyin.

İç yönetici (admin) temel öğeleri

Admin araçları hız ve hesap verebilirliğe odaklanmalı:

• Partner yönetimi: partner oluştur/düzenle, komisyon koşulları ayarla, ödeme yöntemini ata, aktiflik durumunu değiştir.
• Onaylar ve geçersiz kılmalar: dönüşümleri toplu onayla/reddet, kenar durumlar için sıkı kontrollü geçersiz kılmalar yapma (ör. eksik click ID için destekleyici kanıtla manuel atama).
• Notlar ve denetim izi: her manuel değişiklik kim tarafından, ne zaman ve neden yapıldığını kaydetmeli.

Manuel kontrolleri sınırlı tutun: operatörlerin istisnaları düzeltmesi, geçmişi rastgele yeniden yazmaması gerekir.

Rol tabanlı erişim kontrolü (RBAC)

İlk günden RBAC uygulayın:

• Partnerler sadece kendi linklerini, tıklamalarını, dönüşümlerini ve ödemelerini görebilir.
• Partner yöneticileri sadece sahip oldukları partnerleri görebilir/işleyebilir (bölge/ekip bazlı segmentasyon varsa).
• Finans/admin ödemeleri ve mutabakat detaylarını görebilir.

İzin kontrollerini API katmanında uygulayın (sadece UI'da değil) ve ödeme ihracatları gibi hassas görünümlere erişimi loglayın.

Mimari ve Ölçeklenebilirlik Düşünceleri

Partner gelir atama uygulaması genellikle "yazma-ağırlıklı"dır: çok sayıda tıklama, dönüşüm event'i ve periyodik raporlama okuma yükü vardır. Önce yüksek hacimli ingest için tasarlayın, sonra raporlamayı agregasyonla hızlı hale getirin.

Pratik, esnek bir stack

Çalışır bir temel olarak Postgres + bir API + modern frontend yeterlidir:

• Postgres işlemsel gerçeklik için (partnerler, kurallar, dönüşümler, ödemeler).
• API servisi (Node/TypeScript, Python, Go—hangi dil olursa) eventleri alır ve raporlama uç noktaları sunar.
• Frontend (Next.js/React, Vue vb.) partner portalı ve admin için.

Takip uç noktalarını stateless tutun, böylece yük dengeleyici arkasında yatay ölçeklenebilir.

Eğer hızlıca dahili araç prototipine geçmek isterseniz, Koder.ai admin dashboard, partner portalı ve temel API'leri chat tabanlı “vibe-coding” ile prototiplemenize yardımcı olabilir. Planning Mode'u kullanarak izleme → atama → ödemeler akışını tasarlayabilir, React frontend ve Go + PostgreSQL backend üretebilir ve üretime geçmeye hazır olduğunuzda kaynak kodunu dışa aktarabilirsiniz.

Yavaş yol için arka plan işleri

Ağ istek/yanıt döngüsünde pahalı işleri yapmayın. Kuyruk (SQS/RabbitMQ/Redis queues) ve worker'lar kullanın:

• Webhook teslimi ve tekrarları
• Mutabakat (içe aktarılan sipariş/iadelerin önceden izlenen dönüşümlere eşlenmesi)
• Rapor üretimi (günlük rollup'lar, CSV dışa aktarımlar, “son 30 gün” özetleri)

Worker'lar idempotent olmalı: bir iş iki kez çalışırsa sonuçlar doğru kalmalı.

Tıklamalar için veri saklama ve partitioning

Tıklama tabloları hızla büyür. Saklama politikasını baştan planlayın:

• Ham click'leri kısa bir pencere (örn. 30–90 gün) için tutun; bu genellikle itiraz çözümü için yeterlidir.
• Agregatlar (günlük partner/kampanya toplamları) daha uzun süre saklayın.

Postgres'te click'ler için zaman temelli partitioning (aylık partition) ve (occurred_at, partner_id) ile indeksleme düşünün. Partitioning vacuum/index bakımını iyileştirir ve eski partition'ları atarak saklamayı kolaylaştırır.

Atama hatalarını yakalayacak gözlemlenebilirlik

Takip hataları sessiz kalırsa fark edilmez. Şunları ekleyin:

• Event drop rate: alınan istek vs. saklanan event; doğrulama nedeniyle reddedilen %.
• Gecikme: click ingest ve conversion ingest uç noktaları için p95/p99.
• Webhook hataları: hata oranı, yeniden deneme sayısı, teslim süresi, dead-letter hacmi.

Tutarlı bir korelasyon ID'si (örn. click_id/conversion_id) ile log'layın ki destek partner iddiasını uçtan uca izleyebilsin.

Dolandırıcılık Önleme ve Veri Kalitesi

Dolandırıcılık kontrolleri sadece kötü niyetli aktörleri yakalamak için değil—aynı zamanda gürültülü veriler yüzünden dürüst partnerlerin eksik ödenmesini önlemek için de gereklidir. İyi bir yaklaşım otomatik korumalar (hızlı, tutarlı) ile insan incelemesini (esnek, bağlamsal) birleştirir.

Planlamanız gereken yaygın suistimal desenleri

Kendi kendine yönlendirmeler (self-referrals) partnerlerin kendi satın almalarından komisyon kazanmaya çalışmasıdır (ödeme parmak izleri, e-posta veya cihaz sinyalleriyle tespit edilebilir).

Cookie stuffing ve tıklama spam'i kullanıcıyı gerçek niyet olmadan “iddia etmeye” çalışır—ör. görünmez iframe'ler, zorla yönlendirmeler veya neredeyse sıfır etkileşimle yüksek tıklama hacmi.

Sahte lead'ler CPA ödemenizi tetiklemek için düşük kaliteli form gönderimleridir. Kupon sızıntısı özel bir kodun genel paylaşılmasıyla gerçek kaynağı bulanıklaştırır.

Erken dönemde değer getiren temel savunmalar

Partner/IP/rate limitleri uygulayın ve bot tespit sinyalleri ekleyin: user-agent anormallikleri, JavaScript çalışmama sinyalleri, tutarsız zamanlamalar, datacenter IP'leri, tekrar eden cihaz parmak izleri.

Basit eşiklerle anomali uyarıları ekleyin: “hafta bazında dönüşüm oranı 5× artışı” veya “birçok dönüşümde aynı metadata” gibi. Uyarılar yönetici panosunda detaylı bir drill-down'a bağlanmalı (ör. "/admin/partners/:id/attribution").

Veri kalitesi için ingest sırasında doğrulama yapın. Gerekli yerlerde click ID veya imzalı partner token isteyin, hatalı UTM'leri reddedin ve ülke/para birimi alanlarını normalize edin. Birçok soruşturma eksik loglar veya belirsiz join'ler yüzünden tıkanır.

Manuel inceleme iş akışları

Operatörlere net bir queue verin: bayraklar (sebep + şiddet), notlar ve ilgili tıklamalar/dönüşümlerin zaman çizelgesi.

Şüpheli event'lerin hemen ödemeye girmemesi için dönüşüm tutma (“pending”) uygulayın. Partner uyarıları ve yükseltme (geçici ödeme gecikmeleri, trafik kısıtlamaları veya programdan çıkarma) sağlayın; eylemleri şablonlarla tutarlı hale getirin.

Güven ve uyumluluk için denetim izleri

Aşağılar için değiştirilemez denetim izi tutun:

• Atama kural değişiklikleri (ne değişti, kim değiştirdi, ne zaman)
• Ödeme ayarlamaları ve geri alımlar (gerekçe dahil)
• Geçersiz kılmalar (manuel yeniden atama veya istisna işlemleri)

Bu, partner itirazları, finans mutabakatı ve iç hesap verebilirlik için kritiktir—özellikle birden fazla kişinin kuralları ve ödemeleri değiştirebildiği durumlarda.

Gizlilik, Güvenlik ve Uyumluluk Temelleri

Partner gelir ataması takip, kimlik ve ödemelerle ilgilidir—küçük hatalar büyük risk yaratabilir. Amaç yönlendirmeleri ölçmek ve ödemeleri hesaplamakken olabildiğince az kişisel veri toplamak ve sakladığınız verileri korumaktır.

Gerçekte hangi verilere ihtiyacınız var (ve hangilerine yok)

Atama ve mutabakat için gerekli minimum veri setinden başlayın:

• Partner tanımlayıcıları: partner_id, campaign_id ve oluşturulmuş click_id.
• Event zaman damgaları: click_time ve conversion_time.
• Atama bağlamı: iniş sayfası, yönlendiren domain (path/query'leri kırparak tutmayı düşünün), UTM alanları ve cihaz tipi (isteğe bağlı).
• Sipariş bilgisi: order_id (veya dahili transaction_id), para birimi, net gelir ve iade durumu.

Toplamadan kaçının:

• Tam IP adresleri saklamayın; bunun yerine ülke gibi kaba sinyaller veya hashlenmiş IP (döndürmeli) kullanın.
• Ürün gerekmiyorsa ham kullanıcı tanımlayıcılar (e-posta/telefon) saklamayın.
• Kişisel tanımlayıcılar yerine pseudonim ID'ler (click_id, dahili customer_id) tercih edin.

Onay ve takip düşünceleri

Cookie veya benzeri tanımlayıcıları kullanıyorsanız, bölgeye göre onay gerekebilir.

• Cookie banner/consent management: izleme için zorunlu olmayan cookie'ler ayarlıyorsanız onay mekanizması entegre edin ve kullanıcının tercihine saygı gösterin.
• Çıkış seçeneği: net bir opt-out yolu sağlayın ve izleme durdurulsun (veya sadece zorunlu sinyallere dönsün).
• Bölgesel gereksinimler: GDPR/UK GDPR, ePrivacy, CCPA/CPRA gereksinimlerini göz önünde bulundurun.

Pratik yaklaşım sunucu tarafı takibi (postback) desteklemek ve istemci tarafı cookie'leri sadece izin verildiğinde kullanmaktır.

Güvenli depolama ve erişim

Atama ve ödeme verilerini hassas iş verisi olarak ele alın:

• İletim sırasında şifreleme (TLS her yerde) ve dinlenmede şifreleme veritabanları/nesne depolama için.
• Gizli yönetimi: API anahtarları, webhook sırları, DB kimlik bilgileri yönetilen bir secrets vault'ta saklanmalı; düzenli döndürülmeli.
• En az ayrıcalık: admin, finans, destek ve partner için ayrı roller; veritabanı erişimini kısıtlayın ve kapsamlı token'lar kullanın.

Ayrıca veri saklama politikasını düşünün: mutabakat ve itiraz için gerekli olduğu sürece ham event'leri tutun, sonra agregat veya silme işlemi uygulayın.

Log hijyeni (kullanıcıları ve işinizi koruyun)

Log'lar kazara veri sızıntısına yol açabilir. Log kurallarını açıkça belirleyin:

• Ham ödeme detaylarını (kart numaraları, banka bilgileri), tam fatura adreslerini veya tam kimlik doğrulama token'larını log'lamayın.
• Hassas sorgu parametrelerini (ör. bireysel kupon kodları, session token'lar) redact edin.
• İç ID'leri (order_id, click_id) loglayın; hassas payload'ları düz metin log'larda değil güvenli depolamada saklayın.

Açık bir gizlilik bildirimi yayınlayın ve veri akışlarınızı belgeleyin. Partnerler izleme nasıl çalışıyor diye sorduğunda, bunu güvenli ve anlaşılır şekilde açıklayabilin.

Test, Lansman ve İterasyon Planı

Bir partner atama sistemi yalnızca partnerlerin güvenini kazanır ve finansın mutabakat yapabildiği sürece faydalıdır. Test ve lansmanı ürünün bir parçası olarak ele alın: kuralları, veri bütünlüğünü ve operasyonel iş akışlarını doğruluyorsunuz—sadece kodu değil.

Otomatikleştirilecek test kontrol listesi

Uçtan uca tekrar oynatılabilecek küçük bir “golden” senaryo setiyle başlayın:

• Atama kuralı birim testleri: son/ilk tıklama seçimi, lookback pencereleri, kupon-vs-tıklama önceliği, partner uygunluğu ve eksik click ID veya çoklu click gibi kenar durumları.
• Webhook replay testleri: Stripe, Shopify, dahili faturalama gibi kaynaklardan gerçek payload'lar yakalayın ve CI'de tekrar oynatın; idempotency, imza doğrulama ve doğru müşteri/sipariş eşlemesini doğrulayın.
• Zaman ve para birimi testleri: timezone sınırları (gece yarısı, DST), yuvarlama kuralları, iadeler/chargeback'ler ve çoklu para birimi dönüşümleri.
• Veri bütünlüğü testleri: benzersizlik kısıtları (conversion_id), negatif ödemeler yok, "atanan gelir" ile "ödeme dayanağı" tutarlılığı.

Kurallar veya kaynaklar değiştiğinde backfill stratejisi

Atama kurallarını değiştirmek geçmiş rakamları değiştirebilir—bunu açıkça planlayın. Ham event'leri (clicks, conversions, iadeler) değiştirilemez tutun, sonra atamayı versiyonlu tablolara yeniden hesaplayın (örn. attribution_results_v1, v2). Büyük geçmişler için günlük/haftalık partiler halinde backfill yapın ve finansin incelemesi için dry-run diff raporu üretin.

Lansman planı

Küçük bir partner grubuyla pilot başlatın (5–10 partner). Pilot sırasında:

• Partner raporlarını finans kayıtlarıyla haftalık karşılaştırın (siparişler, iadeler, net gelir, ödeme tutarları).
• Pilot dönemi için kuralları dondurun; anomalileri düzeltmek yerine kaydedin.
• Partner geri bildirimini toplayın: ne atandı, neden ve ne hariç bırakıldı açık mı?

Güveni bozmadan iterasyon

Değişiklikleri feature flag'ler arkasında yayınlayın, portalda kural versiyonlarını belgeleyin ve kazançları etkileyebilecek değişiklikleri duyurun.

Operasyonel olarak, raporlama ve ödeme mantığı için hızlı rollback faydalıdır. Koder.ai ile hızlı inşa ediyorsanız, snapshot ve rollback üretime hazır bir sürümü tutarken kural kodu ve pano değişikliklerinde güvenli iterasyon sağlar.

Eğer paketleme ve onboarding'i ileride keşfetmek isterseniz, bakınız "/pricing" veya ilgili rehberlere göz atın: "/blog".