RudderStack

My main use case for RudderStack is to track all user journeys while using it for multiple purposes beyond user journey tracking, such as sending data to different destinations like Mixpanel and BigQuery for data analytics, and sending it to Mixpanel for events and user journeys.

For user journeys and data analytics, I generate reports on Mixpanel that analyze user behavior data. For instance, when I want to check how many users are involved in A/B testing, I have around four different designs for subscriptions and plans screens. I provide that information through events to RudderStack and then pass it to Mixpanel to decide which design leads to the most conversions or purchases. Additionally, I have integrated with Meta Ads to connect with the Pixel and run all my ads and campaigns.

My main use cases for RudderStack include transmitting data to BigQuery, sending data to Mixpanel, and passing data to Meta Ads.

Working with RudderStack has positively impacted my organization by increasing productivity and effectiveness among cross-functional teams, especially since I can connect to third-party destinations without making changes in my apps or submitting new builds to app stores.

Regarding measurable outcomes, the time saved due to using RudderStack has significantly reduced my process from an average of three to four working days for changes to just an hour or two. Productivity improved from spending six to eight additional hours to zero, allowing my marketing team to add new destinations directly on RudderStack.

Some of the best features that RudderStack offers include real-time events tracking, which allows me to see all events transmitted at any given moment, and the ability to run scripts to change my data before sending it to the destination service, which has helped me redact some identification data for users.

I use scripts on RudderStack to transform data before transmitting it to destination services, allowing only the real data to be sent. For instance, I created a transformation script to prevent internal users from passing their information to the destination and thus cleaning up test or dummy users.

I appreciate that RudderStack manages my apps and services smoothly, and I managed to utilize it with the free tier plan, allowing ingestion of one million events without needing a paid plan.

RudderStack could improve by adding environment concepts for organizing development, staging, and production setups, as the current structure often confuses me, highlighting the need for clearer visibility of historical data for debugging and troubleshooting.

The documentation for RudderStack is adequate, but the user interface can be confusing. I would prefer a navbar on the bottom left for easier organization changes, which most modern platforms utilize.

I believe we have covered all necessary improvements already discussed, focusing on the user interface and historical event tracking for troubleshooting.

I have been using RudderStack for the last couple of years since I joined my organization, starting to work on RudderStack as the platform for transmitting all events and ingesting all data.

Before choosing RudderStack, it was the only solution I considered, and I find it stable with positive reviews.

RudderStack's scalability effectively handles growth and increased demand.

I have seen a return on investment through substantial savings in both money and time, as initial integration efforts have cut costs by reducing the need for extensive technical resources.

My experience with pricing, setup costs, and licensing has been good, as I find the free plan allows ingestion of one million events, which suits most of my requirements without needing to purchase a paid plan.

Overall, I rate RudderStack an eight.

I chose an eight due to its functionality, smoothness, and features provided, but I believe the user interface could be significantly improved based on contemporary design standards.

Regarding RudderStack's artificial intelligence capabilities, I see that it has new access management features empowering data authorization and access controls, giving administrators more confidence that data will not be leaked.

I am using RudderStack as a managed service, directly utilizing it as a Software as a Service offering provided by them.

My advice for others looking into using RudderStack is to identify and segregate environments effectively to prevent data mixing and ensure smooth operations.

My main use case for RudderStack is that my team deploys CDPs for our clients, and some of our clients use RudderStack, so we help them deploy RudderStack within their marketing and analytical workstreams.

A specific example of how a client is using RudderStack in their marketing or analytics workflow is that they bring data together from different sources within RudderStack and then build audiences that they can deploy within paid media channels or within their ERP. For example, it's creating specific audiences and then pushing them to Meta, LinkedIn, TikTok, or to Mailchimp to run more targeted, more effective marketing campaigns.

At the moment, those are the standard use cases for how our clients are using RudderStack.

RudderStack has positively impacted my organization and my clients by helping many of them see a complete and connected user journey, as it brings together data from different sources and touchpoints, allowing us to connect the dots. That in itself is a really big benefit of a solution like RudderStack.

