Identify User Interest in Group Video Calls Using Data
You are designing and analyzing a new group video-calling feature for a large social or messaging app. Currently, you mainly have historical one-to-one video call data.
Constraints & Assumptions
-
The feature should create incremental real-time communication, not only shift users from one-to-one calls or messages.
-
Assume access to one-to-one call history, group chat metadata, invite behavior, device/network quality, retention, and experiment infrastructure.
-
Network effects matter: one user's treatment can affect other users in the same social cluster.
-
Participant limits and success metrics should account for product value, call quality, safety, and cost.
Clarifying Questions to Ask
-
Is the product already strong in one-to-one video calls, group chats, or both?
-
Are group audio calls available today?
-
What use cases matter most: family calls, work coordination, creator/community calls, or casual friend groups?
-
Are there hard constraints on participant count, device performance, or bandwidth?
Part 1 - Clarify the Business Goal
What is the business goal of the group video-calling feature?
What This Part Should Cover
-
Primary objective such as meaningful real-time communication, retention, reactivation, or competitive parity.
-
Secondary objectives and guardrails, including quality, reliability, abuse, and infrastructure cost.
-
A clear definition of incremental value.
Part 2 - Identify Interested Users
How would you identify users most interested in group video calls using one-to-one call history, and what additional data would improve the analysis?
What This Part Should Cover
-
Proxies such as frequent callers, repeated calls within group-chat clusters, sequential calls to several contacts, missed coordination, and dense social graphs.
-
Additional data from group chats, surveys, beta signups, device capability, network quality, and current substitutes.
-
Segmentation and scoring that distinguish likely adopters from users who would use any new calling surface.
Part 3 - Decide on Participant Limits
Should the product impose a participant limit, and how would you determine the optimal cap?
What This Part Should Cover
-
Demand distribution by intended group size, call success by size, quality degradation, device constraints, abuse risk, and cost.
-
Staged experiments or rollouts with different caps, if feasible.
-
A rule that covers valuable use cases while protecting reliability and user experience.
Part 4 - Measure Launch Success
Which success metrics would you track after launch, and how would you measure cannibalization versus incremental engagement?
What This Part Should Cover
-
Incremental active group callers, successful group-call sessions, call minutes, repeat use, retention, and invite/join funnel.
-
Cannibalization of one-to-one calls, messaging, and existing group surfaces.
-
Guardrails for dropped calls, join failures, latency, crashes, complaints, and cost.
What a Strong Answer Covers
A strong answer ties business goals, user targeting, participant caps, metric hierarchy, and experiment design together while accounting for network effects and cannibalization.
Follow-up Questions
-
How would you randomize an A/B test for a group feature?
-
If group calls increase total minutes but reduce message activity, how would you decide whether that is good?
-
Which user segment would you invite to a beta first?