# Tips & best practices

Practical guidance for **clearer charts**, **fewer misreads**, and **smoother integration** with the rest of your terminal.

***

### Tick size

* **Too fine:** Rows multiply, text crowds, performance and readability suffer. Zoom may **aggregate** rows, but the underlying choice still matters.
* **Too coarse:** You lose **granularity**; separate prints collapse into one bucket.

**Heuristic:** Start near **1/10 to 1/20 of the average bar range** on your working timeframe, then adjust per instrument. Crypto often uses **round steps** aligned to exchange tick tables.

Document your tick choice per symbol so **support and training** stay consistent.

***

### Zoom and bar width

* **Wide bars:** Bid×Ask **split labels** and **footers** (V / Δ) appear when space allows.
* **Narrow bars:** The engine **simplifies** (blocks or candles) — this is intentional for **frame rate** and clarity.

If users complain numbers “disappear,” explain **zoom in** or **wider timeframe bars** (fewer candles on screen).

***

### Mode selection

| Situation                             | Suggested mode |
| ------------------------------------- | -------------- |
| Learning / detailed review            | **Bid×Ask**    |
| Scanning aggression fast              | **Delta**      |
| Locating **size** without side detail | **Volume**     |

Switching modes is **cheap cognitively** once users know **one story per mode**.

***

### Profile panel

* Use the **profile** when you want a **fixed-width** reading of the **latest** (or active) bar while **panning** history.
* Remember the profile is **linked to footprint data** — if trades are missing, both chart and profile are **incomplete**.

***

### Data quality

* **Footprint is only as good as the tape.** Delayed or **partial** trade feeds produce **false** imbalances.
* Align **bar boundaries** (time zone, session, exchange clock) with **trade timestamps** to avoid **splitting** trades across bars incorrectly.

***

### Performance (applications)

* Prefer **batched** trade ingestion (`footprintAddTradeBatch`) on WebSocket bursts (see Footprint Chart API).
* Avoid **per-trade** synchronous work on the main thread beyond enqueueing to the engine.

***

### UX copy for end users

Suggested one-liners for tooltips or settings:

* **Bid×Ask:** “Show aggressive buy vs sell volume at each price.”
* **Delta:** “Show net buy–sell volume per price.”
* **Volume:** “Show total traded size per price; color by net delta.”
* **Signals:** “Highlight absorption, imbalances, and other footprint patterns.”

***

### Common mistakes

1. **Reading one bar in a vacuum** — always add **context** (trend, level, session).
2. **Ignoring tick size** — changing ticks **changes** the story; compare bars with **consistent** settings.
3. **Treating signals as the holy grail** — use **backtest/forward test** in your **own** market hours.
4. **Mixing maker/taker flags** — incorrect **isBuyerMaker** mapping **inverts** bid/ask; verify against your feed’s spec.

***

### Further reading

* Introduction
* Display modes
* Reading & analysis
* Signals & trade ideas
* Footprint Chart — developer API


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.mrd-indicators.com/terminal/widget/footprint-chart/tips-and-best-practices.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.