Design: Event Recommendations

Outing, a made-up events app, lists local events and sells tickets. Clarify:

• scale: a few million monthly users; about 40,000 upcoming events in a large city at any time; thousands added daily;
• surfaces: a 'for you' feed, 'near you this weekend', and a weekly email or push notification;
• goal: more people register for and attend events they enjoy; organisers sell tickets;
• latency: the feed within about 200 ms; emails computed in batch;
• constraints: events are tied to a place and a time; many are free; some are age-restricted; sold-out events must not be shown.

Events differ from products and videos in three ways that drive the design.

• Every item is new: an event exists for a few weeks, so there is little or no interaction history for most of its life.
• Location and time dominate: a perfect event 80 km away, or yesterday, is worthless.
• Social influence is strong: people go where their friends go.

Rank events for a user as a pointwise prediction (module 14):

• target: probability the user registers (or buys a ticket) for the event after seeing it, within the time before it starts;
• second target: probability they actually attend (check-in), arriving after the event;
• offline metrics: AUC and NDCG at 10, split by event date (train on past events, test on later ones);
• online metrics: registrations per user per week, attendance rate, email click-through, unsubscribes as a guardrail;
• baseline: popular events nearby this weekend.

Registration is the frequent signal; attendance is the truer one.

• Free events attract many registrations and many no-shows, so attendance, where known, is weighted more.
• A time split by event date is essential: random splits leak who registered for future events.

Candidates come mostly from filters, not embeddings:

• a geospatial index of events (by latitude and longitude, or grid cells such as geohashes);
• a time window (this weekend, next 30 days);
• hard rules: not sold out, registration open, allowed for the user's age;
• then, if many remain, a light ranker or embedding similarity to pick a few hundred for the main ranker.

Place and time remove most of the catalogue cheaply and with certainty.

• Whatever remains is small enough to rank fully.
• Distance and time-until-start then become the most important ranking features too.

Grouped:

• user-event: distance from the user's home and work (or current location); time until the event; overlap with the user's usual free times (weekends, evenings); price relative to what they usually pay; category affinity (past registrations by category);
• social: number of friends or followed people registered; the user's history with this organiser;
• event: category, price, capacity, organiser's past attendance rates and ratings, description and image embeddings, registrations so far relative to capacity and time remaining;
• context: day of week, weather forecast for outdoor events, surface (feed versus email).

The strongest features describe the relationship between user and event (distance, time fit, friends going), not the event alone.

• Organiser features carry history to new events: a new event from an organiser whose past events were well attended inherits that signal.
• Content embeddings let a new event match users who liked similar events.

Most events have little history for most of their life. Design for it:

• rely on content (description, category, images) and organiser features rather than event ID embeddings;
• use registrations so far relative to how far ahead the event is, since early signals are thin;
• give new events exploration exposure to gather early signals;
• for new users, ask for interests and location at sign-up; use popular-nearby until signals arrive.

Registrations pile up close to the event date, so for much of an event's life the model sees almost nothing.

• Features that transfer from similar events and from the organiser fill the gap.

A gradient-boosted model (module 12) is a strong, practical choice:

• pointwise, predicting registration, trained on (user, event shown, registered or not) rows;
• a second head or model for attendance given registration;
• final score combines them, for example probability of registering × probability of attending;
• for very large platforms, a neural model with content embeddings and a social graph signal can add more.

The features are tabular and relationship-heavy, where boosted trees shine.

• Combining registration and attendance keeps the feed honest for organisers.

Much event discovery happens outside the app, in a weekly email or a push notification:

• computed in batch (module 18) for each user before sending;
• fewer slots (three to six events), so precision at the top matters most;
• fatigue limits: cap how often a user is contacted; stop or slow sending to people who never engage;
• unsubscribes and spam reports are guardrail metrics.

A notification costs the user's attention; too many lose the channel permanently through unsubscribing.

• The send decision itself can be modelled: send only when the best event's score clears a bar.

Two paths:

• online feed: geospatial and time filter → light ranker → boosted model on a few hundred → re-rank (diversity of categories and dates, sold-out removal) → show; well inside 200 ms;
• batch for emails and pushes: score candidates nightly for each active user;
• live updates: sold-out status and capacity changes flow through a stream and remove events immediately;
• fallback: popular-nearby-this-weekend.

Inventory changes by the minute (tickets selling out), so availability must be checked live even when scores are precomputed.

Evaluate by event date:

• offline: train on events before a cut-off, test on events after; AUC and NDCG at 10; slices for events with almost no registrations yet, new users, free versus paid;
• online: registrations and attendance per user, organiser ticket sales, email engagement and unsubscribes;
• monitoring: share of recommended events that sold out before the user could act, average distance of recommendations, attendance rate trends, concentration on a few large events.

A model can look good offline by favouring big, already-popular events; slicing by registrations-so-far shows whether it helps smaller events too.

• Concentration metrics protect smaller organisers, whose success keeps the marketplace healthy.

Public work this design draws on:

• Liu et al., 'Event-based Social Networks: Linking the Online and Offline Social Worlds', KDD 2012: studies of Meetup-style networks;
• Macedo et al., 'Context-Aware Event Recommendation in Event-based Social Networks', RecSys 2015: content, social, location and time signals for new events;
• 'CPMF: A Collective Pairwise Matrix Factorization Model for Upcoming Event Recommendation': learning to rank upcoming events that have no attendance history yet;
• general learning-to-rank and cold-start material in modules 13 and 14.

Academic work on event networks documents the cold-start, location and social effects clearly, with real data.

The questions interviewers ask about the event recommendation design, from the first screening call to the senior round. Cover the answer, say yours aloud, then compare.

Reading an idea and explaining it are different skills.

• Each answer below is the two or three sentences an interviewer is listening for.
• The reasoning behind each one is in the cards above. If an answer surprises you, go back to that card.

A short build that uses this module's ideas. Write it yourself before looking anything up; the checks at the end tell you whether it works.

An idea you have only read fades in a week.

• Building it once, even in fifty lines, is what makes it yours.
• Interviewers can tell the difference between someone who has read about a loop and someone who has debugged one.