Logging the tick that triggered each entry

[Fairman]

Logging the tick that triggered each entry

When you review an EA's trades, the trade history gives you the entry price and time. It doesn't tell you what the EA saw when it decided to trade. For a scalping EA that reacts to individual ticks, that missing context makes it hard to tell whether a trade was a correct signal or a quirk of the feed.

So I log the triggering tick for every entry. When the entry condition becomes true, the EA writes a line with the bid, ask, spread, the tick time down to the millisecond, the values of whatever indicators it used, and the price of the previous tick. Then it sends the order.

Reviewing later, I can compare the triggering tick with the fill. If the trigger was a sudden spike in the bid that reversed a moment later, I know the entry was caused by a single noisy tick, not a real move. If the spread at trigger was double the usual, that explains a poor fill.

Over time, this lets you find patterns in your EA's behaviour that the trade history hides. For example, entries triggered by ticks with larger than normal gaps from the previous tick tend to perform differently from entries triggered during smooth price movement.

The log takes up very little space. One line per trade is nothing compared to what platforms store anyway.

[FXS HongKong Scalper]

Logging the trigger tick is very useful for reviewing EA behaviour. I would also log the server time and the local time of the machine together. If the two drift apart, for example on a VPS with a clock that is not synced, the logs become hard to match with broker statements. A one second drift does not matter for swing trading, but for tick based scalping it can make a correct signal look like a late one. Using TimeTradeServer next to TimeLocal in the log line keeps both visible.

[Fairman]

MQL5 gives you MqlTick with time_msc for millisecond timestamps, which makes this easier. In MQL4, you're limited to second resolution unless you use GetTickCount to approximate. If you're serious about tick level analysis, MT5 is the better platform. The extra precision matters when you're trying to work out the order of events within a single second. In MT4, it helps to log the sequence number of ticks within each second if precision matters. That way you can at least see which tick came first when several arrive within the same second, even if the exact milliseconds aren't available.

[Fairman]

Log the reason for the trade as well, especially if the EA has several entry conditions. A short code saying which rule triggered the entry makes analysis much simpler. Then you can see which rules produce the best entries and which produce noise. Without that, you only know the EA traded, not why, which makes it much harder to improve. Short codes work best for this, like BR for a breakout rule and PB for a pullback rule. They take up little space in the log and are easy to group in a spreadsheet when you review a month of trades.

[Fairman]

Save the logs in a format that's easy to load into a spreadsheet or a script, like CSV with a header row. Writing them as free text means you have to parse them later. A clean CSV with one row per entry makes it trivial to filter, sort and compare with the trade history from the broker using the ticket number as the link between them. Including the magic number and symbol in each row also helps when several EAs share a log folder. It keeps the data clean and lets you split results by EA without guessing which line came from which one.

[Fairman]

One thing to watch is that writing to a file on every tick slows down the EA. Only write on entries, not on every tick. If you need a tick history around entries, keep the last few dozen ticks in memory and dump them to the file only when a trade is opened. That gives you the context without the performance cost of constant writing. A ring buffer of the last fifty ticks is enough for most purposes. It costs almost nothing in memory and gives a clear picture of how price behaved just before each entry, which is often where the explanation for an odd trade sits.

[Shadow Trader]

A feed delivers a price that's 20 pips away from everything before and after it, for a single tick. It's a bad tick: a glitch, a data error, or an outlier quote from a single provider.

Charts show them as long wicks. Indicators react. A Bollinger Band widens, an ATR jumps, a stochastic spikes. A strategy that uses volatility to size stops now has wildly wrong inputs for the next several bars.

Brokers filter these to varying degrees. Some leave them in, claiming they reflect real quotes. Others scrub them from history but not from the live feed, so a backtest on cleaned data misses the issue that live trading faces.

Stop-losses can be triggered by bad ticks, which is controversial. Brokers sometimes reverse the trades afterward, sometimes not.

Defensive measures: filter extreme ticks in custom code, using a threshold such as ten times the recent average move. Use median-based indicators. Review live trading logs for unexplained stop-outs and check them against tick data.

Another effective filter is to compare each new tick against the previous few. If the price jumps by more than a set multiple of the recent average move, and returns within a second, flag it as a bad tick and ignore it in calculations. It's a few lines of code and can make indicators far calmer.

Anyone had a stop triggered by a bad tick, and did the broker reverse it?