Companies face mounting pressure to digitally transform and deliver seamless cross-channel experiences. These experiences are critical not only for attracting new prospects and driving satisfaction but also for providing more value to customers and enabling business growth. Adobe Experience Manager empowers businesses to optimize and deliver engaging experiences across websites, mobile apps, and other touchpoints. As part of delivering a compelling experience, it is vital that companies develop a deeper understanding of their customers. As a result, user experiences can be optimized, and issues can be proactively addressed before customers become frustrated with errors or broken journeys.

End-to-end observability across every tier powering your digital experiences using RUM

Application owners and SREs often struggle to get a complete picture of the customer journey and are unable to pinpoint issues due to a lack of comprehensive visibility. As a result, it is difficult to ensure application efficiency and ensure accurate delivery across touchpoints. This lack of end-to-end visibility leads to blind spots that impact customer satisfaction.

The Dynatrace platform offers comprehensive observability and monitoring across the entire technology stack. By going beyond application performance monitoring with AI-powered, full stack observability, Dynatrace enables seamless end-to-end visibility. Furthermore, by integrating with Adobe Experience Manager, you get quick visibility, ensuring application efficiency across all channels and the ability to scale in support of even the largest Adobe Experience Manager instances.

Dynatrace automatically detects all Adobe Experience Manager applications and visualizes their dependencies—from the website, to the container, to the cloud service. This enables you to enrich your Adobe analytics data with end-to-end traces across all tiers and to get precise, real-time user insights. You can monitor Adobe Experience Manager instances intelligently and provide personalized, content-driven experiences without gaps or blind spots.

By relying on Dynatrace® Digital Experience Monitoring (DEM) integrated with Adobe Experience Manager—specifically Real User Monitoring, Synthetic Monitoring, and Session Replay—you gain real-time insight into the user experience of their sites and applications. This capability extends across devices and geographies and includes critical front-end monitoring use cases like performance and availability monitoring, troubleshooting, root cause analysis, complaint resolution, and understanding user behavior. This allows teams to understand exactly where to make improvements in the Adobe Experience Manager stack and deliver a smoother, more personalized experience to customers.

Furthermore, Dynatrace turns analytics into real-time answers, enabling you to better understand how applications’ outages impact critical business metrics like conversions, revenue, and engagement. This actionable insight allows you to accelerate time to value, optimize customer experience, and meet your business needs.

Deliver excellent customer experience with the powerful Davis AI engine

The Dynatrace Davis® AI engine allows you to diagnose anomalies when they arise in real-time and pinpoint the root cause down to the broken code before your customers are affected. You can now proactively detect availability and performance issues across the stack.

By enabling faster identification of potential issues, you can reduce mean time to repair and minimize customer impact. With AI-powered observability, you can quickly troubleshoot complex environments like Adobe Experience Manager to maximize uptime and customer satisfaction. The result is a smooth, uninterrupted user experience.

Visit Adobe Experience Manager documentation to learn more about the Dynatrace integration

Want to it out for yourself? Sign up for your Dynatrace free trial.

The post Dynatrace and Adobe Experience Manager: Seamless end-to-end observability appeared first on Dynatrace news.

Synthetic testing simulates real-user behaviors within an application or service to pinpoint potential problems. Here’s a look at why this testing matters, how it works, and what companies need to get the most from this approach.

What is synthetic testing?

Synthetic testing is an IT process that uses software to discover and diagnose performance issues with user journeys by simulating real-user activity. Also called continuous monitoring or synthetic monitoring, synthetic testing mimics actual users’ behaviors to help companies identify and remediate potential availability and performance issues.

For example, teams can program synthetic test tools to send large volumes of simultaneous resource requests to a new application and evaluate how well it responds. Are all requests met in a reasonable amount of time? If not, what was the median increase over baseline response times? Did these requests impact users’ overall application experience? How?

By understanding how an app or service may respond in real-world conditions, teams can better pinpoint potential problems and fix these issues before live deployment or before users are affected. Along with real user monitoring (RUM), synthetic testing provides a comprehensive view into the user experience to ensure software meets user requirements.

Synthetic testing vs. real user monitoring

Both synthetic testing and real user monitoring (RUM) play a role in application development. The biggest difference between synthetic testing and RUM is synthetic simulates real-world scenarios, whereas RUM measures actual real-user behavior.

Another difference is where they happen in the development life cycle. Because synthetic tests don’t require a live environment, teams can conduct them in production or test environments to assess overall performance or the performance of a specific application component. In addition, these tests’ simulated nature requires minimal resource overhead, meaning teams can run them continuously.

RUM, meanwhile, requires actual users. As a result, it can only be conducted once applications or services are live. While this makes RUM more limited in scope, it doesn’t negate its value. Synthetic tests attempt to mimic both common and uncommon user behaviors, but even the best simulations are no substitute for the real thing. Users often interact with technologies in unpredictable ways that could reveal previously unknown issues.

Put another way, users may act out of frustration in response to a set of circumstances — such as “rage clicking” if an application doesn’t respond fast enough. Synthetic tools, meanwhile, can only simulate frustration. While teams can program them to rage click after a certain point or even randomly, they can never truly replicate the real-user experience.

As a result, organizations benefit from a mix of RUM and synthetic tests.

Types of synthetic testing

There are three broad types of synthetic testing: availability, web performance, and transaction. Each offers its own strengths and abilities for different needs.

Availability testing

Availability testing helps organizations confirm that a site or application is responding to user requests. It can also check for the availability of specific content, or if specific API calls are successful.

Web-performance testing

Web-performance testing evaluates metrics including page loading speed, the performance of specific page elements, and the occurrence rate of site errors.

Transaction testing

Transaction testing sees robot clients attempting to complete specific tasks, such as logging into accounts, filling in an on-site form, or completing the checkout process.

How synthetic testing works

Synthetic testing works by using a robotic client application installed on a browser, mobile device, or desktop computer. These applications send a series of automated test calls to a service or application, which simulate a user’s “clickstream,” or the actions they take while on the site.

Consider a synthetic test designed to evaluate an e-commerce shopping application. First is a test of the home screen. Does it open quickly and consistently with no visual artifacts? Next, the synthetic test links to product pages. It then moves on to shopping carts, shipping rates, and, finally, a simulated purchase. The robotic client application reports if any of these transactions fail or perform too slowly, allowing companies to make changes before services go live.

When designing synthetic tests, it’s worth using a combination of browser-based, mobile, and desktop tests to assess application performance. This is because each of these traffic vectors comes with unique challenges. For example, even if response times are consistent across all testing environments, mobile users could still experience issues with automatic screen size scaling or application design choices that favor desktop users.

Requirements for synthetic testing

To create a reliable testing environment, several components are critical.

Well-defined goals

