Build a system to measure viral coefficient and attribute invites to signups

Tests if you can map K=i×c to logged events and resilient pipeline. Good answers define invite_sent, click, signup events with referral tokens; sketch stream joins; and flag cross-device and organic attribution gaps. Red flag: assuming perfect attribution.
WHAT THIS TESTS: Your ability to operationalize the K-factor formula K equals i times c into a measurable data model and pipeline, while demonstrating skepticism about attribution accuracy. The interviewer wants to see that you understand invites are not deterministic conversions, that real pipelines deal with identity fragmentation, and that cycle time matters as much as the coefficient.
A GOOD ANSWER COVERS: First, the event taxonomy. You need invite_sent with sender_id and referral_token, invite_clicked with the same token plus device_fingerprint or cookie, signup_completed with referral_token and new_user_id, and optionally reward_issued to close the loop. Second, the pipeline architecture. Events flow through a streaming layer into a warehouse. You join invite_sent to signup_completed on referral_token, then aggregate by sender cohort to compute i equals count distinct invites sent divided by count distinct senders, and c equals count distinct signups divided by count distinct invites sent. Third, attribution challenges. Cross-device clicks break cookie-based matching. Organic cannibalization happens when a user sees an invite, ignores it, then Googles your product later; without an experiment holdout you will overstate c. Link resharing strips tokens if users copy-paste URLs. Duplicate accounts inflate c. iOS privacy restrictions and cookie deprecation reduce tracking fidelity. Fourth, cycle time. You must timestamp each event and compute the median delta between signup_completed and the parent invite_sent, because a K of 1.2 with a 3-day cycle compounds faster than a K of 1.5 with a 30-day cycle.
COMMON WRONG ANSWERS: Treating every signup with a referral parameter as causally attributed, without considering holdout experiments or organic baseline. Proposing a batch-only pipeline that updates K monthly, missing the need for near-real-time cycle time measurement. Ignoring invite fatigue by computing a global K instead of cohort curves that decay over successive invite rounds. Suggesting that sustained K greater than 1 is a realistic long-term target; the reference notes most healthy programs live at K equals 0.3 to 0.7.
LIKELY FOLLOW-UPS: How would you design an A/B test to prove that referrals are incremental rather than cannibalizing organic signups? What happens to your pipeline if users share invite links in group chats where multiple people click but only one signs up? How do you handle the case where a user receives two invites from different senders before signing up?
ONE CONCRETE EXAMPLE: Suppose you issue a UUID referral token to each user. When Alice sends three invites, you log three invite_sent events with token alice_123. Two friends click on different devices; one click includes the token, the other strips it. The friend with the intact token signs up. In your warehouse, you join on token to attribute the signup to Alice, giving her an i of 3 and a partial c of 0.33 for that cohort. You then compare the conversion rate of token-attributed signups against a holdout group that sees no referral incentive to estimate true incremental K.
Source: getlaunchlist.com
Read the original → getlaunchlist.com
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.