Planning Data Sourcing Activities

Planning Data Sourcing Activities

Quick Answer: Domain 2 (Source Data, about 15% of the CBDA exam) begins with planning what data you need to answer approved research questions—not with downloading every table you can reach. Competency 2.1 focuses on identifying required data elements, assessing availability, documenting gaps, and adjusting the sourcing plan when expected data is incomplete or unreliable.

Domain 1 left you with framed business situations, scope, assumptions, and research questions. Domain 2 turns those questions into a sourcing plan: which fields, at what grain, for which population and time window, from which candidate systems, under which access and quality constraints. Teams that skip this planning either drown in irrelevant extracts or discover too late that the question cannot be answered with current sources.

Competency 2.1: What data is needed?

Plan data sourcing means answering, for each research question:

1. What entities and attributes must exist (customers, orders, tickets, claims, sensors, employees)?
2. At what grain must each row represent reality (order line, daily store, monthly cohort, claim event)?
3. Over what time window must history cover the decision (last 90 days, last fiscal year, post-policy-change only)?
4. For which population (segment, region, product family, channel)?
5. With what freshness (as-of yesterday batch, weekly snapshot, near-real-time)?
6. Under what rights and privacy rules (PII, PHI, commercial third-party licenses)?

Only after those answers are clear do you shop systems, vendors, surveys, or manual collection. On exam stems, “pull all CRM data” without this map is almost always a weak next step.

Required vs nice-to-have

Separate must-have fields that make the question answerable from enrichment fields that improve insight but are not blocking:

CBDA planning rewards honest minimum viable data for the decision, then phased enrichment—not a “data lake first, question later” posture.

Map research questions → data elements, grain, time window

A practical technique is a question-to-data matrix. One row per research question (or sub-question); columns for elements, grain, window, population, candidate sources, and status.

Example: mid-market SaaS retention

Research question: Which mid-tenure online subscribers show elevated voluntary churn that is actionable with the current offer catalog?

Notice the map does not yet name “use Snowflake table X.” It names business data needs. Source selection comes next, using inventory and fitness checks.

Grain mistakes that break analysis later

• Too coarse: Monthly revenue by region cannot answer SKU-level assortment questions.
• Too fine without keys: Clickstream events without stable customer keys cannot support subscriber-level churn drivers.
• Mixed grain joins: Order headers joined carelessly to order lines inflate revenue and create false correlations.
• Wrong event time: Using “load date” instead of “business event date” misplaces pre/post policy windows.

Document grain in the sourcing plan so engineers and SMEs validate the same unit of analysis the research question assumes.

Time window discipline

Time windows must match the decision and the process reality:

• Seasonal businesses need comparable seasons, not an arbitrary last-30-days slice.
• Policy changes create natural breakpoints; mixing pre/post regimes without flags confounds diagnostics.
• Very long windows increase coverage but may include obsolete product definitions.
• Very short windows may miss rare but costly events.

On CBDA scenarios, if a stakeholder wants “all history forever,” the BA often negotiates a fit-for-purpose window tied to decision relevance and definition stability.

BA expertise: required vs available

The business analyst’s contribution in Domain 2 is not limited to writing tickets for IT. CBDA expects BAs to:

• Translate research language into business data language (“voluntary churn” → specific cancel reason codes and exclusions).
• Challenge “we have that data” claims by asking where it lives, who owns it, how complete it is, and whether definitions match.
• Surface process knowledge that systems miss (manual workarounds, regional spreadsheets, shadow CRM fields).
• Protect decision fit: if available data answers a different question, say so and re-scope rather than force a narrative.
• Coordinate owners and stewards for access, dictionary confirmation, and quality expectations.
• Keep ethics and privacy in the plan so acquisition does not outrun consent and policy.

Required vs available assessment pattern