Effective synthetic testing depends on well-defined goals. Organizations need to identify what they’re trying to measure before they write and deploy test scripts. Then, it’s ensured the data captured is relevant to these goals.

Customizable robot clients

Robot clients are the foundation of synthetic testing. But in the same way that testing needs to evolve over time, organizations need client components that can be configured to keep pace with change as their on-premises, cloud, or hybrid environments evolve.

Comprehensive synthetic testing tools

To effectively evaluate and optimize digital experiences, organizations need synthetic testing tools that cover the major user touchpoints with their environments. At a minimum, a synthetic monitoring program should include the following tools:

• Single-URL browser monitors. Single-URL browser monitors simulate a user’s visit to a site using an up-to-date web browser. By consistently running single-URL browser testing from both public and private sources, organizations can ensure that sites maintain an established baseline performance.
• Browser clickpaths. Browser click-path testing monitors specific click sequences through critical application workflows. Running browser click paths regularly can ensure that specific function sequences remain available and high-performing.
• HTTP monitors. HTTP monitors use simple HTTP requests to ensure that specific application programming interface (API) endpoints and website resources are available.

In addition to running these tests regularly, organizations should ensure their synthetic testing tools follow basic security best practices. For example, a synthetic testing tool should not send requests to local hosts or default IP addresses.

Synthetic testing best practices

A few best practices can help organizations achieve reliable, actionable data from synthetic testing tools. The following are three strategies worth considering.

1. Reduce setup complexity

The level of application integration required for synthetic solutions to collect key data can lead to complexity. To help mitigate this risk, clearly define your goals before setting up tests to streamline configuration and leverage tools designed to simplify the process with visual or script-based setups.

2. Prioritize continual monitoring

Continual monitoring is critical for organizations to understand how applications and users interact over time. It also plays a key role in addressing the issue of test fragility. Even small changes to the user interface — such as removing or replacing a button — can cause tests to fail. Continual monitoring allows organizations to detect and fix these failures immediately.

3. Keep context front and center

Testing doesn’t drive action without context. While many synthetic tools provide data about what’s happening when users interact with applications, they don’t answer the question of why. Keeping context front and center with synthetic testing integrated into an end-to-end observability platform provides complete visibility without adding additional tools.

Synthetic testing as part of a unified observability strategy

To make synthetic testing easy to develop and maintain, it should be part of a wider observability strategy. By taking a unified platform approach to observability, organizations can integrate synthetic testing into their overall application performance efforts.

Dynatrace synthetic monitoring provides continuous and on-demand answers to questions about application performance, reliability, and the overall user experience. By combining this approach with Dynatrace RUM, it’s possible to capture the full range of customer behavior, from common clickstreams to unexpected actions that may suddenly tax resources or lead to strange application behavior.

Dynatrace helps organizations proactively evaluate the performance of applications no matter where they are in the development cycle. The result is enhanced application performance and improved user experience that keeps customers coming back.

The post What is synthetic testing? appeared first on Dynatrace news.

In today’s competitive business environment, customers demand seamless user experiences. As businesses compete for customer loyalty, it’s critical for organizations to harness tools that help them see how users interact with their services. By understanding the difference between two such tools, synthetic monitoring vs. real user monitoring, teams can use them to develop high-performing applications and services that deliver loyalty-building user experiences.

Although both of these development and testing practices examine user behavior, they have distinct—and complementary—goals. Here, we’ll explore synthetic monitoring and real user monitoring, and how both help to deliver user experiences that win—and keep—customers.

What is real user monitoring?

Real user monitoring (RUM) is a performance monitoring process that collects detailed data about users’ interactions with an application. RUM gathers information on a variety of performance metrics. If you collect data on page load events, for example, it can include navigation start (when performance measuring begins), request start (when the user initiates a server request), and speed index metrics (measure page load speed).

A user session, also known as a click path or user journey, is a user’s sequence of actions while working with an application. User sessions can vary significantly, even within a single application. RUM collects data on each user action within a session, including the time required to complete the action. As a result, IT pros can identify patterns and where to make improvements in the user experience.

Ideally, a RUM tool would record all user actions to capture the complete picture of a user’s experience. In reality, only highly scalable RUM solutions can collect data on all user actions, while less scalable tools must sample user actions and make inferences from partial data.

Benefits and challenges of RUM

Real user monitoring is great for providing real metrics from real users navigating a site or application. The benefits of RUM include the following:

• Access to data from real end users across various applications, services, and environments.
• The ability to collect a diverse set of data points for every user accessing the application or services.
• Customizable variables to track, collect, and evaluate application-specific data points using JavaScript.
• Real-time monitoring of user application and service interactions.
• Enhanced issue remediation with the option to watch visual session replays of users interacting with web services or applications.

RUM, however, has some limitations, including the following:

• RUM requires traffic to be useful. If teams use RUM in a pre-production environment, it’s challenging to get useful information. Because teams use pre-production environments for testing before releasing an application to end users, they have no access to real-user data.
• RUM works best only when people actively visit the application, website, or services.
• In some cases, you will lack benchmarking capabilities. Because RUM relies on user-generated traffic, it’s hard to indicate persistent issues across the board.
• RUM generates a lot of data. RUM’s attention to detail results in a more accurate diagnosis of end-user issues and experiences. However, the volume of data it generates can make responding to specific issues cumbersome and difficult to prioritize.

What is synthetic monitoring?

Synthetic monitoring, also known as synthetic testing, is a performance monitoring practice that emulates users’ paths when engaging with an application. It uses scripts to generate simulated user behavior for different scenarios, geographic locations, device types, and other variables.

After collecting and analyzing this valuable performance data, a synthetic monitoring solution keeps tabs on application updates and how an application responds to typical user behavior. For example, synthetic monitoring can zero in on specific business transactions, such as completing a purchase or filling in a web form. This gives teams crucial insight into how an application is performing.

Benefits and challenges of synthetic monitoring

Synthetic monitoring is good at catching regressions during development lifecycles, especially with network throttling. The benefits of synthetic monitoring include the following:

• Simulation of entire user journeys in a controlled application environment.
• The ability to identify application performance issues and potential issues by running interval tests.
• Customized tests based on specific business processes and transactions — for example, a user leveraging services when accessing an application.
• Complex transaction and process monitoring that might have deeper dependencies. For example, in e-commerce, you can validate and test checking out a shopping cart.
• Application or service lifecycle testing at every stage. This includes development, user acceptance testing, beta testing, and general availability.
• Geofencing and geographic reachability testing for areas that are more challenging to access. For example, the ability to test against a wireless provider in a remote area.
• Performance testing based on variable metrics (i.e., connectivity, access, user count, latency) of geographic regions.

Much like RUM, however, synthetic monitoring has its limitations. Here are some drawbacks:

