DataDome Reviews

In my organization, the primary use case of DataDome is end-to-end observability across telecom applications and infrastructure, especially for real-time network services and customer-facing systems. In our domain, we use DataDome APM to monitor microservices handling telecom workflows, such as call and session management systems, IMS components, charging and billing gateways, and API gateways handling subscriber requests. If a subscriber experiences a delay in call setup or data session activation, we trace the request across microservices and quickly identify which service is slow and whether it is a database latency issue or downstream dependency.

In one of our day-to-day use cases, we use DataDome to secure the customer login portals, recharge and payment pages, and self-care mobile and web applications. These often face credential stuffing attacks, which we received in earlier days. There was a major outage due to these credential stuffing attacks on one of the Bharti servers in the North India circle. Fake login attempts were also detected. Using DataDome, we secured our servers and all nodes, and we stopped the account takeover attempts. In our system, we expose multiple APIs for balance check, recharge, SIM activation, and plan browsing. Different bots always try to scrape plans and pricing data, abuse recharge APIs, and flood APIs. DataDome helps us by identifying those non-human traffic patterns, blocking malicious API calls, and ensuring service availability for real customers.

In our organization, particularly in our product, multiple teams interact with DataDome regularly, mainly security, NOC, and application teams. The security team uses DataDome on a daily basis to monitor bot traffic trends and malicious traffic trends, and they review block requests and attack patterns. They fine-tune protection policies, including CAPTCHA, block, and allow rules. In one practical scenario, there was a spike in login failures, and the security team checked the DataDome dashboard to confirm if it was a credential stuffing attack, then they tightened rules accordingly. The NOC team uses this for monitoring traffic anomalies, checking if bot traffic is impacting system performance, and coordinating during incidents. The application team and charging team also interact with DataDome to address legitimate users being mistakenly blocked and to handle new APIs or endpoints introduced. We also coordinate with the security team to whitelist trusted traffic and adjust rules to avoid user impact.

For my particular domain in charging, DataDome offers several strong features, but a few stand out as especially valuable for telecom use cases in our situation. The most critical feature of DataDome is that it detects and blocks bots in real-time without noticeable latency. It uses different behavioral analysis instead of just IP-based blocking. This matters for our case because it prevents credential stuffing on login portals, stops API abuse, and ensures genuine users are not impacted. This directly protects customer experience, which is directly proportional to revenue and helps us to onboard more customers overall. The advanced bot identification is another key point of using DataDome, as it identifies bots even if they rotate IPs or mimic human behavior. It uses device fingerprinting and request pattern analysis. The API protection is another key point as it protects backend APIs from abuse and overuse and detects abnormal request patterns. Low false positives indicate that legitimate users are rarely blocked.

DataDome has a significant positive impact on both our security posture and business performance. The first point is reducing fraud and account takeovers. Before implementing DataDome, we observed repeated credential stuffing attempts on customer login systems. After implementation, these attacks get blocked in real-time. The impact is a significant reduction in account takeover incidents and improved customer trust in security. The second point is improving API stability and performance. Our telecom charging APIs, including recharges, balance checks, and plan browsing, are frequent bot targets. It filters out malicious traffic before it reaches the backend system, which directly contributes to reducing unnecessary load on APIs and more stable performance, especially during peak hours. The better customer experience is another benefit since DataDome has low false positives. Genuine users are rarely blocked, and intelligent CAPTCHA is only applied when needed, which is directly proportional to smooth login and transaction experiences and fewer customer complaints related to access issues.

After implementing DataDome, we observed measurable improvements across security, performance, and user experience. The reduction in bot traffic has also decreased significantly. Earlier, around 25 to 30 percent of our incoming traffic on customer-facing portals was bot-driven. After DataDome, we are able to block 90 to 95 percent of malicious bot traffic. The impact is cleaner traffic reaching backend systems and better reliability of analytics and monitoring. There is also a drop in credential stuffing. We used to see thousands of failed login attempts per minute during attack peaks. Post-DataDome, these attacks get blocked at the edge before reaching the application, resulting in a 70 to 80 percent reduction in suspicious login attempts reaching the backend and a significant drop in account takeover incidents. The API load reduction is significant as APIs like recharge and balance check were heavily targeted. Before, there was a high spike in API calls during bot attacks leading to performance degradation during peak hours, and after using DataDome, we observe around 20 to 30 percent reduction in unnecessary API traffic. The impact is quite clear with improved API response time and a more stable system during high traffic.

