Торговый дневник криптотрейдера: как фиксировать вход, риск, ошибку и результат

Торговый дневник криптотрейдера — это не список сделок и не коллекция скриншотов с удачными входами. Это рабочая система, которая связывает торговый план, фактическое исполнение и последующий разбор результата. Без такого журнала трейдер обычно помнит сильные победы, болезненные убытки и несколько ярких ошибок, но не видит статистическую картину: какие сетапы действительно дают преимущество, где риск превышает план, сколько результата съедают комиссии и проскальзывание, как меняется качество решений после серии убытков и насколько реальное исполнение отличается от того, что было задумано до входа.

Главная ценность дневника не в том, чтобы «контролировать эмоции» абстрактно. Он превращает каждую сделку в наблюдение, которое можно сравнить с другими наблюдениями. Для этого до входа фиксируются гипотеза, уровень отмены, плановый риск и условия исполнения; после выхода — фактические цены, комиссии, funding, slippage, PnL, отклонения от плана и причина закрытия. Затем сделки группируются по стратегии, рыночному режиму, инструменту, времени, типу ошибки и другим признакам. Только после такого разбиения становится видно, что именно работает, а что создаёт красивый общий PnL за счёт нескольких случайных выбросов.

Для криптовалют это особенно важно. Рынок работает круглосуточно, торговля идёт одновременно на spot и derivatives, funding меняет экономику удержания позиции, одна идея может исполняться несколькими ордерами, а высокая волатильность делает разницу между planned price и actual fill существенной. Кроме того, PnL часто считается в разных базовых валютах: USDT, USDC, USD, BTC или рублях. Если журнал не нормализует эти детали, он быстро превращается в набор несопоставимых строк.

Эта статья не заменяет общий торговый план, отдельный разбор PnL в криптотрейдинге или будущую самостоятельную страницу о risk/reward. Здесь задача уже: построить журнал, который позволяет отвечать на конкретные вопросы о процессе. Например: «Мои пробои прибыльны после комиссий?», «Я чаще нарушаю стоп после двух убытков подряд?», «Лимитные входы дают лучшую цену, но снижают fill rate?», «Сетап работает только в трендовом режиме?», «Моя средняя потеря больше плановой из-за slippage или из-за ручного переноса стопа?».

Хороший журнал должен быть достаточно подробным для анализа и достаточно простым, чтобы заполняться после каждой сделки. Если форма требует двадцать минут и десятки субъективных оценок, дисциплина быстро исчезнет. Если в ней есть только дата, тикер и прибыль, анализ будет поверхностным. Поэтому ниже система строится слоями: минимальная обязательная карточка сделки, расширенные поля для диагностики, правила группировки, формулы метрик, процедура review и отдельный контур для автоматизации данных.

Что должен фиксировать торговый дневник и чем он отличается от истории ордеров

Увеличить

История ордеров показывает действия, но не замысел

Биржевая история отвечает на технические вопросы: какой ордер был создан, по какой цене он исполнился, какой объём прошёл и когда позиция была закрыта. Но она почти ничего не говорит о том, почему сделка вообще появилась. Два одинаковых входа по BTC могут относиться к разным стратегиям: пробой диапазона, возврат к уровню, mean reversion или импульс после новости. Если не записать сетап и критерий отмены, потом невозможно честно объединить сделки в одну статистическую группу.

Поэтому торговый дневник хранит не только фактические fill-данные, но и decision context: что трейдер видел до входа, какие условия считал обязательными, где ожидал ошибку гипотезы и какой риск был разрешён. Это превращает журнал из бухгалтерии в исследовательский набор данных.

Одна позиция может состоять из нескольких ордеров

Практическая сложность криптотрейдинга — дробное исполнение. Трейдер может набрать позицию тремя лимитными ордерами, частично сократить её на первой цели, перенести остаток в безубыток и закрыть последнюю часть по stop-market. Если каждая строка истории считается отдельной «сделкой», статистика win rate и среднего результата становится бессмысленной.

В журнале полезно иметь trade ID или parent position ID, который объединяет все связанные fills в одну торговую идею. Отдельно сохраняются дочерние исполнения. Тогда можно одновременно анализировать механику ордеров и итог всей позиции.

Минимальная карточка сделки

Минимальный торговый дневник криптотрейдера должен позволять восстановить решение без памяти. Запишите дату и время, инструмент, venue, spot/perpetual, направление, сетап, planned entry, actual average entry, stop, target или exit rule, размер позиции, плановый денежный риск, фактический выход, комиссии, funding, realized PnL и причину закрытия. Этого уже достаточно, чтобы сравнивать план с фактом.

Если поле не помогает будущему решению, его не нужно добавлять только потому, что оно выглядит профессионально. Например, десять шкал эмоций мало полезны, если вы никогда не строите по ним выборку. Начинайте с полей, по которым реально будете фильтровать или считать метрики.

Время фиксируйте в едином стандарте

Если нужен базовый контекст, сначала полезно разобрать что такое трейдинг. Крипторынок работает 24/7, поэтому «утром» и «вечером» недостаточно. Если сделки совершаются на нескольких площадках или данные выгружаются через API, полезно хранить timestamp в UTC и при необходимости отдельное поле local time. Это позволяет анализировать сессии, funding intervals и поведение стратегии в разные часы без ошибок из-за часовых поясов и перехода на летнее время.

Особенно важно отделять время отправки ордера от времени первого и последнего fill. Для быстрых стратегий задержка между signal timestamp и execution timestamp может быть самостоятельным источником ухудшения результата.

Инструмент нужно описывать точнее тикера

BTCUSDT spot и BTCUSDT perpetual — экономически разные объекты. У perpetual есть funding, mark price, margin, liquidation mechanics и возможность плеча. Токен с одинаковым тикером на разных площадках также может отличаться ликвидностью и условиями исполнения. Поэтому в журнале нужны поля venue, market type, contract/pair и при необходимости settlement asset.

Такой уровень детализации помогает не смешивать статистику. Стратегия может выглядеть хорошей на ликвидном perpetual и хуже на тонком spot просто из-за spread и slippage. Без правильной идентификации это различие потеряется.

История сделок на бирже полезна как источник, а не как готовый дневник

Выгрузка CSV или API-история снижает ручной труд и помогает не потерять комиссии, fills и время исполнения. Например, отдельная инструкция OneMagic показывает, как смотреть историю сделок и ордеров. Но импорт должен дополняться полями, которых биржа не знает: сетапом, плановым риском, причиной входа и оценкой соблюдения правил.

Автоматический импорт фактов плюс ручное добавление решения — хороший компромисс. Он уменьшает вероятность опечаток и одновременно сохраняет контекст, ради которого журнал вообще ведётся.