• Synthetic monitoring can be too predictable. In synthetic monitoring, tests and results are generated in a controlled and predictable testing environment. Because synthetic monitoring doesn’t track real users, you’ll have challenges gauging what an end user might experience in the event of an unpredictable variable.
• Tools may be limited. Depending on the vendor or technology you work with, you may not be able to integrate existing tools with scripts for your tests.
• The range of costs and feature sets can vary widely for synthetic monitoring tools. It’s recommended to work with partners that can deliver RUM and synthetic user monitoring to deliver the most value.

Synthetic monitoring vs. real user monitoring: Which do you need?

The real answer may not be one or the other. Instead, when working with websites, applications, or services, you may need both. While synthetic monitoring allows you to create a consistent testing environment by eliminating the variables, both RUM and synthetic monitoring provide feedback about site, application, or service performance. The strength of both solutions comes when you combine them.

By using synthetic monitoring and RUM together, you can thoroughly investigate specific user issues, and discover and resolve shortcomings. Furthermore, both tools provide full visibility into user and service performance. Using both, you can gauge how fast a site or service needs to be to ensure user satisfaction and to deliver optimal performance.

Together, RUM and synthetic monitoring can accomplish the following:

• Help correlate business requirements with performance levels by providing the performance data you need to analyze the end-user experience.
• Pinpoint challenges before active users access your website or services by identifying problems, such as configuration issues, so you can fix them before users log on.
• Use data from one engine to facilitate testing for the other. For example, you can use RUM data to provide real use cases you can use for simulation in synthetic monitoring for detailed testing in a staging environment.

Finally, combining RUM and synthetic monitoring data can make troubleshooting faster and easier. For example, real-user monitoring metrics might reveal a user performance issue that you can then apply to synthetic testing to replicate the issue by exercising the same transaction across several different variables.

Synthetic monitoring and RUM—better together

The bottom line? Both RUM and synthetic monitoring tools provide insight into every step within the application delivery chain and life cycle.

Working with both RUM and synthetic monitoring creates a healthy long-term solution to support the best possible user experience. While using one or the other tool will undoubtedly help to analyze performance in different ways, the true power comes when you use them as a complementary toolset. The result is a more comprehensive and robust monitoring strategy that will have a longer-lasting impact on user performance and experience.

The post Synthetic monitoring vs. real user monitoring: Understanding best practices appeared first on Dynatrace news.

Particularly during the COVID-19 pandemic, we’ve seen how poor application performance can impact business bottom lines and lead to lost revenue for many organizations, as laid out in our recent blog post about digital experience. To provide “quality signals that are essential to delivering a great user experience on the web,” Google introduced their Core Web Vitals initiative last year, advocating the Largest contentful paint, Cumulative layout shift, and First input delay metrics. Google recently included these metrics as “user experience signals” in their search result rankings, demonstrating that these metrics aren’t just nice to have but are a necessity.

While the information provided by Google Core Web Vitals is certainly valuable, it leaves you to resolve any high-level issues that are reported by tools such as the Google Search Console without giving you the option of drilling into details or seeing necessary context information across your application front and back ends.

Read on to understand why the Google Search Console is a great place to start but why you also need to understand how you can use Dynatrace Digital Experience Monitoring (DEM) to get valuable context information that you can proactively act on. Dynatrace is the leader in this space, giving you the ability to see business outcomes and monitoring data in the same distributed trace, capturing all details from each user click down to each database call, and using the Dynatrace Davis AI causation engine to identify the actual root causes of issues.

Google Search Console is a great place to start but it leaves you with more questions than answers

As a product manager or application owner, you care a lot about how discoverable your business is on Google. Therefore, SEO and improving your search rankings should be high on your agenda.

To get started, you might use the Google Search Console and select the Core Web Vitals  tab. Browsing through this section, you can check the report for each Core Web Vital  metric  that requires action and view all the individual URLs that are affected. You have two options for each URL:

• You can visit a URL in the browser to better identify the page in question.
• You can jump to PageSpeed insights, analyzing the URL in a single run.

While all this is certainly valuable, it leaves you with:

• Aggregated field metrics rather than valuable details from single instances.

You might wonder, what about details of the requests made on this page? Which of them is slow?

• Metrics and recommendations rather than helpful context information.

You won’t know, for example, whether your 75th-percentile value for Largest contentful paint (LCP) is the result of some users experiencing slow resources because of a CDN issue or a poorly performing service in your back end.

• Ex-post information rather than ex-ante insights to act on proactively.

PageSpeed insights has never been straightforward enough to use with non-public development or staging environments. Therefore, you often end up reacting to changes that are introduced with a release.

Dynatrace complements Google Core Web Vital measurements with insights across your application front and back ends

With zero configuration, you can leverage all three Core Web Vital metrics in Dynatrace and get details with just a few clicks:

• Largest contentful paint (for load actions in RUM and Synthetic Monitoring) provides you with an indication of how fast your page is loading.
• First input delay (for load actions in RUM) gives you an idea of how interactive your page loads are.
• Cumulative layout shift (for load actions in RUM and Synthetic Monitoring) offers you the means to understand whether elements on your page are stable through the page load process.

In the following sections of this blog post we’ll explain how you can:

• Unleash Core Web Vitals by defining them as key performance metrics.
• Analyze the Core Web Vitals in session detail pages and use them in USQL.
• Improve Core Web Vitals timings using Synthetic Monitoring.

Unleash Core Web Vitals by defining them as key performance metrics

After gathering your valuable feedback and Google’s recent announcement, we decided to integrate the Core Web Vital metrics more deeply into Dynatrace RUM and Synthetic Monitoring to acknowledge their importance. So we’ve accorded them full key performance metric status, allowing you to:

• Define them as such for browser monitors, applications, and single key user actions.
• Leverage Google’s predefined thresholds for your Apdex calculation.
• Automatically capture long-term data for all three metrics.
• Fetch each of the three metrics via the Metrics API and query them with USQL.
• Create custom alerts for Core Web Vitals.
• Create dashboards based on these out-of-the-box metrics in custom charting and the new Data explorer.

To get started, pick any of the Web Vitals as a Key Performance metric in the RUM General Application settings. Or, for a synthetic browser monitor, configure Largest contentful paint or Cumulative layout shift as key performance metrics in the Monitor Setup tab of monitor settings.

From here on, the Davis AI has you covered and will automatically baseline your selected Core Web Vital and detect anomalies in the metric.

Whenever you want to explore and analyze any of the Core Web Vitals, simply start on the Synthetic or RUM multidimensional analysis page, where you can filter for synthetic monitor actions or RUM user actions. For example, when you see a reported Core Web Vital issue in the Google Search Console, navigate to the corresponding RUM user action in Dynatrace, as shown below.

