Zdefiniuj ramę czasową wejścia, zanim zaczniesz ją oceniać
Częsty błąd polega na traktowaniu „Entry Timeframe” jako pojedynczej, gwarantowanej reguły decyzyjnej. W praktyce „Entry Timeframe” oznacza konkretny okres wykresu, którego używasz do podjęcia decyzji o tym, kiedy następuje wejście (na przykład wybraną ramę czasową świecy, na której oceniana jest logika wejścia). Gdy ta definicja jest nieostra, ludzie przypadkowo mieszają ze sobą różne idee — takie jak ramy czasowe sygnału, moment realizacji i okres utrzymania — a potem obwiniają samą koncepcję zamiast metody.
Niezależne sprawdzenie (neutralne): zapisz, jaką ramę czasową wykorzystujesz dla decyzji oraz jaką ramę czasową wykorzystujesz tylko dla kontekstu. Jeśli nie potrafisz wskazać różnicy w jednym zdaniu, Twoja „Entry Timeframe” nie jest dobrze zdefiniowana.
Mylić ramę czasową decyzji z realizacją i kosztami
Kolejny częsty błąd polega na założeniu, że wybrana rama czasowa wejścia automatycznie przekłada się na realistyczne wypełnienie (fill). Realizacja zależy od mikrostruktury rynku (czyli tego, jak wypełniają się zlecenia), płynności dostawcy, spreadów oraz momentu składania zleceń — czynników, które mogą się zmieniać nawet wtedy, gdy Twoje reguły wykresu pozostają stałe. Jeśli testujesz lub wyjaśniasz „Entry Timeframe” przy użyciu zidealizowanych wypełnień (na przykład „wejście dokładnie na otwarciu świecy”), możesz niechcący mierzyć coś innego niż rzeczywisty proces.
Neutralne sprawdzenie: oddziel to, co Twoja reguła określa (punkt decyzyjny) od tego, co zakładasz dla realizacji (cena wypełnienia, poślizg, prowizje/opłaty). Jeśli Twoje założenia nie są jawne, wyniki mogą wyglądać spójnie w backtestach, a później rozjechać się w rzeczywistości.
Używać niespójnych założeń przy liczeniu przykładów
Ludzie popełniają też błędy w obliczeniach: zmieniają założenia w trakcie, na przykład używając jednej ramy czasowej dla setupu, a innej dla wyzwalacza wejścia, albo traktując „zgodność czasową” jako nieistotną. W rozumowaniu wieloramowym (multi-timeframe) mapowanie świecy z jednego okresu na świecę z innego okresu może mieć znaczenie (na przykład, czy wymagasz, aby warunek z wyższej ramy czasowej był już spełniony, zanim podejmiesz decyzję o wejściu na niższej ramie czasowej).
Istotne ograniczenie: zależności widoczne w historycznych świecach nie muszą automatycznie utrzymywać się w przyszłych warunkach.
Reguła założeń: dla każdego przepracowanego przykładu podaj (1) ramę czasową decyzji, (2) dokładny warunek, którego używasz (np. „warunek musi być spełniony na zamknięciu świecy” vs „na dotknięciu świecy”), oraz (3) czy wejście jest modelowane na otwarciu, na zamknięciu czy po potwierdzeniu. Bez tego porównania nie są „jabłko do jabłka”.
Ignorować przynajmniej jeden tryb porażki
Istotnym trybem porażki jest „timing mismatch” (niedopasowanie czasowe): Twoja „Entry Timeframe” generuje późne wejścia względem ruchu, który próbowałeś przechwycić, albo generuje wejścia w warunkach niskiej jakości (na przykład podczas szybkich przejść, gdy wybrana rama czasowa aktualizuje się rzadziej). Innym jest „regime change” (zmiana reżimu): wzorce zmienności i korelacji mogą się przesuwać, więc ta sama logika decyzyjna oparta na ramie czasowej może zachowywać się inaczej.
Neutralne sprawdzenia, które możesz wykonać koncepcyjnie (bez danych):
- Zapytaj, co się stanie, jeśli świeca decyzyjna zostanie potwierdzona o jeden krok później, niż się spodziewałeś.
- Zapytaj, co się stanie, jeśli koszty i tarcia realizacyjne wzrosną.
- Sprawdź, czy Twoja reguła nadal ma sens, gdy świece stają się bardziej lub mniej zmienne.
Zweryfikować za pomocą jasnej checklisty i pytania „co by to obaliło?”
Aby ograniczyć nieporozumienia związane z „Entry Timeframe”, stosuj nastawienie weryfikacyjne zamiast nastawienia na pewność. Proste podejście kontrolne (control-checklist):
- AFVINK (doprecyzuj dane wejściowe): Jaka dokładnie jest rama czasowa decyzji?
- Udokumentuj dowody: czego reguła wymagała na każdym etapie (i kiedy)?
- Sygnały ostrzegawcze: czy zakładałeś idealną realizację albo pominąłeś koszty?
- KLAAR (kryterium zakończenia): Czy potrafisz wskazać, jakie obserwacje pokażą, że podejście nie działa w ramach Twoich zadeklarowanych założeń?
Przykład Klaarcriterium (neutralne): „Jeśli wejścia zależą od konkretnego założenia dotyczącego granicy świecy (open vs close), aby wyglądały dobrze, to podejście nie jest odporne na to założenie.”
Jeśli chcesz pójść o jeden poziom głębiej, skup kolejne sprawdzenie na tym, czy Twoje wyjaśnienie pasuje do Twojego rzeczywistego momentu podejmowania decyzji: moment decyzji, moment realizacji i okres utrzymania są różne, a „Entry Timeframe” kontroluje tylko pierwszy z nich.