> ## Documentation Index > Fetch the complete documentation index at: https://docs.useboom.ai/llms.txt > Use this file to discover all available pages before exploring further. # Guiding questions and variables > What the agent asks, what Boom extracts without asking, and how to decide which one a piece of information belongs in. Every conversation an initiative runs turns into data. Some of that data comes from things the agent **asks**. Some of it Boom **notices** on its own, by reading the conversation once it's over. Knowing which is which is most of what it takes to design a study that comes back with numbers you can use. | | Guiding questions | Variables | | - | - | - | | **Who sees it** | The agent. It's part of the brief it works from. | Only Boom's extraction. The agent's brief doesn't include your variables. | | **During the conversation** | The agent asks it, in order, and follows up as deep as you set. | Nothing. The agent never asks for a variable. | | **After the conversation** | Its answer is extracted as a variable. | Boom reads the whole conversation and fills it. | | **Good for** | What you need the person to tell you. | What shows up on its own: a classification, a flag, a list in the person's words. | ## Guiding questions: asked, then extracted Guiding questions are the topics every conversation should cover. You write them on the initiative, in the order you want them asked, and the agent decides how to phrase each one and when to bring it up. **Follow-up depth** sets how far it explores once it has an answer, from taking the first answer to digging deeper. Each guiding question **also becomes a variable**. When the conversation closes, Boom extracts the answer, typed by the question's answer type: | Answer type | What gets stored | | - | - | | **Open** | The answer, as text. | | **Yes / No** | Yes or no. | | **Multiple choice** | One of the options you listed. | | **Scale** | A number within the range you set. | So you don't need to repeat a guiding question as a variable. Its answer is already in the data. ## Variables: never asked, still captured A variable is a field Boom fills by reading the conversation **after it ends**. The agent doesn't know your variables exist, so it never asks for them and never steers the conversation toward them. The person talks about their experience; Boom notices what they said. That makes variables the right place for: * **A classification across the whole conversation.** Whether someone tried a feature once, keeps using it, or stopped. Nobody answers that in one message, but it's clear by the end. * **A flag.** Whether they mentioned a liquidation, an outage, a competitor, or asked to talk to a person. * **A list in the person's own words.** Features they asked for, bugs they reported, other tools they use. * **Something you shouldn't ask directly.** Which costs are on someone's radar is more honest when they name them unprompted than when the agent lists them. Variables come in the types described in [Extraction](/extraction): yes/no, a whole number, one value from a list, several values from a list, text, or a list of free text. ## Where variables come from On an initiative's **Data** step, under **What to extract**, Boom groups every variable by where it comes from: | Group | What it is | | - | - | | **Included by default** | Signals Boom adds to every initiative: sentiment, an alert flag, a summary, a key quote, and activity and quality levels. A reward-eligibility flag joins them when the initiative rewards participants. | | **Shared across your organization** | Fields your organization extracts on every initiative, such as topic, problem and competitor. | | **From your guiding questions** | One per guiding question, as above. | | **Your variables** | The ones you add with **Add custom variable**, specific to this initiative. | ## Variables you pass in are a third thing Don't confuse extracted variables with the **context** you send for each participant when you enroll them, such as a customer segment, a plan, or the date of their last purchase. That context goes to the agent before the conversation starts so it can adapt: talk differently to someone who used a feature once than to someone who uses it every week. Declare those fields on the initiative's context schema (set through the CSV upload in the app; see [Initiatives](/initiatives)). A useful pattern is to pass a segment in **and** extract the same dimension out. The extracted version records what the person actually said, so you can see where your segment and their story disagree. ## Writing variables that fill A variable is only as good as the share of conversations that fill it. Four rules make the difference: 1. **Anchor every variable to the study's objective.** Fields about side topics rarely come up, so they come back empty and add noise to the report. 2. **The description is the instruction.** Boom reads it to decide what to extract, so write it like a brief: what counts, what doesn't, and what to do when the conversation doesn't say. 3. **Give single-value fields an honest way out.** A yes/no, number, single choice or text field always gets a value. Add an option like "Not clear" or "Not mentioned" to a list so the model can abstain instead of guessing. Multi-value fields come back empty when there's no signal. 4. **Mirror what the agent offers.** If your guiding question tells the agent to suggest a few options when someone is stuck, use the same options as the variable's values, so the chart reflects what people were actually offered. ## A worked example A team wants to know why people try a new feature once and don't come back. **Guiding questions**, which the agent asks: 1. What made you try it? 2. Tell me about the first time you used it. 3. If you've used it again, what brings you back? If not, what stopped you? **Variables**, which the agent never asks: | Variable | Type | Values | | - | - | - | | `usage_pattern` | One value | Tried once / Uses it regularly / Used it and stopped / Not clear | | `stop_reasons` | Several values | The same options the agent offers in question 3 | | `costs_mentioned` | Several values | Fees / Time it takes / Risk / Other (only costs the person names) | | `features_requested` | Free-text list | In the person's words | | `requested_contact` | Yes / No | Asked for someone from the team to follow up | Someone replies *"I tried it once in March, the fees surprised me and I haven't been back."* Question 3 gets its answer, and without anyone asking, `usage_pattern` comes back "Tried once" and `costs_mentioned` comes back "Fees". ## When the data appears * **After the conversation closes.** Extraction runs when a conversation ends, for conversations with at least 3 messages and at least one reply. Someone who never answers produces no data. * **Set your variables before you launch.** A conversation is extracted against the variables that existed when it ran. You can re-run extraction on past conversations from the initiative's data view after a change. * **Where to read it.** The initiative's data view (**Answers**), insights, CSV exports, and the API, described in [Extraction](/extraction#reading-the-data-back). ## Related Variable types, limits, and setting a schema over the API or MCP. Objective, context, guiding questions and the context schema. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.