Торговый дневник не равен журналу криптотранзакций

На сайте уже есть отдельная инструкция о том, как вести журнал криптотранзакций. Такой журнал нужен для TxID, себестоимости, документов, переводов и сверки движения активов. Торговый дневник решает другую задачу: оценивает качество решений и исполнения конкретных торговых идей.

Иногда эти базы пересекаются — например, комиссия или перевод между счетами влияет на итоговую стоимость. Но объединять их в одну таблицу необязательно. Для аналитики трейдинга важнее чистая структура trade-level данных, а для учёта операций — полный финансовый след.

Что записывать до входа: гипотеза, риск и условия отмены

Сначала фиксируется причина сделки, потом результат

Самая ценная запись делается до исполнения. После того как рынок уже прошёл вверх или вниз, мозг быстро создаёт удобное объяснение: «уровень был очевиден», «объём подтверждал вход», «я просто рано вышел». Чтобы не переписывать историю, сохраните короткую гипотезу до позиции: что должно произойти, почему это создаёт торговую возможность и какое наблюдение покажет, что идея неверна.

Гипотеза не должна быть эссе. Формат «тренд вверх, возврат к пробитому уровню, вход только после удержания, отмена ниже локального low» намного полезнее длинного описания рынка. Главное — чтобы из записи было понятно, можно ли было выполнить сделку по заранее заданным правилам.

Сетап должен иметь стабильное имя

Если одну и ту же механику сегодня назвать «пробой», завтра «импульс», а послезавтра «breakout BTC», выборка раздробится. Создайте словарь сетапов и используйте фиксированные коды: BO-1, PB-1, MR-1 или понятные русские названия. Новый код появляется только тогда, когда правила действительно отличаются, а не когда хочется оправдать необычную сделку.

Стабильная таксономия позволяет через месяц построить выборку по одному паттерну. В материале про технический анализ криптовалют подробно разобрано, почему правила должны быть воспроизводимыми. Дневник превращает эти правила в наблюдаемую статистику.

Плановая цена и фактическая цена — разные поля

Если вы хотели войти по 100, но получили средний fill 100,8, нельзя задним числом заменить planned entry на 100,8. Разница — это информация об исполнении. Она может возникнуть из-за market order, недостаточной глубины, быстрого движения, задержки или частичных fills. Сохраняйте оба значения и считайте execution slippage отдельно.

Так становится видно, что проблема стратегии и проблема исполнения — не одно и то же. Положительное ожидание может исчезнуть не потому, что сигнал плохой, а потому, что реальный рынок регулярно даёт хуже предполагаемой цены.

Стоп нужен как уровень отмены, а не декоративное поле

До входа запишите stop price и логику его расположения. Отдельный материал о stop-loss и take-profit объясняет механику ордеров; в дневнике важно другое — был ли стоп частью исходного плана и соблюдался ли он. Если после входа стоп сдвинут дальше только ради нежелания принять убыток, это отдельное нарушение.

Для сделок без жёсткого stop-order всё равно нужен критерий invalidation: временной, структурный или событийный. Иначе невозможно определить плановый риск, а любой последующий выход будет выглядеть «логичным» задним числом.

Плановый риск лучше хранить и в деньгах, и в R

Запишите сумму, которую вы готовы потерять при нормальном исполнении стопа, а рядом — относительный риск как 1R. Если плановый убыток 100 USDT, то −1R означает потерю примерно 100 USDT, +2R — прибыль около 200 USDT до корректировки на издержки. R делает сделки разных размеров сопоставимыми.

При этом дневник должен хранить и реальные деньги. R удобен для качества процесса, но счёт оплачивает комиссии и переживает drawdown в конкретной валюте. Поэтому R не заменяет realized PnL, а дополняет его.

Размер позиции фиксируйте вместе с notional и leverage

Количество монет само по себе мало что говорит. 0,1 BTC при одной цене и 0,1 BTC через год — разные денежные экспозиции. Для derivatives ещё важнее distinction между margin и notional. Записывайте quantity, notional value, leverage и margin mode. Тогда можно анализировать, не растёт ли риск незаметно вместе с плечом.

Криптовалютные деривативы особенно чувствительны к этому различию: небольшая маржа может контролировать большую позицию. CFTC отдельно предупреждает, что leverage усиливает и прибыль, и убыток. В дневнике leverage должен быть измеряемым фактором, а не просто настройкой интерфейса.

Рыночный режим должен быть определён до просмотра результата

Тег режима — тренд, range, high volatility, low volatility, event-driven — полезен только если критерии понятны. Нельзя после убыточной сделки объявлять рынок «хаотичным», а после прибыльной — «трендовым». Лучше использовать простые заранее определённые признаки: структура high/low, положение относительно диапазона, ATR percentile, funding/OI контекст или другой воспроизводимый набор.

Позже это позволит увидеть, что один сетап имеет положительное ожидание в тренде и теряет деньги в боковике. Без regime tag все сделки смешаются, и средняя статистика скроет полезное различие.

Контекст настроения рынка — только если вы действительно его анализируете

Некоторым стратегиям полезен sentiment context. Например, можно фиксировать экстремальные значения индекса страха и жадности как внешний тег и затем проверить, влияет ли он на результат. На OneMagic есть отдельный материал об индексе страха и жадности криптовалют. Но добавлять десять индикаторов в журнал «на всякий случай» не нужно.

Каждое поле создаёт стоимость заполнения. Оставляйте переменные, для которых есть гипотеза: «в экстремальном sentiment мой breakout-сетап хуже». Тогда поле становится частью исследования, а не украшением таблицы.

Что записывать после исполнения: fill, комиссии, slippage и фактический риск

Средняя цена должна строиться из fills

Если ордер исполнился частями, используйте средневзвешенную цену по фактическим fills, а не цену заявки. Для входа несколькими ордерами нужна единая average entry всей позиции. То же относится к масштабированному выходу: две цели и финальный стоп образуют несколько exit fills, из которых рассчитывается средняя цена закрытой части и итоговый realized PnL.

Это особенно важно для скальпинга и высокочастотной ручной торговли, где небольшая разница в цене может составлять существенную долю ожидаемого edge. Отдельный материал о скальпинге криптовалют показывает, насколько издержки критичны для коротких целей.

Комиссии записывайте в фактической валюте и в валюте отчёта

Комиссия может списываться в quote asset, base asset или токене площадки. Для корректного анализа сохраните исходную сумму и её стоимость в базовой валюте журнала на момент операции. Иначе через несколько месяцев невозможно точно понять, сколько net PnL было потеряно на издержках.

В итоговой статистике важен результат после всех торговых расходов. Gross PnL полезен для оценки самой идеи, но стратегия, которая положительна до fees и отрицательна после них, экономически не работает.

