Integrated email marketing software with a SaaS product for targeted campaigns

My work at Hypefury spans several areas across growth and engineering. This case study focuses on one specific initiative: integrating Customer.io to connect product usage with lifecycle marketing.

Overview

Hypefury is a social media scheduling and automation platform that helps creators publish content, grow their audience, and sell products across multiple social platforms.

The marketing team wanted to communicate with customers based on how they used Hypefury. However, product activity and marketing communication were disconnected. They could not easily identify customers who had never tried a particular feature, send them an educational email, or show them a relevant message while they were using the app.

The Challenge

The marketing team wanted to target users based on how they used Hypefury, but there was no connection between product usage and marketing. For example, if someone had never tried Auto-DMs, there was no easy way to identify them and send them an email or campaign targeted at teaching them how to use Auto-DMs, why they should use them, and so on.

The Solution

I integrated Customer.io with Hypefury and connected every user to their activity inside the product. We sent their account information, signup source, UTM values, subscription status, and feature usage to Customer.io.

This allowed the email marketer to create targeted campaigns and in-app messages based on what someone had or had not done inside Hypefury, without needing an engineer every time they wanted to launch a campaign.

My approach

I worked closely with the email marketer to understand what kind of users they wanted to target and what information they needed from the product.

Since I was the sole engineer on this work, I handled the data model, the backfill script, the event design, the identity fix, and the in-app messaging integration myself.

The first step was sending users to Customer.io. Hypefury has multiple signup flows depending on the social platform someone uses, and not all platforms give us the same information. For platforms where we received an email during signup, the user was added to Customer.io immediately. For Instagram and Threads, the next step after signup was asking the user to add their email, so we added them to Customer.io after that.

For each user, we sent basic account information such as:

• Name
• Username
• Email
• The platform they signed up with
• Whether they were on a trial or paid plan
• Subscription and account information
• UTM values, when available

Hypefury already had existing users before we introduced Customer.io, so I also created a script to backfill them. I ran the backfill in batches and sent their identity and account information. Feature usage was not available at this point, so that came in the next phase.

After users were available in Customer.io, I started connecting their activity inside Hypefury. The email marketer told me which features and actions would be useful for creating campaigns, then I implemented the tracking inside the application.

Some of the information we sent included:

• How many posts someone had published
• How many posts they had in their queue
• How many drafts they had
• Whether they had used AI to create posts
• Whether they had ever used a particular feature
• Whether they had used Auto-DMs
• How many Auto-DMs they had sent
• Whether they had used Auto-comments

Whenever one of these actions happened, we updated the relevant usage information on the user's Customer.io profile and sent the event to Customer.io. This gave the marketing team both the user's latest feature usage and the individual actions they had performed.

One of the technical problems I had to solve was user identification. In the first version, we used Hypefury's internal user ID as the primary identifier. This created a problem because the same person could end up with separate Customer.io profiles connected to the same email.

For the second version, I changed the primary identifier to email and merged the duplicate profiles. This gave us one Customer.io profile for each user and prevented their account information and feature activity from being split across multiple profiles.

The final part was integrating Customer.io's in-app messaging with Hypefury. Once that was working, the email marketer could create a message, choose the users they wanted to target, and display it inside the Hypefury app without needing another product release.

Working closely with marketing helped me decide what was worth tracking, what would actually be useful in a campaign, and what should stay out of the system.

Outcome and impact

The integration was used for onboarding, trial upgrades, product announcements, re-engagement, and teaching users about features they had not tried.

For example, the marketing team could identify users who had never used Auto-DMs and create a campaign specifically for them. They could do the same for Auto-comments and other features without asking an engineer to first find and export those users.

The biggest impact was not just that we added Customer.io. We connected the marketing team directly to what users were doing inside the product and gave them the freedom to act on that information themselves.

Reflections and learning

The biggest lesson from this project was how important it is to choose the right user identifier before sending any data.

Using Hypefury's internal user ID seemed like the obvious choice at first, but it created duplicate profiles when the same person appeared under different records with the same email. Once campaigns and feature activity depend on those profiles, this becomes more than just a duplicate data problem. A user might enter the wrong campaign, receive the same message twice, or have their activity split across different profiles.

Changing the primary identifier to email and merging the duplicate profiles gave us a much cleaner foundation.

I also learned that it is not useful to track every action just because you can. I worked with the email marketer to understand what they actually wanted to do, then tracked the information that could help them do it. This made the integration useful to the people it was built for, instead of just filling Customer.io with data.