Katkat
Back

Design an advertiser metrics tracking platform

AmazonApplied Scientist · Technical Screen
MediumApplied ScientistTechnical ScreenSoftware Engineering Fundamentals

Last updated

This question tests your ability to design a flexible, object-oriented system for ingesting, processing, and querying real-time advertising performance metrics.

Problem Statement

Design the core component for an advertiser metrics tracking platform. The system needs to ingest raw ad events (e.g., clicks, impressions, conversions) and provide real-time aggregate metrics (e.g., total spend, CTR, conversion rate) for specific campaigns over given time intervals.

Requirements

  1. Extensibility: The system must support adding new event types (e.g., 'video_view', 'hover') without modifying core processing logic.
  2. Aggregation: Provide a mechanism to retrieve the sum of a specific metric (e.g., total clicks) for a campaign_id within a time range [start_time, end_time].
  3. Interface: Define the necessary classes and methods to handle event ingestion and metric retrieval.

Constraints

  • Assume events are received sequentially.
  • Focus on the class hierarchy and API design rather than persistence or distributed database storage.
  • Aim for clean, maintainable, and decoupled code.

Example

# Expected usage pattern
tracker = MetricsTracker()
tracker.record_event(ClickEvent(campaign_id="C1", timestamp=100, cost=0.5))
tracker.record_event(ImpressionEvent(campaign_id="C1", timestamp=101))

# Query total clicks for campaign C1
total = tracker.get_metric("C1", "clicks", start=0, end=200)

Hints

Hint 1

Use an Abstract Base Class (ABC) for the Event type to enforce a consistent structure while allowing specific implementations for different event types.

Hint 2

Consider using an aggregation service or map-based storage where keys represent campaign IDs and values are time-series buffers or buckets.

Hint 3

Decouple the storage of metrics from the calculation logic to ensure that adding a new metric type doesn't break existing query functions.

Follow-up questions

  • How would you optimize the `get_metric` function if the system receives millions of events per second?
  • How would you handle the challenge of late-arriving events that occur in the past but are ingested out-of-order?
  • If you needed to calculate a rolling average instead of a simple sum, how would your data storage structure change?