Evaluate Messenger's P2P Payments Feature for Business Viability
Quick Overview
Evaluates business viability for a Messenger P2P payments feature. Strong answers define networked adoption and transfer metrics, assess fraud, compliance, support, trust, and unit economics, and propose a beta or experiment design that handles spillovers and contamination.
Evaluate Messenger's P2P Payments Feature for Business Viability
Company: Meta
Role: Data Scientist
Category: Analytics & Experimentation
Difficulty: hard
Interview Round: Onsite
##### Scenario
Facebook Messenger considers launching a Venmo-like peer-to-peer payments feature.
##### Question
Is adding P2P money transfer in Messenger worthwhile from a business perspective? What business goals and success metrics would you track? List possible negative impacts or risks of launching this feature. How could the feature be monetized? Design an experiment or pilot/beta test to measure impact. Which variants, sample sizing, and duration would you choose? Which metrics determine whether the feature met expectations? How would you compare user engagement between beta participants and non-participants (e.g., difference-in-difference)? If a control-group user wants access to the feature, how would you handle the contamination risk?
##### Hints
Define north-star metric, guard against spillover, consider A/B vs. geo holdout, outline causal inference assumptions, quantify revenue paths.
Quick Answer: Evaluates business viability for a Messenger P2P payments feature. Strong answers define networked adoption and transfer metrics, assess fraud, compliance, support, trust, and unit economics, and propose a beta or experiment design that handles spillovers and contamination.
Evaluate Messenger's P2P Payments Feature for Business Viability
Facebook Messenger is considering launching a Venmo-like peer-to-peer money transfer feature. You need to assess whether the feature is worthwhile from a business perspective and how to test it safely.
Constraints & Assumptions
Messenger is a networked product, so adoption and value depend on social graph effects.
P2P payments carry trust, fraud, compliance, and support risks.
The feature may create engagement or ecosystem value even if direct monetization is limited.
Include metrics, unit economics, risks, and experiment or pilot design.
Clarifying Questions to Ask Guidance
Which markets, payment rails, and regulatory requirements are in scope?
Is the feature free, fee-based, or monetized through instant cash-out or future products?
What user problem is being solved: splitting bills, paying friends, marketplace payments, or family transfers?
What fraud, KYC, AML, and support constraints exist?
Part 1 - Business Goals and Metrics
What business goals and success metrics would you track?
What This Part Should Cover Guidance
North-star metrics such as activated P2P users, completed transfers, repeat transfers, transfer volume, or incremental Messenger retention.
Funnel metrics for onboarding, KYC, linking payment method, send, receive, cash-out, repeat use, and failed transfers.
Guardrails for fraud, chargebacks, support tickets, complaints, payment failures, latency, privacy, and compliance.
Part 2 - Risks and Negative Impacts
What potential negative impacts and risks should be considered?
What This Part Should Cover Guidance
Fraud, scams, mistaken payments, regulatory risk, support burden, user trust, account takeover, spam, and social discomfort.
Cannibalization or distraction from core Messenger use.
Segment and market risks.
Part 3 - Monetization and Unit Economics
What monetization paths and simple unit economics would you evaluate?
What This Part Should Cover Guidance
Direct fees, instant transfer fees, payment method costs, fraud losses, support costs, interchange where relevant, and future ecosystem value.
Contribution margin per transfer and per active P2P user.
Break-even and sensitivity assumptions.
Part 4 - Experiment or Pilot Design
How would you design an experiment or beta to measure impact?
What This Part Should Cover Guidance
A/B test versus geo holdout or invitation-based beta, with reasoning about network effects and contamination.
Randomization unit, variants, sample size, duration, metrics, decision criteria, and difference-in-differences comparisons.
Handling control users who receive transfer requests from treatment users.
What a Strong Answer Covers Guidance
A strong answer treats P2P payments as a trust-heavy network feature, balances engagement and monetization with fraud and compliance risk, and proposes a measurement plan that accounts for social spillovers and unit economics.
Follow-up Questions Guidance
How would you detect fraud early in the beta?
What if engagement rises but support tickets surge?
Would you randomize by user, friend graph, or geography?