After finding the corresponding load action, go to the action detail page for additional, rich context information that helps identify the reasons for a poorly performing Web Vital metric. For example, you can select View analysis in waterfall chart to immediately:

• Check how resources are requested on that page (script files, images, etc.) and find any particularly slow request.
• If a request is slow, get additional context information across the application front and back ends to narrow down the issue. Analyze whether slow requests are back-end or front-end related. For instance, use Dynatrace PurePath to jump from the front end to slow back-end requests so you can further analyze them. Or, use front-end-related metadata such as the effective connection type and network downlink of the given user.
• If your requests are fast, check for Long task times, which indicate that an issue is front-end related and whether heavy JavaScript execution is blocking your page from loading quickly.
• Act proactively by getting these signals early on, from every environment, not just production environments. Davis AI knows when your key performance metric slows down from one release to the next.

Here’s how a similar analysis of Largest contentful paint and Cumulative layout shift would work for synthetic browser monitors.

1. Select Synthetic from the navigation menu.
2. Select a single-URL browser monitor or clickpath to view the details page.
3. Select the performance infographic on the right.
4. Select Analyze performance to view multidimensional analysis of performance.
5. Make sure to have Load actions analyzed based on Largest contentful paint and Cumulative layout shift.

Analyze the Core Web Vitals on session detail pages and use them in USQL

But what if the user action alone isn’t enough? What if you need more context? That’s easy! Just jump to user sessions and find all the metrics for every load action. Simply expand a given load action and check out the measurements and scores in the breakdown.

If you’re a fan of USQL, then no worries, we’ve also included the Core Web Vitals here. Use them to start your exploratory analysis at a higher level in USQL and use all the relevant context data to segment them. For those of you who want to build custom solutions based on the metrics, we’ve got you covered. User session export now includes all three Core Web Vital metrics.

Improve Core Web Vital timings using Synthetic Monitoring

Core Web Vitals are available for synthetic monitors out of the box, without any additional configuration. Leveraging Dynatrace Synthetic Monitoring is the perfect addition to Real User Monitoring, so you can analyze and improve your Core Web Vital metric timings. Synthetic (or lab) data provides a stable baseline, as the metrics are always measured with exactly the same parameters (network conditions, screen resolution, device type, CPU, etc.). This makes synthetic monitors a great option for monitoring performance during development and allows you to catch performance regressions as early as possible.

What about First input delay for synthetic monitoring?

You might have noticed that First input delay is not available as a key performance metric for synthetic browser monitors. Google argues that it doesn’t make much sense to look at First input delay for synthetic data as there isn’t any actual user input (which is only simulated). They suggest using Total blocking time (TBT) instead.

TBT is currently not available in Dynatrace. However, we recommend looking at a new metric that we’ve added instead—Long tasks (which TBT is based on). This metric is captured via the browser Long Tasks API and has the advantage (over TBT) of also being available for real users.

Long tasks is the total time of all long JavaScript tasks (over 50 ms) added together. It’s measured from Navigation start for the entire User action duration.

Long tasks is currently not a key performance metric, but you can find it in multidimensional analysis and you can also create a calculated metric based on it if you want to have long-term data or be alerted on it.

Seeing is believing

Prepare for the change to Google search rankings and improve user experience by fine-tuning Web Vital metrics with Dynatrace today.

• Already a Dynatrace customer? Start using all the Core Web Vitals today with zero configuration in all your applications!
• New to Dynatrace? Try Dynatrace by starting your free trial today.

What’s next

• Pages: Ever wondered where you can find your route changes for single-page applications? Rest assured that you’ll have an answer soon!
• CSP violations: You’ve probably already seen that we’ve added another Request error type in Dynatrace RUM—expect an official explanation of this soon in a future release.
• Errors in USQL and session export: As mentioned in previous troubleshooting-related releases, we’re currently looking into bridging some gaps in our error-analysis flows. In particular, we’re looking into adding high-level error information to USQL as well as making this information available to you via session export.

The post Full support for Google’s Core Web Vitals improves your user experience and search rankings appeared first on Dynatrace news.

In a world of accelerating deployment cycles, understanding and fixing web front-end errors quickly can make or break your business. For example, developers know that a JavaScript error can ruin the user experience of your web application, so you want to find such errors quickly, analyze them, and ensure that they don’t occur again. Dynatrace Real User Monitoring (RUM) allows you to be proactive, reduce the number of front-end errors, and massively improve user experience.

Whether you check errors based on Davis®-reported problem alerts that you receive or are proactively exploring them in the Dynatrace web UI, your problem analysis should be based on an intuitive workflow that is consistent and explicit. To provide you with such a solution, we’ve further enhanced Dynatrace Real User Monitoring.

In August, as a first step, we announced extended Davis AI awareness of HTTP and custom errors with automatic monitoring of your JavaScript, HTTP, and custom errors. Now, with Dynatrace version 1.206, we also enable you to alert on individual HTTP and custom errors . Additionally, we’ve made error counts available consistently across the product and aided charting of error counts per type on your dashboards. We’ve improved the RUM web UI with additional links and flows to switch between Dynatrace entities, better labels and names for consistency, and extended error information.

Catch errors faster, create tailored front-end error alerts with Davis, and more

Most monitoring solutions available today try to distinguish themselves by providing you with “the best” dashboards, lists, filters, or information to help you find and analyze your front-end errors. While all these elements are certainly important, simply crossing them off a “must-have” list isn’t enough! At Dynatrace, we believe that a truly valuable solution automatically detects the front-end errors that matter to you and provides guidance and comprehensive explanations as to where and why they occurred. Let’s look at two concrete scenarios to illustrate this:     

• As an application owner, you frequently need to report on and improve the error counts of your applications. But you aren’t only interested in error counts per application; you’re probably more focused on ensuring that a specific geolocation or user group doesn’t encounter any errors. Now, using Dynatrace error count metrics, you can tailor the Dynatrace Davis AI to only alert you of errors that matter to you and track those errors over time to optimize your application.
• As a developer, part of your regular performance-improvement routine likely includes exploring and catching errors. For example, as you go through our aggregated waterfall charts to analyze user action performance, you can now see errors from the edge to the core so that you can immediately fix them.

With other new improvements, you can:

• Run better-informed error analysis by accessing the summary of all occurrences
• Capture every failed image and every error page using extended error information
• Analyze the error type you’re most interested in using the simplified error type filter

Get Dynatrace Davis alerts on your error count metrics

We’re excited to announce that with Dynatrace version 1.206, we now provide error counts in the Multidimensional analysis for RUM, which you can now use with calculated metrics. So now you can create your own HTTP or custom error counts for a specific error and use them to set up Davis alerting.