Funding — это часть результата derivatives-сделки

Perpetual-позиция может несколько раз пройти через funding interval. Поэтому funding payment нужно привязать к trade ID и включить в net PnL. На сайте отдельно разобрана механика фандинга; в дневнике важен его фактический денежный эффект на конкретную позицию.

Если стратегия удерживает позиции долго, funding может систематически улучшать или ухудшать результаты. Без отдельного поля трейдер рискует приписать этот эффект качеству входов.

Slippage нужно считать, а не описывать словом «плохо исполнилось»

Сравните benchmark price и actual fill. Benchmark должен соответствовать вашей логике: planned entry, mid price в момент сигнала, best bid/ask при отправке или другая заранее определённая цена. Затем разницу переведите в basis points или проценты. Отдельная статья OneMagic подробно разбирает slippage в криптовалюте.

После десятков сделок можно проверить, какие инструменты и часы дают наибольшее проскальзывание. Это уже не впечатление, а execution dataset.

Причина выхода важнее красивого описания после сделки

Используйте ограниченный набор exit codes: planned stop, target, trailing stop, time stop, thesis invalidation, manual early exit, liquidation, operational error. Свободный комментарий можно оставить рядом, но код должен быть стандартизирован. Тогда вы увидите, например, что ранние ручные выходы сокращают среднюю прибыль или что time stop улучшает эффективность определённого сетапа.

Если причина всегда записывается текстом, классификация позже станет трудоёмкой и субъективной.

Фактический убыток сравнивайте с плановым риском

Сделка со stop на −1R может закрыться на −1,2R из-за gap, slippage или комиссии. Это нормальное рыночное отклонение, но его нужно измерять. Намного опаснее, если −1R регулярно превращается в −2R из-за переноса стопа, добавления к убыточной позиции или отказа исполнить план.

Показатель actual loss / planned loss создаёт простой контроль дисциплины. Он отделяет несовершенство исполнения от систематического нарушения риска.

Ликвидность влияет на журнал через реальную цену выхода

Практический пример исполнения крупных заявок разобран в материале о крупной покупке без проскальзывания. Последняя котировка не гарантирует, что весь объём можно закрыть рядом с ней. Для крупной позиции useful fields — spread, приблизительная depth, order type и наблюдаемый price impact. На OneMagic отдельно разобрана ликвидность криптовалюты и сценарии, когда рыночная цена мало говорит о доступном выходе.

Если стратегия масштабируется, журнал должен показывать, растёт ли execution cost вместе с размером позиции. Иначе маленький успешный тест может дать ложное ощущение, что тот же edge сохранится при десятикратном капитале.

Скриншот полезен как доказательство контекста, но не заменяет данные

Сохраняйте один снимок до входа и один после выхода, если визуальный контекст действительно важен. На них должны быть видны те же уровни и таймфрейм, которыми вы пользовались. Не перерисовывайте график после сделки так, чтобы он выглядел «чисто».

Скриншот хорош для разбора структуры и ошибок восприятия. Но показатели PnL, risk, fill и fees должны храниться отдельными числовыми полями, чтобы их можно было агрегировать.

Как фиксировать ошибки без самообмана: taxonomy вместо эмоциональных заметок

Ошибка — это нарушение процесса, а не любой убыток

Убыточная сделка может быть выполнена идеально: сетап соответствовал правилам, риск был ограничен, исполнение нормальное, рынок просто пошёл против гипотезы. Прибыльная сделка, наоборот, может быть процессной ошибкой — например, вход без стопа, случайно закрывшийся в плюс. Если журнал называет ошибкой только минусовой PnL, он обучает трейдера неправильной причинности.

Поэтому поле «ошибка» должно отвечать на вопрос: нарушено ли заранее существовавшее правило. Результат сделки хранится отдельно.

Создайте короткий список кодов ошибок

Практичная taxonomy может включать: E1 — вход без сетапа, E2 — превышение размера, E3 — перенос стопа дальше, E4 — ранний выход без правила, E5 — поздний вход/FOMO, E6 — revenge trade, E7 — неверный order type, E8 — пропуск комиссии/funding, E9 — торговля вне разрешённого времени, E10 — техническая ошибка. Коды должны описывать действия, а не характер трейдера.

Такой список позволяет через месяц увидеть частоту конкретного нарушения. Формулировка «сегодня был недисциплинирован» для статистики почти бесполезна.

FOMO должен фиксироваться через наблюдаемое действие

Вместо субъективного «боялся упустить движение» полезнее записать: вход был выше разрешённой зоны, сигнал уже прошёл, planned entry не дождался. Тогда эмоциональная причина связана с измеримым нарушением. Отдельный материал OneMagic разбирает FOMO в криптотрейдинге, а журнал позволяет проверить, сколько денег реально стоят такие входы.

Если FOMO-тег никак не меняет поведение и не анализируется, он превращается в психологическую заметку без операционной ценности.

Revenge trading выявляется через последовательность сделок

После крупного убытка или серии минусов трейдер может резко увеличить частоту, size или агрессивность входов. Чтобы это увидеть, полезны поля previous trade result, time since previous trade и change in risk. Тогда журнал покажет, что после −2R сделки следующий риск, например, часто превышает обычный лимит.

Это намного надёжнее воспоминаний. В спокойном состоянии человек склонен недооценивать, насколько сильно менялось поведение под давлением.

Ошибки исполнения и ошибки стратегии нужно разделять

Плохой сигнал и плохой fill — разные проблемы. Если сетап даёт отрицательное ожидание даже при нормальном исполнении, менять нужно стратегию. Если сетап стабилен, но результаты портят market orders в тонком рынке, нужен другой execution process. Один общий тег «плохая сделка» не помогает выбрать действие.

Поэтому полезны отдельные группы: strategy error, risk error, execution error, discipline error, operational error.

Нельзя создавать новый код под каждую неприятную сделку

Taxonomy должна быть устойчивой. Если после каждого убытка появляется уникальная категория, статистика снова распадается. Новый код имеет смысл только для повторяемого типа поведения, который требует отдельного исправления.

Редкие исключения можно описывать в comment field. Основная аналитика должна идти по ограниченному списку признаков.

Оценка «соблюдение плана» лучше бинарной морали

Полезно хранить простую шкалу: 1 — план соблюдён; 0 — нарушен. При желании добавить третье состояние «частично», но только с чёткими правилами. Потом сравните expectancy compliant trades и non-compliant trades. Иногда оказывается, что стратегия сама требует доработки; иногда — что большая часть потерь приходит именно из нарушений.

Так дневник перестаёт быть дневником самокритики и становится системой контроля процесса.