I can't share any specific numbers right now, but we've seen outcomes such as a drop in cost per lead for auto clients by targeting more effective and niche user segments, thus reducing the cost for driving a lead from the website. In the banking sector, there's been a similar situation where deploying audiences based on specific behaviors to certain personalization platforms has improved key performance indicators, such as click-through rates, due to the niche behavioral audiences we could deploy within RudderStack and easily push to personalization tools.

The best feature RudderStack offers is partly its worst; it's the ability to actually deploy the CDP seamlessly while acknowledging that there are parts of the UI that are less seamless. However, the ability as a CDP is very easy to use, and the audience segmentation workstream is very niche, granular, and allows you to extract a lot of individual behaviors.

What makes the audience segmentation so effective for my clients is that generally speaking, my clients tend to give solutions such as CDPs to their data teams, who build audiences using pure SQL in warehouses, which leads to a mistranslation between the data team and the marketing team. This results in it taking them days rather than minutes to create audiences, but with RudderStack, all of that becomes much easier.

Nothing immediate comes to mind for improvement, although I think some parts of the UI could be enhanced. The support team is very helpful, and the tool is structured and laid out well.

I have been using RudderStack for probably less than a year.

I find RudderStack to be stable.

I think RudderStack's scalability is good, as you can connect to plenty of data sources, so practically you can expand based on your requirements.

The customer support is adequate; there could be regional issues, and while the US team is reliable, I'm based in the Middle East, which has a big time difference that hasn't always helped.

The clients that have RudderStack haven't really mentioned any previous CDPs they've used, but personally, my team and I have partnered with many of the big CDPs across the globe.

The primary activation of RudderStack was within paid media activations, and while we haven't moved into ROI or ROAS measurement yet, we're seeing uplifts in some of the metrics mentioned before, so it's heading in the right direction.

My client would have handled the purchasing of RudderStack.

I don't have exposure to the pricing, setup cost, and licensing, as all that was managed by the client who brought us in to derive value from the tool.

I have clients that conduct regular MarTech evaluations, and the ones that have RudderStack came to us with the solution, so it wasn't a case of running an RFP; it was just that we have it, let's run it and make use of it.

On a scale of one to ten, I would rate RudderStack at eight out of ten, as I think it's a fair assessment considering it's a great CDP that allows you to do a lot of things.

I chose eight out of ten because seven would suggest some form of consistent or significant flaw, which I don't think RudderStack has, while nine would mean it's outstanding which I wouldn't push it that far. The lack of ability to deploy within sovereign nations such as Saudi Arabia and follow those specific requirements means it's not really in the nine or ten category, so I think eight is fair.

I haven't looked into RudderStack's governance and security capabilities in too much detail, but the documentation suggests it ticks all the boxes for our governance and security protocols and certificates. Both I and my clients are satisfied in that regard.

Regarding RudderStack's accuracy and reliability of output, I think it's adequate, but I haven't really used that part of RudderStack much. The clients that we have that use RudderStack are not really trusting of components that are too automated or reliant on AI, so I cannot provide further comment.

RudderStack is primarily deployed within the regional warehouses, so we use public cloud.

Both of the examples I have use multiple cloud providers; some have Azure and GCP, while another has GCP and AWS. I'm not sure what they specifically connect to RudderStack, but as a business, they operate on both.

My advice to others looking into using RudderStack is to make sure you know your data. Some CDPs can work with unstructured data, but RudderStack may not be one of them. When you have good clean data and a clear idea of what you want to do, RudderStack can deploy those requirements quickly.

My main use case for RudderStack during the time I used it was to bring different analytics sources to a coherent dashboard.

For a specific example of how I used RudderStack to bring those analytic sources together, we stitched together data from Google Analytics and PostHog, and routed it through RudderStack; that is the function of RudderStack.

RudderStack simplified getting all this data to one location, so I would say it did have a positive impact, but in the grand scheme of things, that is pretty standard nowadays.

