Managing Custom Events

On the Settings > Project Settings page, use the Manage Custom Events section to control how Iterable handles incoming custom events.

In general, consider saving events that help you measure conversions, trigger journeys, or will help you with segmentation (now or in the future).

On the other hand, if you don't need an event, don't send it to Iterable. Too many events can add clutter to your project, making it hard for users to understand your data model and find the information they need.

# Table of contents

# Event handling options

For each incoming event, Iterable can:

1. Save the event to a user's event history (which can be useful in segmentation).
2. Trigger a journey.
3. Save the event to a user's event history and trigger a journey.
4. Do nothing.

With this sample configuration, Iterable ignores incoming error_app_crash events, saves quizCompleted events, and triggers one or more journeys with signUp events.

This example does not save signUp events.

# Event handling for newly encountered events

The Allow New Custom Events into the System toggle determines how an Iterable project deals with incoming custom events:

• When the toggle is on, the project saves all incoming events regardless of their event names. Additionally, it adds newly encountered events to the Existing Custom Events table (below the toggle), selecting both Allowed and Saved. This is the default behavior.

• When the toggle is off, the project only saves incoming events listed as Saved in the Existing Custom Events table (because they've been previously tracked or you've manually added them).

  Disabling the Allow New Custom Events into the System toggle does not prevent Iterable from storing never-before-seen data fields on custom events that the project still allows. The toggle controls the top-level event names that Iterable stores, not the fields on those events.

To learn more about the Event Creation API key setting, see our guide API Keys.

# Adding Events to the custom events list

In order to add a new event to the custom events table, navigate to the Existing Custom Events section and click New Custom Event.

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 journey that triggers off of the event (like below), then the Triggers Journeys 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.

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 journey from an event that is not allowed
• You cannot disallow an event that triggers a journey without first dropping it as the trigger to that journey
• An event cannot be deleted from the custom events table
• Allowing an event that was previously disallowed will not backfill or restore event history

# Updating custom events

When sending a custom event to Iterable via the POST /api/events/track API endpoint, an optional string id parameter may be passed. If an event exists with that id, the event will be updated. If no id is specified, a new id will automatically be generated and returned.

Sample response where an id of "12345" is passed in the track request:

{
    "msg": "Event with id: 12345 tracked.",
    "code": "Success",
    "params": {
        "id": "12345"
    }
}}

Sample response when no id is passed in the track request:

{
    "msg": "Event with id: 1397b147db9c41f187a39844beba9c tracked.",
    "code": "Success",
    "params": {
        "id": "1397b147db9c41f187a39844beba9c"
    }
}