Iterable Foundations Certification common mistakes
Iterable Foundations Certification · Understand the traps and how to avoid them.
Treating a Campaign send and a Journey send as interchangeable, then trying to add a delay or branching step to a Campaign after launch.
Candidates learn the two features separately and assume both are 'just sends'. Campaigns are one-off, single-message sends to a list or segment with no wait or decision logic; Journeys are multi-step, event- and time-driven orchestrations. The exam tests whether you can pick the right construct for a stated goal, and whether you know that adding logic requires rebuilding as a Journey rather than editing a Campaign.
What to do instead
Before answering, restate the goal in one line and ask: does it need more than one message, a wait, or a branch? If yes, it is a Journey. Memorize the boundary: Campaigns = single send, no orchestration; Journeys = triggers, delays, filters, and multiple steps. Practice mapping five short scenarios to the correct construct and write down the deciding phrase for each.
Selecting a trigger type for a Journey by name alone (for example choosing a list-subscription trigger when the requirement is 'send 24 hours after a purchase') without checking what event actually starts the Journey.
Iterable Journeys can start from several trigger categories, including audience/list entry, event occurrence, and scheduled or recurring starts. Candidates skim the scenario, latch onto a familiar trigger label, and miss the timing condition buried in the prompt. The trigger determines both who enters and when, so a wrong trigger silently breaks the whole design.
What to do instead
For every Journey question, underline two things first: the entry event and the timing. Then eliminate triggers that cannot express that timing. Build a one-page table of trigger type -> who enters -> when they enter -> what cannot be done with it, and rehearse it until you can fill it from memory. If a scenario says 'after' or 'when X happens', default to an event-based start unless the prompt clearly describes a batch or schedule.
Answering audience-size questions by assuming a segment counts every profile that matches any condition, instead of reasoning about how multiple criteria combine.
Segments are built from criteria groups, and how those groups combine (all conditions versus any condition, and how nested groups are evaluated) changes the resulting population. Candidates who have only built simple one-criterion segments assume criteria always AND together, so they predict a larger or smaller audience than the logic actually yields. The exam frequently presents a multi-criterion segment and asks what it includes.
What to do instead
Read the segment definition as a boolean expression. Draw the criteria as nested brackets, resolve the innermost group first, then apply the outer combination rule. Practice with three-criterion examples where one uses 'is not' or 'does not exist', because negation and missing-field behaviour are where predictions usually break. Confirm whether a profile with no value for a criterion is included or excluded before you commit to a count.
Confusing list membership with segment membership when deciding whether a profile will receive a Campaign or enter a Journey.
Lists are explicit, static collections that profiles are added to or subscribe to; segments are dynamic and re-evaluated as profile data changes. Candidates treat them as synonyms, so they expect a profile to stop qualifying when it is removed from a list, or expect a segment to be a fixed snapshot. The exam tests whether you know which one updates automatically.
What to do instead
Use one rule: lists are curated membership, segments are computed membership. When a question asks 'who gets this message', identify whether the send targets a list or a segment, then ask whether the population is frozen at send time or recomputed. Note that a profile can be in a segment without being on any list, and that removing a profile from a list does not change its segment eligibility. Drill with paired scenarios that differ only in list versus segment targeting.
Assuming a Catalog item and a user profile field are interchangeable sources of personalization data, then choosing the wrong one for a message that needs product attributes.
Catalog holds structured, reusable item data (such as products or locations) that messages and Journeys reference by identifier; profile fields hold per-user attributes. Candidates who personalize only from profile fields try to inject a product name or price from a profile field, or expect Catalog to store user-level data. The exam checks whether you can identify the correct data source for a given merge requirement.
What to do instead
Classify the data before answering: is it about the person (profile) or about a thing the person is being shown (Catalog)? If the message must render item details, the design needs a Catalog collection plus the identifier that links the user or event to the item. Sketch the reference chain end to end (user -> identifier -> catalog item -> rendered field) for two examples, and check that the identifier actually exists on the profile or event.
Interpreting an Insights metric as a count of people when it is actually a count of events, or the reverse, when answering engagement questions.
Insights surfaces both message-level and event-level metrics, and some numbers are per-send while others aggregate user actions. Candidates read a label like 'opens' or 'clicks' and assume unique recipients, so they misjudge rates and comparisons. The exam often gives a small dataset and asks which conclusion is supported, and the event-versus-person distinction is the trap.
What to do instead
For any metric question, write down three things before computing: the unit (event or unique profile), the denominator (sent, delivered, or total audience), and the time window. Then compute the rate explicitly and state it in words. If the prompt does not give you the denominator, treat any percentage conclusion as unsupported. Practice converting between counts and unique-user figures so the difference becomes automatic.
Designing a Journey with a delay or filter step and expecting profiles already inside to be re-evaluated immediately when the underlying segment or data changes.
Journeys evaluate entry criteria at the point of entry and then proceed through steps on their own schedule; a profile in a wait step does not automatically exit because its segment membership changed later. Candidates carry over intuition from dynamic segments and assume continuous re-checking. The exam tests understanding of when filters apply and how in-flight profiles behave.
What to do instead
Separate two moments in every Journey question: entry-time evaluation and step-time evaluation. Decide which one the requirement implies, and place filters accordingly (a filter at entry versus a filter mid-journey). Remember that a profile already in a wait step continues unless a mechanism explicitly removes it. Draw a timeline with entry, wait, and filter points and mark where each condition is checked.
Answering deliverability or suppression questions by assuming a hard bounce and a soft bounce, or an unsubscribe and a spam complaint, have the same downstream effect on future sends.
Different response types carry different consequences for the address and for future targeting, and candidates flatten them into one bucket called 'not delivered'. The exam probes whether you know which outcomes are temporary, which are permanent, and which affect consent. Guessing here produces answers that sound reasonable but invert the actual behaviour.
What to do instead
Build a short table of outcome -> temporary or permanent -> effect on future sends -> effect on consent status, and fill it from the platform documentation rather than memory. For each practice question, name the outcome type first, then reason forward. Pay particular attention to the difference between an engagement-based skip and a consent-based suppression, because those are commonly conflated.
Reading a Catalog question as a one-time data import task and ignoring how items stay current, then choosing an answer that leaves stale product data in live messages.
Catalog data must be kept in sync as items are added, changed, or retired, and messages reference the current state at render time. Candidates focus on the initial load and forget the maintenance path, so they pick an option that works on day one but breaks when a price changes. The exam includes scenarios about updates and removals for exactly this reason.
What to do instead
For every Catalog scenario, ask two questions: how does data get in, and how does it get updated or removed? Then check whether the proposed design handles a changed attribute and a retired item. Note what happens when a message references an identifier that no longer exists, and prefer designs that degrade gracefully. Write a two-line lifecycle (ingest -> refresh -> retire) for each Catalog question before selecting.
Comparing two campaigns or two Journey variants by eyeballing open or click totals without accounting for different send volumes or different observation windows.
Raw totals scale with audience size and elapsed time, so a larger send looks better even when its rate is worse. Candidates under exam time pressure skip the normalization step and pick the bigger number. The exam deliberately supplies unequal volumes and unequal windows to see whether you normalize before concluding.
What to do instead
Adopt a fixed routine for every comparison: convert each arm to a rate using the correct denominator, confirm both arms share a comparable time window, then compare. If the window differs, say so and treat the comparison as inconclusive rather than picking a winner. Do three timed drills where the larger total is the worse performer, so the habit of normalizing first becomes reflexive.