The specific outcome for my organization from getting all the data in one location was that we had a single dashboard to look at, so that was the main goal, and it was possible with RudderStack.

The best feature RudderStack offers is a clean UI.

What I liked about the clean UI is the overview, how everything is routed, and how easily I can disconnect and connect different sources. I can pipe them easily to targets as well, so the overview was really clean to understand.

The feature where I could customize my data was also valuable; I could manipulate it with a few lines of JavaScript before sending it to another tool, and that was helpful.

I liked the open-source part of RudderStack, so it could definitely be improved there.

The dashboard could be improved; as far as I knew at that time, you could host your open-source self-hosted dashboard, but it was not at the level of the online version, which was free to use. It would be really beneficial for someone who wants to self-host everything and not send their data to any cloud.

I am currently not using RudderStack, but I was using it for about a year.

In my experience, RudderStack was stable at that time. There was some incident, but it was quickly fixed by the team. They had a really active Slack channel where I could write about issues, and they quickly responded.

We only stitched together a maximum of three or four data points.

The customer support is really great. They had a really active Slack channel where people offered support. There was also one person from the open-source team who was really friendly and wanted to make open source better. I would give a rating of 10 out of 10 for that.

We used Databox before RudderStack.

We decided to switch from Databox to RudderStack because it was open source and we could then self-host it.

At first, we used everything in the cloud with RudderStack's free plan. Then we switched to hybrid, where the transformer container was self-hosted, but the dashboard was used in the cloud because the self-hosted version was not that good.

We did not track our return on investment that precisely, but it definitely saved time. The collection of data from different sources was minimized to just one specific dashboard for an overview. We looked at this data about three times per week, so it saved us a few hours per week.

My experience with pricing, setup cost, and licensing is that we mostly used the free plan, and then we switched to self-hosting. We used the free plan and then self hosted, so I can not comment on the pricing.

Before choosing RudderStack, we evaluated Segment.

On a scale of one to 10, I would rate RudderStack a nine. I was pleased with most of what we needed.

A nine is pretty much perfect in my opinion, but the improvement could be the self-hosting part. They tried to be active in open source, and they even had separate Slack channels for open source.

I would advise others looking into using RudderStack to try it out. I hope they still offer a free plan, and if the free plan is not enough, just try self-hosting and see how it works.

My main use case for RudderStack is being able to connect several data sources to Google Analytics and event triggers that I can fire from the frontend and mainly the backend, so I can send to CleverTap or some automations that I have also used. Basically, I can connect several data sources that are implemented on the frontend and also from the backend, including purchase and subscription event triggers, and from that, I can connect to several providers and several destinations without needing to configure one thing. I do not need to configure one event for each provider I am using. This makes it much easier for me because I greatly simplify my logic for event triggers and synchronization without having to configure everything from scratch for each system I am going to use. For example, CleverTap would be one such case, and with HubSpot, I could connect with the exact same events that I already have configured. I have already developed several automations that used these events, such as sending tracking to the Meta platform, Meta Ads, Google Ads, using the exact same events that all the other platforms received.

The ease of connecting multiple sources and destinations with RudderStack impacts my day-to-day work by bringing clear benefits. In CleverTap, when I started using RudderStack, the main reason for using CleverTap was that we were using CleverTap, but we did not know whether it would be suitable software for our use cases, which would be email, WhatsApp, SMS triggers, and building messaging flows. We signed the contract with CleverTap but did not know how long we would stay with them, and RudderStack brought a big benefit in that I could test the tool, configure all the events, and manage to unify everything in a tracking plan. I had also built a tracking plan that I knew was exactly the user journey that I would use regardless of the software. This applies not just to the Customer Engagement Platforms like CleverTap but also to analytics platforms like Amplitude, using the RudderStack data source.