While DataDome performs very well overall, there are a few areas where improvements would make it even more effective in a telecom environment. One point is better handling of false positives. Although it is generally very accurate, in some cases, legitimate users or internal systems get flagged, especially corporate VPN users, internal testing tools, and partner integrations. The improvement would be a more granular and easier whitelisting mechanism and better transparency on why a request was blocked. Another point is more detailed analytics and custom reporting. The current dashboards are good, but sometimes detailed analysis is limited. Custom reporting options are not very flexible. As part of improvement, more customizable dashboards can be made, along with the ability to create business-specific reports, for each API and per region. Better visibility for API-level protection can also be developed. The protection works well, but debugging blocked API requests can take time and is not always easy to trace the exact reason for blocking, thus requiring more detailed logs and traceability for API traffic, along with easier correlation with backend systems. The integration with the existing security ecosystem can also be improved.

I believe I have added enough information. The most valuable feature for our organization is DataDome's real-time bot detection and mitigation. Since our applications like login and recharge APIs are frequent targets of automated attacks, the ability to block malicious traffic instantly is very critical. It helps us prevent fraud, maintain API performance, and ensure a seamless experience for genuine users.

In our project, we mainly work with hybrid infrastructure, but for cloud environments, we commonly use Amazon Web Services and sometimes Microsoft Azure, depending on the customer requirement and region. This is because it integrates very smoothly with AWS services including EC2, EKS Kubernetes clusters, and Lambda. We use these integrations for real-time infrastructure monitoring, application performance monitoring, and log analytics.

For some customer environments, the subscription and integrations are managed through the AWS marketplace because it simplifies procurement, billing, and enterprise account management. For larger portions, this is convenient because cloud spending and monitoring costs can be consolidated under the same AWS commercial agreement. It also makes deployment faster since integrations with AWS services are already streamlined. However, the procurement model can vary depending on different customers. Some sub-organizations use direct enterprise licensing with DataDome, especially when they need custom pricing, advanced support, security modules, and multi-region enterprise agreements. The procurement model varies from customer to customer.

The integration of DataDome with our existing systems was relatively smooth compared to many traditional monitoring tools. One major advantage is that it already provides built-in integration for public cloud platforms, Kubernetes, Linux servers, databases, messaging systems, CI/CD pipelines, and logging tools. For most components, we mainly needed agent deployment and API-based integration and configuration rather than heavy custom development. In our environment, we integrated DataDome with clusters, application servers, API gateways, and cloud infrastructure for centralized logging systems. It fits well into our existing DevOps and NOC workflows because alerts can be connected to ticketing and incident management platforms.

I would rate this review as a 9 out of 10.

DataDome has been used primarily for real-time bot protection and fraud prevention. It secures login pages, checkout flows, and API endpoints against automated attacks such as credential stuffing, scraping, and account takeover attempts.

The main workflow involves reviewing today's traffic and block charts to quickly understand if anything unusual is happening. After that initial check, we drill into attack types, scraping, fraud attempts, review flagged IPs, sessions, check false positives, and validate recent rule changes for model updates. The first action is essentially to determine whether we are under attack and whether DataDome is blocking correctly.

The core capabilities we rely on every day are real-time bot detection and automatic traffic blocking. The real-time dashboard and threat visibility are the features we use most frequently. The automatic bot mitigation engine handles most of the protection without manual intervention. We also frequently use traffic analysis and reporting, especially when investigating incidents such as scraping attempts or credential stuffing attacks. The most valuable aspect for the team is that DataDome operates mostly in a set it and monitor it mode where the system actively protects applications while we primarily focus on reviewing exceptions and tuning when needed.

After implementing DataDome, the biggest impact we observed was a reduction in automated abuse and stabilization of traffic patterns across our applications. Before implementation, we dealt with frequent spikes from scraping bots and login abuse attempts. Once it was fully in place, we saw clear improvement in application stability and backend server efficiency. On the security side, we improved our overall posture against credential stuffing and scraping attacks, which reduced the number of manual incident investigations the team had to handle. In terms of operational benefits, the team now spends less time analyzing traffic anomalies and more time focusing on actual application issues. It also improved confidence during high-traffic events since we know a significant portion of automated traffic is being handled in real time. The main improvements have been better protection, reduced operational noise, improved system stability, and lower manual effort in handling bot-related incidents.

There are some features in DataDome that we do not actively use anymore in day-to-day work. One example is the more fine-grained manual rule tuning and the custom challenge configurations during onboarding. We spent time experimenting with these to understand how different rules would impact traffic, but once the system was properly tuned, we rarely needed to adjust them manually anymore because the automated detection handled most scenarios effectively. Another feature we initially explored was the deep investigative drill-down for individual sessions and advanced forensic analysis. While it is powerful, we found that we only use it occasionally during specific security incidents rather than as part of regular monitoring. We also experimented early on with some advanced reporting and segmentation views, but over time, the team standardized on a smaller set of dashboards that provide the key metrics we need, so the more detailed views are used less frequently. Most of the unused features are not problematic; they are just more situational. As the system matured in our environment, we naturally shifted toward the core features such as real-time blocking, high-level dashboards, and automated protection.

