Identify the Research Questions
From business problem to researchable question
This domain tests whether you can convert a stakeholder's concern into a question that data can actually answer. Know the sequence: elicit the business need, state the problem in measurable terms, identify the decision the analysis will inform, then write research questions and, where appropriate, testable hypotheses. Know the four analytics intents - descriptive (what happened), diagnostic (why), predictive (what will happen), prescriptive (what should we do) - and how the intent determines data and method.
Scope matters: population, time window, unit of analysis (customer, transaction, branch), and success criteria belong in the question itself. Assumptions and constraints (budget, access, regulation) should be recorded, not silently absorbed.
Traps. The commonest is answering "what data do we have?" instead of "what decision are we making?" - a data-first question produces analysis nobody uses. Others: questions too vague to falsify ("improve customer experience"), smuggling a solution into the question ("should we build an app?"), skipping stakeholder validation so the question drifts, and scope that quietly expands mid-project.
Rule of thumb - the decision test. If you cannot name the decision, the decision-maker, and the metric that would change, the question is not ready. Rewrite "sales are down" as: "Among customers acquired in the last 12 months (population), does onboarding email frequency (factor) affect 90-day retention (outcome), and is any effect large enough to justify changing the campaign?" That version names population, factor, outcome, timeframe and a practical threshold - all of which drive sourcing and analysis downstream.