1. List required elements from the research question.
2. For each element, record candidate source, owner, known definition, and confidence (confirmed / assumed / unknown).
3. Mark status: available & fit, available but risky, partial, unavailable.
4. For risky/partial/unavailable items, define actions: profile sample, interview steward, seek alternative source, collect primary data, or refine the question.
5. Update assumptions and dependencies from Domain 1 with evidence from this assessment.

This is where Domain 1 assumptions become Domain 2 work: “warehouse has two years of clean churn flags” is no longer a hope—it is a checklist item.

When expected data is unreliable: re-evaluate sourcing (exam theme)

A recurring IIBA-style theme: you planned on a source, then profiling or SME review shows the data is incomplete, inconsistently defined, late, or legally restricted. What is the next step?

Re-evaluate sourcing can include:

• Switching from CRM cancel flags to billing termination events if CRM is sparsely maintained.
• Using store-level sales when item-level POS is delayed—but only if the research question can be restated at store grain.
• Commissioning a short survey when attitudinal drivers are essential and systems only hold transactions.
• Purchasing a third-party firmographic feed after rights review when internal firmographics are empty.
• Narrowing population to regions with reliable data and stating external validity limits.

Only after feasible sourcing paths are exhausted—or when remaining paths cannot meet decision timing—do you renegotiate the research question with stakeholders. Abandoning the question as the first response is usually wrong on exam items; so is pretending the original question is still fully answerable.

Mini-scenario

Plan: Use CRM “reason for leave” to diagnose voluntary churn drivers.
Finding: 55% of churned accounts have blank or “other” reasons; agents say the field is optional.
Poor next step: Cancel the churn study.
Better next steps: (1) Profile billing and product-usage signals as alternative diagnostic inputs; (2) sample call notes if allowed; (3) propose a time-boxed improvement to reason-code capture for future cycles; (4) restate near-term question toward behavioral drivers that systems do capture. That is re-evaluating sourcing and, if needed, refining—not abandoning—the analytical intent.

Data inventory and gap list

Data inventory (what we might use)

A data inventory for an analytics effort is a working catalog of candidate datasets relevant to the research questions. Minimum useful fields:

• Dataset / system name
• Business owner and technical contact
• Entities covered and primary keys
• Known grain and refresh cadence
• Access path (warehouse table, API, extract, manual file)
• Sensitivity classification (public, internal, confidential, restricted)
• Known quality issues or dictionary links
• Fit rating for each research question (high / medium / low / unknown)

You do not need a perfect enterprise catalog on day one. You need enough inventory that the team stops relying on hallway knowledge.

Gap list (what we still lack)

A gap list converts inventory into action:

Gaps should be visible to sponsors. They are not project failure—they are the sourcing plan’s risk register.

Planning activities checklist (Domain 2 start)

1. Restate approved research questions and success criteria.
2. Build the question-to-data matrix (elements, grain, window, population).
3. Draft inventory of candidate internal/external sources.
4. Confirm definitions with SMEs for must-have fields.
5. Assess availability, access path, rights, and preliminary quality.
6. Produce gap list with options and owners.
7. Choose primary sourcing approach and fallbacks.
8. Update assumptions, constraints, and dependencies.
9. Get light approval on the sourcing plan before large extracts or purchases.
10. Only then schedule acquisition, profiling, and preparation (covered deeper in later Domain 2 chapters).

Linking plan-sourcing to later work

• Source types and acquisition: Inventory items become concrete lakes, warehouses, APIs, or vendor feeds (next sections).
• Quality and preparation: Gap severity drives cleaning, sampling, and integrity work.
• Analysis: Grain and window choices constrain which techniques are honest.
• Interpretation and influence: Limitations documented in the gap list become transparency in the story—not surprises in the decision meeting.

CBDA exam habits for planning data sourcing

• Prefer options that derive data needs from the research question.
• Prefer inventory + gap analysis over blind full-enterprise extracts.
• Prefer re-evaluate sourcing / refine approach when data is unreliable—not instant abandonment of the question.
• Prefer BA actions that validate definitions and owners early.
• Reject both extremes: tool-first collection with no plan, and analysis paralysis that never inventories real sources.