Amplitude Certification common mistakes
Amplitude Certification · Understand the traps and how to avoid them.
Treating a single event as the unit of analysis for funnels and retention, then reporting conversion rates that do not match the product team's numbers.
Candidates confuse raw event counts with unique-user metrics, and forget that Amplitude's default chart modes aggregate by unique users unless explicitly changed.
What to do instead
Before answering, state explicitly whether the metric is user-based, session-based, or event-based, and confirm which chart mode is selected. Practice switching between unique users and event totals on the same dataset and reconciling the difference.
Misidentifying which events are active versus inactive for a funnel step when an event is sent with a property filter or from multiple sources.
Candidates assume every event of that name counts, ignoring that a filtered or condition-scoped step only counts events matching the condition, and that events from different SDKs may carry different properties.
What to do instead
Walk through each funnel step's exact condition (event name plus property filters) and verify the property exists in the event's schema. Check the event's sources and property coverage before concluding a step is broken.
Designing an event taxonomy that mixes naming conventions (camelCase, snake_case, spaces) or reuses one event for multiple user intents, then failing questions about governance best practices.
Candidates focus on getting data in rather than on long-term usability, and underestimate how inconsistent naming breaks downstream charts, cohorts, and governance reviews.
What to do instead
Memorize and apply a single convention (e.g., object_action, snake_case) across all examples, and split distinct intents into separate events. When asked to evaluate a taxonomy, audit for naming consistency, single-purpose events, and documented property types.
Assuming data appears in Amplitude instantly after SDK instrumentation and blaming the integration when charts are empty.
Candidates forget ingestion latency, SDK batching, and that events must match the project's API key and be validated before they are queryable.
What to do instead
Recall the pipeline stages: SDK buffers and batches, events hit the ingestion endpoint, are validated, then become queryable after processing. For troubleshooting questions, check API key/project match, event validation errors, and expected latency before concluding the SDK is broken.
Conflating a feature flag's evaluation with an experiment's exposure event, then misreading which users are actually in the analysis.
Candidates treat flag delivery and experiment assignment as the same thing, but an experiment only analyzes users who triggered the exposure (assignment) event, not everyone who received a variant.
What to do instead
Distinguish flag evaluation (who sees which variant) from exposure logging (who is counted in analysis). For any experiment question, identify the exposure event and confirm it fires only after the user is eligible and the variant is determined.
Declaring an experiment conclusive from a peeked, underpowered, or multiple-comparison-inflated result.
Candidates read a p-value or lift at face value without checking sample size, planned duration, or whether several metrics/variants were tested simultaneously.
What to do instead
Before judging significance, verify the experiment reached its pre-computed sample size, ran for full planned duration, and that any multiple-metric or multi-variant analysis uses appropriate corrections. Reject conclusions drawn from early peeks or underpowered samples.
Assuming Session Replay captures every session by default and that replays are complete recordings of all user activity.
Candidates overestimate coverage and forget sampling rates, capture settings, privacy masking, and that replays are reconstructions from captured events, not video.
What to do instead
Treat replay coverage as a configured percentage with masking rules applied. For coverage questions, check the project's sampling and capture configuration, and remember masked or excluded elements will not appear in the reconstruction.
Interpreting a heatmap's click or scroll data as applying to all users when it reflects only the captured sample and the specific page state shown.
Candidates ignore that heatmaps aggregate a subset of sessions, depend on element identification, and can misattribute clicks on overlapping or dynamically rendered elements.
What to do instead
State the sample basis and page/URL scope before interpreting a heatmap, and check whether elements are reliably identified (stable selectors, no overlapping layers). Treat heatmap insights as directional and corroborate with event data.
Confusing Guides targeting and eligibility rules with survey response analysis, leading to wrong conclusions about who saw or completed a guide.
Candidates blend the delivery side (who is eligible to see a guide) with the analytics side (who actually viewed or responded), and overlook throttling and audience filters.
What to do instead
Separate the two: first identify the guide's audience/targeting and display rules, then look at view and completion events for that guide. Confirm throttling and eligibility filters before interpreting response rates.
Treating cohorts and user properties as static snapshots, then misreading retention or segment comparisons built on them.
Candidates forget that cohorts can be dynamic (membership recalculated) versus static, and that user properties reflect their latest value unless the analysis is time-scoped.
What to do instead
For any cohort or segment question, determine whether the cohort is dynamic or static and whether user properties are evaluated at event time or current value. Reconcile the definition with the chart's date range before drawing conclusions.