Conversion Suppression

Conversion suppression prevents a contact from continuing through a Wunderkind Journey Builder campaign after they have made a purchase.

Wunderkind journeys use conversion data in Salesforce Marketing Cloud to evaluate purchase activity both when a contact enters a journey and between email sends. When a qualifying conversion is identified, the contact is prevented from receiving subsequent campaign emails.

Conversion Data Requirements

Conversion data is typically maintained within an existing Salesforce Marketing Cloud Data Extension.

  • As part of implementation, the first step is to identify your source of truth for purchase activity and confirm that it can be used within Journey Builder.
  • At minimum, the conversion data used for this implementation must provide:
    • Contact Key / Subscriber Key: the unique identifier used to identify the contact in Journey Builder.
    • One current record per Contact Key / Subscriber Key: The conversion source must contain a single current record for each contact. This ensures Journey Builder can reliably retrieve a single current Last Purchase Date when evaluating the contact.
    • Last Purchase Date: the date or timestamp of the contact's most recent qualifying purchase.

The conversion source should maintain a single current record per Contact Key containing the contact's most recent purchase date.

Data Freshness

The Last Purchase Date must be updated frequently enough to support the timing of the journey's conversion checks.

Journey Builder evaluates this data between campaign touchpoints to determine whether a contact has converted since their previous email. Therefore, any delay between the actual purchase and the corresponding update in Salesforce Marketing Cloud creates a period during which Journey Builder may not yet recognize the conversion.

For example, if a contact:

  1. Receives the first campaign email on Monday,
  2. Makes a purchase on Tuesday, and
  3. Is scheduled to receive the next campaign email on Wednesday,

the conversion data must reflect Tuesday's purchase before the contact reaches the next conversion check in the journey.

We recommend confirming the expected refresh frequency and latency of your conversion data during implementation. If the conversion data is not refreshed before the applicable journey conversion check, the conversion criteria and/or journey timing may need to account for the expected delay.

Making Conversion Data Available to Journey Builder

The conversion check uses Contact Data rather than relying on the static Journey Data provided when the contact originally entered the journey. The conversion Data Extension is linked to the Salesforce Marketing Cloud Contact Model through Contact Builder > Data Designer.

The relationship uses the Contact Key / Subscriber Key contained in the conversion source to associate the conversion record with the contact progressing through the journey.

This allows Journey Builder to retrieve the contact's current Last Purchase Date when conversion criteria are evaluated.

Where Conversion Suppression Is Applied

Conversion data is evaluated at two points within applicable Wunderkind journeys:

  • At journey entry
  • Between journey touchpoints

These checks serve slightly different purposes.

Journey Entry Filter

The journey Entry Filter prevents contacts who recently converted from entering the campaign.

  • An example entry condition may be:

    Last Purchase Date is before Today minus 4 days
    OR
    Last Purchase Date is null

In this example, a contact may enter the journey when their most recent purchase occurred more than four days ago, or no purchase has been recorded for the contact.

A contact whose Last Purchase Date falls within the previous four days does not meet the entry criteria and is not admitted into the journey.

The exact conversion window is configured according to the agreed campaign rules.

  • For migrations, Wunderkind will generally preserve the existing conversion-suppression logic where applicable.

Conversion Checks Between Sends

Conversion suppression is evaluated again while the contact is progressing through the journey (between touchpoints).

  • Following the wait period between campaign touchpoints, the contact reaches a Conversion Check Decision Split before the next email is sent.
  • The Decision Split evaluates the current Last Purchase Date to determine whether the contact remains eligible to continue.

For example, where there is approximately one day between sends, the continuation criteria may resemble:

Last Purchase Date is before Today minus 1 day
OR
Last Purchase Date is null

Contacts meeting the continuation criteria proceed toward the next campaign touchpoint.

Contacts who have made a qualifying purchase during the applicable suppression window follow the conversion path and exit the campaign without receiving the next email.

The date threshold used for this check should correspond to the timing between journey touchpoints and the conversion-data update frequency. Therefore, the exact criteria may vary between journeys.

Cross-Campaign Priority Reset

Wunderkind behavioral journeys also maintain cross-campaign priority state to prevent competing behavioral campaigns from sending simultaneously.

When a contact exits a journey because of a conversion, the journey includes an Update Contact activity before the contact exits. This activity resets the contact's applicable cross-campaign priority state.

This step is important because the contact is no longer actively participating in the campaign. Without resetting that state, the conversion-based exit could leave the contact represented as active within the cross-campaign priority Data Extension and incorrectly affect their eligibility for future Wunderkind campaigns.

Wunderkind Pre-Trigger Conversion Check

While Journey Builder conversion suppression provides protection after a contact has been passed into Salesforce Marketing Cloud, Wunderkind also maintains a conversion check before the initial campaign signal is triggered.

For the first touchpoint of a Wunderkind campaign, Wunderkind verifies that the contact has not converted since the behavioral event that qualified them for the campaign.

For example, for Cart Abandonment:

A user adds an item to their cart.
The behavior makes the user a potential candidate for Cart Abandonment.
Before sending the campaign signal to Salesforce Marketing Cloud, Wunderkind checks whether the user converted after the qualifying cart activity.
If a conversion is identified, the campaign signal is canceled.
If no conversion is identified, the signal is sent to Salesforce Marketing Cloud and the contact may enter the journey, subject to the configured Journey Builder entry criteria.

This pre-trigger check protects the initial campaign touchpoint from conversions made during the user's visit. The Journey Builder conversion checks protect subsequent touchpoints after the contact has entered the journey and, in some cases, a longer lookback on the initial entry.

Client Considerations

The effectiveness of Journey Builder conversion suppression depends on the accuracy and freshness of the conversion data provided within Salesforce Marketing Cloud.

During implementation, please confirm:

  • The Data Extension that serves as the source of truth for conversion activity.
  • The field used as the Contact Key / Subscriber Key.
  • The field containing the contact's Last Purchase Date.
  • How frequently the Data Extension is updated.
  • Whether the conversion source contains a single current record per contact.

Please copy and complete the following table to provide to your WKND Rep:

Date /LocationExtension NameContactKey FieldLast Purchase Date FieldUpdate FrequencySingle Current Record per Contact
EXAMPLEPurchase_Data
Data Extension > Conversions
ContactKeyLastPurchaseDateNightlyYes

Wunderkind will configure the Journey Builder criteria according to the agreed implementation requirements. However, because the underlying conversion data and its refresh process are client-owned, we recommend validating the freshness and accuracy of that data and identifying any known latency that should be accounted for in the journey configuration.



Did this page help you?