Going Beyond the CDP: An Iterable vs. Blueshift Showdown

The ability to set up if/then scenarios inside customer journey flows is a standard but important capability for today’s marketer. For example, if someone reserves a hotel room to check in on Tuesday the 1st, then they will receive a How is your stay? push notification from the hotel manager on Wednesday the 2nd. But what happens if that customer changes their reservation?

Well, with Iterable, you’d have to rebuild the segment. Blueshift, on the other hand, automatically adapts the How is your stay? email date based on the new reservation. And what if you want to send multiple messages at different times related to the hotel reservation? One day before check-in, one day after check-in, two days after check-out, 11 months after check-out, etc. With Iterable, you’d need to build multiple customer journeys for each scenario, which can become a lot to maintain.

With Blueshift, that same process is taken care of behind the scenes. Our platform enlists an individual’s historical data to trigger event-based campaigns without requiring the marketing team to activate a specific promotion. In this example, the individual might receive a message that says something like, “You loved last year’s trip; let us help you book another great vacation.” This feature, which we call transactional modeling, allows you to connect and segment lifecycle events/behaviors through a common identifier.

Iterable was built to solve email personalization challenges, but consumer expectations have grown far beyond the inbox. In order to be successful, today’s marketer needs to be just as savvy when it comes to mobile, apps, social profiles, and more.

Blueshift’s customer record doesn’t have a single primary key, but can be created and executed against any of the following keys: email, phone, device UUID, customer_id and Blueshift’s anonymous_id. This means clients can execute personalized messages to all of their customers, both known and unknown. For example, in Blueshift you can send mobile push messages to anyone that has a device UUID — and that’s it. There’s no need for an email address or customer id. Meanwhile, Iterable’s current documentation states the inability to send mobile push notifications, SMS, web-push, or the like to anyone without an email, as email is a required field.

Blueshift also stores behavioral data related to anonymous profiles so you don’t lose valuable data insights just because someone hasn’t signed in yet. Once there’s an identifiable event (email, phone, customer_id, etc), Blueshift combines all the anonymous data into a single identifiable user profile.

No system is perfect. Even the best of the best will occasionally experience hiccups, but those that are designed from the ground up to be scalable will be far more stable than those that aren’t (over the last 18 months, Iterable has experienced 61 incidents which degraded the performance of the application compared to Blueshift’s 6).

The way Blueshift handles scale is unique because our platform uses micro-services. Each service is tied to a different backend data store including in-memory, key-value, time-series based, reverse index, OLAP, log-based, etc. This means the Blueshift infrastructure is optimized for speed and flexibility by always ensuring the application hits the right data store for speed. Iterable is optimized for storage, which limits the amount of data it can process and retain along with how fast it can respond.