The most practical example I had was precisely this: with the same events and the same tracking I did with CleverTap, I was able to use that in Meta automations, Google Ads, without having to configure everything again. I could also use it in tracking triggers for Meta, Google, and even TikTok API with an internal service I developed, which processed the events. I built a financial system that used backend events that I knew were one hundred percent reliable to present churn and MRR reports, tracking all users' payment events and building the company's financial dashboard based on that.

The most obvious clear benefit this brought me is not configuring everything from scratch and being able to use a validated structure because I knew that my dataset was being validated. I could see any errors and if I needed to make any corrections, I could do it within the platform. RudderStack shows the error percentage happening in the data, which was one of the biggest examples.

The estimate of time savings I arrived at this through several processes. For example, when we did the universal identification of users, which involves unifying our "asset," the SSC ID, which is the Account ID from our database, across all destinations, RudderStack helped a lot with this by allowing real-time transformations to unify that data. The GA4 implementation and even Firebase were accomplished using RudderStack. I had multiple sources: web frontend sources with JavaScript, backend sources with Node.js, and Firebase itself sending this information. If I had to integrate Firebase, the backend, and the frontend manually, even with a ready structure for CleverTap, I would have spent three times as long for these new integrations using Node, JavaScript, and Firebase. I could join the user's web journey with reliable purchase data from the backend, which had an extremely high success rate, and also from Firebase. I would not easily achieve that without Firebase, which would certainly have increased my workload significantly.

I would add that the Transformations in RudderStack, if I am not mistaken, is the name of the feature. Basically, some fields where I would need to do special processing did not require processing from the frontend. Let us suppose I have a platform where the required phone number format is different from all the others. I could create a Transformation in RudderStack just for that source I wanted to use, and only that source would receive it. This has happened before.

Another point was when I had a very specific business rule in the platform. We needed to create some messaging flows and infer that from a specific parameter, country ID, in the platform sent in the events. In CleverTap, I could not map that country ID to what the country was, so I did that using a Transformation where I created a lookup table, mapping the country ID into a readable name, Brazil, Chile, Portugal, Spain, to use inside CleverTap. This type of transformation helped me many times because some specific tools required it while others did not. I could customize the use case for each platform based on these transformations. I created several little rules based on these transformations, including external API calls, where I enriched data from the IP address. RudderStack itself provides a library that can determine the user's location from the IP, and I have run many segmented campaigns based on users' locations with a transformation that RudderStack gave me, where the user's IP could provide additional fields to enrich my data in real time.

The best features that RudderStack offers, in my opinion, include its main feature, which is having a fast connection with destinations where you will use the platform, so you do not waste time with configurations and name transformations. For me, this is exactly the platform's proposal, and it does that very well. The second feature would be the transformations I mentioned. I did not use the ETL part of uploading to databases like BigQuery, as I know you could schedule events to upload events to an external database every two or three hours, but I only used real-time flows. What was most useful for me was the Transformations and the quick connection between destinations.

Regarding RudderStack's AI features, I find the governance and security aspects excellent, and I appreciate the tracking plan configuration inside RudderStack itself, which I find very interesting.

Regarding the transformations I mentioned, everything worked as expected. However, figuring out how it worked took a long time. The issue is that RudderStack's documentation does not explain the transformation flow well, making it hard to understand where the transformation was applied because of different sources. For example, Node.js had one format, and the frontend part with JavaScript had another format, and I did not know how to work with transformations between these nodes due to lacking documentation. I had to conduct many tests over months to gradually figure out how the transformation worked.

I experienced another problem with name restrictions that were not documented. I remember using "name" in a transformation to transform from a generic name such as full_name to "name", but sending it to CleverTap did not work without providing any error. It merely did not arrive. It was not until I switched the variable name from "name" to "short_name" that it worked. It took two days to realize this issue was not in my transformation or the JSON I built but rather a name limitation not mentioned in the documentation. Essentially, the main problem is the documentation, which I find terrible. When it does exist, it is not very helpful.