Положительная случайность тоже должна отмечаться

Если вы нарушили правило и случайно получили +4R, это особенно опасная запись. Мозг запоминает вознаграждение и хочет повторить нарушение. Отметьте сделку как profit with process error и не включайте её в «успешные образцы» стратегии без отдельного анализа.

Цель дневника — не максимизировать количество зелёных строк, а отделить воспроизводимое преимущество от удачи.

Какие метрики считать из торгового дневника и как не обмануть себя средними значениями

Увеличить

Win rate без среднего выигрыша и среднего проигрыша почти бесполезен

Процент прибыльных сделок легко выглядит убедительно, но сам по себе не говорит о качестве стратегии. Система с 80% выигрышей может иметь отрицательное ожидание, если редкие убытки слишком велики. И наоборот, трендовая стратегия с 35% прибыльных сделок может быть положительной при достаточно большом среднем выигрыше. Поэтому journal dashboard должен показывать win rate вместе с average win, average loss и expectancy.

Полезно считать эти показатели и в деньгах, и в R. Денежная версия отражает реальный счёт, а R-version позволяет сравнивать сделки при изменяющемся размере капитала.

Expectancy отвечает на вопрос о среднем результате одной сделки

В упрощённой модели expectancy получают из двух частей: частоту положительных исходов взвешивают на типичный выигрыш, а частоту отрицательных — на типичный убыток; разница между этими вкладами и даёт ожидаемый результат одной сделки. Но результат имеет смысл только для достаточно однородной выборки. Смешивать scalping, swing trades, spot и leveraged perpetual в одну цифру опасно.

Сначала считайте expectancy по стратегии и режиму, затем уже общий результат. Если одна стратегия сильная, а другая систематически отрицательная, общий плюс может скрывать ненужную утечку.

Profit factor полезен, но чувствителен к редким крупным сделкам

Profit factor — отношение gross profit к gross loss. Значение выше единицы означает, что сумма прибыльных сделок превышает сумму убыточных на выбранной выборке. Но одна аномальная победа способна резко улучшить показатель. Поэтому рядом полезно видеть результат без лучшей сделки и долю PnL, созданную top-5 сделками.

Если почти вся прибыль зависит от одного выброса, стратегия может быть менее устойчивой, чем показывает headline metric.

Maximum drawdown показывает путь, а не только финальную прибыль

Две стратегии могут заработать одинаковые 20R, но одна пройти через −4R drawdown, а другая через −15R. Для реального трейдера это совершенно разный риск психологического и финансового отказа от системы. Дневник должен строить equity curve и измерять peak-to-trough снижение.

Дополнительно сохраняйте duration drawdown: сколько сделок или дней потребовалось, чтобы восстановить предыдущий максимум. Длинная стагнация может быть не менее важна, чем глубина просадки.

Средний результат нужно дополнять медианой

Крипторынок даёт тяжёлые хвосты и редкие сильные движения. Средняя сделка может быть заметно выше медианной из-за нескольких больших winners. Поэтому journal review полезно показывать mean и median R. Большой разрыв между ними предупреждает, что distribution асимметрично и headline average зависит от редких событий.

Это не обязательно плохо: trend-following часто живёт за счёт хвостовых winners. Но трейдер должен понимать структуру результата и не ожидать «среднюю прибыль» в каждой серии.

MAE и MFE помогают анализировать путь сделки

Maximum Adverse Excursion показывает, насколько далеко цена шла против позиции до закрытия, а Maximum Favorable Excursion — насколько далеко шла в плюс. Эти поля полезны для исследования stop distance, trailing rules и ранних выходов. Например, если прибыльные сделки редко уходят ниже −0,4R, стоп −1,5R может быть избыточно широким — но вывод требует большой выборки и проверки по режимам.

MFE особенно полезен для manual exits. Если трейдер систематически закрывает +0,8R сделки, которые затем достигали +2R по исходному плану, дневник делает это поведение видимым.

Holding time показывает, где капитал застревает

Записывайте длительность позиции. Сравните прибыль на сделку и прибыль на единицу времени. Две стратегии с одинаковым expectancy могут по-разному использовать капитал: одна держит риск несколько часов, другая несколько недель. Для портфеля с ограниченным margin это существенно.

Holding time также помогает найти time-stop. Если после определённого количества часов сетап статистически перестаёт улучшаться, это гипотеза для отдельной проверки, а не повод немедленно переписать правила.

Комиссии как процент gross edge показывают экономическую хрупкость

Считайте не только сумму fees, но и их долю от gross profit. Если стратегия зарабатывает 1000 USDT до издержек и платит 600 USDT комиссий, запас прочности мал. Небольшое ухудшение fee tier, spread или slippage способно убрать edge.

Для частых стратегий этот показатель иногда важнее красивого gross win rate.

Серии убытков и выигрышей важны для операционного риска

Максимальная последовательность losses помогает оценить, выдержит ли трейдер систему психологически и финансово. Если исторически встречалось 8 убыточных сделок подряд, после третьей не стоит автоматически объявлять стратегию «сломавшейся». Но если текущая серия выходит далеко за обычный диапазон, это повод провести structured review.

Записывайте не только streak length, но и поведение во время серии: изменялся ли size, появлялись ли revenge trades, нарушались ли фильтры.

PnL нужно считать корректно для realized и unrealized результата

В дневник завершённых сделок обычно попадает realized result, но при длительных позициях полезно хранить snapshot unrealized PnL на review dates. Отдельный материал OneMagic подробно объясняет realized и unrealized PnL. Главное — не смешивать закрытый торговый результат с текущей переоценкой открытых позиций.

Если стратегия использует частичный выход, journal engine должен корректно распределять realized PnL по закрытым объёмам и не считать остаток закрытым.

Как разбирать сделки по группам: сетап, рынок, время, инструмент и режим

Общий PnL — это только верхний слой

Если смотреть только на итог месяца, невозможно понять, почему результат изменился. Положительный месяц может скрывать убыточный сетап, компенсированный одной большой сделкой; отрицательный — содержать хорошую стратегию, испорченную несколькими нарушениями. Поэтому после накопления выборки сделки разбиваются на cohorts по признакам, заданным заранее.

Базовый набор: strategy/setup, market type, instrument, long/short, regime, time of day, day of week, execution type, compliance status и error code. Не нужно одновременно создавать сотни срезов: каждый новый разрез увеличивает риск случайных закономерностей.

Сетап — главный уровень сравнения

Сначала сравните стратегии между собой. Для каждой посчитайте number of trades, expectancy, median R, profit factor, drawdown, fees, average holding time и долю нарушений. Если «breakout» и «mean reversion» живут в разных распределениях, объединённая статистика мало полезна.

