Data Collection, Tagging, and Tracking Architecture
Collection architecture determines whether data arrives complete, deduplicated, and attributable. Candidates must understand the AppMeasurement/Web SDK distinction, the tracking call lifecycle (page view, link tracking, custom events), and how the request is assembled from variables, context data, and the data layer. Know the role of context data variables and their mapping to report-suite variables, and why mapping at collection time beats client-side renaming.
Server-side and edge collection deserve attention: the Web SDK datastream, edge configuration, and server API enable first-party and server-to-server collection, which affects identity continuity, latency, and bot/ad-blocker exposure. Understand visitor identification: Experience Cloud ID service, first-party ID settings, and how identity stitching across devices depends on authenticated IDs being passed consistently.
Also know the collection hygiene concepts: bot filtering, IP obfuscation, internal traffic exclusion, and timestamp options (client vs server) and their interaction with offline or delayed data.
Traps: assuming client-side collection survives ad blockers; mixing client and server timestamps causing out-of-order visits; sending duplicate page views from both a tag rule and application code; and passing authenticated IDs on some calls but not others, which fractures stitching. Questions may describe 'missing data' where the real cause is a duplicate or suppressed beacon.
Rule of thumb: one event, one beacon, one owner. Every tracking call should have exactly one code path responsible for firing it, and identity values should be sent on every call or none.
Worked example: a mobile app reports inflated visits. Investigation shows both the tag rule and native SDK code fire a page view on screen load. Consolidating to a single path restores visit counts without changing any report-suite setting.