RudderStack

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.

My main use case for RudderStack is creating dashboards and analytics.

A specific example of how I use RudderStack for creating dashboards and analytics is calculating booking rates, where we store the data in our database regarding jobs booked for certain people, and we have linked it with RudderStack to see the analytics for the rate or for the percentage of calls that are being booked, the percentage of calls which are being dropped off or those that are not booked. Based on that at a customer level, we are seeing the rates at which we are generating leads, the booking rate for different customers, and so on.

In my previous company, we used to create custom customer-specific dashboards with RudderStack where we would track all the metrics for the customer, and that used to help us find any anomaly or gain certain insights which were useful for us to improve the experience of the customer and improve our product through it.

The best features RudderStack offers include table joining features, creating dashboards and analytics, and metrics.

The table joining feature in RudderStack helps us because we have certain data spread across multiple database tables, and there is no direct tool that we can use to actually combine certain things and query on top of that and visualize it or transform it into a dashboard or a table. RudderStack usually helps us to do that. Regarding metrics and analytics, it is mostly for different use cases, such as getting the booking lead percentage, understanding where the user is dropping off, counting certain things, or tracking certain customer behavior. So for those purposes, analytics, metrics, and dashboards are valuable.

RudderStack has positively impacted our organization by helping us keep our customers happy because we are able to track the data, and according to that, we are improving the product and the experience of the customer. So if our customers are happy, the organization is also happy and positive as well.

I cannot think of anything major that RudderStack can be improved on right now. I cannot really think of anything small or a feature that could make my work even smoother as of now.

I have been using RudderStack for two to three years at my previous company, whereas in this one, we have started a few months back, so it has been six to seven months.

My advice to others looking into using RudderStack is to just go for it if you are looking for dashboards and analytics that can be run on top of different databases.