A business identifier attached to every instance, chosen at DESIGN TIME and unchangeable afterwards. Without it you cannot answer "what happened to invoice 4471" without reading payloads one by one.
This is the single highest-value decision in operating an integration, and it costs one field at design time.
Without a tracking variable, the console shows a list of instances identified by timestamp and status. Somebody asks what happened to invoice 4471. You have no way to find its instance except by opening runs one at a time and reading their payloads, and there may be four thousand of them from that day. In practice the answer becomes "I cannot tell you", which is how an integration acquires a reputation for being a black box.
WITH ONE, YOU SEARCH FOR 4471 AND GET THE INSTANCE. Its status, its activity stream, its failed step. The question takes ten seconds, and the same identifier is what a business user quotes when they report the problem.
"UNCHANGEABLE AFTERWARDS" IS THE WARNING IN THE TITLE. A tracking variable is fixed at design time, so it cannot be added to instances that have already run — you can change it for future runs, and everything before that change stays unsearchable forever. The moment you need it is the moment it is too late to add.
CHOOSE THE IDENTIFIER THE BUSINESS USES, NOT THE ONE THE SYSTEM USES. An internal surrogate key is useless to somebody phoning about an invoice; the invoice number is what they have. Where the flow spans several integrations, the right value is Module 10's correlation id, which is what turns four separate instances into one searchable story.
And Module 12 Lesson 8 constrains the choice: this value is visible to everyone with console access, so it must be an IDENTIFIER and never a name, a salary or a national id.