При этом не удаляйте неудачный сетап после десяти сделок только потому, что другой выглядит лучше. Малые выборки шумны; решение об изменении playbook требует заранее заданного минимального sample size и понимания режима.

Рынок и инструмент могут менять результат одной и той же логики

Одинаковая идея может работать по-разному на BTC perpetual, ETH spot и малоликвидном altcoin. Причина не только в волатильности: отличаются spread, depth, funding, торговые часы ликвидности и характер ложных пробоев. Поэтому journal должен позволять сравнивать instrument cohorts.

Отдельный материал о структуре крипторынка помогает понять, почему активы нельзя считать одинаковыми только из-за общей категории «криптовалюта».

Long и short лучше анализировать отдельно

Даже симметричная стратегия может вести себя асимметрично. В криптовалютах импульсы вверх и вниз часто имеют разную скорость, funding и ликвидационные каскады также меняют microstructure. Разделяйте направление сделки и сравнивайте expectancy, slippage и holding time.

Если short-сделок мало, не делайте сильный вывод по трём наблюдениям. Journal должен показывать sample size рядом с любым процентом.

Время суток анализируйте только при достаточной выборке

Круглосуточный рынок создаёт соблазн найти «лучший час». Но если у вас две прибыльные сделки в 03:00 и одна убыточная в 15:00, это не закономерность. Сначала задайте buckets, например Asia/Europe/US overlap или фиксированные UTC-интервалы, затем накопите выборку.

Основной смысл time analysis — не магический час, а связь с ликвидностью, новостями и вашей собственной работоспособностью.

Режим рынка должен быть воспроизводимым тегом

Trend/range/high-volatility tags дают ценность только при стабильном определении. Если режим назначается после результата, возникает hindsight bias. Зафиксируйте правила классификации в playbook и не меняйте их внутри выборки.

Тогда journal сможет показать условную эффективность: стратегия хороша в тренде, нейтральна в спокойном диапазоне и опасна в event-driven volatility.

Фильтр «соблюдён план» часто даёт самый полезный срез

Сравните все compliant trades с нарушениями. Если compliant expectancy положительно, а violations резко отрицательны, главный проект улучшения — execution discipline. Если обе группы отрицательны, обвинять психологию преждевременно: сама стратегия, возможно, не имеет преимущества.

Это один из самых практичных способов не превращать журнал в бесконечное изучение эмоций.

Не ищите закономерности в сотнях фильтров одновременно

Если после каждой серии сделок перебрать десятки часов, индикаторов, фаз луны, видов свечей и настроений, случайно найдутся «идеальные» подгруппы. Это та же проблема multiple testing, которую статья о бэктесте рассматривает для исторических стратегий. В журнале она проявляется как post-hoc segmentation.

Сначала формулируйте вопрос, затем стройте срез. Например: «почему breakout убыточен — из-за high-volatility режима?» Это лучше, чем бесцельно искать самый прибыльный набор тегов.

Малую выборку лучше обозначить как гипотезу

Если результат интересный, но наблюдений мало, не переписывайте систему. Добавьте hypothesis flag и продолжайте собирать данные. После следующего заранее заданного блока сделок вернитесь к вопросу.

Так дневник становится forward research tool, а не фабрикой мгновенных оптимизаций.

Как проводить daily, weekly и monthly review, чтобы дневник менял решения

Заполнение и анализ — разные процессы

После сделки нужно быстро сохранить факты, но не обязательно сразу менять стратегию. Горячая реакция после большого выигрыша или убытка создаёт риск переоценить одно наблюдение. Разделите workflow: trade capture происходит сразу, daily review — после завершения торговой сессии, weekly review — по серии сделок, monthly review — по агрегированной статистике и изменениям playbook.

Это защищает от постоянного «улучшения» системы после каждого результата. Правило должно меняться только по процедуре, а не потому, что последняя сделка эмоционально заметна.

Daily review ищет процессные ошибки, а не новую стратегию

В конце дня проверьте: все ли сделки импортированы, совпадает ли PnL с аккаунтом, были ли нарушения risk limits, stop rules и разрешённых сетапов, есть ли технические ошибки. Затем запишите одну-две короткие мысли: что повторить и что не повторять завтра.

CME в своём учебном материале о trade log рекомендует после торгового дня фокусироваться не только на прибыли или убытке, а на причинах результата и ошибках. Такая post-mortem логика полезна и для криптотрейдинга.

Сверка счёта обязательна перед психологическими выводами

Если журнал показывает +420 USDT, а account statement — +360, сначала найдите техническое расхождение: fee, funding, partial fill, незакрытая часть, transfer или ошибочная конвертация. Нельзя обсуждать «дисциплину», пока фактические числа не согласованы.

Reconciliation — скучная, но критичная часть дневника. Ошибочная база производит ошибочные выводы независимо от качества аналитики.

Weekly review работает с серией, а не с отдельной сделкой

Раз в неделю или после заранее заданного числа сделок соберите dashboard: number of trades, net PnL, R, expectancy, plan compliance, error counts, fees, slippage, best/worst setup и drawdown. Затем выберите одну проблему для следующего периода. Если пытаться исправить десять вещей одновременно, невозможно понять, что именно изменило результат.

Например: «следующие 20 сделок не переносить stop дальше» — измеримый experiment. Через 20 сделок сравните excess loss и compliance.

Monthly review сравнивает стратегии и устойчивость результата

На месячном уровне полезно смотреть не только net PnL, но и distribution. Сколько прибыли создали top trades? Какой setup дал лучшую expectancy? Как изменился max drawdown? Увеличился ли turnover? Сколько процентов gross profit ушло на fees? Есть ли системное ухудшение slippage?

Если результат изменился, сначала ищите объяснение в структуре выборки: другой market regime, instruments, leverage, частота. Только потом делайте вывод, что стратегия «перестала работать».

Отдельно проверяйте размер риска после роста или падения счёта

Если position sizing зависит от equity, денежный 1R со временем меняется. Журнал должен показывать planned risk both absolute and relative. После сильного роста легко незаметно увеличить денежную волатильность результатов; после drawdown — продолжать рисковать старой суммой, превращая тот же trade в больший процент текущего капитала.

CME рассматривает intended leverage, maximum trade loss и maximum day loss как ключевые параметры risk plan. Дневник нужен, чтобы проверять фактическое соблюдение этих границ.

Playbook меняется только с версией и датой

Когда правило изменено, создайте version: PB-1 v2, breakout v3. Запишите дату, причину и ожидаемый эффект. Старые сделки остаются привязаны к старой версии. Иначе через полгода вы протестируете «один сетап», который фактически менялся несколько раз, и статистика потеряет смысл.

