Integrating RightMessage with...

We often get asked about integrating with email marketing platforms we don’t yet support, or about why we’re not able to work with platforms like Zapier.

On this page, we’ll explain a bit more about how our integrations work and, though we’d love to integrate with everything, integrations generally take a while to implement.

What’s required to integrate with RightMessage

Unfortunately, adding a new integration isn’t always quick. Many form tools that integrate with various email platforms or CRMs simply take submitted information (like a name, email address, and phone number) and create a new record in those systems.

This means they’re only handling a single endpoint: the “create contact” API endpoint.

RightMessage integrations are significantly more involved. Because of how we identify returning subscribers to your website, we need to both pull visitor data down and push, sometimes incrementally, new segmentation data back up.

And this synchronization is handled continuously as someone moves around your website, which means that the APIs of the products we integrate with get a bit more battered than the ones that just get called when a contact form is filled out.

For us to integrate with a 3rd party, the following needs to happen:

  • There needs to be a way of “authenticating” a website visitor with a specific contact in an ESP/CRM.
  • And this generally requires the platform to both 1) send marketing emails and 2) be able to attach a record ID or some other individually identifiable data to each email.
  • Once we (RightMessage) have identified that a specific website visitor is Contact #12345 in your ESP/CRM, we need to be able to query that database to retrieve what’s known about them (e.g. their tags, custom fields, lists they belong to, etc.)
  • This data needs to then be normalized to fit into the way RightMessage auto-segments visitors or routes visitors in a CTA Funnels. Each provider has a different take for how they store, represent, and expose that data via their API.
  • Now that we’ve associated the visitor with a discrete record in your ESP/CRM, when RightMessage learns more things about this visitor we need to seamlessly update this record in the background.
  • We also need to handle what happens when the data structure in your ESP/CRM changes after setting things up in RightMessage. Depending on how the provider is architected, this can be simple – or it can be complex.
  • Any custom field data (like someone’s first name or company name) needs to be serialized into our Liquid templating engine. Some providers have “native” fields, whereas others just have all custom fields thrown together. This often adds another layer of complexity.
  • Finally, we need to be able to create new records in the ESP/CRM for RightMessage customers who use our form functionality within CTA Funnels. This is the extent of what most form platforms need to do!

We are trying our best to roll out new integrations. It just takes a while because of the complexity RightMessage that goes into setting up a new integration.

Why we don’t have an Klaviyo integration yet

Our #1 integration request is Klaviyo, but we’ve been struggling to complete this integration.

Truthfully, about 95% of the integration is complete. But one design decision that went into the Klaviyo API is currently holding us back. Here’s what that is…

Identifying a visitor who exists in Klaviyo makes use of Klaviyo’s Profiles API.

When querying the Profiles API, you’re expected to provide the person ID you want to get information about. This is how RightMessage reconciles a website visitor with a ESP/CRM contact.

So far, so good.

Here’s an example of what Klaviyo would send back:

{
  "object": "person",
  "id": "dqQnNW",
  "$email": "george.washington@example.com",
  "$first_name": "George",
  "$last_name": "Washington",
  "$organization": "U.S. Government",
  "$title": "President",
  "$city": "Mount Vernon",
  "$region": "Virginia",
  "$zip": "22121"
  "$country": "United States",
  "$timezone": "US/Eastern",
  "$phone_number": "",
}

The response is a list of attributes associated with that person. Attributes that begin with a $ are built-in to Klaviyo, and others would be custom attributes.

Again, we’re looking good.

Where we run into trouble is when we want to find out what lists a contact belongs to.

Klaviyo uses lists, rather than tags. A contact can belong to any number of lists: a “Customer” list, a “Newsletter” list, and so on.

Unfortunately, when querying the Profiles API a person complete set of list memberships aren’t returned. This is where Klaviyo fundamentally differs from the other products we’ve integrated with.

Instead, you’re required to use the Lists API to query whether the specific person belongs to a particular list.

And this wouldn’t be all that bad… if you could query multiple lists at once.

But, alas, you can’t. You need to first query their Lists API to get back all available lists, and then go through each list – one by one – and check to see if the person in question belongs to it.

In practice, this ends up playing out as follows:

  1. Visitor shows up at website, we know they’re Person #123.
  2. API Call #1: Find out what attributes exist on Person #123 (e.g. their name, city, …)
  3. API Call #2: Now find out what lists exist in this Klaviyo account (“Customer”, “Newsletter”, …)
  4. API Call #3: Does Person #123 belong to “Customer”?
  5. API Call #4: Does Person #123 belong to “Newsletter”?

The more lists that exist in an account, the more API calls are required.

Should a Klaviyo account have 100 lists, 102 total API calls would need to be made just to figure out what attributes and lists are associated with a contact!

And this is why we’re struggling to release this integration. 102 API calls for a single session, multiplied by the 50,000 people who just received your latest marketing email and clicked over to your site, equates to a lot of server load and slowness.

Work at Klaviyo?

👋 Hi!

We love what you all are building. And we have a lot of mutual customers who are itching to see Klaviyo work with RightMessage.

All we need is the ability to have a single API endpoint that allows us to fetch attributes and list memberships for a person. Once that’s available, our integration is ready.

Why we don’t support $YOUR_PLATFORM yet

Building an integration is time consuming and expensive, so we tend to “follow the money”: how many customers are we losing out on by not supporting a particular ESP/CRM?

The single best way to get your desired platform to the top of our integration list is to write in and ask. – and encourage peers who use your platform and are into personalized marketing to do the same.

After having written in, if/when we roll out your integration we’ll notify you over email.

Integrating with Zapier

We regularly get questions about why we don’t have an integration with Zapier.

Here’s why…

An integration with RightMesage requires us to look up information about the visitor, and possibly send up information about a new contact or when we learn something new (i.e., we change the segmentation) of an existing contact.

Based on this architecture, there are two things that are keeping us back from integration with Zapier. One of which has to do with our ability to look up data. The other has to do with saving you money.

#1: How Zapier triggers and actions work

Most of the tools that integrate with your ESP/CRM likely have a Zapier integration that exposes a trigger, like “a form was submitted”, to Zapier.

The trigger data will include whatever information was collected by the form, and then a new action can be set up to send that same data to your ESP/CRM as a new record.

Because we have a lookup requirement for our integrations – we need to know who we’re dealing with, and what you already know about them – we’d need to have “A visitor went to your website” as a trigger, which would then lead to an action of “look up in your ESP/CRM what we know about this visitor.”

In practice, few ESP/CRM’s that integrate with Zapier have a “find” action. Most just have the ability to create or update new records. And without the ability to easily query a contact record, RightMessage becomes like any other form tool… we have no idea that the visitor is already on your list, that you already know X, Y, and Z about them, and so on.

#2: “Zap” limitations

The “Professional” tier of Zapier costs $49/month and lets you run 2,000 tasks a month.

This wouldn’t be an issue if RightMessage were just capturing leads for you via a form. If you were generating 2,000 leads a month, you’d likely gladly pay Zapier that money and be eager to upgrade to bigger plans that support more “zaps” per month, allowing you to capture more leads.

But a true RightMessage integration with Zapier would mean that we’d need to fire a “zap” every single time a known visitor comes to your website!

This means that if you send an email to 50,000 people and a bunch of them show up to your website, RightMessage would then phone over to Zapier to look up a contact’s data in your ESP/CRM, and then Zapier would send back to RightMessage what it finds out.

In the above scenario, your 2,000/monthly “zap” allowance would be eaten up in minutes.

Next up

Segmentation

RightMessage includes a centralized Segmentation Engine that drives pretty much every facet of the product.