For example, you can make sure that your employees have the required permissions to access certain resources in your internal web application by setting up alerts for HTTP 403 errors (see the image below). Or you can answer questions like “How many of my loyalty customers in Japan run into unavailable resources” by setting up HTTP 404 error alerts that leverage session and action properties to segment your traffic.

Note that we’re working on providing you with the ability to create custom counts and alerts for JavaScript errors too!

Easily visualize error counts per type by pinning custom charts to your dashboard

Besides making error counts available for calculated metrics, we’ve also provided some out-of-the-box application-level error counts that you can use in custom charting. We’ve made it easy for you to pick and chart the correct time series. Simply use the two-click approach shown in the screenshots below to pin error counts per type onto your dashboards.

It’s as simple as selecting Create custom chart on the Multidimensional analysis page for errors and then selecting Pin to dashboard on the custom chart. If you need to change the default settings, you can adjust them on the custom chart.

See errors from the edge to the core

At Dynatrace, we’re convinced that automation isn’t just a matter of problem detection but should also be reflected in the user interface and product experience. So we’ve added hints and links at just those places that we believe will aid your error analysis by enabling you to draw the right conclusions and find true insights.   

• Instantly see which user actions and sessions are affected by JavaScript errors

You can now see information for JavaScript errors that was previously only available for HTTP and custom errors. For example, we’ve added the ability to navigate directly from the JavaScript error details page to the affected user actions and user sessions.

• Analyze individual occurrences with full context

This improvement covers the use case where you likely start off by looking into how to improve the performance of a certain user action and then find errors in an aggregated waterfall—now the Errors finding displays a link and guidance per error type to help you further analyze such errors.

These links automatically take you to the individual waterfall instances filtered by the error type you selected (for example, JavaScript errors) on the aggregated waterfall. We now clearly mark the user action instances that are affected by errors. The new Error count column shows the errors per instance so that you can better prioritize which instances to look at first.

Select an instance and select the Errors finding to see the individual errors.

• Compare user action instances to their aggregates to check “normal” behavior
  

Another improvement that’s very useful for troubleshooting and performance optimization is the ability to jump from a single user action instance in the waterfall chart (the micro level) to aggregated information on the user action details page (the macro level). This is helpful when you want to compare timings and information for an individual user action with aggregate information to check what’s considered normal.

Run better-informed error analysis by accessing the summary of all occurrences

To empower you to run better-informed, high-level error analysis and segmentation, we now show a generic Errors column in all tables and charts. With extended Davis awareness of HTTP and custom errors in RUM, this column now sums up all error occurrences of all error types. You can now use this complete error information when prioritizing errors for analysis and breaking them down by dimensions such as geolocation or user type.

In addition to all application-related pages in the Dynatrace web UI, we’ve also introduced consistent error counts per type and per user action in USQL, which means that you can now use USQL to check for the user actions that have the most JavaScript, HTTP, or custom errors.

Note: If you’re already working with the existing error counts in USQL or the Session export API, please review the details below that explain how the counts will change and what you might need to do.

Capture every failed image and every error page by using extended error information

• Easily catch failed images

Now you can also use extended error information to find failed images. These are indicated with the prefix HTTP <unknown>: in the error name on the Multidimensional analysis page for errors. (Note that error names will be changed to use the prefix “Failed image:…” in a future release.)

In another improvement, we’ve added the HTTP status code on the HTTP error details page so that you don’t need to look these up.

• Capture every single error page

Remember the traditional HTTP 404 error pages that featured cats, dogs, or even Lego figures pulling out an electrical plug? While such pages can be fun, we’ve seen more than a few HTTP error pages that aren’t well designed (think of “Product not found” pages that return an HTTP response code of 200 and are therefore not captured as HTTP errors by Dynatrace RUM).

We’ve now introduced the ability to mark such pages as “true” error pages by using our dtrum JavaScript API. All such pages are then counted as additional HTTP errors and are also highlighted in waterfall charts. The following illustration shows a page that was marked as an error page using the command dtrum.markAsErrorPage(501, "error").

Analyze the error type you’re most interested in using the simplified Error type filter

When you select an error type or user type using the filters in the upper-right corner of the Multidimensional analysis page for errors, your selections are automatically propagated to the Detail analysis below.

Previously, you could filter displayed user actions per error type by selecting, for example, Has JavaScript errors. As the underlying user action could also have other associated error types, this turned out to be confusing. So we’ve changed the logic and the name of the filter. The new Error type filter now does exactly what you’d expect—it only displays the error count of the error type that you select.

Update on error counts in USQL and Session exports

With Dynatrace version 1.204, we’ve introduced the following three new error counts in USQL and Session export for every user action:

• javaScriptErrorCount
• requestErrorCount (already configured for the name change of HTTP errors to Request errors. See the What’s next section below for details)
• customErrorCount
• useraction.failedXHRRequests—Considers only failed XHR calls made in your end user’s browser, which could possibly can be the flip side of your server-side HTTP errors (i.e., httpRequestWithErrors).

These error counts are fully consistent across Dynatrace. Going forward, the existing totalErrorCount for every session will be the sum of these three new error counts.

In turn, we’ll deprecate these existing error counts starting with version 1.212.

• useraction.errorCount—Only includes JavaScript errors.
• useraction.httpRequestsWithErrors—Considers only server-side errors.
• useraction.failedImages—Will be part of the new requestErrorCount.

What should I do now?

If you currently use error counts that will be deprecated in USQL or Session export, please use the following replacements:

• Use javaScriptErrorCount instead of useraction.errorCount.
• Use requestErrorCount instead of useraction.httpRequestsWithErrors and useraction.failedXHRRequests.

What happens after version 1.212?

• USQL and the Session export API result will no longer serve the deprecated counts.
• USQL dashboards using the deprecated counts can’t be displayed, and you’ll need to adapt the underlying queries.
• User session pages will be based on the new counts.

What’s next

Further improvements that we’re already working on include:

• Updated session pages that consider and display the new error counts per user action.
• CSP violations for Chrome browsers—these new errors will be part of a new, more generic error type called “Request errors,” into which HTTP errors and Failed images will be merged.
• Filter and search for individual JavaScript errors.
• The ability to use individual JavaScript errors for calculated metrics, charting, and creating individual error alerts.

Questions?

We’d love to hear your feedback. Please share your feedback with us at Dynatrace Community and feel free to mention any other improvements you believe will help you in better exploring and analyzing your web front-end errors.

Or, if you’re new to Dynatrace, start your free trial now to explore all our performance and troubleshooting capabilities for your front-end applications.

The post Find and analyze your web frontend errors faster appeared first on Dynatrace news.

Connecting insights from different tools is hard

