What is our primary use case?
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.
How has it helped my organization?
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.
What is most valuable?
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.
What needs improvement?
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.
For how long have I used the solution?
I used RudderStack for basically a year and two months, around a year and three months.
What was our ROI?
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.
What other advice do I have?
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.
Which deployment model are you using for this solution?
Public Cloud
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Other