Growth Is Possible Without a CDP — Packaged or Composable

A story of fast growth without a CDP.

You don’t need a CDP. 

All you need is a data warehouse, a couple of data collection tools, and a reverse ETL tool, and there you go — you’ve got everything you need to accelerate growth via data-powered personalization.

Well, guess what? 

When I was given reigns of Growth at Integromat (now Make), we had none of the above. We just had Google Data Studio powered by a Postgres database, that’s it — not even a Product Analytics tool. 

And this is when we were already growing very fast, adding several hundred users every day. 

We were constrained and badly needed better tools to deliver personalization and reduce churn. And since we didn’t have a data team at the time, it was on me to figure out what data tools we needed for our stack. 

As a bootstrapped company, we neither had the budget nor the people power to implement a fancy data stack that I could write blog posts about. 

So I went shopping with a thrifty mindset and bought only the tools I knew for sure we’d use — a product analytics tool, an email engagement tool, and an onboarding tool. 

That’s it. 

That was the growth stack that calmly led Integromat to 200k+ users and a $100M+ exit. A pretty sweet outcome for a bootstrapped company with a growth team of four — or so I’d like to think. 

Growth without a CDP is possible.

So with all the talk about the need for Composable CDPs and deliciously layered data stacks, I figured now would be a good time to write about our evaluation and implementation processes, the challenges we faced, and how we used the tools in our stack to grow a little every day.

Let’s roll.

Evaluation 

It’s the summer of 2019 and the modern data stack is yet to blossom.

I’ve always been obsessed with good software, and since I’d spent a year creating tutorials on how to leverage the full power of Integromat and growing our user community, tinkering with new tools was a big part of my job. 

So when I was tasked with evaluating our data stack, I left no tool alone and explored pretty much everything that existed at the time. 

I had a clear idea of the capabilities I needed and how I wanted to make them work together. I’d also learned that building and maintaining integrations is a pain nobody deserves unless that’s the job. Therefore, I was on a constant lookout for out-of-the-box integrations between the tools for product analytics, email engagement, and onboarding — I was almost maniacal about integrations.

I spent a lot of time going through the documentation of the tools I evaluated and was quickly able to dismiss the ones that didn’t meet my expectations (based on their API docs or the available endpoints).

This was also the first time I experienced demos where prospects are treated as noobs and are made to go through a series of calls just to see a basic demo — I was equal parts amazed and amused. 

The Stack

Anyhow, I ultimately settled for the following tools:

• Mixpanel, where we got a pretty sweet end-of-quarter deal (that included the group analytics feature)

• Customer.io, where we had to opt for the premium plan (that came with a customer success manager who was insanely helpful)

• Userflow, which I’m glad I discovered on Product Hunt because their workflow builder was delightful (and the founder offered us a white-glove experience)

Together, for less than fifty thousand monthly-tracked users (MTUs), we spent a little over two thousand dollars per month on this stack. 

I had looked into Snowplow but our DevOps team had concluded that it was too complicated to self-host (Snowplow didn’t offer a hosted solution in 2019) and we didn’t really have the budget for a readymade CDI solution like Segment Connections. Therefore, our CTO assigned one of our ace engineers to build a microservice that would collect and sync event data to all the tools in our stack. 

The Integromat Growth Stack

Were there gaps in this solution? Many.

Did I want a CDP? Absolutely. 

Were there days I was frustrated due to the constraints of our stack? You bet. 

In retrospect though, I don’t regret anything we did, and in fact, I like to believe that we were able to move relatively fast because we had to make do with less and not proving the ROI wasn’t an option.

Implementation

This is where I knew I wouldn’t compromise. 

By the time our procurement was complete, I’d done the following:

• Listed down the burning questions that I wanted Mixpanel to answer 

• Planned the preliminary campaigns I wanted to run on Customer.io and Userflow 

• Created a comprehensive tracking plan with the bare minimum events (and associated properties) we needed in each tool 

Deciding what data to collect and for what purpose made the implementation process rather smooth — it’s the fundamental thing to do before implementing a customer data stack. 

Our ace engineer — let’s call him Trackman since that’s what he called the tracking service he’d built — had a few questions along the way, and answering them wasn’t a problem for me. 

Surprises

To my surprise, it wasn’t obvious to Trackman why he was being asked to collect all that data with so much granularity and he was curious to understand how his efforts would help accelerate growth. I’d taken it for granted that someone with his level of technical aptitude would surely know all this stuff — a classic mistake that most non-data teams make when working with their data or engineering counterparts.

Most of the collaboration took place async and we’d only get on calls if Trackman had to ask me something specific or when I had to explain why I wanted certain account properties to be synced alongside user properties and events — a topic that I intend to cover in detail very soon.

In a few short weeks, we had the growth stack up and running and it was delightful to see data flowing in. 

