Table of Contents:
In the Project Settings page (Settings > Project), you can manage how custom events flow into Iterable through the "Manage Custom Events" section. You may find this functionality useful if using a platform like Segment to pass events into Iterable, and it’s passing in events that you don’t need.
In general, we recommend sending events to Iterable only if they:
- Trigger a workflow
- Are useful for segmentation purposes (now or in the future)
This includes events that are misnamed or no longer relevant. The main downside to sending all events is that it can clutter segmentation and other workspaces, making it harder for both experienced users and newcomers to find the fields that they're looking for. This can also have a performance impact, as it may take longer for our software to return all of the possible fields to you.
Before we dive too far into the project settings, it's important to understand the different ways that Iterable can handle incoming events. For each incoming event, we can:
- Save the event to a user's event history (useful for later segmentation)
- Trigger a workflow
- Save the event to a user's event history and trigger a workflow
- Do nothing
The below table shows an example configuration where we ignore all incoming error_app_crash events, save quizCompleted events, and trigger one or more workflows with signUp events.
In this example, we are not saving signUp events to users' event histories.
Also worth noting: because quizCompleted events are allowed, they have the potential to trigger workflows, but Trigger Workflows is not selected in this example because the event has not been listed as the trigger in any existing workflows.
Towards the top of the "Manage Custom Events" section, you will find an "Allow new custom events into the system" toggle.
This toggle dictates how Iterable will handle events that are entering your project for the first time and are not already listed in the "Existing custom events" table (found below the toggle).
If the toggle is set to "Yes", newly encountered events will be added to the custom events table with both Allowed and Saved selected. This is the default behavior.
If set to "No", newly encountered events will be ignored by Iterable until manually entered into the custom events table.
In order to add a new event to the custom events table, navigate to the "Existing custom events" section below, and then click on the "+ New Custom Event" button.
Now, enter your desired event name in the "Custom Event Name" field that's presented to you, and click "OK". Remember when entering the name that event names are case sensitive!
Notice how your new event is created with Allowed and Saved selected by default.
If you have already created a workflow that triggers off of the event (like below), then the Triggers Workflows checkbox will be selected as well.
With your new event now established, navigate to the space to the far right of the event, and click "Edit" to adjust how it will be treated in your environment.
Note: This screenshot assumes that the aforementioned surveyCompleted workflow exists
While editing, you can decide if you want to allow the event to pass through, and if so, if you want it to be saved to a user's event history.
Here are some additional considerations:
- You cannot save an event to a user's event history without also allowing the event
- You cannot trigger a workflow from an event that is not allowed
- You cannot disallow an event that triggers a workflow without first dropping it as the trigger to that workflow
- An event cannot be deleted from the custom events table
- Allowing an event that was previously disallowed will not backfill or restore event history