Business Analysis and Requirements Gathering
Requirements work on an Adobe Analytics engagement starts with the business question, not the tool. A candidate should be able to translate a stakeholder goal ("we need to know which campaign drives renewal") into a measurable KPI definition, the dimensions and metrics that express it, and the success criteria that prove it worked. Know the standard artifacts: the Business Requirements Document (BRD), the Solution Design Reference (SDR), and the KPI framework that links objectives to reports.
A reliable method is the SMART + variable mapping approach: write the objective, name the KPI, define numerator/denominator, then map each element to an eVar, prop, or event and note its allocation and expiry. This surfaces scope gaps early.
Traps
- Confusing a business requirement (what decision the data supports) with a functional requirement (which variable captures it). Questions often ask which comes first - the business requirement does.
- Treating success metrics as vanity numbers. A good requirement names a threshold and an owner.
- Ignoring data governance constraints (PII, retention) until implementation, which forces rework.
Rule of thumb
If you cannot state the decision the report will drive and the action taken if the number is high or low, the requirement is not finished. Write the KPI definition so a new analyst could compute it without asking you.
Worked example: "Reduce cart abandonment." KPI: abandonment rate = 1 − (orders ÷ cart additions). Dimensions: device type, marketing channel. Success: 5-point reduction in one quarter. Owner: ecommerce lead. Each element maps to an event or dimension in the SDR.