Processing Rules, Classifications, and Data Governance
Post-collection logic shapes data after the beacon arrives. Candidates must know processing rules: conditions and actions that copy, set, or delete values, append or prepend, and concatenate, evaluated in order against incoming hits. Understand their limits - they operate on hit data, cannot invent context absent from the request, and can silently overwrite values set client-side. Know VISTA as server-side, Adobe-managed logic for cases processing rules cannot handle, and bot rules as a filtering layer.
Classifications enrich dimensions with hierarchical or flat attributes via manual upload, rule-based classification, or SAINT. Understand rule-based classification ordering, regex behavior, and the fact that classifications are not retroactive unless reprocessed. Know classification hierarchies and how they enable rollup reporting.
Governance here means naming conventions, approved value lists, change control, and documentation of every post-collection transformation. The architect must be able to explain why a value changed between the raw feed and the report.
Traps: using processing rules to fix a client-side bug instead of fixing collection; assuming a classification applies to historical data automatically; overlapping rule-based classification rules where the first match wins unexpectedly; and deleting a value in processing rules that a downstream team depends on. Questions often describe a 'correct' rule that nonetheless breaks another report.
Rule of thumb: fix data at the earliest possible layer. If the value is wrong at collection, correct collection; use processing rules and classifications for enrichment and normalization, not repair of broken tracking.
Worked example: marketing wants campaign codes normalized to uppercase. A processing rule that uppercases the campaign variable at hit time is appropriate; a classification is better if the mapping requires a lookup table and historical reprocessing is acceptable.