P.S. I later learned that many organizations begin to decide what data to track only after completing the buying process, and then blame the data/engineering team or the tools for taking months to implement. 

P.P.S. I also learned that at some orgs nobody decides, let alone documents, the events that are tracked and synced downstream. The tools are just handed over for implementation while non-data teams keep their eyes peeled for juicy insights. And when things go wrong, guess what happens? Exactly.

Challenges 

We had to deliberate over some issues we hadn’t anticipated in advance. 

Like every other email tool at the time, Customer.io neither supported custom objects (for account-level data) nor had the ability to create an email preference center (for users to opt out of specific types of emails instead of hitting a global unsubscribe button). In fact, they released both of these last week — more than three years after I asked for those capabilities.  

Since it was common for a user to be part of multiple accounts (organizations on Integromat), it was critical for us to trigger campaigns only based on a user’s activity within a particular account rather than their activity across all the accounts they were active in. Power users and channel partners, in particular, would have been inundated with emails if their activity across multiple accounts had been merged. 

One user performing events in multiple accounts

Therefore, we had to come up with a workaround that was far from elegant — we created distinct profiles on Customer.io by concatenating the user_id and the organization_id, effectively creating multiple profiles of a user if they had used the same email to join multiple accounts. 

And since we were using Customer.io to send multiple newsletters — product announcements, blog updates, etc — as well as event-based lifecycle emails, I just couldn’t settle for a global unsubscribe.

I respect the sanctity of the inbox and the idea of not enabling our audiences to choose the kind of content they’d like to receive via email was very unsettling. I like to keep my own inboxes sanitized and very often find myself completely unsubscribing from newsletters — often very good ones — because of a lack of choice over the topics or the delivery cadence. 

Users must be able to choose the types of content they wish to subscribe to

I regularly find established companies, including some household names in SaaS, settle for a global unsubscribe — such a missed opportunity to retain users and better understand their needs.

Anyhow, we had to build and integrate our own email preference center which turned out to be astoundingly non-trivial. 

Execution

Our growth was purely organic via content, community, and engagement activities — we didn’t spend a dime on paid marketing. 

Once we identified points of friction in our onboarding, it was easy to advocate for minor additions and adjustments — like why we needed an onboarding survey to deliver more relevant, timely, and personalized emails or why we must create an exit survey to reduce churn by understanding the reasons for downgrades or cancellations.

For the most part though, we just created highly personalized in-app and email onboarding campaigns and then kept iterating on the copy and the segments. 

Little things

As I mentioned earlier, we tried a lot of little things to improve the end-user experience. 

Sebastian, the Userflow founder, built us a nice integration with Mixpanel that enabled me to create funnel reports combining events from our app with events from Userflow — allowing me to see if users moved in the right direction in the product upon completing a step in an in-app guide (tracked as an event on Userflow). 

But there were other little things that I really wanted to implement — seemingly straightforward things — which in reality, were astonishingly complicated. 

Constraints

We didn’t pat ourselves on the back when our email open rates improved because we wanted to know if users actually performed the desired actions after opening an email or not. We also wanted to compare the data with that of users who had reached the activation milestone — the elusive aha moment — without much engagement with our email and in-app campaigns. Turns out, such analyses were a lot more complicated than they should be. 

Seemingly simple analyses that are more complicated than they should be

Similarly, we wanted to implement a workflow to exclude a user from an email campaign if they had an open (as in unresolved) support ticket. 

Please correct me if I’m wrong but I’m certain that you’ve received emails to the tune of “hey did you know we also have this mind-blowing feature” while you’re already struggling with a not-so-mind-blowing feature and support hasn’t managed to find you a resolution — it happens with me way too often.

These are times when I’m really tempted to smash that unsubscribe button (spam reports are only for perpetrators) but then I remind myself of my own struggles implementing supposedly simple workflows. And if I’m feeling particularly generous, I’ll even respond to that email with unsolicited advice.

Conclusion

I’d like to conclude with an opinion. 

I’m not one to undermine the importance of a data team but I’m also not going to shy away from saying that growth is possible without a CDP — even without a data team — if you can empathize with the end user and are willing to do the little things to improve their experience.

When I first started at Integromat, I was just a failed startup founder with a desire to put my skills to use in an environment where I’d be given the time and the freedom to experiment, and like they say — do things that don’t scale. 

I was already in love with Integromat as a user and I would jump with joy thinking about all the ways I could help the company grow. One of them was creating use case-specific tutorials — something I knew Integromat needed — so I reached out to their support offering to help with just that. 

Long story short, Integromat enabled me to work with data at scale and learn most of what I know today in a pretty short span. And for that, I’m forever grateful to Ondrej Gazda for betting on me.

---

This is the third and final part of the CDP Beats series.

But there’s more…