One problem I have seen in RudderStack's documentation is that because it covers many tools and different destinations, there is a lot that is poorly documented and does not explain how it works, which I believe is due to many different destinations and edge cases that are not mapped in the documentation. For example, in Meta Ads, there are usage permissions issues when you create a Meta app to use the API, leading to various permission conflicts regarding number verification that require an API call via Postman, among other potential problems.

RudderStack can improve mainly in its documentation, which is lacking. It does not adequately explain how to use the platform, what edge cases exist, and issues such as forbidden names are not explained either. The documentation around Transformations needs to be better as well, to clarify RudderStack's data flow and how it treats incoming data from sources such as JavaScript, which would assist in understanding the expected JSON for each type of information.

A potential problem beyond documentation relates to a limitation on API calls for external enrichment. Specifically, I have had a two-second lifetime limitation for the transformation to make an API call, wait for the response, and insert it into the flow. Two seconds can be a very short time.

I used RudderStack for basically a year and two months, around a year and three months.

RudderStack positively impacts my organization, and I was able to measure concrete results such as time savings and increased efficiency. As I mentioned, RudderStack is a CDP we used in connection with CleverTap, and the savings in results, particularly in revenue, reflect closely connected to CleverTap. For instance, in CleverTap, we have had three to four consecutive months of net revenue around twenty to thirty thousand, solely due to the messaging triggers from CleverTap, but that uses data from RudderStack. I believe I could have saved maybe around forty to sixty percent of my implementation time using RudderStack. At the very least, I estimate about thirty-five percent, but I have not tracked paper results on the time saved. It was definitely a very valuable tool to help me achieve results with CleverTap.

The primary factors influencing my rating are the ability to utilize several input platforms, multiple input nodes, and assign data to various destinations, all of which significantly simplify my work. Even if the Transformations did not exist, which are extremely useful, this capability alone saves a lot of time.

The cloud provider I use is RudderStack's own provider. I do not utilize any external cloud implementation, just event routing through theirs. I only use the cloud offered by RudderStack's platform without any integration with AWS, Google Cloud, or Azure.

My advice for others thinking of using RudderStack is to first understand the platform and how it works. I think having course documentation such as what CleverTap offers, which provides excellent courses to understand their platform, is crucial because RudderStack lacks that. I suggest trying to implement, but do not just aim for a functional setup. If you are unsure about something not working, explore the platform to understand it. I faced many use cases where I had to experiment extensively due to scarcity in documentation. If I had to advise someone starting now, my key suggestion would be to try to grasp the platform first, since that proves more critical than just implementing the data flow they have in mind. I rate RudderStack a nine out of ten.

My main use case for RudderStack includes event collections and customer unification for 360 profiles.

RudderStack has impacted my organization by allowing us to integrate our customers and providing scalable visibility into the activities within our system.

RudderStack allows for a smooth integration of customers from several sources, approximately seven in total.

The best features of RudderStack for my setup are identity stitching and event collections from different sources, which end up getting used the most.

The biggest friction point or frustration I have encountered with RudderStack is documentation and updates to the releases.

I wish RudderStack had a better transformation framework.

If I could change just one thing about RudderStack that would make the biggest difference in my workflow, I would say a more predictive monitoring of the event workstream would reduce the number of alerts we receive.

I have been familiar with RudderStack for almost three years.

Our team did not need any formal training as it was intuitive, but we actually received support from RudderStack as part of the purchase.

Before I landed on RudderStack, I was partially using Snowplow.

I decided on RudderStack specifically over continuing with Snowplow because it was cheaper, simpler to use, and easier to manage.

When I first implemented RudderStack, it took a few weeks to get up and running.

The scope of that setup involved a small part of the data team, but there are many source systems.

The adoption of RudderStack has gone well since the whole company uses data from it, and we primarily have one type of user that generally builds the integrations, along with one or two administrators.

I did not consider any other tools alongside RudderStack.

The product I want to review is RudderStack, the customer data platform and event pipeline tool. My advice to someone considering RudderStack who has a similar workflow to mine is to try the open-source version if you have doubts and then see if it is a fit. I would rate RudderStack a nine on a scale of one to ten.