What data pipelines and infrastructure feed a viral user acquisition model?

WHAT THIS TESTS: Your ability to design data infrastructure that captures causal viral dynamics rather than correlational growth signals. The interviewer cares about instrumentation strategy, pipeline architecture, and feature engineering for network effects. They want to see you understand that without clean attribution between inviter and invitee, any k-factor model is built on garbage data.

A GOOD ANSWER COVERS: First, product instrumentation. You need event schemas that track invite sent, invite viewed, invite accepted, and first action, with a persistent attribution token flowing through the funnel. Identity resolution is critical because users may send invites from mobile but signups happen on desktop, so you need an identity graph or at least probabilistic matching to link the pair. Second, pipeline architecture. Ingest high-volume engagement events through a streaming layer so viral signals are not stale by the time they reach the model. Clean and validate the attribution join early, because if the inviter-invitee link is broken downstream, the feature store serves incorrect network topology. Third, defining the viral coefficient. A senior candidate explains that k-factor is not simply invites per user times conversion rate; it must be cohort-based, time-bound, and decomposed by channel and user segment. You should separate organic traffic from viral traffic using holdout logic or geo-based synthetic controls so the model learns causation. Fourth, feature engineering. The model needs more than invite counts; it needs network state features like local network density, friend-of-friend reach, time since last invite, and channel fatigue. These should live in a feature store that serves both offline training datasets and low-latency online inference. Fifth, infrastructure for feedback loops. Viral models decay quickly as user behavior shifts, so the pipeline must monitor feature drift and data quality in near real time, not just in nightly batch jobs.

COMMON WRONG ANSWERS: Treating every signup with a referral code as a purely viral event without accounting for users who would have signed up anyway. Proposing a complex deep learning model before the basic attribution join is reliable. Suggesting a batch-only warehouse pipeline when viral growth loops require sub-hour latency to adapt spend and product prompts. Ignoring privacy and consent in invite tracking, which can poison the dataset when users opt out of sharing. Stating the k-factor as a single global number rather than a time-varying, segment-specific distribution.

LIKELY FOLLOW-UPS: How would you validate that a predicted viral coefficient actually caused a signup rather than correlating with organic interest? What happens to your pipeline when a user deletes their account and GDPR requires erasure of the inviter-invitee link? How do you handle viral saturation where the same community runs out of new users to invite? If the product shifts from contact-list invites to social sharing, how does your schema evolve without breaking historical features?

ONE CONCRETE EXAMPLE: Imagine a fintech app where users get five dollars for each friend who links a bank account. You instrument the invite flow with a UUID attached to the referral URL. When the friend clicks, the UUID passes through the app install or web session and is stored in the identity graph. A streaming job enriches the signup event with the inviter's user ID, then writes to a feature store. The training pipeline computes k-factor per cohort over a seven-day window, while the real-time inference pipeline queries the feature store to predict whether showing the invite prompt to a specific user today will yield a conversion within 48 hours.

Source: ittech-pulse.com