Skip to main content
Curious if anyone has worked a creative solution to better track when a user has replied to a specific email in order to improve downstream workflow nodes?

As an example, if I have an email that is sent from a Sales rep two days after an intake is complete, and want to send a follow-up email from that sales rep seven days later, it'd be great to ensure that follow-up is only sent to users that did not engage with the day two email to ensure we do not sound tone-deaf in our messaging.

I know email replies are typically hard to track, but wanted to see if there's a clever workaround that someone has implemented successfully.
Hi @Corey Egan ! Rachel from Support here, with an idea. Since the reply would be sent to your inbox, you would know when responses come in. What you could do is send a custom event at that time with information on the user that made the reply. Then in your workflow, after that initial email send, have a filter checking for that custom event. If they do have it on their profile, then they already engaged with the initial email, and they would exit the workflow. If there's no custom event, stay in the workflow and get the follow-up. Hope this helps!
@Rachel Wu This is a great creative solution! I think I can set up a Zap to automate the custom event creation as well.

Follow-up q - do you know if there is a way of only sending a custom event for users that are already created in Iterable? I want to avoid creating new user profiles if the email address set up in the Zap is receiving emails from other sources (e.g. internal sales teams, etc).
Hi @Corey Egan ! The only way I can think of not creating events for users that don't exist yet, is if you happen to use "userId" in your calls, and your "events/track" API call only includes the "userId", rather than email. In this case, if the user doesn't exist yet with that "userId", there will be an error like "userId doesn't exist".

All other times, sending a custom event won't create a profile, but there's still action on that user. If you send a custom event for an email address (or userId plus email address), if that user doesn't exist yet, it will create what we call a "shell profile", which has the Events History tab populated with the custom event, but there are no fields listed under the "Available Fields" tab on the profile. This profile also won't be searchable via segmentation. It becomes an actual profile if you update the profile, send an email, subscribe them to a list, etc.

Because of how difficult it is to work with these "shell profiles", we recommend having some way to check if a user was created in Iterable before sending a custom event, such as using the https://api.iterable.com/api/docs#users_getUser endpoint, or having some source of truth on your end so you don't run into the rate limit of that endpoint.

Hope this helps!

Reply