Implementation Planning and Requirements Gathering
Start from business questions, not from variables
A developer's first instinct is to open the tag property; the expert's first move is to convert stakeholder goals into measurable business requirements, then into a solution design reference (SDR). The SDR is the contract: it maps each KPI to a metric (success event or calculated metric), the dimension that slices it (eVar, prop, or list var), the scope and allocation, and the report it feeds. Requirements workshops should surface the decision each report will drive - a report nobody acts on is a candidate for deletion, not implementation.
Concepts you must know
Know the difference between a business requirement ("understand which campaigns drive high-value orders"), a functional requirement ("capture campaign tracking code, order revenue, and product SKUs"), and a technical specification ("set eVar12 with last-touch allocation, 30-day expiry, Marketing Channel processing"). Know the standard discovery artifacts: KPI inventory, SDR, data layer spec, page/flow inventory, and a measurement plan for testing. Understand that scope (hit, visit, visitor) and allocation (recent/last, original/first, linear) are decisions made at design time and are painful to change later because they require report suite reconfiguration and historical data loss.
Traps in questions
- Confusing a KPI with a dimension; success events are the metrics, eVars/props are the dimensions.
- Forgetting that changing allocation or expiry on an eVar does not retroactively rewrite collected data.
- Treating the SDR as optional documentation rather than the source of truth for QA.
- Ignoring non-functional requirements: performance budget, consent gating, mobile app parity, and localization.
Rule of thumb
If a requirement cannot be written as "metric X broken down by dimension Y answers decision Z," it is not yet implementable - send it back to discovery.