Set up MaxData around your goal: charts, alerts, backtests and automation

This is educational product content associated with MaxData, including an invitation to create an account. Product descriptions below are attributed to the linked help materials. Our proposed workflows are editorial recommendations, with no promised trading outcome.

Start with a question you can finish

Our proposed starting point is a small, observable task: “I want to watch this series and receive a message when this written condition is met.” Choose an instrument, an observation interval and a review time. For your first session, aim to save one chart, describe one alert and document one notification check. Treat those as completion criteria for learning the configuration.

For a beginner, we suggest a notebook entry that another person could follow. For an active analyst, we suggest a hypothesis with an explicit review horizon. For an advanced user, we suggest a written separation between the data condition, notification delivery and any intended automated action. These are our proposed working conventions, rather than measures of trading performance.

The official Help Hub introduces MaxData Info Bot as an assistant for questions about MaxData and the workspace. MaxData Help Hub. [E1]

Under our proposed support convention, ask a specific question: name the view, describe the setting you chose and explain the result you expected. Include the step where your observation differed from that expectation. Keep access keys and authentication details out of the example. If a control mentioned in this guide is absent from your interface, ask support to identify the corresponding setting before proceeding.

Make your chart reproducible

The English Max Terminal guide identifies the Indicator option for adding indicators in Pro Charts. Max Terminal guide. [E2]

Our proposed first exercise is to choose one instrument and one series, then save the view under a name that states the question. An example working title is “price observation — evening review”. Use it as a naming example, without treating it as a trade idea. Before adding a second series, write down what extra question it would address.

Attach our proposed data note to the saved view:

• Definition: what does this series measure, and in which units?
• Source: which provider, venue or data scope have you selected?
• Interval: what time unit are you observing?
• Update delay: what has been confirmed for this particular series?
• Horizon: when will you revisit the observation?
• Limits: what information remains unresolved?

For this workflow, enter “unconfirmed” when you cannot establish an update delay. We do not assign a common delay to every metric. Keep the data interval and your planned review horizon in separate fields. Write an alternative explanation for the pattern you intend to observe, and specify what missing information would prevent you from interpreting it.

As an editorial completion rule, do not advance beyond the chart exercise until you can reopen the view and explain its settings. A saved picture is not the completion criterion we propose; a documented configuration is.

Express the alert before configuring it

The English Pro Alerts guide distinguishes an Alert with a single condition from a Pro Alert combining several conditions. Its setup instructions say the metric must be visible on the chart, describe right-clicking the Pro Charts screen, and place subsequent editing in the right sidebar. For a Pro Alert, the instructions call for at least two existing alerts. Pro Alerts guide. [E3]

Our proposed workflow is to write the condition in plain language first. Include the series name, comparison, threshold and reference period. Label any example threshold as a practice parameter. Then configure the corresponding fields and read the completed form back into a sentence. If the sentence has changed, revisit the settings before saving.

The guide describes a condition window, a sleep period after activation, a choice of activation when a condition begins, remains or stops being met, one-time or repeated triggering, expiration, and data choices including open, close, minimum, maximum and average. Alert settings. [E4]

Our proposed checklist gives each setting its own line. Prepare three written cases: one that meets the condition, one that does not, and one at the boundary. For a combined alert, repeat the exercise for every component and for the time window. Do not use “several conditions” as shorthand for logic you have not yet described.

We suggest names in the form “instrument — condition — version”. Record a new version when you change the threshold, source or timing. Add a reason for the change and a planned review date. This is our notebook convention, not a claim about an application versioning feature.

Check delivery separately from the condition

The English alert guide lists phone, SMS, email, Telegram and browser notifications. Notification description. [E5]

Our proposed delivery exercise uses one channel that you can identify in your account. Confirm its setup and record a test result where a test facility is available. Do not assume that every channel named in a help article is enabled for your account. Ask support about any channel whose availability or configuration remains unclear.

In our proposed journal, keep three timestamps separate: the data observation, the recorded alert activation and receipt of the message. Mark unknown timestamps explicitly. Describe what you observed rather than assigning a cause to a missing message.

For troubleshooting, we suggest a three-part support note: the intended condition, evidence of activation if available, and the delivery result. Add the expected behaviour and the exact point where your observation diverged. Use this structure again after changing a channel or alert setting. Keep the alert logic review and the delivery review as distinct tasks in your notes.

Read the backtest as a historical exercise

The English backtest guide describes checking how often an Alert or Pro Alert would have triggered in a selected historical period. It describes average and median price-change lines before and after activation, and says testing can cover a single condition or several conditions together. Backtests guide. [E6]

Its procedure includes selecting components, building the Pro Alert, initiating a backtest, choosing the period and reviewing trigger frequency and the result chart. Backtest procedure. [E7]

Our proposed test record starts with the alert version, instrument, historical range, trigger count and observation horizon after each event. Add the intended exit rule if your evaluation includes exits. Keep an event-price observation and a proposed execution scenario in separate sections of the record.

For execution questions, the Polish backtest material identifies fees and slippage as possible differences between historical modelling and implementation. It also describes simulations involving take profit, stop loss and timed exits. Polish backtest reference. [E8]

Our proposed evaluation checklist asks you to document costs, slippage assumptions, liquidity assumptions and the treatment of overlapping events. Ask support about any assumption the report does not explain. Leave an unresolved field visibly unresolved; do not silently substitute zero costs or unlimited execution capacity.

For our editorial workflow, historical results belong to the tested period and recorded parameters. Do not turn them into a forecast of yearly returns. Write an alternative hypothesis, such as the possibility that the observed pattern belongs to one selected historical segment. Set aside a separate period for checking that hypothesis, and record the parameters before examining it.

To address fitting choices to history, our proposed convention is to list every parameter variant examined, including rejected variants. Write the conditions that would invalidate your interpretation: an unexplained sample, a changed data definition, an unreproducible configuration or unresolved execution assumptions. These are our proposed review gates, not evidence that an alert is profitable.

Write the oversight plan before automation

The English Max Terminal guide describes trading automations based on Pro Alerts and the use of Pro Alerts as stop-loss triggers within automations. Automation description in Max Terminal. [E9]

Our proposed automation preparation begins with a one-page map: trigger, permitted action, instrument scope, action limit, exit rule and review owner. Confirm the meaning of each relevant interface field with the product help before considering activation. We do not provide a universal allocation, loss threshold or trading parameter.

Begin our proposed sequence by observing notifications without placing trades. Next, document where you would review actions and how you would stop the process. Identify the person responsible for an unexpected-event review. Write a rule requiring another configuration check before restarting after such an event.

Use “controlled automation” here as the name of this proposed oversight workflow. It carries no promise about execution, returns or capital protection. Finish by checking whether you can explain the data, the alert condition, message delivery, the historical test and the review responsibility. Choose your next learning task from whichever answer is still incomplete.