How to replicate your Trigger Automations from MEP to CEP?

This guide is dedicated to transitioning your MEP Campaigns to Batch's Customer Engagement Platform (CEP). To facilitate your migration, we have implemented an automatic replication tool directly with

1. How to Launch the Replication

The process is designed to be simple and fast. Follow these steps:

  1. Log in to your Batch interface and go to the Automations tab.

  2. Select the Trigger automation you wish to migrate.

  3. Once on the Automation form, click the Actions drop-down menu in the upper right corner of the screen.

  4. Choose the "Replicate on CEP" option.

  5. Once this action is performed, a modal window will appear to confirm which elements will be transferred and which will require manual configuration.

  6. Click “Replicate on CEP” to launch the replication.

2. Migration Scope: What is Transferred

During replication, Batch attempts to match your MEP settings with the new CEP settings. Generally speaking, elements (events, attributes, etc.) that do not exist on the CEP cannot be transferred.

✅ Migrated Elements (Subject to Availability)

💡 Note:

  • For an attribute to be migrated between MEP and CEP, it must have the same name and the same type (string, float, bool, etc.).

  • For an event to be migrated between MEP and CEP, it must have the same name.

  • Basic Targeting:

    • Country and Language.

    • Attributes: Custom and Native attributes (if an equivalent exists on the CEP side).

    • Migrated Natives and new names in CEP:

      • On Mobile: App version ⇒ App version, Installation date ⇒ App installation, Last visit date ⇒ Last visit, Has custom user ID ⇒ Has custom ID, Push opt-in ⇒ Push opt-in.

      • On Web: Last visit date ⇒ Last visit, Has custom user ID ⇒ Has custom ID, native event "subscription" ⇒ subscribed to web push notification.

  • Event Targeting:

    • Count, Count Since, Last Event, and event counter filters (if events and attributes exist on the CEP side).

💡 Note :

  • To avoid targeting errors, if any targeting element—such as an event, event filter, or attribute—is missing in the CEP, the entire query is not migrated. Otherwise, it could be difficult to identify the specific missing element.

  • Trigger:

    • The trigger event and its associated filters (if an equivalent exists on the CEP side).

💡 Note:

  • If the event has multiple filters and at least one filter attribute does not exist in the CEP, none of the filters will be migrated to prevent errors due to partial migration.

  • Time Management:

    • The delay (custom or based on a date attribute) as well as the start and end dates.

  • Cancellation:

    • Cancellation events and their filters (if equivalents exist on the CEP side).

💡 Note :

  • If there are multiple exit events and at least one does not exist in the CEP, none of the exit events will be migrated.

  • If there are multiple exit events with filters and at least one filter attribute is missing, none of the filters for any of the exit events will be migrated (though the exit events themselves will be migrated). As with the trigger, this behavior is designed to avoid errors from partial migration.

  • Content:

    • Title, message body, and deep link.

  • Technical Settings:

    • Priority, Payload, and TTL.

  • Cappings & Grace Period:

    • Rules are copied, but history is not migrated.

    • Example: If a user has already triggered an MEP Automation limited to 2 sends twice, they will still be eligible to enter the new CEP Automation.

❌ Non-Migrated Elements (Must be configured manually on CEP)

Certain elements specific to the previous platform or requiring new logic are not imported:

  • Automation Analytics: You will have access to analytics for all sends orchestrated from the CEP.

  • Labels: You can easily recreate them in the CEP via Settings > Labels and then associate them with your Orchestration.

  • Smart Segments: You can reproduce a similar version of smart segments using CEP targeting.

  • Natives:

    • The following native events: installed then opted-in, installation.

    • The following native attributes:

      • On Mobile: OS version, Device type, Last push date, Mobile carrier, Transactions tracked, City (coming soon), Last location (coming soon).

      • On Web: Installation date, Last push date, City (coming soon), Device category, Browser model, OS model.

  • Audiences: You can import your audiences into the CEP via Data > Audiences using the same files as for the MEP, then associate them with your Orchestration from the targeting section.

  • Retargeting: This feature is available in an improved format within the CEP; you can reproduce your retargeting and even go further.

  • AB Tests: In CEP Trigger Automations (which are multi-step), AB testing is performed using the Random Split feature, allowing you to test 2 to 4 variants.

  • Mobile Landings: This feature has also evolved significantly on the CEP to offer more composition capabilities. Choose "Show Mobile Landing" as the redirection for your Push and build your new improved landing page.

3. Managing the User Flow Transition

Once the automation is created on the CEP, the question is that of "pending" users (those who triggered the event but have not yet received the message due to a delay). The user flow is not transferred automatically.

Here are the two recommended strategies:

Option A: Immediate Switch / Easy set-up

If your trigger has no delay (instant send) or if you do not necessarily wish to keep pending users in your MEP trigger, you can simply:

  1. Stop the automation on the MEP.

  2. Immediately activate the automation on the CEP.

    Users will exit the MEP trigger immediately and can enter the CEP trigger upon completing the trigger event.

Option B: Gradual Transition / Advanced set-up

If you have a significant delay (e.g., 7 days) or a delay based on a date attribute, use this method if you want users currently in the MEP trigger to remain there until the end of the delay and receive the message:

  1. On the MEP side: Change the trigger event to a "Fake Event" (an event name that does not exist in your actual tagging plan). This "closes the tap" for new entrants without stopping the processing of those already in the funnel.

    • To do this, send the following payload (adapting the id, time, and name as desired) to the Trigger Events POST - Track Events API:

  2. On the CEP side: Launch your new Automation. New users will enter here.

  3. Closure: Wait until the configured delay has elapsed (e.g., wait 7 days if your delay is 7 days) or until no more messages are being sent (if you have a delay relative to a date attribute), then permanently stop the MEP automation.

Please feel free to contact your Customer Success Manager if you have any questions.

Last updated