Klaviyo Product Certification common mistakes
Klaviyo Product Certification · Understand the traps and how to avoid them.
Treating a Klaviyo flow as a single message rather than a multi-step sequence whose steps are connected by time delays and conditional splits, so questions about what a recipient receives after entering a trigger are answered as if only the first email exists.
Candidates study the flow email templates and the trigger in isolation, then skim the canvas mechanics. They do not mentally trace the path a profile takes through delays, conditional splits, and additional emails, so they confuse 'the first message sent' with 'everything the profile eventually receives'.
What to do instead
Before answering any flow question, sketch the canvas on scratch paper: trigger, each delay with its duration, each conditional split with its branch criteria, and each message in order. Then walk a hypothetical profile through it and state explicitly which branch it takes and what it receives. Practise on flows with at least one split and one delay so the habit becomes automatic.
Assuming a profile that enters a flow always completes it, ignoring that a profile can be removed mid-flow by a conditional split, by a skip condition on a message, or by the profile no longer meeting the flow filter.
The flow diagram looks linear, so candidates picture entry as a guarantee of delivery. They forget that filters are re-evaluated and that a split can route a profile to an empty branch where the journey simply ends.
What to do instead
For every flow question, ask 'what could stop this profile before the message in question?' Check the flow filter, any split conditions upstream, and any message-level skip logic. State the removal reason explicitly rather than defaulting to 'they get the email'.
Confusing a segment with a list and answering segmentation questions as if segment membership must be manually maintained or as if a list can contain computed conditions like 'opened email in the last 30 days'.
Both appear under Audience and both can be used to target a campaign, so the underlying difference is glossed over. Candidates memorise names without the definition: lists are explicit membership that profiles join or leave, segments are dynamic and recomputed from profile properties and event history.
What to do instead
Memorise the one-line distinction: a list is who you put in it, a segment is who currently matches a rule. Then classify each scenario in practice questions by asking whether membership is a stored fact or a computed condition. Segments update automatically as data changes; lists change only by explicit subscribe or unsubscribe actions.
Building or interpreting a segment definition with the wrong logical operator, treating OR as if it narrows results and AND as if it broadens them, so a question about segment size or overlap is answered backwards.
Candidates read the condition list top to bottom and assume every added condition shrinks the audience. In Klaviyo, conditions within a single definition group combine with AND, while separate definition groups combine with OR, so adding an OR group grows the audience.
What to do instead
Redraw the segment as a boolean expression before judging size: AND inside a group, OR between groups. Test with a tiny example, for instance 'opened email AND clicked link' versus 'opened email OR clicked link', and predict which returns more profiles. Apply that reasoning to every segment-size or overlap question.
Confusing a campaign's send-time options, treating smart sending, throttling, and A/B test scheduling as interchangeable, and therefore mispredicting who receives a campaign or when.
All three appear on the same campaign review screen and all affect delivery, so candidates lump them together. They do not separate what each control does: smart sending suppresses recent recipients, throttling spreads a send over time, and A/B testing splits recipients across variants.
What to do instead
Write a one-line definition for each control and what it changes about the recipient set or timing. For any scenario, ask three separate questions: does this change who is eligible, does this change when they receive it, or does this change which version they receive? Answer each independently before choosing.
Answering sign-up form questions as if a form's display behaviour and its submission behaviour are the same setting, for example assuming a pop-up form always collects consent or that a form embedded on a page behaves like a full-page form.
The form builder presents style, targeting, and submission options across several panels, and candidates remember the visual preview rather than the configuration. They conflate where the form appears with what happens to the profile after submission.
What to do instead
Separate form questions into two buckets: presentation (type, targeting, timing, display rules) and data capture (fields, consent, list membership, double opt-in). Answer the bucket the question actually asks about, and check whether the scenario mentions where the form shows or what it does with the submitted data.
Assuming every profile in a list or segment is mailable, forgetting suppression, unsubscribes, and consent status, so questions about expected recipient counts are answered with the raw audience size.
The audience count shown in the UI is a total, not a deliverable count. Candidates take that number at face value and do not subtract suppressed profiles, unsubscribed profiles, or profiles lacking the required consent for the message type.
What to do instead
For any recipient-count or 'who gets this' question, start from the audience size and subtract suppressed, unsubscribed, and non-consented profiles, plus anyone excluded by smart sending. Treat the displayed count as an upper bound, never as the send count.
Mixing up profile properties and custom events when defining triggers or segment conditions, using an event metric where a profile property belongs or vice versa, which produces a definition that never matches.
Both appear in the same condition and trigger menus, and the labels are similar. Candidates pick the first matching-looking option without checking whether the data is a stored attribute on the profile or a timestamped activity record.
What to do instead
Classify the data before choosing: is it a fact about the person (property, such as a birthday or a plan tier) or something they did at a point in time (event, such as placed order or viewed product)? Properties go in profile-property conditions; activities go in event-based conditions and flow triggers. Apply this test to every condition you evaluate.
Treating a flow's trigger as the same as its filter, so a question about who enters a flow is answered with the filter criteria or vice versa, and profiles are assumed to enter when they actually only qualify.
Both are conditions attached to the flow and both mention profile or event data, so the distinction blurs. The trigger is the event that starts the journey; the filter restricts which triggered profiles are allowed to continue.
What to do instead
State the pair explicitly for each flow: 'enters when X happens, but only if Y is true.' The trigger is the event, the filter is the gate. When a question asks who receives a flow message, check both the trigger event and the filter, and note that the filter is re-evaluated as the profile moves through the flow.
Reading a campaign or flow report as a single conversion number without checking the attribution window and conversion metric, so results from different reports are compared as if they used the same definition.
Reports display opens, clicks, and placed order value prominently, and candidates assume these are measured identically everywhere. They do not check the attribution settings, so they compare a five-day open-attributed value with a longer click-attributed value and draw the wrong conclusion.
What to do instead
Before comparing or interpreting any performance figure, identify the conversion metric and the attribution window attached to that report. Only compare figures that share both. If a question gives two reports with different settings, say so rather than treating the numbers as directly comparable.