Marketo BP Expert common mistakes
Marketo BP Expert · Understand the traps and how to avoid them.
Assigning a person to a lifecycle stage without also ensuring the underlying scoring and data-value fields that gate that stage are set, then wondering why reports show stage counts that the segmentation rules contradict.
Candidates memorize the stage names and the Change Data Value flow step but treat lifecycle as a label to be set rather than a state that downstream reports, smart lists, and sync filters depend on.
What to do instead
Before changing lifecycle, list every downstream consumer (smart list filters, engagement program gates, CRM sync filters, revenue cycle model) and confirm the stage transition satisfies each condition; practice tracing one record from anonymous through MQL in a sandbox.
Building a smart list with filters that reference fields which are not yet populated at the time the campaign runs, then concluding the campaign 'didn't fire' when the real problem is filter logic.
Candidates conflate trigger campaigns (which fire on a change event) with batch campaigns (which evaluate current state), and they forget that filters evaluate the value at the moment of the run.
What to do instead
For each smart list, state aloud whether it is trigger or batch, what field each filter reads, and when that field gets written; test with a single known record before scaling.
Putting a person into a nurture stream without checking communication limits, engagement program cadence, and whether the person is already in another stream, causing duplicate or suppressed sends.
Candidates treat engagement programs as simple email sequences and overlook that membership, cadence, and global communication limits interact, and that a person can only be in one stream per engagement program.
What to do instead
Before adding to a stream, verify: person not already in that engagement program, communication limit status, and expected send day from the cadence; document the add/remove flow steps explicitly.
Assuming a form submission will overwrite existing field values without checking the 'change data value' behavior and form pre-fill, resulting in stale or blanked data.
Candidates assume forms always update records, but form field behavior, progressive profiling, and pre-fill settings determine what actually gets written.
What to do instead
For each form field, state the intended write behavior (always update, only if blank, never), and confirm pre-fill and progressive profiling settings match; test with a record that already has values.
Confusing segmentation (dynamic, rule-based, on person fields) with static lists and smart lists, and using the wrong one for targeting, causing audiences that drift or don't refresh.
Candidates treat segmentations, static lists, and smart lists as interchangeable audience containers, but segmentation memberships update automatically as fields change while static lists do not.
What to do instead
For each targeting need, classify it: dynamic attribute-based (segmentation), fixed snapshot (static list), or rule-based query (smart list); verify segment membership recalculates after a field change.
Setting up a CRM sync without verifying field mappings, sync direction, and sync filters, then diagnosing 'missing leads' that were actually filtered out or mapped to the wrong field.
Candidates focus on the connection status and ignore that sync filters, field-level sync settings, and direction (bi-directional vs one-way) determine what actually crosses the boundary.
What to do instead
Audit the sync filter, field map, and per-field sync direction for each object before testing; create one record on each side and trace it end-to-end, including a field update in both directions.
Building a score model with overlapping or double-counting behaviors so a single action inflates the score, and never validating against a known record's expected total.
Candidates add scoring behaviors without checking whether multiple smart campaigns or behaviors fire on the same event, and they don't reconcile the score against the score field.
What to do instead
Maintain a score ledger: list each behavior, its points, and the campaign that applies it; test with a fresh record and confirm the resulting score equals the expected sum, and check for duplicate triggers.
Configuring email programs and deliverability settings (unsubscribe, communication limits, sender authentication) incorrectly and assuming sends will behave as in a test environment.
Candidates test with internal addresses that bypass unsubscribe and limit logic, so they never see suppression, and they skip sender authentication and unsubscribe link checks.
What to do instead
Test with an external address that has communication limits and unsubscribe states set, verify the unsubscribe link and preference center work, and confirm sender authentication before any production send.
Reading a report's numbers as ground truth without checking the report's time frame, attribution model, and whether the underlying program/channel tags are consistent.
Candidates assume reports aggregate the same way regardless of setup, but program channel, acquisition, and attribution settings change what a report counts and how it credits success.
What to do instead
Before interpreting any report, state its time frame, filter set, and attribution basis; cross-check a small number of records manually against the report to confirm the aggregation logic.
Creating programs and channels ad hoc without following the workspace/partition and channel conventions, leading to records that can't be found, reported on, or synced correctly.
Candidates treat program setup as a naming exercise and overlook that channel definitions drive program statuses, success attribution, and reporting, and that partitions control visibility.
What to do instead
Before creating a program, confirm the correct workspace/partition, the channel that matches the program type, and the program status progression; verify the program appears in the intended reports and sync scope.