Versioning особенно важно после review, где возникает соблазн слегка изменить stop, target и фильтры одновременно.

Одно изменение за раз повышает диагностическую ценность

Если одновременно уменьшить stop, изменить time filter, добавить индикатор и перейти на другой order type, улучшение результата нельзя связать с конкретной причиной. Старайтесь тестировать одну существенную модификацию на заранее определённой серии.

Это не строгий лабораторный эксперимент, но дисциплина изменения правил резко уменьшает самообман.

Review должен включать сделки, которые вы не совершили

Иногда полезно вести небольшой missed-trades log: валидный сигнал появился, но сделка не была исполнена из-за страха, технической проблемы или отсутствия у терминала. Не нужно записывать каждый возможный график; только те сигналы, которые по playbook реально требовали действия.

Так можно обнаружить противоположную ошибку: стратегия выглядит хуже не из-за плохих сделок, а потому что лучшие сигналы систематически пропускаются.

Не меняйте правила ради восстановления последнего убытка

После drawdown естественно хотеть «починить» систему. Но изменения, направленные на то, чтобы исторически избежать последних трёх losses, часто создают overfitting. Дневник должен заставлять формулировать проблему в общей форме: какой класс сделок плох, сколько наблюдений, какой mechanism ожидается.

Если аргумент сводится к «новое правило спасло бы последнюю сделку», этого недостаточно.

Дневник — часть торгового плана, а не отдельное хобби

CME включает trader log как один из компонентов trade plan наряду с objective, methodology, risk management и strategies. Это полезная рамка: журнал имеет смысл только тогда, когда проверяет заранее существующие правила.

Если trading plan отсутствует, дневник может отлично описывать хаотичные решения, но не сможет измерить отклонение от процесса — потому что самого эталонного процесса нет.

Как автоматизировать торговый дневник без потери качества данных и безопасности

Лучший вариант — автоматический импорт фактов и ручное добавление контекста

Ручной ввод каждой комиссии, fill и timestamp быстро становится источником ошибок. Поэтому фактические торговые данные разумно импортировать из CSV или API, а поля decision context добавлять вручную. Такая архитектура разделяет объективные данные площадки и субъективную часть торгового плана.

Автоматизация особенно полезна при частичных исполнениях и нескольких аккаунтах. Но она не должна скрывать происхождение данных: журнал должен позволять восстановить raw fill, из которого рассчитана агрегированная сделка.

Orders и fills нельзя хранить как одно и то же

Ордер — инструкция рынку, fill — фактическое исполнение. Один order может иметь zero, one или many fills; limit может быть отменён частично. Если импорт сохраняет только order history, средняя цена и fees могут быть неполными. Для корректного PnL важен execution-level слой.

В data model полезно иметь таблицу raw fills и отдельную таблицу trades/positions, где fills сгруппированы по trade ID.

Transfers не должны попадать в PnL как прибыль или убыток

Пополнение счёта на 10 000 USDT не является торговой прибылью, а вывод 5 000 USDT — убытком. Импорт должен отделять external cash flows от realized trading PnL. Это особенно важно для equity curve и drawdown.

Если деньги переводятся между собственными spot, futures и funding accounts, операция вообще может быть внутренним перемещением. Журнал торговых результатов и журнал денежных потоков должны быть связаны, но не смешаны.

Нормализуйте валюту отчёта

Если часть сделок рассчитывается в USDT, часть в USDC, а часть имеет fees в BNB или другом токене, выберите report currency и храните conversion value на момент события. При этом исходную сумму тоже сохраняйте, чтобы можно было перепроверить расчёт.

Для долгих периодов это важно: текущая цена fee token не должна задним числом менять историческую комиссию.

API-ключ для журнала должен иметь минимальные права

Если сервису нужен только импорт истории, ему обычно достаточно read-only доступа. Торговые и особенно withdrawal permissions для журнала не нужны. Принцип минимальных полномочий снижает blast radius при компрометации сервиса или ключа.

Не храните API secret прямо в таблице, заметке или репозитории. Если используется собственная автоматизация, секреты должны находиться в предназначенном для этого хранилище, а доступ — журналироваться и регулярно пересматриваться.

CSV безопаснее API только в некоторых сценариях

CSV не даёт постоянного доступа к аккаунту, поэтому для простого журнала это часто разумный вариант. Но файл содержит финансовую историю и тоже требует защиты. Не отправляйте его в случайные онлайн-конвертеры и не храните в публичной папке.

API удобнее для регулярной синхронизации, но увеличивает поверхность доступа. Выбор зависит от частоты торговли и вашей инфраструктуры, а не от моды на автоматизацию.

Дедупликация нужна при повторном импорте

Если один CSV загрузить дважды или API повторно вернёт старые fills, журнал не должен удвоить сделки. Используйте stable execution ID либо составной ключ из venue, order ID, trade/fill ID и timestamp. Любая синхронизация должна быть idempotent: повторный запуск не меняет уже корректные данные.

После импорта полезно сверять totals по количеству fills, fees и realized PnL с источником.

Частичные закрытия требуют position accounting

Если 40% позиции закрыто на первой цели, а остаток позже по stop, journal engine должен знать, какая часть остаётся открытой. Нельзя просто усреднить две цены без учёта quantity. Для каждой exit leg храните qty и realized result.

Это позволяет анализировать scale-out rules отдельно: возможно, ранняя фиксация снижает drawdown, но слишком сильно режет right tail.

Cross и isolated margin должны быть различимы

Для derivatives поле margin mode важно: cross position делит риск с другим collateral, isolated ограничивает его отдельным margin bucket. Одно и то же движение цены может иметь разные последствия для account-level exposure.

Если журнал анализирует только trade PnL, он может недооценить контекст общего риска при cross margin. Поэтому храните account exposure snapshot для сделок с плечом.

Скриншоты не должны содержать секреты

Перед автоматической загрузкой изображений в cloud проверьте, нет ли на них email, UID, API key, QR-кодов, адресов, размеров всего баланса или других чувствительных данных. Для анализа графика обычно достаточно chart area.

Минимизация данных полезна и с точки зрения безопасности, и с точки зрения качества review: лишний интерфейс не должен отвлекать от сетапа.

Данные должны быть экспортируемыми

Если journal service не позволяет выгрузить raw trades и ваши tags, возникает vendor lock-in. Для долгосрочной аналитики выбирайте формат, который можно получить в CSV/JSON и независимо обработать. Дневник — накопленный исследовательский актив, а не просто интерфейс текущего сервиса.

Полезно периодически делать резервную копию и проверять, что экспорт действительно читается.

Автоматизация не должна придумывать причину сделки

