ÇALIŞMA DETAYI
Portföy takibi ve analitik
Dağınık işlem kayıtlarını tek pozisyon mantığında birleştirip performans okumasını sadeleştirme çalışması.
Bu çalışma bir ürün tanıtımı değil; belirli bir operasyon problemini nasıl ele aldığımın özeti.
Başlangıç noktası
Manuel takipte en sık görülen sorunlar şunlar:
Örnek Senaryo:
Yatırımcı A Excel'de portföy takibi yapıyordu; BTC'ye 3 farklı zamanda alım yaptı ama ortalama maliyeti yanlış hesapladı. Satış yaptığında kâr/zarar hesabı yanlış çıktı. Yatırımcı B pozisyon kapattı ama geçmiş kayıtları kayboldu; hangi coin'den ne kadar kazandığını hatırlayamadı. Yatırımcı C açık pozisyonlarla kapanmış pozisyonları karıştırdı; gerçekleşen kârı gerçekleşmemiş kârla topladı, yanlış karar verdi.
- •fiyatlar sürekli değiştiği için portföy "anlık" takip edilemez
- •ortalama alış hesapları (DCA) manuel yapılınca hata çıkar
- •pozisyon kapanınca geçmiş kaybolur, performans metrikleri bozulur
- •gerçekleşen (realized) ve gerçekleşmemiş (unrealized) kâr karışır
- •analitik: win/loss, aylık trend, hold süresi gibi metrikler için ayrı tablolar gerekir
Bu çalışma, tüm bunları tek veri modeli ve kontrollü güncelleme stratejisi ile bir araya getirir.
Bu çalışmadaki 3 ana karar
Neden “sürekli refresh” değil, kontrollü veri tazeliği?
Problem
Her sayfa yüklemede API'den fiyat çekmek rate-limit ve yavaşlık üretir; hiç çekmemek de veriyi bayatlatır.
Karar
Zaman tabanlı invalidation ile cache’li güncelleme: tazelik–maliyet dengesini kurarak veriyi “yaklaşık” olmaktan çıkarmak.
Uygulama
Fiyatlar belirli bir aralıkla "yenilenmesi gerekiyorsa" güncellenir; toplu güncelleme ile tek çağrıda çoklu sembol çekilir; API yoksa cached fiyatla devam edilir.
Bu fiyatlar gerçeği yansıtmamaktadır. Canlı veri bağlantısı yoktur. Demo amaçlıdır.
Amaç hız değil: yanlış karar üretmeyecek kadar güncel, sistemi yormayacak kadar kontrollü veri.
Manuel ortalama maliyet neden yanıltır?
Problem
Manuel takipte en çok yapılan hata, ortalama maliyetin zihinsel/Excel üzerinden yanlış hesaplanmasıdır.
Karar
Sembol bazında mevcut aktif pozisyon varsa, eklemeyi pozisyon birleştirme olarak ele almak ve ortalamayı otomatik hesaplamak.
Ortaya çıkan yapı
Kayıt tutarlılığı korunur; ortalama maliyet “yorum” değil, sistem hesabı olur.
Önce
Miktar
0.5 BTC
Ortalama Alış
₺45,000
Maliyet Tabanı
₺22,500
Sonra
Miktar
0.5 BTC
Ortalama Alış
₺45,000
Maliyet Tabanı
₺22,500
Neden realized/unrealized ayrımı olmadan analiz güvenilmez?
Problem
Açık pozisyonlar ile kapanmış pozisyonlar aynı sepete girince ROI, kâr/zarar ve trendler doğru görünmez.
Karar
Portföy değerini ikiye ayırmak: Unrealized (açık pozisyonlar, current price ile) ve Realized (kapanmış pozisyonlar, sell price ile). Bu ayrım risk/performans okumasını doğru zemine oturtur.
Ortaya çıkan yapı
ROI, win/loss, aylık trend ve trade metrikleri güvenilir hale gelir.
Gerçekleşmemiş Kâr/Zarar
₺22,000
Açık pozisyonlar
Gerçekleşen Kâr/Zarar
₺25,000
Kapanmış pozisyonlar
Aylık Performans
Win/Loss
12/3
Kâr Faktörü
2.4x
Ort. Tutma Süresi
45 gün
Risk Yönetimi Notları (Kısa)
- •Pozisyon güncellemelerini atomik tutmak: tutarsız ROI/kâr hesaplarının önüne geçmek için.
- •Değişiklik izini saklamak: 'neden bu değer değişti?' sorusunu cevaplayabilmek için geriye dönük kayıt tutmak.
- •API erişimi kesilse bile 'son geçerli veri' ile kontrollü devam etmek: ekranı değil, kararı korumak için.
- •Amaç: daha fazla grafik değil, hesap hatasının karar üzerindeki etkisini düşürmek.
Birlikte değerlendirelim
Bu çalışma, manuel portföy takibini; kontrollü veri tazeliği, ortalama maliyetin sistem kuralı olması ve realized/unrealized ayrımıyla ölçülebilir hale getirir. Amaç “daha çok metrik” değil; yanlış karar üreten hesap hatalarını azaltmaktır.
Bu çalışmayla birlikte portföy takibi, dağınık kayıtlardan tek pozisyon mantığına taşındı. Asıl fark, ortalama maliyet, kapanış ve performans okumasının manuel yorumdan çıkarılıp sistem mantığına bağlanmasıydı.
Eğer portföy takibiniz hâlâ Excel ve manuel hesaplamalara bağlıysa; hangi noktada veri güvenilirliği kaybolduğunu birlikte çıkarabiliriz.
Örnek çalışma
Başvuru, değerlendirme ve kurul hattını tek sistem mantığında birleştiren operasyon kurgusu
Başvuru, hakem ve kurul hattı tek operasyon omurgasında değildi; süreçler e-posta ve dosyalar arasında dağınıktı.
Sistem kararlarını inceleyin→Örnek çalışma
Kullanıcı keşfi ile işletme tarafını aynı yapıda buluşturan iki taraflı sistem kurgusu
Kullanıcı keşfi ile işletme tarafının geri bildirim ve görünürlük ihtiyaçları aynı sistem mantığında birleşmiyordu.
Sistem kararlarını inceleyin→Süreci birlikte değerlendirelim
Eğer süreçleriniz dışarıdan çalışıyor gibi görünse de içeride belirsizlik, tekrar ve sürtünme üretiyorsa; ilk çerçeveyi birlikte çıkarabiliriz.