While Dynatrace provides software intelligence to accelerate your company’s digital transformation, web analytics tools like Adobe Analytics help you deeply understand your user journeys, segmentation, behavior, and strategic business metrics such as revenue, orders, and conversion goals. As an application owner, product manager, or marketer, you need these insights to further refine your product and your go-to-market strategy.

But whenever you see one of your KPIs underperforming, does your web analytics tool give you a clear answer as to why? While reports may tell you that there’s a sudden increase in shopping cart abandonment, they won’t tell you that the reason is a particularly slow web page. And finding that root cause becomes even harder if application and IT teams are looking at business outcomes and user sessions from different perspectives.

To identify what matters most and how to improve performance and business outcomes, you need an easy way to translate your web analytics report into the language of your performance monitoring tool and vice versa. By establishing a common language between your application and IT teams, you can finally work on compatible customer segments and numbers, thus keeping up your conversions and, ultimately, your business success.

Integrate Dynatrace with Adobe Analytics and other tools to establish a common language

To help bridge the two worlds of IT and application teams, we’re excited to ship our first set of property packs for Adobe Analytics and other tools. Property packs make variables and properties of web analytics tools easily accessible in Dynatrace, enabling you to use similar segmentation mechanisms and match individual sessions. This link is established easily, leveraging your existing instrumentation. Break up silos, speak the same language, and collaborate toward the same goals:

• Understand how availability, functionality, and performance are impacting KPIs in Adobe Analytics or similar tools.
• Share business context like page names and customer segments—integration with Adobe Analytics makes props and eVars such as the Adobe ID and page name available in Dynatrace (see the image below). Thus, you can recreate segmentations and drill down into individual sessions.
• Leverage Dynatrace Session Replay to watch and understand individual user sessions.
• Get real-time answers in Dynatrace to understand exactly why business anomalies are occurring.

Easily integrate your tool of choice with Dynatrace, with a single click

As a first step, we provide one-click integrations for these tools:

• Adobe Analytics—add your most important Adobe insights with one click to link them easily to performance insights provided by Dynatrace.
• Google Analytics
• Intercom (Session ID)
• Web properties (such as UTM parameters, referrer, and others)

Get actionable insights by tying together application performance, user experience, and business KPIs

After easily setting up the properties of your analytics tool in Dynatrace, you can immediately use them with our multidimensional analysis (MDA) view. For example, to chart the slowest landing experiences by country for your application (see the image below), you can use the UTM content property in combination with the User action duration key performance metric filtered by a preferred country. And don’t worry, we preserve these filters when you delve deeper into your analysis, for example, by clicking on individual user actions.

You can then choose the key performance metric of your choice and create a new metric from it. This allows you to:

• Have the information available as a timeseries over months or even years.
• Alert based on your new metric.
• Query your new metric via the Timeseries API.
• Build custom charts based on the new metric to use in your dashboards—the image below shows how entering a name and selecting Create metric makes the new metric available for charting.
  

At Dynatrace, we’re already using the Web properties pack in combination with calculated metrics to chart and track the application performance of our marketing campaigns running on www.dynatrace.com.

Get started with just a few clicks

You can start using our new property packs with Dynatrace version 1.192, released for Saas and Managed environments respectively.

How to get started

To capture these properties in Dynatrace, all you have to do is to select a property pack and the desired properties in your Session and user action properties application settings.

You can bring as many as 200 defined properties per application to enable your developers, architects, and marketers to speak the same language and join forces to optimize end user experience.

Note: Depending on your hosting type and location, you may only be able to leverage these 200 properties starting with Dynatrace version 1.194.

20 properties are included per application; additional properties will result in additional DEM unit consumption. You can check the new property usage quota under Session and user action properties in your application settings.

Prerequisites

• Dynatrace version 1.192+
• OneAgent version 1.185+
• For double and long properties, your need our RUM JavaScript tag version 1.187+

What’s next

Google Analytics, Adobe Analytics, and Intercom are just the start of the property packs we’re about to make available to you this year. We’re already looking into adding packs for A/B testing, personlization, chatbots, web analytics, ad providers, and CDN tools like:

• AppNexus
• Certona
• Clicktale
• Chartbeat
• Dynamic Yield
• Optimizely
• Cloudflare
• LiveChat
• PubMatic
• Permutive
• Riskified
• Zopim
• and more…

If you have any particular tool in mind that should be on our list for future releases, please reach out to us by posting your suggestion in the Dynatrace Community user forum.

And if you have read thus far…

There’s no doubt you’ll be interested in Part 2 of this blog series, where we’ll show how you can quickly improve customer experience by translating performance insights into the language of your web analytics tool, so stay tuned!

The post Actionable insights with our Adobe Analytics integration and new web properties (referrer, UTM…) appeared first on Dynatrace news.

How your customers interact with your website or application can tell you a lot about the buying habits of your different customer segments. Dynatrace Real User Monitoring automatically detects and names all such user actions for you. To help you easily analyze user actions, Dynatrace gives you the ability to create your own custom user action names. Custom names enable you to better find, group, and analyze the user actions that are relevant to the success of your business. However, with web applications becoming more and more dynamic all the time, resulting in millions of customer interactions, creating effective user action naming rules can be challenging.

To make it easier for you to name user actions, we’re excited to introduce enhanced user action naming, which contains the following major improvements:

• Placeholders, which provide more flexible user action naming and analysis
• Delimiters, which simplify information extraction and replacement
• API support, which allows configuring user action naming via REST endpoints

Save time configuring user action names with placeholders

We’ve introduced the concept of placeholders into our enhanced settings for user action naming. Placeholders give you the option to introduce dynamic information into your user action names. Placeholders are clearly displayed on the enhanced User actions application settings page (see example below), which is now divided into the following two sections:

• Placeholders where you set up the insertion of variable values into your user action naming rules
• User action naming rules where you can define custom names for user actions and specify conditions under which the names should apply

Placeholders allow you to insert processing instructions for selected data variables (such as page URLs or JavaScript variables) that are captured by Dynatrace as user actions occur. The result of processing these variables, stored in placeholders, can then be included in multiple user action naming rules.

Example: Name individual steps in your checkout funnel with a single rule

Suppose you want a more generic name for your load actions because each page has a different name. Prior to this, to name the steps in a checkout funnel, you had to create a separate naming rule for each step. With the enhanced version of user action naming, you can make use of a placeholder for a step number or name and then leverage the placeholder in a single user action naming rule.

To do this, let’s first create a placeholder called pageName (see image below), which retrieves the page name from a JavaScript variable (in this example, from the data layer of an Adobe tag manager implementation).

After creating the placeholder, it’s time to define a generic user action naming rule. The image below shows the naming rule and how you can leverage the previously defined placeholder pageName to:

• Include the page name as a dynamic value in your user action name.
• Include the page name in a rule or condition that specifies when the user action name should be applied.