AI или rule-based классификатор может предложить setup tag по графику, но окончательный pre-trade reason должен исходить из зафиксированного плана. Если алгоритм после результата автоматически назовёт сделку «breakout», возникает тот же hindsight bias, только автоматизированный.

Машина хорошо импортирует факты и считает метрики. Смысл решения должен быть записан в момент, когда будущее ещё неизвестно.

Практический шаблон торгового дневника: от первой записи до решения по стратегии

Начните с 12 обязательных полей

Торговый дневник криптотрейдера не обязан начинаться со сложного dashboard. Достаточно двенадцати полей: trade ID, дата/время, инструмент, market type, direction, setup, planned entry, stop/invalidation, planned risk, actual entry, actual exit и net PnL. Сразу добавьте поле plan compliance. Такой минимум уже позволяет отделять идею от исполнения и считать базовую статистику.

Через несколько недель добавляйте только те поля, которые нужны для конкретного вопроса: regime, MAE/MFE, slippage, error code, screenshot, funding или session. Не проектируйте идеальную базу до первой сделки.

Шаблон одной сделки должен читаться как короткий протокол

Карточка может выглядеть так: «BTCUSDT perpetual, long, PB-1, planned entry 64 200, stop 63 550, risk 120 USDT, target 2R; actual average entry 64 260; exit частями; fees 14 USDT; funding −3 USDT; net +1,42R; план соблюдён; ошибка — нет». Даже без графика спустя месяцы понятно, что было задумано и что получилось.

Если запись не позволяет восстановить основную механику без памяти, в ней не хватает структуры.

Пример: прибыльная сделка с плохим процессом

Трейдер планировал риск 100 USDT, но вошёл после движения, увеличил позицию и не поставил stop. Рынок развернулся в его пользу, итог +350 USDT. В обычной истории это «успех». В дневнике: PnL +3,5R условно, но plan compliance = 0, error E2/E5, фактический worst-case risk неизвестен.

Такую сделку нельзя использовать как доказательство преимущества стратегии. Наоборот, её нужно сохранить как пример поведения, которое случайно было вознаграждено.

Пример: убыточная сделка с хорошим процессом

Сетап полностью соответствовал правилам, размер рассчитан, stop исполнен с небольшим slippage, итог −1,06R после комиссии. Это нормальное наблюдение отрицательного исхода. В review не требуется искать психологическую проблему только потому, что строка красная.

Если серия таких compliant trades становится статистически хуже исторического диапазона, тогда изучается стратегия и regime, а не отдельная ошибка.

Пример: стратегия положительна gross, но отрицательна net

Предположим, 80 сделок дали +12R до расходов, но fees, spread и slippage составили 15R. Gross edge существует только на бумаге; net expectancy отрицательна. Это типичная проблема частой торговли и одна из причин отдельно анализировать стоимость исполнения.

Если размер цели невелик, даже хороший directional signal может быть экономически непригодным.

Пример: журнал обнаруживает скрытый FOMO

После 50 сделок фильтр показывает: planned-entry trades имеют +0,35R expectancy, а chase entries — −0,6R. При этом chase составляет 18% всех сделок и возникает преимущественно после пропущенного сильного движения. Это уже конкретная операционная проблема: не «быть спокойнее», а запретить вход после заранее заданного отклонения от planned zone.

Следующий experiment можно сформулировать измеримо и проверить на новой серии.

Главная ошибка — вести дневник только после убытков

Если подробно описываются только плохие сделки, dataset biased. Прибыльные нарушения останутся невидимыми, а compliant winners не дадут понять, что именно работает. Каждая сделка должна проходить одинаковую форму независимо от результата.

Иначе journal превращается в коллекцию проблем, а не репрезентативную историю процесса.

Вторая ошибка — менять поля каждую неделю

Когда taxonomy постоянно меняется, старые и новые данные становятся несопоставимыми. Новое поле можно добавить, но ключевые определения setup, error и regime должны иметь version history. Если классификация изменена, зафиксируйте дату.

Стабильность схемы часто важнее количества показателей.

Третья ошибка — путать корреляцию с причиной

Допустим, сделки после 18:00 хуже. Это не доказывает, что время само по себе причина. Возможно, вечером торгуются другие инструменты, ниже ликвидность или трейдер устал. Journal находит patterns, но причинность требует гипотезы и forward проверки.

Поэтому хороший review заканчивается не выводом «никогда не торговать вечером», а проверяемым experiment.

Четвёртая ошибка — оптимизировать статистику вместо поведения

Можно удалить неудобные сделки, переименовать сетап или считать gross PnL вместо net, чтобы dashboard выглядел лучше. Но ценность дневника именно в неизменности неприятных фактов. Raw executions и исходные записи не должны переписываться после review.

Корректировки и комментарии добавляются как новые поля или версии, а не заменяют историю.

Пятая ошибка — делать вывод по слишком маленькой выборке

Пять прибыльных сделок не подтверждают edge, как и пять убытков не доказывают его исчезновение. Для каждого среза показывайте number of observations. Чем больше фильтров, тем быстрее выборка становится маленькой.

Если данных недостаточно, честный статус — «гипотеза». Это лучше ложной точности.

Шестая ошибка — смешивать ручную торговлю, бота и копитрейдинг

Ручной setup, торговый бот и copy trading имеют разные источники решений и исполнения. Их можно видеть в одном account dashboard, но journal должен иметь strategy/source tag. Иначе ошибка master trader, баг automation и ручное нарушение попадут в одну статистику.

Для автоматизации отдельно полезно хранить bot version, а для copy trading — master/follower context. Тогда общий портфель можно анализировать без потери причинности.

Седьмая ошибка — вести дневник, но никогда не менять действия

Сотни строк сами по себе не улучшают торговлю. Каждое review должно заканчиваться решением: ничего не менять; собрать больше данных; изменить один процесс; поставить стратегию на паузу; уменьшить риск; исправить execution; обновить playbook. Решение фиксируется вместе с датой и условием повторной проверки.

Так журнал становится замкнутым циклом feedback: план → сделка → запись → анализ → контролируемое изменение → новая выборка.

Когда дневник показывает, что стратегию лучше остановить

Pause rule стоит определить заранее. Причинами могут быть превышение допустимого drawdown, последовательность технических ошибок, резкое ухудшение execution, изменение рынка, невозможность воспроизвести сигнал или нарушение лимитов риска. Остановка — не признание поражения, а элемент контроля.

После паузы стратегия возвращается не потому, что «кажется, рынок снова хороший», а после review, paper/small-size проверки или другого заранее определённого условия.

Итог: дневник должен отвечать на вопрос «что именно изменить?»

