Propose a multi-touch attribution model and its data pipeline
This tests your ability to choose a practical data model under real-world constraints. Propose a time-decay or position-based model, then describe the data pipeline: event collection, identity resolution, and aggregation. A red flag is ignoring signal loss.
What's really being asked
This question tests your ability to design a data system for a specific business need—understanding marketing ROI in a long sales cycle—while being realistic about modern data challenges. Interviewers want to see if you understand the trade-offs between model complexity (e.g., rule-based vs. data-driven), data requirements, and the severe limitations imposed by privacy changes like iOS 14.5 and cookie deprecation. It's a test of practical system design, not theoretical data science.
The full answer
First, acknowledge the long sales cycle and propose an interpretable, rule-based model like Time-Decay or Position-Based (U-Shaped). These are auditable and don't require massive conversion volume. Mention that data-driven ML models are an option but require 2,000+ conversions/month and are often black boxes, making them a risky starting point. Second, detail the data pipeline implementation: event collection from all channels (web, mobile, CRM, ad platforms) with consistent UTM tagging. Third, describe the critical identity resolution step, which stitches anonymous IDs (cookies) to known user IDs (email) to create a single customer journey. Fourth, explain the transformation job (e.g., in dbt) that cleans data and orders touchpoints chronologically for each user path. Finally, specify a long, configurable attribution window (e.g., 90-180 days) and explicitly state that due to signal loss, MTA coverage is only 30-60% of 2020 levels, so the model provides directional insight, not absolute truth.
The mistakes people make
Jumping to a complex ML model like Shapley values or a Markov chain without justifying the data volume (2,000+ conversions/month) or the need for its complexity. This suggests a lack of practical experience. Ignoring identity resolution is another major flaw; just saying "we'll collect events" without explaining how to link a user's journey across devices is a junior-level answer. Failing to mention the impact of privacy changes and signal loss is a huge red flag. Proposing a short attribution window, like 30 days, shows a fundamental misunderstanding of the business context.
What usually comes next
"How would you handle offline touchpoints, like a sales call?" (Answer: Ingest data from the CRM and match on email or a company identifier.) "How would you validate this model is better than last-touch?" (Answer: Run A/B tests on marketing spend based on the model's recommendations against a control group.) "What if we don't have 2,000 conversions a month? Can we still use a data-driven model?" (Answer: No, the model would be statistically unstable. We must stick to rule-based approaches.)
A concrete example
For a B2B SaaS company with a 90-day sales cycle, we'd implement a Time-Decay model with a 90-day lookback window. The pipeline would ingest web events (Segment), ad platform data (via Fivetran), and CRM data (Salesforce). A dbt model would run daily to stitch user journeys using email as the primary key. A final table, fct_attribution, would list every conversion and the fractional credit assigned to each touchpoint (e.g., touchpoint_id, conversion_id, credit_amount: 0.15). This table powers our marketing dashboards in a BI tool.
Interview question
When designing a modern multi-touch attribution system, what is the most critical real-world constraint that impacts the reliability of its output?
- a.The difficulty in choosing between a time-decay, U-shaped, or other rule-based model.
- b.The high cost of data warehousing for storing massive volumes of raw event data.
- c.Significant, unavoidable signal loss from privacy changes, meaning the model provides directional insight, not absolute truth.Correct
- d.The engineering complexity of stitching together anonymous and known user IDs across different platforms.
Why? this is the answer
Privacy changes like iOS 14.5 and cookie deprecation fundamentally limit data collection, making it impossible to capture a complete customer journey. While identity resolution (D) is a major technical challenge, the external constraint of signal loss is the most critical factor impacting the final model's reliability.
Just read this? Test yourself on what you have been reading.
Read the original → improvado.io
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on data engineering — each one lists the topics its interview covers.
See open roles