In this example, we combine two contains conditions with a logical And to specify that the naming rule should only be applied to a user action when the page name contains the words checkout and step.

The flexibility of the new placeholders means that you’ll need fewer naming rules and, as a consequence, you’re less likely to reach the maximum number of allowed user action naming rules.

Use delimiters to easily extract or replace information

When creating placeholders, you can optionally use delimiter-based processing steps that can extract or replace information from the data source (for example, a page URL). In the example below, we use an extract processing step and provide leading and trailing delimiters to extract only the search term from a page URL.

Note: Even if your URL doesn’t contain an ampersand character (&) as a trailing delimiter, Dynatrace will still extract the correct information for your placeholder.

You can probably imagine other custom scenarios for the use of placeholders in your user action naming rules. To find more examples of how to create placeholders and custom user action names, see Create custom names for user actions.

Enhanced user action naming allows you to use:

• Regular expressions in processing steps for creating placeholders.
• Regular expressions in the conditions for applying user action naming rules.
• AND or OR conjunctions between conditions for user action names.
• Naming rules for your custom actions.
• The Web application configuration API to add and configure action naming.

FAQs

When will the transition to enhanced user action naming take place?

With Dynatrace version 1.192, all environments using the existing version of user action naming will automatically see an additional tab called User actions new (inactive) in application Settings. Your existing user action naming rules will still be active and accessible under User actions (active).

Having both versions of user action naming settings as separate tabs allow you to see your existing rules and your new enhanced rules at the same time. You’ll have enough time to recreate your existing rules with our enhanced user action naming.

So that you have an overview of your progress towards this goal, you’ll see an application progress count and a list of applications for which you haven’t yet defined rules in the User action new (inactive) tab.

Note: Don’t see two tabs? Then you’ve either started afresh, haven’t already defined user action naming rules, or have already migrated existing rules, as you received early access to enhanced user action naming rules. In these cases, you don’t have to do anything.

What happens to my existing naming rules?

Do you already have naming rules defined using the existing version of user action naming?

If so, we provide you with both the existing and enhanced versions in your application settings as shown in the image above. You can revise and migrate your existing rules to the enhanced version at your pace. Your existing default rules Loading of <page> and XHR URL are predefined in the enhanced version, ready to use with our out-of-the-box placeholders. Before you can switch completely to enhanced user action naming, you must migrate all existing user action naming rules for all applications in your environment.

How do I switch?

1. You must first migrate all your existing naming rules to the enhanced version (i.e., from the User actions (active) tab to the User actions new (inactive) tab). Only then should you perform the actual switch.
2. Enable the setting Switch to the enhanced user action naming for all applications.

By when do I need to switch?

Support for earlier user action naming rules will end on October 31, 2020 11:59 PM UTC. All environments still using the existing user action naming will be moved to the enhanced version at this time.

How can I test and validate my new rules before switching?

Our enhanced user action naming provides you with a preview that you can use to validate the potential results of your migrated rules.

Why can’t I migrate my existing naming rules automatically?

The features and possibilities of our enhanced user action naming are substantially different, which means that existing and enhanced rules don’t necessarily look alike. More importantly, we strongly believe that with the greater flexibility of our enhanced user action naming, you can consolidate and narrow your existing rules down to a minimum of new rules, which is why automated migration isn’t an option.

Where can I ask for help?

Feel free to ask a Dynatrace ONE representative for help—just start a chat from within the Dynatrace web UI. You can also post your questions in our Dynatrace Community user forum.

What’s next

Our primary goal right now is to support you as much as possible during the transition to enhanced user action naming. We’ve extensively gathered customer feedback in the past months that we’ve rolled into this release. We continue to look forward to your ideas and input on how we can further improve user action naming.

The post Easily configure user action names with enhanced user action naming rules appeared first on Dynatrace news.

Real User Monitoring (RUM) is one of the building blocks of Dynatrace Digital Experience Monitoring and the only way to monitor your users’ experience. Another building block is Synthetic Monitoring, which adds two additional and important use cases that are hard to cover with RUM.

• Availability monitoring—Is my application working 24 x 7?
• Performance baseline monitoring—Did my performance baseline change (based on a clean-room environment)?

When talking to Dynatrace customers who only leverage RUM, we find they usually agree that Synthetic monitoring adds tremendous value to RUM. However, the next question is often, “How do I get started with Synthetic monitoring”?

24×7 monitoring from three locations with a single click

With the latest release of Dynatrace, we’ve made it super easy to start monitoring your application’s availability using synthetic monitors. You’ll see an extra card (Monitor your application’s availability) on the application overview page. Just select Monitor availability and you‘re done!

The main entry points of your application are now actively monitored 24×7 from three locations worldwide.

Customize automatically created monitors, add new locations, and more

When you select Monitor availability, Dynatrace takes the top three entry actions of your application and automatically creates synthetic monitors for them in the background. An entry action is the first action of a user session. By selecting the top three entry actions, your users’ most frequent entry points to your application are covered.

The generated monitors are configured to run from three automatically selected locations to provide geographical coverage and are executed every 15 minutes. The image below shows the Availability card on the application overview page after you have opted to automatically configure the three synthetic monitors.

Monitoring the top three entry actions from 3 locations every 15 minutes is a great starting point for synthetic monitoring, and you can always mix this up to your taste. Instead of choosing Monitor availability, simply expand the card by selecting Manual setup and choose the entry action you want to create a monitor for. You can also always further configure automatically created monitors to add additional locations or change the frequency.

Prerequisites

The Availability card (see example above) only shows up on the application overview page if the following conditions are met:

• The user has change monitoring permission for the environment.
• The application has at least one entry action.
• There are no synthetic monitors configured.

What’s next?

We’re already working on some improvements to this feature. In the upcoming versions, Dynatrace will automatically pick synthetic locations based on the top geographic locations that your real users access Dynatrace from. We’ll also automatically check if an application is only accessible internally and will choose the most appropriate locations accordingly.

The post Start monitoring your web application’s availability with one click appeared first on Dynatrace news.

The premise of BizDevOps is the easy, full circle collaboration and sharing of information to make applications perform as best as possible, all the time, and create new opportunities for businesses. To do this you need to break-down silos of information, democratize data access, and rely on a common data set. Then, you can get people “speaking the same language” for easy discussions and decisions.

They key question is: does doing this collaboration mean that everyone has to use the same tool? For example, I’ll get asked “We are using Adobe Analytics/Omniture SiteCatalyst, would we retire this when we use Dynatrace?” And I’d suggest no – instead you probably want to integrate it with Dynatrace for better collaboration! The only exception to this would be if you have Adobe Analytics for the sole purpose of understanding geographically where your users are coming from.

Cool parts of integrating Adobe Analytics and Dynatrace

