Partner tıklamalarını, dönüşümleri ve geliri izleyen bir web uygulamasının nasıl tasarlanıp inşa edileceğini öğrenin. Veri modeli, takip, raporlama, ödemeler ve gizlilik konularını kapsar.
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.
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:
Bu tanım gereksinimlerinizin, veri modelinizin ve ileride çözmeniz gereken itirazların temelini oluşturur.
“Partner” genellikle farklı beklenti ve iş akışlarına sahip birkaç grubu içerir:
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.
Pratik bir partner gelir atama web uygulaması güvenilir şekilde dört çıktıyı sağlamalıdır:
Bu alanlardan herhangi biri zayıfsa, partnerler rakamlara güvenmez—matematik doğru olsa bile.
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:
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.
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.
Ç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:
UI ve raporlarınızın desteklemesi gereken düz dilde sorguları yazı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.
Ö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.
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.
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.
Ç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:
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)?
Ne atayacağınıza karar verin: sadece ilk satın alma mı, yoksa zaman içinde net gelir 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.
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.
partner_id, durum, ödeme koşulları, varsayılan para birimi saklayın.campaign_id, başlangıç/bitiş tarihleri.link_id, partner_id'ye ve isteğe bağlı olarak campaign_id'ye ait.click_id, link_id ve partner_id referans eder.visitor_id (çoğunlukla birinci taraf cookie ID'sinden türetilir).conversion_id, click_id (varsa) ve visitor_id referans eder.order_id, customer_id'ye referans ve conversion_id ile bağlantılı.payout_id, partner_id'ye referans ve uygun siparişleri toplar.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.
Siparişler değişir. Bunu açıkça modelleyin:
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.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.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 partner gelir atamasının temelidir: her partner linki kalıcı bir “click kaydı” oluşturmalı ki daha sonra dönüşüme bağlanabilsin.
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:
Tüm partner trafiğini bir redirect uç noktasından (ör. /r/{partner_id}) geçirin:
Bu, click oluşturmayı tutarlı kılar, partnerlerin click ID'yi sahtelemesini önler ve kural uygulamayı merkezileştirir.
Çoğu ekip cookie'yi birincil, localStorage'ı yedek ve sunucu tarafı oturumları sadece kısa akışlar için kullanır.
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:
Link kurallarını partner portalında belgeleyin (ör. "/blog/partner-links") ki partnerler parametrelerle aşırı yaratıcı davranması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.
Çoğu ürün dönüşümleri birkaç yerden gözlemleyebilir:
Ö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.
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:
Birincil join şu olmalıdır: conversion.click_id → click.id. Eğer click_id eksikse, açık yedek kurallar tanımlayın:
Bu yedekleri yönetici aracında görünür kılın ki destek ekipleri sonuçları tahmin etmeden açıklayabilsin.
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)payment_provider_charge_idDö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.
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.
Pratik bir yaşam döngüsü şöyle görünü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.
Sistemde “gelir”in ne anlama geldiğine karar verin ve bunu açıkça saklayın:
Sabit bir politika zorlamadan destekleyebileceğiniz yaygın yapı:
Finans ekipleri mutabakat edebilecekleri verilere ihtiyaç duyar:
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.
Günlük olarak partnerlerin sorduğu soruları cevaplayan küçük ekran setiyle başlayın:
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ı.
Partnerler ve yöneticiler sonuçları hızlıca dilimlemek ister; dışa aktarmaya ihtiyaç olmadan şu filtrelere öncelik verin:
Birden fazla ürün veya plan izliyorsanız, temel işler stabil olduktan sonra ürün filtresi ekleyin.
Admin araçları hız ve hesap verebilirliğe odaklanmalı:
Manuel kontrolleri sınırlı tutun: operatörlerin istisnaları düzeltmesi, geçmişi rastgele yeniden yazmaması gerekir.
İlk günden RBAC uygulayın:
İ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.
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.
Çalışır bir temel olarak Postgres + bir API + modern frontend yeterlidir:
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.
Ağ istek/yanıt döngüsünde pahalı işleri yapmayın. Kuyruk (SQS/RabbitMQ/Redis queues) ve worker'lar kullanın:
Worker'lar idempotent olmalı: bir iş iki kez çalışırsa sonuçlar doğru kalmalı.
Tıklama tabloları hızla büyür. Saklama politikasını baştan planlayı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.
Takip hataları sessiz kalırsa fark edilmez. Şunları ekleyin:
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 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.
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.
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.
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.
Aşağılar için değiştirilemez denetim izi tutun:
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.
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.
Atama ve mutabakat için gerekli minimum veri setinden başlayın:
Toplamadan kaçının:
Cookie veya benzeri tanımlayıcıları kullanıyorsanız, bölgeye göre onay gerekebilir.
Pratik yaklaşım sunucu tarafı takibi (postback) desteklemek ve istemci tarafı cookie'leri sadece izin verildiğinde kullanmaktır.
Atama ve ödeme verilerini hassas iş verisi olarak ele alı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'lar kazara veri sızıntısına yol açabilir. Log kurallarını açıkça belirleyin:
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.
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.
Uçtan uca tekrar oynatılabilecek küçük bir “golden” senaryo setiyle başlayın:
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.
Küçük bir partner grubuyla pilot başlatın (5–10 partner). Pilot sırasında:
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".
Partner gelir ataması, hangi partnerin bir gelir olayına kredi alacağını (ve ne kadar alacağını) belirleyen kurallar ve verilerin tümüdür; kanıtlar arasında click_id'ler, kupon kodları ve zaman pencereleri bulunur.
Yararlı bir tanım şunları içerir:
Önce bir cümlelik bir politika yazın, sonra istisnaları listeleyin.
Güçlü bir V1 politikası genellikle şöyledir:
Sonra kupon önceliği, yenilemeler ve doğrudan trafik gibi istisnaları belgeleyin.
En azından şunları izleyin:
Daha sonra lead veya denemeler eklense bile, bu üçü trafik → gelir → terslemeleri bağlamak için yeterlidir.
Bir yönlendirme uç noktası kullanın (ör. /r/{partner_id}) ve şu adımları uygulayın:
Bu, partnerlerin click_id sahtekârlığını önler ve takibi tutarlı hale getirir.
En güvenilir kaynak olarak sunucu tarafı sipariş oluşturmayı tercih edin.
Pratik olarak:
click_id(veya attribution token)ı sipariş oluşturma sırasında siparişe ekleyinBu, çift tetiklenmeleri azaltır ve finansal mutabakatı kolaylaştırır.
Tekrar denemelerin kopya dönüşümler oluşturmasını önlemek için idempotency anahtarları kullanın.
Yaygın anahtarlar:
order_id (küresel olarak benzersizse en iyisi)payment_provider_charge_idVeritabanında benzersiz kısıtlama uygulayın. Tekrarlar geldiğinde başarı döndürün ama ikinci bir dönüşüm veya komisyon satırı oluşturmayın.
Kanıtlanabilir bir uçtan uca zincir için hedefleyin:
partner_id → link_id → click_id → visitor_id → conversion_id → order_id → payout_idHem dahili hem harici ID'leri (ör. shopify_order_id) saklayın ve created_at, ingested_at gibi zaman damgaları tutun ki anlaşmazlıkları izleyip mutabakat yapabilesiniz.
Parayı denetimlenebilir ve geri alınabilir şekilde modelleyin:
currency_code ekleyinDestek sorularını azaltacak temel ekranlarla başlayın:
Her dönüşüm için kanıt alanları (tıklama zamanı, sipariş ID'si—maskelenmiş, uygulanan kural) gösterin.
Hafif, tutarlı önlemler kullanın:
Gizlilik için minimum veri saklayın, IP gibi hassas sinyalleri hashleyin ve ödeme/veri gizli bilgilerini log'lamayın.
Bu, geçmişi korur ve gerektiğinde sonraki ödeme döngülerinde negatif satırlar oluşturmanıza izin verir.