Trading jurnal platformasının hazırlanmasında əsas məsələ dashboard yaratmaq deyil: fərqli brokerlərdən gələn tarixçəni eyni məna daşıyan, izlənə bilən hadisələrə çevirməkdir. Bu mərhələ zəif qurularsa, win rate, P&L, drawdown, strategiya üzrə nəticələr və hətta trade sayı inandırıcı görünə, amma yanlış ola bilər. Ona görə hesablamalar xam CSV, PDF-dən çıxarılmış sətirlər və ya birbaşa API cavabları üzərində deyil, versiyalanmış normallaşdırılmış model üzərində işləməlidir.
Bu yanaşma post-trade analitikasını order icrası və ya canlı bazar datasından ayırır. Məqsəd istifadəçiyə “bu rəqəm haradan gəldi?” sualının aydın cavabını verməkdir. POLADO-da FinTech və trading sistemləri xidməti çərçivəsində bu tip inteqrasiyalar, analitika və idarə olunan məlumat axınları məhsulun biznes qaydalarına uyğun layihələndirilə bilər.
Niyə broker tarixçələri eyni data deyil
“Trade history” adı bütün mənbələrdə eyni şeyi ifadə etmir. Bir broker order, fill və cash fəaliyyətlərini ayrı qaytara bilər; digəri isə yalnız bağlanmış position səviyyəsində hesabat verə bilər. MetaTrader 5 hesabatlarında orders, deals, positions və balans göstəriciləri ayrıca bloklardır; deal nəticəsinə komissiya, fee və swap daxil edilə bilər. Alpaca-nın fəaliyyət sənədlərində isə tam və qismən fill-lər, depozitlər, çıxarışlar, fee-lər, dividend və korporativ hərəkətlər fərqli activity tipləri kimi təqdim olunur. Interactive Brokers Flex Query-ləri isə seçilmiş sahələrə görə XML, CSV və ya mətn exportu yaratmağa imkan verir.
Bu fərqlər bir nəticəyə gətirir: hər import formatını birbaşa analitika cədvəlinə yazmaq düzgün memarlıq deyil. Sistem əvvəlcə mənbənin verdiyi hadisəni anlamalı, sonra onu platformanın kanonik modelinə çevirməlidir.
İkiqat məlumat modeli: dəyişməz xam import və kanonik hadisələr
Etibarlı trading journal app development üçün iki səviyyəli model qurun.
1. Dəyişməz xam qat
- Yüklənən faylın orijinal nüsxəsini və ya API cavabının şifrələnmiş snapshot-ını saxlayın.
- Import mənbəsini, fayl hash-ini, import vaxtını, parser versiyasını, istifadəçi və hesab identifikatorlarını qeyd edin.
- Eyni fayl ikinci dəfə yüklənəndə hash və mənbə metadatası ilə təkrarı aşkar edin.
- Xam sətri və ya API payload-ını sonradan “düzəltməyin”; düzəliş ayrıca versiyalı transformasiya kimi saxlanmalıdır.
Bu qat support və audit üçün vacibdir. İstifadəçi “14 martdakı nəticəm niyə dəyişdi?” deyəndə komanda həm ilkin məlumatı, həm tətbiq olunan mapping qaydasını, həm də yeni hesablama versiyasını müqayisə edə bilir.
2. Normallaşdırılmış kanonik qat
Kanonik model broker terminlərini məhsul terminlərindən ayırır. Minimum obyektlər adətən bunlardır:
- Account: broker, hesab identifikatoru, əsas valyuta, leverage və hesab növü.
- Instrument: daxili instrument ID, asset class, baza/quote valyutası, contract ölçüsü və broker simvol alternativləri.
- Execution: fill ID, order ID, tərəf, quantity, qiymət, execution vaxtı, komissiya və fee.
- Cash event: deposit, withdrawal, transfer, interest, dividend, vergi, fee və düzəliş.
- Position lot / trade group: açılış və bağlanış fill-lərinin məhsulun seçdiyi matching qaydası ilə birləşdirilmiş görünüşü.
- Import issue: həll olunmamış simvol, naməlum valyuta, konfliktli account mapping və ya parser xətası.
Bu ayrım sayəsində yeni broker əlavə ediləndə mövcud P&L və statistika ekranlarını yenidən yazmaq əvəzinə yeni adapter və mapping qaydaları hazırlanır.
Normallaşdırmada ən çox səhv yaradan beş məsələ
Simvol və kontrakt mapping-i
EURUSD, EUR/USD, EURUSD.a və ya brokerin daxili CFD simvolu eyni iqtisadi aləti ifadə edə bilər, amma bunu avtomatik fərz etmək təhlükəlidir. Mapping cədvəlində mənbə brokeri, xam simvol, asset class, kanonik instrument, quote currency, multiplier və etibarlılıq statusu saxlanmalıdır. Avtomatik uyğunluq yalnız yüksək etibarlı olduqda tətbiq edilməli; şübhəli hallarda istifadəçi və ya əməliyyat komandası təsdiq verməlidir.
Qismən fill-lər və çoxhissəli bağlanış
Bir order bir neçə qiymətdə icra oluna, bir position hissə-hissə bağlana bilər. Platforma yalnız order səviyyəsində bir sətir yaradarsa, orta giriş/çıxış qiyməti, slippage, holding time və komissiya səhv hesablanacaq. Hər execution ayrıca saxlanmalı, sonra seçilmiş lot-matching siyasəti ilə ticarət görünüşünə aqreqasiya edilməlidir. FIFO, LIFO və ya brokerin təqdim etdiyi realized-P&L yanaşması məhsul qərarıdır; istifadəçi üçün görünən və dəyişiklikdə yenidən hesablana bilən olmalıdır.
Depozit və çıxarışları gəlirlə qarışdırmaq
Hesab balansının artması həmişə trading qazancı deyil. 10 000 depozit net P&L kimi yazılarsa, return və drawdown göstəriciləri mənasızlaşır. Cash-flow hadisələri performance hesablamasından ayrılmalı, seçilmiş metodologiya isə açıq göstərilməlidir: məsələn, sadə net P&L, equity change, time-weighted return və ya money-weighted return eyni rəqəm deyil.
Vaxt zonası və trading günü sərhədi
Broker exportu UTC, server vaxtı və ya lokal vaxtdan istifadə edə bilər. Platforma həm source timestamp, həm normallaşdırılmış UTC vaxtı, həm də istifadəçinin hesabat vaxt zonasını saxlamalıdır. Bundan əlavə, “trading day” üçün ayrıca kəsim vaxtı müəyyənləşdirin. Gecə yarısını keçən futures, forex və kripto əməliyyatlarında sadəcə təqvim gününə görə qruplaşdırma gündəlik nəticələri təhrif edə bilər.
Düzəlişlər, ləğvlər və yenidən import
Bəzi mənbələr trade correction və trade bust hadisələrini ayrıca göndərir. Import pipeline idempotent olmalıdır: eyni cursor, fayl və ya event təkrar gəldikdə yeni execution yaratmamalıdır. Bununla yanaşı, broker sonradan düzəliş göndərərsə, əvvəlki nəticəni gizlicə dəyişmək əvəzinə hadisə zəncirini saxlayıb təsirlənmiş periodları yenidən hesablamaq lazımdır.
İstifadəçi üçün görünən correction workflow qurun
Hətta yaxşı parser bütün halları avtomatik həll etməyəcək. Yaxşı trading performans analitika platforması istifadəçiyə “data quality” ekranı verir:
- Import nəticəsi: qəbul edilən, təkrarlanan, xəbərdarlıqlı və rədd edilən sətirlərin sayı.
- Həll gözləyən siyahı: tanınmayan simvol, uyğunlaşmayan account, çatışmayan kurs və ya qeyri-adi quantity.
- İstifadəçi düzəlişi: məsələn, “US100.cash” simvolunu konkret kanonik instrumentə bağlamaq.
- Təsirin preview-u: hansı trade-lər və metriklərin dəyişəcəyi.
- Təsdiqlənmiş override: kim tərəfindən, nə zaman və hansı səbəblə tətbiq edildiyi.
Manual düzəliş xam məlumatın əvəzi deyil. O, xam importa bağlı override qaydası olmalıdır. Beləliklə, parser yenilənəndə və ya istifadəçi yeni tarixçə import edəndə platforma qərarın harada qüvvədə olduğunu itirmir.
Hesablamalar: dashboard deyil, versiyalı nəticə sistemi
Normalized executions və cash events hazır olduqdan sonra metriklər ayrıca calculation layer-də qurulur. Trade-level net P&L, gross P&L, commission, swap, fee, R-multiple, hold time, expectancy, win rate, profit factor, equity curve və drawdown üçün dəqiq təriflər yazılı olmalıdır. Open-position unrealized P&L ayrıca işarələnməlidir; bağlanmış nəticələrlə qarışdırılmamalıdır.
Hər metric nəticəsinə calculation version, istifadə olunan event set və filter konteksti əlavə etmək faydalıdır. Məsələn, istifadəçi 1–31 may aralığında “London session” filtrini seçirsə, görünən rəqəm hansı vaxt zonası, hansı session qaydası və hansı import statusu ilə hesablandığını bilməlidir. Bu yanaşma ESFX kimi analitika yönümlü FinTech məhsullarında etibarlı filtr, drill-down və izah edilə bilən nəticə təcrübəsinin əsasını təşkil edir.
Trading journal məhsulu üçün discovery checklist
- İlk buraxılışda hansı brokerlər, terminal exportları və asset class-lar dəstəklənəcək?
- Mənbə order, execution, position, cash activity və corporate action məlumatlarından hansını verir?
- Hansı sahələr unikaldır və deduplikasiya açarı nə olacaq?
- Hesab, simvol, valyuta və kontrakt ölçüsü mapping-i kim tərəfindən idarə ediləcək?
- Lot matching və netting/hedging davranışı necə təyin ediləcək?
- Depozit, çıxarış, fee, interest, swap və dividend performance metodologiyasına necə daxil olacaq?
- Tarix, saat və trading-day sərhədi hansı vaxt zonasında işləyəcək?
- İstifadəçi hansı düzəlişləri edə, hansıları isə yalnız support komandası təsdiqləyə biləcək?
- Re-import, parser versiyası və broker düzəlişi nəticələrə necə təsir edəcək?
- Hansı metriklər yalnız məlumat keyfiyyəti yoxlamasından keçmiş account-larda göstəriləcək?
Nəticə: əvvəl etibarlı hadisə modeli, sonra performans ekranı
Yaxşı trading jurnalının dəyəri rəngli equity curve deyil; rəqəmlərinin təkrar hesablana, izah edilə və düzəldilə bilməsidir. İlk mərhələdə broker trade import integration, kanonik event modeli, mapping idarəetməsi və correction workflow-a sərmayə qoymaq sonradan daha sürətli analitika, mobil jurnal və AI əsaslı insight funksiyalarına təhlükəsiz baza yaradır.
Broker importları ilə işləyən yeni məhsul, mövcud trading aləti və ya investor hesabat platforması planlaşdırırsınızsa, FT10 təcrübəsi və POLADO-nun FinTech xidmətləri əsasında discovery sessiyası ilə məlumat mənbələrini, hesablama qaydalarını və MVP sərhədini birlikdə müəyyənləşdirə bilərik.