Section 2: Two Products Sharing One Pipe - Requirements (Functional & Non-Functional)

Executive Summary: This section turns Section 1's answers into a contract. The functional list is short. The non-functional list is where the design gets decided, and it has to be written twice: once for collection, the fire-and-forget firehose every tagged page writes into, and once for reporting, the dashboard product site owners read from. The two get different availability, latency and accuracy targets, and we say why. We end on the tension behind every later section: freshness, correctness and cost can't all be maxed at once, so the system runs three clocks (seconds, an hour, a day) and labels which one each number came from.

The clarifying questions are done. The interviewer caps the marker: "Good. So what are we actually promising?" A Staff answer starts by noticing two customers who never meet. The hiker in Lisbon doesn't know she's being measured and will never retry a failed request. Dana in Denver sees only the reports. One pipe joins them, but each end makes different promises, and folding both into one "highly available" line is where requirement-writing usually goes wrong.

The Functional Contract

Each item is here because a later section has to build it:

• Collect events. Page views, custom events (scroll, add_to_cart) and e-commerce events (purchase with value and currency) from the web tag, the app SDKs and a server-to-server Measurement Protocol. Enrichment adds device (from the user agent), geography (from the IP) and traffic source (from UTM parameters).
• Derive sessions and users, so "users" and "sessions" mean the same thing on every report.
• Standard reports. Any combination of supported dimensions × metrics × date range × filters: Dana's "users from the newsletter, last 7 days, and how many bought" is the canonical query.
• Real-time card. "Users on your site right now", broken down by a few dimensions (page, country, source).
• Explorations. Ad-hoc questions the standard reports don't cover, answered from event-level data.
• Property admin. Create a property, set its time zone (Trailhead is America/Denver, so its "day" is a Denver day, not the hiker's Lisbon day), manage access roles.
• Data controls. A retention setting (2 or 14 months of event-level data), user-deletion requests, and consent signals that change what we collect.

Key Insight: The time-zone setting looks like admin trivia, but it shapes the architecture. A "day" is a property-local day, so there's no global midnight when everyone's numbers close. That one line is why Section 8's finalization runs in about 24 waves across the UTC day.