Полезный торговый дневник криптотрейдера связывает план, риск, исполнение и статистику. Он не обещает прибыль и не превращает неопределённый рынок в формулу, но резко повышает качество обратной связи. В любой момент трейдер должен уметь показать, какие стратегии торгует, какой риск планирует, каковы фактические издержки, какие ошибки повторяются и какие изменения проверяются сейчас.

Если журнал не помогает выбрать следующее действие, его нужно упростить или перестроить. Лучший формат — тот, который регулярно заполняется, сохраняет факты без ретроспективной правки и позволяет сравнивать решения на достаточной выборке.

Как учитывать добавление к позиции без превращения усреднения в новую сделку

Если стратегия разрешает scale-in, заранее определите, относится ли дополнительный вход к той же торговой идее. Пока hypothesis, invalidation и общий risk budget остаются едиными, логично хранить один parent trade с несколькими entry legs. Но если после срабатывания исходного стопа трейдер открывает новую позицию по другой причине, это уже новая сделка, даже если тикер тот же.

Особенно важно не маскировать увеличение риска словом «усреднение». Journal должен показывать cumulative notional и новый worst-case loss после каждого добавления. Если общий риск превысил первоначальный лимит, это process deviation независимо от итогового PnL.

Как учитывать частичный выход и перенос стопа

Scale-out полезно разбирать по legs: доля закрытого объёма, цена, причина и оставшийся риск. После первой фиксации трейдер может перенести stop остатка; журнал должен сохранить прежний и новый уровень, а не только финальное значение. Тогда можно проверить, улучшает ли правило перевода в безубыток распределение результатов или слишком часто выбивает позицию перед основным движением.

Для аналитики удобно считать total trade R и отдельно R каждой exit leg. Это показывает не только качество входа, но и эффективность management rule.

Как фиксировать liquidation или forced close

Ликвидация не должна записываться просто как «stop». Это отдельный exit code, потому что она показывает провал risk architecture: либо плечо было слишком высоким, либо stop не исполнился, либо cross-margin exposure оказался больше ожидаемого. Сохраните liquidation price, mark price context, leverage, margin mode и фактический loss.

Если forced close произошёл из-за технической проблемы площадки или недостатка collateral, добавьте operational tag. Цель — не распределить вину, а понять, какой control должен предотвращать повторение.

Как журналировать торговлю несколькими стратегиями на одном инструменте

Один BTCUSDT может одновременно участвовать в swing long и коротком intraday hedge. Если платформа агрегирует позиции, raw account history не всегда ясно показывает, какая часть исполнения относится к какой идее. В журнале используйте strategy allocation или отдельные sub-accounts, если инфраструктура позволяет.

Без такого разделения итог по инструменту может выглядеть нейтральным, хотя одна стратегия стабильно зарабатывает, а другая теряет. Trade-level attribution важнее простой позиции по тикеру.

Как учитывать сделки, закрытые вручную из-за новости

Если playbook допускает event exit, сохраните событие и источник решения, но не переписывайте первоначальный target. После серии таких сделок можно проверить, действительно ли ручные exits снижают tail risk или чаще режут прибыль. Если event rule не существовал заранее, это manual override и должен иметь отдельный tag.

Так дневник помогает отличить разумное управление новым риском от ретроспективного оправдания импульсивного выхода.

Как хранить субъективные заметки без превращения журнала в психологический тест

Эмоциональный контекст полезен, если он привязан к повторяемому поведению. Вместо десяти шкал можно оставить два поля: state before trade и urge/pressure event. Например: normal, tired, rushed; missed move, loss streak, external distraction. Потом проверьте, меняется ли compliance или expectancy в этих группах.

Если связь не обнаруживается и поле не влияет на решения, его можно убрать. Журнал должен оставаться инструментом торговли, а не бесконечной анкетой.

Как проверять качество самого дневника

Раз в месяц проведите audit data quality: доля сделок без setup tag, пропущенные fees, несовпадение PnL с account statement, пустые stop fields, повторные trade IDs, неразмеченные manual exits. Если обязательные поля часто отсутствуют, проблема не в дисциплине трейдера, а в слишком сложной форме.

Хороший journal имеет высокий completion rate. Лучше восемь стабильно заполненных полей, чем сорок полей, половина которых пустая или заполнена задним числом.

Как связать дневник с будущим risk/reward-анализом

В этой статье risk/reward хранится как поле плана, но не становится главным предметом анализа. Следующий материал блока 06 отдельно разберёт, как считать planned и realized R/R, почему высокий target multiple не гарантирует положительное ожидание и как связать stop distance с position sizing.

Для текущего дневника достаточно сохранять planned risk, planned reward или exit rule и фактический R. Это обеспечивает данные для последующего анализа без каннибализации самостоятельного risk/reward-интента.

Не используйте один journal benchmark для всех стратегий

Сравнение с buy-and-hold, cash или другой базовой линией зависит от задачи. Для краткосрочной стратегии buy-and-hold может быть полезным контекстом, но не полным benchmark, потому что экспозиция и риск отличаются. Для market-neutral или hedge-стратегии нужен другой ориентир. Поэтому поле benchmark должно быть strategy-specific.

CME также рекомендует в trade log сравнивать результаты системы с альтернативными подходами, но смысл такого сравнения появляется только при сопоставимом горизонте и риске.

Не путайте торговую активность с продуктивностью

Большое число сделок не означает, что трейдер использовал больше возможностей. Journal должен показывать долю валидных сигналов, пропущенные сетапы, overtrading и результат на единицу turnover. Иногда лучший процесс после review приводит к меньшему количеству сделок и меньшим комиссиям.

Если активность растёт, а expectancy и compliance падают, это важнее самого количества исполненных ордеров.

Храните причину отменённого ордера отдельно от причины выхода из позиции

Cancel до fill и exit после открытия позиции — разные события. Лимитный ордер может быть снят из-за истечения времени, изменения структуры или технической ошибки. Эти отмены полезны для анализа fill rate и missed opportunities, но не должны считаться нулевыми сделками в win rate.

Такой distinction особенно важен для систем, где качество limit execution является частью edge.

Отдельно отмечайте изменения инфраструктуры

Смена площадки, fee tier, режима комиссий, источника данных или типа ордеров способна изменить результаты даже при неизменной стратегии. Добавьте infrastructure version или хотя бы дату такого изменения. Тогда ухудшение slippage после миграции не будет ошибочно приписано market regime.

Это особенно полезно для долгих журналов, где торговая среда постепенно меняется.

Сохраняйте raw data до любых исправлений

Если обнаружена ошибка импорта, не перезаписывайте исходный CSV или raw API response. Исправление выполняйте в производной таблице и оставляйте audit note. Тогда спорный расчёт можно воспроизвести и понять, где возникло расхождение.

Такая простая data lineage превращает журнал из личной таблицы в надёжный исследовательский архив.