Why don't analytics and backend user counts match?
This tests your systematic debugging and understanding that 'user' has different definitions. A good answer first defines 'user' in each system, then investigates tracking implementation, timing differences, and filtering.
What's really being asked
This question assesses your practical experience with data systems and your ability to perform a root cause analysis on a common, ambiguous problem. It's not about finding a single 'right' answer, but demonstrating a systematic, logical investigation process. The interviewer wants to see if you understand that definitions (what is a 'user'?) must precede technical debugging.
The full answer
A strong answer outlines a multi-stage investigation. First, establish definitions: clarify how the analytics tool defines a user (e.g., by a client-side cookie, device ID) versus the backend (e.g., a row in the users table with a verified email). Second, investigate the data capture layer: check for analytics script failures, pages without tracking, or event configuration errors. Ad blockers can cause a 10-30% drop in client-side events. Third, examine the data processing pipeline: look for ETL/ELT job failures, API sync delays, or data sampling in the analytics tool. Fourth, check for filtering and timing differences: are both systems using the same timezone (e.g., UTC)? Is one system filtering out internal or bot traffic while the other is not?
The mistakes people make
A major red flag is immediately assuming one system is 'right' and the other is 'wrong.' Another is jumping to a highly technical but unlikely cause (e.g., 'it's probably a race condition in the stream processor') without ruling out the basics first. Candidates who cannot articulate the difference between a client-side identified user and a backend authenticated user will struggle. Simply listing potential causes without structuring them into an investigation plan is also a weak answer.
What usually comes next
'Let's say the discrepancy is consistently 15%. What does that number suggest to you?' (Could point to ad-blocker rates or a specific untracked user cohort). 'How would you design a system from scratch to minimize this discrepancy?' (Discussing server-side tracking, a single source of truth for identity, or a unified event schema). 'Which of these two numbers would you trust for financial reporting, and why?'
A concrete example
'In a previous role, our Amplitude 'new user' count was 20% higher than new rows in our users table. The root cause was our definition. Amplitude counted any new device as a 'new user.' Our backend only counted a user after they completed the full sign-up and email verification flow. The 20% discrepancy represented users who started the sign-up process but never finished. We resolved this by creating a separate 'Signed Up' event in Amplitude to make the comparison apples-to-apples.'
Interview question
When investigating a discrepancy between analytics and backend user counts, what is the most critical initial step?
- a.Comparing the definitions of "user" used by the analytics tool and the backend system.Correct
- b.Verifying that analytics scripts are correctly implemented and not blocked by ad blockers.
- c.Assuming the backend user count is inherently more accurate and using it as the source of truth.
- d.Checking for ETL/ELT job failures or API sync delays in the data processing pipeline.
Why? this is the answer
The card emphasizes that establishing definitions (what constitutes a 'user' in each system) must precede technical debugging. Assuming one system is 'right' is a common red flag, and checking technical issues like script failures or ETL jobs are later steps in the investigation process.
Just read this? Test yourself on what you have been reading.
Read the original → usermaven.com
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 — each one lists the topics its interview covers.
See open roles