Event mapping: sanity checklist before publishing

Publishing changes to your event mapping impacts behavioral models and aggregations. Here is a quick checklist we recommend following before publishing a new event mapping. 

1. If you have defined events with sub-conditions, check the order of these events. 

For example, if you have mapped the following events: 

• event = form_submission THEN ‘Other form submission’

• event = form_submission Where title contains 'demo' THEN ‘Requested Demo’
  
  

Since events can only be mapped to 1 event to avoid duplicates, the mapping is read one line after the other. Here a demo request event would actually fall in the first condition and therefore be mapped to  "Form Submission" instead of "Requested Demo". 

To make sure the events are mapped correctly, drag and drop the rows to reorder them. 

2. If you have changed the MK Event name, you will need to change the model in the Data Studio after publishing your changes. 

For example, you have changed "Requested Demo" into "Demo Request". 


If behavioral models and aggregations are configured with "Requested Demo", they would be looking for this exact name and not "Demo Request". Therefore after publishing your changes, head to the Data Studio to update your models or aggregations using this event. 

3. If you have added new events to the mapping, you will need to add them to your Likelihood to Buy model in the Data Studio after publishing your changes.

Events not mapped fall into a catch-all event "Other [connector] activity".

By adding an event to the mapping, the event will get its own name. Your behavioral models or aggregations need to be updated to so that they can take the newly mapped events into account.

> Learn how to do update them in this article.

Want to learn more tips? Get a 1:1 session with one of our product specialists: book here!