Section 12: The Doors You Left Unlocked - Follow-up Feature Evolution

Executive Summary: The interviewer turns into a product manager and reads out a roadmap: funnels, retention cohorts, raw export to a warehouse, remarketing audiences, anomaly alerts, server-side tagging. A Staff candidate doesn't design six new systems. Each feature gets three questions: which existing layer does it read (raw log, session state or cubes), what does it add, and what does it cost? The answers show that the important doors were opened sections ago, by decisions made for other reasons: the raw store's sort key, immutability, additive cubes, and versioned days.

With about ten minutes left, the interviewer closes the privacy thread and changes hats.

Interviewer: "Congratulations, it shipped. Now product has a list. Dana wants funnels and retention. Big customers want their raw data in their own warehouse. Marketing wants audiences for remarketing. And everyone wants an alert when their traffic does something weird. What does this do to your design?"

You: "Very little, if the earlier choices were right. Before I add any box I'll ask which of three layers each feature hangs off. The raw store is immutable and sorted by (property_id, client_id, event_ts). Session state lives in the streaming job. The cubes are additive and versioned. A feature that fits one of those is an extension. A feature that fits none is a new system, and I'd say so out loud."

Funnels: The Sort Key Pays Off

Dana's funnel is newsletter landing → product page → add_to_cart → purchase, over the last 7 days. A funnel step is ordered and belongs to one person: "did this client do B after A?" Cubes can't answer that. They store counts per dimension value and lose which events happened in what order for whom. So funnels run on the exploration path over raw events.

Here the raw store's sort key (Section 5) does the work. Raw files are sorted by (property_id, client_id, event_ts), so each visitor's events are already contiguous and in time order. A funnel is one streaming pass per client with a small step matcher: no shuffle, no self-join, no sort at query time.

The number: Trailhead's ~3M hits/day × 7 days = 21M events, above the 10M-event unsampled limit, so the query samples at 10M ÷ 21M ≈ 48% and says so. Sampling by hash(client_id) keeps each client entirely in or entirely out; sampling events would drop random steps and invent drop-offs. The scan fits the 10-second exploration p95.

The Lisbon hiker is a good test. Her purchase arrived 40 minutes late and missed the streaming watermark, but the raw writer still landed it in the right event_date partition, so she completes step 4. A funnel over provisional cubes would show her abandoning at checkout.

Interviewer: "Funnels are popular. Why not precompute them?"

You: "Each analyst defines different steps, so precomputing every possible funnel is the same combinatorial explosion Section 5 rejected for dimensions. The flip is the same as for any report: when the query logs show a saved funnel running daily, a scheduled batch materializes its step counts per property-day."

Quick check before moving on: