Supported strategy patterns and limitations

Algo Trade Analytics compares events. A backtest entry can match an alert entry, and an alert can later match a broker-reported fill, only when the records describe the same symbol, strategy, direction, time, and quantity clearly enough.

This page describes the patterns the comparison workflow can interpret. It does not prescribe trading logic or make a strategy suitable for live capital.

Use explicit event intent

For webhook events, send one of the four canonical positionDirection values:

Strategy event	positionDirection	Typical side
Open or add to a long position	entryLong	buy
Close or reduce a long position	exitLong	sell
Open or add to a short position	entryShort	sell
Close or reduce a short position	exitShort	buy

Do not make the matcher infer entry versus exit from a generic buy or sell label. The full accepted payload is documented in the Webhook API reference.

Keep strategy identity stable

Include a strategy name in every payload, especially when more than one strategy uses the same symbol. The server accepts either a top-level strategy field or metadata.strategy; the top-level value wins when both exist.

If the name is omitted, the server may inherit a name from an earlier order or fall back to the webhook connection name. That keeps the event usable, but it is less reliable than sending the identity explicitly.

Treat every order leg as its own event

The comparison can preserve multiple entries and partial exits, but each expected leg still needs its own timestamp, direction, price, and quantity. Pyramiding, scaling, and partial exits are therefore reviewable only when the TradingView export and webhook stream expose the same individual legs.

When those sources aggregate position changes differently, expect unmatched rows or quantity differences. Do not collapse them by widening tolerances until the records appear to agree.

Keep TradingView settings with the evidence

These strategy properties can materially change when orders are created or filled:

• pyramiding
• calc_on_every_tick
• calc_on_order_fills
• process_orders_on_close
• order-size, commission, slippage, and margin settings

There is no universally correct value for these fields. Preserve the values used by the run and compare like with like. Changing a timing property to improve a match rate creates a new strategy variant; it does not repair the evidence from the old run.

Historical and realtime execution can differ

Intrabar recalculation, order-fill recalculation, non-standard chart prices, and the broker emulator can make historical behavior differ from realtime alerts. Investigate the event rows before assigning a mismatch to repainting or delivery latency.

Prefer order-fill alert messages

For a Pine strategy, attach the JSON payload to the existing strategy.entry(), strategy.exit(), strategy.close(), or strategy.order() call with alert_message. In TradingView’s alert dialog, set Message to:

{{strategy.order.alert_message}}

This keeps the alert message on the same order path as the strategy event. It also avoids maintaining a second set of alert conditions that can drift away from the backtest logic.

Use the Webhook action in the Algo Lab Editor if you want the Algo Agent to propose this wiring. Review the diff before applying it, then verify one event in the Webhooks event log.

Verification checklist

Before interpreting a comparison, confirm that:

• the TradingView chart symbol and timeframe match the uploaded export;
• the strategy name is consistent across the export and webhook payloads;
• every event has a canonical entry/exit and long/short intent;
• quantity uses the same unit in both sources;
• multi-leg positions produce separate records in both sources; and
• the comparison tolerances describe expected clock or price variance rather than hiding a logic mismatch.

Next, configure the webhook or run the paired sample comparison.