Розробка індикатора Volume Delta: де ламається розрахунок
Дельта обсягу за угодами — це різниця між агресивними купівлями та продажами за інтервал часу. На неперервному потоці вона обчислюється однозначно, але індикатор бачить лише те, що йому віддав источник, і саме на цьому стику починаються розбіжності. Розробка індикатора Volume Delta впирається не у формулу, а в правила обробки вхідного потоку.
Незакрита свічка перезбирається за кожної нової угоди: значення, яке трейдер бачив хвилину тому, змінюється, а після закриття бару історичний перерахунок і потік у реальному часі можуть дати різні цифри.
Якщо стан розрахунку не зберігається між сесіями, після перезапуску накопичена дельта обнуляється, і картина за день перестає сходитися.
Друга точка відмови — втрачені угоди. Обрив з'єднання, пропущений пакет у стрічці або перемикання на резервне джерело залишають пропуск, який за агрегованими свічками не відновити: у них немає розбивки за стороною угоди. Саме тому розрахунок дельти обсягу вимагає контролю повноти потоку, а не лише коректної формули.
Третя причина — різне трактування агрегатів. Одні майданчики віддають сторону угоди явно, інші — лише ціну та обсяг, і сторону доводиться виводити за правилом: ціна на рівні ask — купівля, на рівні bid — продаж, усередині спреду — за попередньою угодою.
Від вибраного правила та кроку агрегації залежить підсумок, тому зовні однакові індикатори на двох платформах показують різну дельту.
Нижче — як ми закриваємо ці проблеми розрахунку індикатора: детерміноване ядро перерахунку, зберігання стану між сесіями та звірка результату зі стрічкою угод.
Що дає точний розрахунок дельти обсягу в торгівлі
Дельта обсягу в торгівлі — це різниця між агресивними купівлями та продажами за інтервал. Точність індикатора визначається тим, чи знає розрахунок сторону ініціатора за кожною угодою: з агрегованих барів вона відновлюється оцінно, з потоку угод з ознакою агресора — точно.
На змішаних барах помилка класифікації в 5–7% розвертає знак дельти та змінює висновок на протилежний, тому сторону угоди ми відновлюємо за стрічкою, а не за свічкою.
Хибні сигнали індикатора майже завжди народжуються на тонкому ринку: одна велика заявка без зустрічного обсягу дає сплеск, який алгоритм читає як розворотний потік.
Ми гасимо це порогом мінімального обсягу на інтервал і накопиченням дельти із затуханням — одинокі викиди поріг не пробивають, а серія інтервалів залишається видимою і не «схлопується» разом із ними.
Затримка оновлення розрахунку знімається інкрементальним перерахунком: оновлюється лише незакритий інтервал, агрегати попередніх беруться з кешу, тому значення на графіку змінюється в момент надходження угоди, а не після закриття бару.
Той самий розрахунок переноситься в TradingView і кастомні платформи — логіка одна, відрізняється лише шар відмальовування.
На тестових серіях це дає вимірюваний результат: частка спрацювань, які не підтвердилися рухом ціни, знижується вдвічі, розбіжність із біржовою стрічкою зменшується до меж одного інтервалу, а на малоліквідних парах дельта перестає «тремтіти» без потоку. Оцінюємо ваші ринки та джерела даних — повернемося з планом розрахунку.
Volume Delta: розрахунок за угодами проти агрегованих барів
Дельта — це різниця між обсягом агресивних купівель і агресивних продажів за інтервал. Точною вона буває лише за розрахунку за потоком угод біржі: у кожній угоді відома сторона ініціатора, тому покупець і продавець не зливаються в одну цифру.
Агрегований бар віддає лише набір OHLCV — напрямок ініціатора всередині нього вже втрачено.
Дельту на барах відновлюють евристикою, за закриттям щодо діапазону або за знаком руху ціни: на спокійній ділянці результат близький до точного, а на серії свічок із довгими тінями розбіжність стає помітною часткою обсягу.
Зворотний бік точності — вимоги до джерела. Повний потік угод біржі доступний у реальному часі та на обмежену глибину історії, тому власний архів доводиться накопичувати й стежити за розривами з'єднання. Вибір режиму — це обмін між точністю та вартістю супроводу.
| Режим розрахунку | Джерело даних | Точність | Стійкість до пропусків |
|---|---|---|---|
| За потоком угод | Канал угод біржі в реальному часі | Еталонна: сторона ініціатора відома | Вимагає контролю розривів і дозрахунку пропущеної ділянки |
| За агрегованими барами | Історія свічок будь-якого таймфрейму | Наближена, залежить від вибраної евристики | Висока: бар цілісний, пропуск відновлюється з історії |
| Гібрид | Потік угод на поточному вікні, бари на історії | Близька до еталонної на «гарячій» ділянці | Середня: потрібне зшивання джерел за міткою часу |
Ми закладаємо перемикання режимів на рівні налаштувань індикатора, а не окремої збірки: точний розрахунок там, де він важливий, і працездатний графік там, де потік угод недоступний.
Етапи впровадження: аудит, схема, налаштування, перевірка, передача
Індикатор Volume Delta починається не з коду, а з інвентаризації вхідних даних: якщо в потоці угод немає розділення обсягу за ініціатором, розрахунок дає гарну, але недостовірну картину. Порядок робіт вибудуваний так, щоб кожен наступний шар спирався на вже перевірений попередній.
- Аудит джерела даних — які потоки угод і агреговані бари доступні, чи є ознака ініціатора, з якою затримкою надходять оновлення, де можливі пропуски та перевідкриття.
- Схема розрахунку — правила агрегації у вікні, момент скидання накопиченого значення, поведінка на межі сесії та при зміні періоду. Підсумок — специфікація, за якою розрахунок відтворюється однозначно.
- Прототип і звірка — рахуємо на історичних даних і порівнюємо з ручним перерахунком контрольних ділянок; розбіжності розбираємо до причини, а не гасимо підгінним коефіцієнтом.
- Інтерфейс і параметри — набір керованих параметрів, значення за замовчуванням, поведінка графіка за неповних даних і перемиканні періодів.
- Тестування розрахунку — розриви котирувань, низька ліквідність, сплески обсягу, довгі вихідні, перерахунок історії: у кожного сценарію є очікуваний результат і перевірка.
- Передача в експлуатацію — вихідні коди, зібраний індикатор, інструкція зі встановлення та оновлення, розбір логіки з вашою командою.
На кожному етапі видно проміжний результат, тому правки не накопичуються до фіналу. Далі підтримку можна вести власними силами — ми не стаємо єдиною точкою відмови.
Склад постачання: модуль розрахунку, схеми та регламенти
Приймання індикатора — це не лише крива на графіку. Важливо, щоб розрахунок можна було перевірити, перенести на іншу платформу та супроводжувати без автора, тому в постачання входить комплект артефактів: від вихідних налаштувань розрахунку до регламенту оновлень.
- Модуль розрахунку. Код розділяє потік угод за стороною ініціатора та рахує дельту обсягу за заданим вікном. Параметри винесено в конфігурацію, а не зашито в тіло: вікно агрегації, поріг відсікання дрібних угод, згладжування, правила скидання накопиченого обсягу на відкритті нової сесії.
- Схема потоків даних. Звідки надходять угоди, де накопичується буфер, у який момент запускається перерахунок історії, що відбувається при розриві з'єднання і на яких даних тримається відмальовування.
- Документація до індикатора. Як читати сигнал, що означає розбіжність дельти з ціною, які значення вважаються аномальними та як змінювати пороги, не втрачаючи сенс розрахунку.
- Регламент супроводу. Порядок перевірки після змін платформи, перелік місць, які ламаються найчастіше, і критерії, за якими розрахунок визнається коректним.
- Перевірні набори. Контрольні зрізи угод і еталонні значення дельти, з якими звіряють збірку після будь-яких правок — розбіжність видно одразу, а не через тиждень торгів.
Окремим пунктом іде передача вихідних кодів і прав: репозиторій з історією змін і запуском однією командою. Якщо супровід залишається за нами, працюємо за тим самим регламентом, що описаний у постачанні.
Кейс: прибрали хибні розвороти на ф'ючерсах
До нас прийшла команда, що торгує ф'ючерсами на кількох біржах, із симптомом: індикатор дельти обсягу на TradingView і у власній панелі показував розворот там, де потік угод його не підтверджував.
Сигнал будувався на агрегованому барі, але під час звірки з первинним журналом угод сума купівель і продажів не сходилася: на волатильних ділянках розбіжність сягала 15%.
Що було
Бар збирався з потоку угод «як прийшов»: частина виконань губилася при обриві зв'язку, частина задвоювалася після відновлення, а угоди в момент перезбирання свічки потрапляли в сусідній бар.
Дельта зміщувалася, гістограма змінювала знак раніше за реальну перевагу покупців — на історії це давало близько третини хибних розворотів. На ф'ючерсному ринку з плечем такий сигнал обертається серією входів проти потоку.
Що змінили і що вийшло
Єдиним джерелом став первинний журнал угод з ідентифікатором виконання: дедуплікація за ним, а бар за будь-якого розриву з'єднання перезбирається з журналу заново.
Додали звірку контрольної суми дельти з незалежно отриманим потоком — розбіжність вище порогу позначає свічку як недостовірну й не віддає сигнал. Агрегацію винесли в сервіс, панель отримує вже перевірений результат.
Частка хибних розворотів упала з третини сигналів до 6–8%, розбіжність дельти з біржовим потоком — з 15% до менш ніж 1%.
Перерахунок активної свічки прискорився майже вдвічі, а пропуски при перепідключенні перестали впливати на відмальовування: свічка або достовірна, або позначена як недостовірна.
Що робити, якщо розрахунок уже впроваджено, але він розходиться з потоком?
Розбіжність майже ніколи не в самій формулі дельти — перевіряти треба шар даних. Індикатор може рахувати за агрегованими барами, тоді як потік угод іде тік за тіком: межі бару та торгової сесії у двох джерел не збігаються.
Достатньо різного часового поясу або правила перенесення обсягу на межі доби, щоб накопичена дельта розійшлася по всій історії, а не лише на останньому барі.
Друга часта причина — гілка реального часу. Обрив з'єднання, повторна доставка, пропущені угоди: обсяг або подвоюється, або губиться, і після перепідключення графік розходиться зі стрічкою.
Окремо дивимося на дедуплікацію та порядок застосування історії й поточних угод — якщо перерахунок історії затирає вже накопичене, значення «тремтить» на кожному оновленні.
Третя група — класифікація угод: аукціонні, позабіржові, що проходять без обсягу. Якщо розрахунок і потік враховують їх за різними правилами, дельта розходиться на рівному місці, і однаково виглядає як збій і на TradingView, і в кастомному терміналі.
Порядок робіт: аудит наявного розрахунку, звірка з потоком угод на контрольному інтервалі, локалізація шару — джерело, агрегація, реальний час, виведення.
Далі точкове доопрацювання готового рішення: змінюємо лише той шар, який дає розбіжність, і закриваємо його перевіркою на еталонному інтервалі. Повна переробка потрібна рідко — зазвичай достатньо кількох правок у конвеєрі даних.
Технічні питання: розрахунок, дані, підтримка
Розрахунок дельти обсягу спирається на напрямок угоди: ті, що пройшли за ціною пропозиції, ідуть у купівлі, за ціною попиту — у продажі, накопичена різниця дає лінію дельти.
Там, де майданчик віддає лише бари без потоку окремих угод, дельта відновлюється за структурою бару, і така оцінка позначається в налаштуваннях — інженер бачить, де дані точні, а де наближені.
Пропуск у потоці не замазується інтерполяцією: розрив позначається на графіку, буфер довантажується після перепідключення, розрахунок за пропущений інтервал перераховується. Гладка картинка тут шкідлива — інтерполяція створює фіктивні сплески дельти та хибні спрацювання.
Як рахується дельта там, де немає потоку окремих угод?
За барними даними: обсяг розподіляється всередині бару за типовою ціною та положенням у діапазоні. Похибка на ліквідних інструментах мала, на тонких помітна, тому режим розрахунку перемикається в налаштуваннях, а не схований усередині.
Що робити з пропусками в історії?
Довантажуємо ділянку з архіву майданчика або альтернативного джерела; за розбіжності пріоритет у біржового архіву. Якщо даних немає ніде, ділянка залишається порожньою та позначеною — дельта на ній не рахується.
Як підтримується індикатор при зміні формату даних?
Приймання даних виносимо в окремий шар адаптера: при зміні схеми правки стосуються одного модуля, логіка розрахунку та відмальовування не чіпається. Набір записаних сесій проганяється після кожного оновлення — регрес ловиться до викладки.
Обговоримо задачу та повернемося з планом і оцінкою робіт
Щоб розбір задачі інженером не розтягнувся на листування, вступні дані краще надіслати одразу — тоді ми повернемося зі схемою рішення, планом впровадження та межами робіт. Описувати можна вільним текстом, скриншотами поточних графіків і прикладами розрахунків.
Що допомагає нам точно оцінити обсяг робіт:
- Джерело даних. Звідки йдуть угоди: стрічка біржі, вивантаження з архіву, власний потік; який обсяг історії потрібен для перерахунку і чи є тестовий контур.
- Майданчик і середовище. Індикатор потрібен усередині TradingView, у власному терміналі чи одразу в двох місцях — від цього залежить і обсяг, і спосіб доставки даних.
- Логіка розрахунку. Як рахуєте дельту: за тіковими угодами чи за найкращими цінами попиту та пропозиції, яке вікно агрегації та згладжування використовуєте.
- Відображення та сигнали. Гістограма за барами, кумулятивна лінія, розбіжність ціни та обсягу, оповіщення про сплески — які елементи малюємо і коли подаємо сигнал.
- Навантаження. Скільки інструментів і таймфреймів відкрито одночасно і наскільки критичне відставання картинки від потоку.
- Інтеграції. Чи потрібне вивантаження сигналів у зовнішні системи та журналювання історії розрахунків.
- Обмеження та приймання. Доступи до даних, еталонні значення для звірки, критерії приймання результату.
Якщо частина вступних даних поки не визначена, надсилайте те, що є: прогалини закриємо на дзвінку та зафіксуємо припущення прямо в плані. Опишіть задачу — повернемося з оцінкою обсягу робіт і планом етапів.