In my opinion, there are three key reasons and use cases for integrating Adobe Analytics and Dynatrace:

1. Deep, detailed, technical insight on a user session – while Adobe has a lot of analytics available around usage stats, marketing campaigns and more – it’s missing vital experience information like web performance issues, and technical errors such as HTTP or JavaScript errors. But, by capturing the Adobe ID by leveraging Dynatrace User Session Properties you not only get the numbers you need, but you also have the ability to watch a replay of particular user sessions – every transaction, flow and user response.

2. Get the “WHY” for the exits of users on your conversion track – with Adobe Analytics you are getting the number of people exiting on a conversion step or landing page, which is important because the performance of your website has a huge impact on how users will behave. For example, a slowdown from one second to five seconds in response time can increase the probability of a bounce by 90% (see Search Engine Land, or How Not to Get Lost, for more info). Therefore, by integrating Adobe Analytics and Dynatrace you get a lot more useful insights to tweak and optimize the perfect performance.

3. Know exactly how to optimize the right things – when implementing Adobe Analytics, you can spend quite a bit of time with the dev team on getting a page name and section structure set up to meet your needs. But since IT uses different solutions, like Dynatrace, out-of-the-box names don’t match. But by integrating the two, Biz and IT can come together and understand the same correlations when they are optimizing a particular application section or page, avoiding confusion and mis-understandings.

Adopt an Adobe Analytics & Dynatrace integration with a few easy steps

Configure capturing of Adobe Experience Cloud ID

The Adobe Experience Cloud ID allows you to look up a session you believe to be of interest in Adobe. The data is stored in a cookie value, and to capture the data, go to Application > Edit > User session and action properties > Add property. Select Expression type “Cookie value” and data type String.

It’s important to note that the “Cookie value” is different per each Adobe account. Simply look it up via the Web tool kits the browsers provide. You also have to configure a clean-up rule, so you only extract the ID and not the entire data stored in the cookie.

 Configure capturing of the Adobe Analytics pageName

As described above, the naming conventions are different for each solution. Therefore, to overcome this obstacle, when collaboration is needed, it makes sense to leverage the Adobe pageName in Dynatrace to focus analysis on those pages and not get lost in translation.

In order to capture the pageName, go to Application > Edit > User session and action properties > Add property. Select Expression type “JavaScript variable” and data type String. Specify a key and into the JavaScript variable input field add “s.pageName”.  If you do not have the specified the pageName on your web application, use the Adobe pageURL by filling in “s.pageURL“.

Configure capturing of Adobe eVarN, propN, hierN and more

There are a lot of other datapoints that you can implement to get insights via Adobe Analytics, and each of them has the potential to help you improve performance and user experience. So, it’s up to you and your peers on the Adobe or Dynatrace solution side to evaluate the choices that you have, and the problems you can solve.’

As a complement to this blog, check out  our video on “Mastering Dynatrace Session and User Action Properties for Enhanced Business Analytics”, and specifically roll-forward to minute 32 where I review how to feed additional business data from your own code execution or external monitoring tools, such as Adobe to Dynatrace. In this video you’ll see a hands-on walkthrough on configuration, analytics, and integration use cases such as leveraging the Dynatrace User Session Query Language (USQL) to integrate this data with other third party business analytics tools.

But get going on breaking down the silos for true BizDevOps sharing; democratize data access and get a common data set going. Soon you’ll all be talking the same language and having easier discussions and better decisions.

The post Tightening the communication within BizDevOps with Adobe Analytics & Dynatrace appeared first on Dynatrace news.

With the rapid adoption of SaaS vendor-provided applications in the enterprise (for example, Salesforce, Workday, Sharepoint, and Office 365), companies are increasingly looking for ways to ensure the customer experience and performance of the SaaS applications that their employees and customers rely on. Unfortunately, it’s usually not possible to install Dynatrace OneAgent on the web servers that SaaS vendors use to serve their applications. This is why Dynatrace now offers a browser extension that enables you to gain user experience insights into the performance of SaaS applications without access to the underlying web servers. The new Dynatrace Real User Monitoring (RUM) browser extension allows you to capture all the application performance and user behavior data that you need. Once configured, the RUM browser extension delivers complete Dynatrace real user monitoring capabilities.

We’re happy to announce the availability of the public Beta of the Dynatrace RUM browser extension. During the Beta period, this feature is available for Google Chrome browsers only.

Monitoring the SaaS-vendor applications you rely on enables you to pin down the root causes of certain elusive user-experience issues. You can now easily determine when SaaS-application performance problems only affect individual users and when such problems affect all your users. The browser extension is also a great way to monitor how the adoption of new SaaS products affects the user experience of your existing customers.

How to set up monitoring via the RUM browser extension

Monitoring applications via the browser extension is easy. For all the technical details and setup instructions, see  Dynatrace help. Following are the high-level steps to get you started.

1. 1. Login to your Dynatrace environment and select Deploy Dynatrace from the navigation menu.
   2. Click the Monitor via browser extension button.
      
   3. Install the browser extension locally to test and refine your configuration.
   4. Configure the applications you want to monitor using the browser extension.
   5. Deploy the RUM browser extension company-wide.
      For full details, see How do I monitor the user experience of 3rd-party SaaS vendors?

Real user monitoring

Monitoring data captured via the browser extension is analyzed and presented on your dashboards alongside all other Real User Monitoring data captured by OneAgent and agentless RUM.

To analyze data gathered via the RUM browser extension

1. Select Applications from the navigation menu.
2. On the Applications page, select the Injection type > Browser extension injected filter to view all applications currently monitored via the RUM browser extension.
3. Proceed with user experience monitoring as explained in Dynatrace Help.
   

Deploy the RUM browser extension company-wide

Once you’ve configured your first applications, you’ll likely want to roll out the RUM browser extension to a larger group of users within your organization. The easiest way to roll out the extension—pre-configured and ready to go—is via two Google Chrome policies that are best deployed via windows group policies. Options for Linux & MacOS are also available. Head over to Dynatrace help for details on how to deploy the extension. 

All deployed extensions automatically receive all configuration changes you make (for example, updated URL injection patterns or even completely new applications to be monitored). Also, any application-specific settings changes you make via the Dynatrace UI will be automatically picked up by the RUM browser extension.

Missing user actions or XHR actions?

If you don’t see all the user actions or XHR actions you expect to see, make sure you’ve enabled the relevant JavaScript frameworks in your application settings (Application settings > Async requests and single page apps).

Feedback

If you’re interested in using the RUM browser extension for Firefox or Edge, let us know. Have other feedback for the team? We’d love to hear from you!

The post Real User Monitoring (RUM) browser extension for 3rd-party SaaS vendors appeared first on Dynatrace news.