Кастомний індикатор замість вбудованого: де втрачається сигнал
Вбудовані індикатори побудовані на усередненій логіці: одна формула з однаковими значеннями за замовчуванням застосовується до будь-якого активу й будь-якого таймфрейму.
Ковзна середня, RSI, MACD або смуги Боллінджера не знають, що торгується — ліквідний спот чи тонкий альткоїн, де одна заявка зсуває ціну на відсотки.
Звідси запізнення сигналу: на момент, коли умову формально виконано, рух уже пройшов більшу частину шляху, а вхід припадає на його кінець.
Друге джерело втрат — згладжування. Чим сильніший фільтр шуму, тим пізніше індикатор відгукується на розворот; зменшуєш період — отримуєш хибні входи на кожному сплеску волатильності крипторинку.
Підбором параметрів це не лікується: компроміс між чутливістю та стійкістю закладено в саму конструкцію.
Типові параметри не описують реальні умови торгівлі. Ліквідність змінюється за годинами й днями тижня, нічні сесії тонші за денні, на деривативах працюють ставка фінансування й каскади ліквідацій, а сплески волатильності йдуть групами. Період, підібраний на одній ділянці історії, на іншій дає зовсім інший профіль входів і виходів.
Кастомний індикатор розв’язує не задачу «взяти іншу формулу», а задачу описати конкретні умови ринку: нормалізація за волатильністю, адаптивний період, пороги входу з урахуванням комісії та прослизання.
Така логіка перевіряється на історії та на даних, що не брали участі в налаштуванні. Далі розбираємо, як це збирається й де проходить межа між корисною доопрацюванням і підгонкою під минуле.
Що дає власний розрахунок: точність, швидкість, стійкість
Готовий індикатор рахує за формулою, яку не можна змінити: він або підтверджує вхід після закриття свічки, або згладжує рух так сильно, що сигнал приходить на відкаті.
Власний алгоритм розрахунку знімає це обмеження — момент появи сигналу зміщується на свічку, що формується, за того самого набору вихідних даних.
Хибні спрацювання дешевше відсікати до входу, а не розбирати після невдалої угоди. У розрахунок додаються підтверджувальні умови: сплеск обсягу, узгодженість зі старшим таймфреймом, положення ціни щодо меж накопиченого діапазону.
Фільтрація працює всередині логіки, а не поверх готового сигналу, тому частка хибних спрацювань на тестовому відрізку падає кратно.
Боковик — режим, де класичні осцилятори видають потік зустрічних сигналів і стратегія перевертається на кожному відскоку.
Тут вмикається класифікатор режиму ринку: за стисненням волатильності та структурою екстремумів алгоритм розпізнає діапазон і переводить розрахунок на роботу від меж. Кількість переворотів за порівнянний відрізок падає в рази, а просадка на флеті скорочується.
Потік котирувань обробляється інкрементально: угоди агрегуються у свічки, перераховуються лише змінені значення, а не весь масив історії.
Майданчики на кшталт Binance віддають дані різними за частотою каналами — ми зводимо їх до єдиної моделі й тримаємо стан розрахунку, щоб розрив зв’язку не призводив до перерахунку з нуля.
Ефект вимірюється трьома числами: наскільки раніше з’являється сигнал щодо закриття свічки, якою є частка хибних спрацювань на історичному відрізку і скільки разів логіка перевертається на боковику.
Ці метрики знімаються до і після правки розрахунку — так видно, що дала саме власна логіка, а не вдалий період ринку.
Варіанти реалізації: розрахунок у терміналі, сервіс або потік
У кастомного індикатора три принципово різні місця розрахунку, і вибір між ними визначає все інше: звідки береться історія котирувань, як швидко можна змінити формулу і хто отримає сигнал.
Помилка на цьому кроці стає видною пізніше — переписуванням архітектури індикатора, коли логіка вже навантажена користувачами.
Відштовхуватися варто не від зручності розробки, а від двох питань: де лежить історія котирувань і хто споживач сигналу. Нижче — три робочі схеми та обмеження, які кожна накладає.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Розрахунок у торговому терміналі | Індикатор потрібен вам одному в реальному часі, історія котирувань уже завантажена в TradingView або іншу платформу | Логіка прив’язана до конкретної платформи, поділитися сигналом із підписниками складно, важкі обчислення на великому вікні помітно гальмують графік |
| Зовнішній сервіс розрахунку | Індикатор потрібен багатьом, важливий однаковий результат у всіх і власна історія котирувань | Завантаження й зберігання історії ведете ви, сигнал приходить із затримкою на бар, з’являється окремий контур доступів |
| Потоковий розрахунок | Багато інструментів і висока частота, сигнали йдуть у бота або в зовнішню систему | Дорожче в підтримці, потрібен моніторинг потоку й відновлення після розривів, повторний перерахунок на історії складніший |
На практиці схеми комбінують: термінал — для швидкої перевірки ідеї, сервіс — для історії та однакових сигналів у всіх, потік — для розсилки. Обговоримо задачу й зберемо зв’язку під ваш сценарій.
Як будується робота: від постановки задачі до передавання коду
Кастомний індикатор — це не лінія поверх графіка, а розрахунковий конвеєр із перевірюваною поведінкою. Тому починаємо не з коду, а з аудиту даних і формалізації логіки: поки неясно, на якому потоці рахуємо і що саме рахуємо, реалізація просто відтворює помилки заднім числом. Нижче — етапи, за якими йде робота.
- Аудит ринкових даних. Звіряємо джерело, глибину історії та частоту; шукаємо пропуски, дублікати міток часу, перетини свічок і зміну режимів торгів.
- Формалізація торгової логіки. Перекладаємо «сигнал на затуханні імпульсу» у формальні умови: пороги, пріоритет сигналів, поведінку в боковику й заборону на майбутні значення.
- Схема розрахунку. Фіксуємо, що рахується за закритою свічкою, а що перераховується на кожному тіку: вікна, згладжування, буфери, захист від ділення на нуль.
- Налаштування параметрів. Підбираємо значення й перевіряємо стійкість — результат не повинен руйнуватися за невеликого зсуву вхідних параметрів.
- Перевірка на історії. Прогоняємо на тренді, боковику та сплесках волатильності: дивимося затримку сигналу, частку хибних спрацювань і поведінку на межах вибірки.
- Перевірка на живому потоці. Звіряємо розрахунок у реальному часі з історичним на тому самому інтервалі; розходження вище допуску розбираємо до причини — дані, округлення або порядок обробки.
- Приймання індикатора. Передаємо код, конфігурації, тести й документацію щодо параметрів та обмежень, разом проходимо контрольні сценарії.
Комплект передавання: вихідний код, документація, регламенти
Передавання — це не архів файлів, а комплект, за яким ваші інженери зможуть самі зібрати розрахунок, перевірити його на своїх даних і розвивати без нашої участі.
Склад фіксуємо в акті: кожен пункт закриває конкретний ризик — розходження у формулі, розрив у потоці котирувань, зупинку розрахунку без власника, доступ «відразу всім».
- Вихідний код індикатора — репозиторій з історією змін і коментарями до формул, а не зібраний артефакт: будь-яку правку видно порядково, відкат до попередньої ревізії займає хвилини.
- Опис розрахунку — які вхідні ряди беруться, як рахуються вікна усереднення, чим гасяться викиди й пропуски в котируваннях, які припущення закладено й де вони перестають працювати.
- Схема потоків даних — шлях від джерела котирувань до моменту, коли значення читає торговий контур, із точками контролю й описаною поведінкою під час обриву зв’язку.
- Регламент оновлення — хто і коли випускає нову версію, як перевіряється сумісність із уже накопиченою історією сигналів, де ведеться журнал правок параметрів.
- Права доступу до розрахунку — ролі: хто змінює параметри, хто лише читає значення, хто викочує в торговий контур; зміна параметрів пишеться в незмінний журнал.
- Тестовий контур — набір еталонних розрахунків на історичних даних: після будь-якої правки порівняння показує, які сигнали змінилися і чому.
- Інструкція з розгортання — порядок підняття з нуля в чистому середовищі, щоб відновлення після збою не залежало від нас.
Проходимо по комплекту разом із вашою командою на живих даних — так кожен пункт підтверджується до підписання, а не виявляється через місяць.
Кейс: розрахунок арбітражного спреду на потоці котирувань
Що було до
Індикатор рахував арбітражний спред за зведенням котирувань із шести майданчиків, але зведення збиралося періодичним опитуванням — раз на секунду. Затримка оповіщення сягала 4-6 секунд, а розходження цін живе менше: сигнал приходив, коли вікно вже закрилося. Сам спред рахувався за останньою угодою, без глибини стакана й комісій.
Розбір кейса почали з вимірювання: скільки живе розходження і на якій секунді після нього з’являвся сигнал. Метрика до — шість хибних входів із десяти.
Що змінили
Зведення котирувань перевели на потокові підписки, події з майданчиків зводяться до єдиної шкали часу з компенсацією розходження годинників.
Спред рахується за виконуваними заявками в стакані з урахуванням комісій і затримки виведення — цифра відображає реальну дохідність, а не різницю на графіку.
Шум придушували адаптивним фільтром Калмана, а поріг входу зробили плаваючим: він розширюється на волатильності й звужується на спокійному ринку.
Що стало
Затримка оповіщення — менше секунди, частка хибних входів упала з 60% до 12%. Сигналів на день стало менше, але частка прибуткових серед них зросла в рази: індикатор перестав реагувати на розходження, які неможливо виконати.
Кастомний індикатор винесли в окремий сервіс із журналом розрахунків — будь-який сигнал розбирається заднім числом: які котирування надійшли, який поріг діяв, де спрацювала фільтрація.
Чим відрізняється кастомний індикатор від вбудованого в термінал?
Штатний індикатор у терміналі — фіксована формула з відкритими налаштуваннями: період, тип згладжування, джерело ціни, іноді врахування обсягу. Змінюючи їх, ви регулюєте чутливість і запізнення, але не логіку розрахунку.
Можливості штатного розрахунку закінчуються там, де потрібен контекст за межами одного цінового ряду.
Нестандартні умови ринку — тонка ліквідність, затяжний флет, гепи на стику сесій, каскади ліквідацій — штатна формула згладжує разом із корисним сигналом.
Вона не бачить глибину книги заявок, ставку фінансування й розподіл обсягів за рівнями, а саме там найчастіше й лежить причина руху.
Кастомний індикатор збирається під вашу торгову логіку: які джерела беремо, як приводимо їх до спільного масштабу, який стан ринку вважаємо зміною режиму.
Умова входу перестає бути описом на словах і стає відтворюваною — її можна перерахувати на історії та звірити з фактичними угодами.
Межі застосовності важливіші за саму формулу. Пороги, підібрані на одному інструменті й одному режимі волатильності, на іншому активі дають хибні спрацювання. Тому фіксуємо, на яких даних рахувалися пороги, за яких режимів індикатор мовчить і коли сигнал вважається недійсним.
Критерій вибору простий: якщо задача зводиться до підбору пари параметрів, вистачить вбудованого розрахунку. Щойно потрібні власні дані, власна логіка й явні межі — це розробка кастомного індикатора. Опишіть задачу — повернемося з оцінкою та планом.
Часті питання: джерела даних, затримки, перерахунок історії
Індикатор чесний лише тоді, коли вхідні дані повні й однакові за кожного прогону. Тому до першого рядка коду розбираємо три речі: звідки береться історія котирувань, що відбувається під час розривів потоку і як унеможливити підгонку логіки під минулі рухи ціни.
Розриви не затираємо мовчки: пропущені інтервали позначаються, довантажуються з резервного джерела й залишаються в журналі перерахунку.
Під час зведення кількох майданчиків дані приводяться до єдиної шкали часу й однієї бази розрахунку — інакше різні типи свічок і різні межі доби дають хибні сигнали на стиках.
Що робити, якщо історія котирувань неповна?
Неповнота фіксується, а не приховується: рахуємо частку пропущених інтервалів за кожним інструментом, довантажуємо їх із другого джерела й позначаємо відновлені ділянки. На них індикатор або не видає сигнал, або позначає його як ненадійний — замість тихої підміни нулями.
Як ви захищаєтеся від підгонки під минулі рухи ціни?
Логіка перевіряється на відрізках, які не брали участі в налаштуванні: параметри підбираються на одному періоді й перевіряються на наступних, включно з ділянками різких рухів і боковим рухом. Якщо результат тримається лише в одному стані ринку — параметри перезбираються.
Наскільки точний перерахунок під час зведення кількох майданчиків?
Перерахунок іде на однаковому наборі інструментів і однаковому вікні за кожного запуску, тому результат відтворюється точка в точку. Розходження двох перерахунків на тій самій історії вважаємо помилкою, а не допустимим шумом.
Обговоримо задачу й повернемося з оцінкою та планом робіт
Щоб розмова була предметною, до звернення достатньо додати те, що вже є під рукою: вивантаження історії свічок або угод за період, чернетку логіки розрахунку — хай навіть у вигляді тексту чи таблиці, — і опис того, як сигнал має виглядати на графіку.
Якщо індикатор уже реалізовано на іншій платформі, надішліть вихідник і скриншоти поведінки: за ними відразу видно розходження, які зазвичай спливають під час перенесення.
На першій розмові розберемо:
- склад даних: глибина історії, чи є окремі угоди, як поводимося на розривах котирувань і пропусках;
- логіку розрахунку: вікно згладжування, реакцію на різкі рухи, поведінку за низької ліквідності;
- ринки та часові інтервали, на яких індикатор зобов’язаний давати однаковий результат;
- форму виведення: окрема панель, мітки на графіку, рівні або оповіщення;
- що вже напрацьовано: прототип, чужий код, готові модулі, які потрібно перевикористати;
- критерії приймання: на яких ділянках історії звіряємо значення і що вважаємо розходженням;
- обмеження за термінами та порядком упровадження.
За підсумками повернемося з планом робіт: етапи, що потрібно з вашого боку, у якій послідовності випускаємо розрахункове ядро й візуальну частину. Опишіть задачу в двох абзацах — цього вистачить, щоб назвати терміни й склад першого етапу.