If there is one thing I could change about DataDome, it would be to improve the transparency and explainability of detection decisions, specifically making it easier to understand why a request was classified as a bot or triggered a block in a more intuitive way. Currently, the system is very effective, but when something gets flagged, we sometimes need to dig through multiple dashboards and logs to fully understand the reasoning behind the decision. A clearer, more unified explanation layer would have a direct impact on workflow. Overall, it would make day-to-day operations smoother by turning an investigation from a multi-step analysis process into something more immediate and self-explanatory.

I have been familiar with DataDome for the past six to seven months.

Before DataDome, we were not using any other solution. We were completely focused on DataDome itself.

The initial setup to get DataDome in front of our key endpoints such as login and checkout was relatively straightforward. However, getting it fully production ready took longer. The first one to two weeks were mostly about tuning, adjusting rules, reviewing false positives, and making sure legitimate users were not being impacted. We also spent time validating traffic behavior across different regions and user patterns. Overall, it was fairly quick to get live and protecting traffic, but it took closer to a few weeks to reach a stable, well-tuned state that we were confident running at scale in production.

DataDome is not used single-handedly; it is a team workflow. With DataDome, we were able to start using it fairly quickly. Without formal training for the entire team, the initial onboarding was straightforward, and the basic dashboard and alerts were intuitive enough that we could begin monitoring traffic almost immediately. That said, a small core group, mainly from Security and DevOps, did spend some time diving into more advanced parts, such as tuning detection rules, reviewing false positives, and understanding how the scoring and blocking decisions work. In practice, most of the team did not need dedicated training sessions, but a few key engineers did a deeper dive to make sure we were using it effectively and safely in production.

We were focused on DataDome, so there were no other options considered.

On the traffic side, we observed a reduction of roughly 70% to 90% in malicious bot traffic reaching our applications. From an operational perspective, the number of bot-related security incidents dropped by around 60% to 75%. We also saw improvement in incident response efficiency, with roughly 30% to 40% less time spent per security investigation. Overall, the biggest measurable benefit was not just fewer attacks getting through, but also the reduction in noise, meaning the team could focus on real issues instead of constantly reacting to bot-driven alerts.

Collaboration definitely changed after adopting DataDome. Before, bot-related issues were mostly handled in a reactive way where security, DevOps, and application teams would jump in only after an incident was reported. That often led to a lot of back-and-forth during active issues. After implementation, collaboration became more structured and proactive. The security platform team now primarily owns the configuration and monitoring of DataDome. We also saw better alignment between teams during incidents. Instead of debating whether traffic was legitimate or malicious, everyone refers to the same dashboards and threat data. Overall, it shifted collaboration from reactive firefighting to a more centralized, data-driven, and preventive model with clearer ownership and faster alignment during incidents.

With DataDome, the biggest friction points we experienced were mostly around tuning and visibility during the early phase. Initially, one challenge was false positives, where some legitimate traffic, especially from unusual user behavior patterns, corporate networks, or certain geographies was occasionally flagged as suspicious. It required careful tuning and coordination between security and application teams to strike the right balance between protection and user experience. Another friction point was the learning curve around rule behavior and detection logic. While the platform is easy to start with, understanding why certain traffic is blocked and how scoring decisions are made took time for the team to fully get comfortable. We also noticed that debugging edge cases can sometimes take effort, especially when trying to trace why a specific session was challenged or blocked. Finally, during the early rollout, there was some coordination overhead between teams, since security owned the configuration, but application teams were impacted when legitimate traffic needed adjustments. That improved over time, but it was a noticeable friction point during onboarding. Overall, most of these issues reduced significantly after the initial tuning phase, and once the system stabilized, day-to-day friction became much lower.

In terms of its main capabilities such as real-time bot detection, traffic reporting, and dashboards, the evolution is less about features being set and more about progression toward automation and simplification, where the platform requires fewer manual interventions and more managed, intelligence-driven protection. I would rate this review as an 8.

We are DataDome in SOC for cybersecurity. We use the solution to perform traffic analysis on any website or server to see whether there is a lot or little traffic.

The most valuable feature of DataDome is the traffic analysis. Suppose any customer website has a 1,000 threshold value per minute. If the traffic exceeds the threshold value, we can block that traffic.

The solution catches and perfectly blocks traffic from malicious IPs. DataDome does not catch legitimate IPs during traffic analysis, even when the traffic exceeds the threshold value.

I have been using DataDome for the last one year.

I didn't see any bugs in DataDome. However, the solution sometimes does not catch malicious traffic.

More than 100 people are using the solution in our organization.

I contacted the DataDome team and raised my concerns. They said that the issue was related to some rule creation and that they would work on it and update us.

Using the solution depends on your purpose. DataDome is a good tool for analyzing traffic in a SOC project. It is easy for a new user to learn to use the solution for the first time.

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