We don't have a partnership, but we're a consulting organization. We've proposed Segment as a solution to a few of our clients, and some of them have adopted it. We've helped them with the configuration and integrations.

One example is in the InsurTech space. The client had a direct-to-consumer (D2C) channel for selling and distributing policies, along with other channels like an agent portal for sales, leads from partners and purchased databases, and ads from Google and Facebook. We had a lot of different data sources, and we wanted to consolidate all those leads into a CDP instead of just sending them straight to the CRM, which was HubSpot. 

So, we used Segment to ingest all the leads from those sources, and then integrated with a few third-party tools like Verisk to qualify the leads within the CDP. The qualified leads were then sent directly to the CRM, where they became MQLs—marketing qualified leads—and entered the sales funnel.

I like the straightforward way of connecting with various data sources and destinations. That's the most valuable feature. It has built-in integrations for a lot of them, so the overall effort required for integrations is relatively low. 

And they have SDKs in a wide range of programming languages, so it can support pretty much any language if you need to integrate it with your own products, not just off-the-shelf solutions. 

In this case, the D2C application was built using Java, and it was easy to integrate, with a few challenges.

The main challenge is that the SDKs are pretty similar across programming languages, and they're not super flexible. They might not support certain use cases. It has a set of functions that work well if they fit your needs, but if you need something custom, you can't rely on the SDKs and have to use recipes. And using those recipes extensively isn't ideal. 

For example, we were getting leads from the D2C application, sending them to Segment, and then from Segment to HubSpot. If Segment could mimic HubSpot's API, we could leverage HubSpot's SDK capabilities even through Segment. 

But Segment's API is generic, so it doesn't do anything tailored to HubSpot. As a product designer, I know that would be hard to accomplish anyway. It's not a criticism, because I would probably design it the same way. 

But as a consumer, I don't care how it's designed; I care if it fits my use case. If not, how much effort will it take to make it work? That was the challenging part.

It took a lot of time to integrate Segment and make it communicate with HubSpot in a certain way. So, the challenge is the lack of flexibility in the SDKs, given the capabilities of the destinations.

From my experience, it's mostly fine. It could benefit from more customization capabilities. The product itself is good, but it would be awesome if it allowed you to write your own extensions to augment the CDP's capabilities.

And another suggestion. It's not about a missing feature, but rather something Segment is doing that I personally don't think a CDP should do. It's like a mobile phone you use for watching videos, listening to music, and making calls. But to be a good mobile phone, you need to be the best at making and receiving calls, and texting. Everything else is a distraction. Instead of optimizing for those distractions, you should solidify the basics.

To illustrate this, Segment has many capabilities that overlap with things like CRMs, campaign management systems, tracking systems, and so on. These capabilities can give a small startup a real kick-start, but as you scale, the capabilities other than the core CDP features don't scale as well. 

For example, it does campaign management, but it's not really a full-fledged campaign management system. When you're starting out, it's fine, it's great, it fits almost all your use cases. 

But as you grow from a two-person organization to a 300-person organization, you'll have to deal with more complexity. You'll likely need to look for a dedicated campaign management system and integrate it with Segment. 

Now, if you've been using Segment's campaign management for a long time, moving that part to a different system will be a roadblock.

We have been using it for about a year and a half, maybe a bit longer.

Segment is stable. There have been some occasional challenges with time lags between data being passed from the source and reaching the destination, but it's not common.

In terms of general scalability, I think it scales very well. It's capable of handling loads of traffic. I'd rate it a nine out of ten.

I wouldn't call that scalability because it's more about the functional and auxiliary features. Not all of the features scale equally well.

I've used mParticle and Cadence from a vendor called the Data Team.

Top pros of Segment compared to those other products: 

• It's easy to set up.
• It's SaaS, so no infrastructure expertise is needed.
• It integrates easily with most common SaaS-based tools. 
• The segmentation capability is also great.

Cons of Segment:

Customization can be hard. Sometimes the Segment SDKs don't match the API contracts of the destinations, which necessitates custom coding.

Cadence had its own strengths. It was a different kind of CDP, with a primary strength in machine learning-based lead qualification. Segment doesn't have that capability. I don't remember much about mParticle; it's been a while since I used it extensively.

The initial setup is straightforward. 

1. First, you need to understand why you're using it, so establish the business objectives, particularly from sales and marketing perspectives. 

2. Second, identify what's driving you to use a CDP. Pinpoint the specific use cases, especially for smaller or newer setups. That's crucial, which dictates whether or not a CDP is necessary. 

In my opinion, a CDP should typically be used when the organization and its systems are mature, with plenty of customers, not right at the beginning. 

Consider if you're adding unnecessary complexity and cost by using a CDP too early.

So, first, establish the need. Then, identify the source and destination systems. Define the purposes. 

For example, you might use it for lead qualification or to consolidate leads in one place before sending them to a central management system. That's a major use case for any CDP. 

Once you've identified the use cases and established the need, identify the data sources and destinations. 

3. Then, move on to the implementation strategy. Start with out-of-the-box connectors, then look at any custom solutions that require custom integrations, like your D2C or agent portal. 

When planning, assess how much is readily available and how much needs custom work, as that's where we encountered challenges.

The resources required for deployment depend on the use cases, but it can start with just one developer. However, they need to be well-versed in marketing and sales concepts.

It's important because a typical developer might not have the business knowledge to gather requirements effectively. Someone who understands lead management, tracking, Google Analytics, and similar tools will be easier to code and contribute to requirements development.

The average timeframe for a full deployment of Segment is two to four weeks on average. You can even get started in a day if you don't have any custom tools.

Moreover, it does not require much maintenance. It's one of those systems you can set up and forget.

The ROI is entirely dependent on the nature of your business. If you're a new business, I don't think you'll reach ROI breakeven quickly with a CDP product. 

However, if you're an established business facing challenges with lead qualification or segmentation, for example, Segment can bring ROI very quickly.

It's not for everyone.

The pricing was on the higher side but it wasn't excessively high. It's definitely not tailored for the smallest businesses, but it's well-suited for setups that anticipate significant growth.

My one-line advice, not just for CDPs but for many other products, is this: Don't adopt them simply because they exist. 

Establish and validate your use case, and consider the ROI before configuring requirements. This is especially relevant for startups. 

Often, they have a young CTO who's enamored by loads of technology, viewing them as shiny toys to play with. This can lead to adding excessive complexity that becomes difficult to manage later, potentially resulting in a net loss. 

I'd always recommend starting with the basics, and a CDP isn't a basic need for most organizations. Start simple, evaluate your needs continuously, and when you encounter challenges worth solving, explore solutions like Segment.

Overall, I would rate the solution an eight out of ten.