According to Gartner estimates, “by 2025, 55 percent of large enterprises will successfully implement an all-in cloud SaaS strategy.” Synthetic transaction monitoring is one method IT teams and vendors alike are using to ensure that service level agreement (SLA) targets are being met as business-critical applications move to software as a service (SaaS) models. Synthetic data is useful because it can help identify reoccurring pain points with SaaS that cut into user productivity. When coupled with real-user monitoring, synthetic transactions can also be used to pinpoint the root cause of SaaS issues, even when accountability falls on the SLA vendor. The ability to manage SaaS is an integral part of any digital experience monitoring strategy but can be difficult to execute. Here’s how to simplify dual usage of synthetic transactions and real-user monitoring to ensure a positive end-user experience with SaaS.

How else can CIOs prepare for SaaS? Find out in our white paper, "Succeed with Workspace Analytics for IT"

Synthetic transaction monitoring vs. real-user monitoring

Synthetic transactions work by simulating workloads with "synthetic" (i.e. not real) users, typically during periods when real users are offline. These workloads or “transactions” allow IT to see the results of user behavior without actual end-user involvement. For example, an IT admin could run a script during a specified time window that measures how long it takes to launch Outlook. Spikes in the transaction trend would show IT when Outlook launch times were slow—something that would affect real user productivity. But the time that it took to complete a process is generally the only metric returned by synthetic transactions; meaning that, while they do a good job of alerting IT to a potential problem, they don’t provide the context needed to find the solution.

In contrast, real-user monitoring involves the continuous collection of system performance and end-user experience data from actual end users. Robust solutions in this area offer both real-time and historical analysis of the data to fully contextualize the environment. An admin with access to real user data can see any performance issue that a user is experiencing. Instead of testing Outlook launch times, the admin would notice the issue in the real user population in addition to metrics like CPU utilization and network latency that would help the admin identify the reason behind the slowness.         

Using synthetic transactions to monitor SLAs

Synthetic transactions can be useful in cases where IT wants to proactively test if something is working as desired. In the case of SaaS, IT can run transactions to ensure that critical processes are up and running before real end users start accessing them. If a SaaS application is not meeting its SLA uptime, IT can contact the provider to attempt to resolve the issue before users are affected. However, there’s always the possibility that the issue is rooted in the internal environment and cannot be solved by the SaaS provider.   

Combining synthetic and real-user monitoring

Discussions of synthetic transaction monitoring and real-user monitoring generally conclude that they are complementary solutions, which they are. The proactive testing abilities of synthetic transactions alongside the comprehensive view provided by real user data open up possibilities for IT to discover and solve an array of potential issues. But what is rarely proposed is how to incorporate the two.

Performing analysis across multiple interfaces can be time-consuming and introduces the possibility of user error. To facilitate the comparison of synthetic and real end-user data, Lakeside has integrated with popular synthetic transaction tools, AutoIT and Itexis, to natively collect synthetic transaction data. Integration with Login VSI is coming next year.

These integrations enable IT to view synthetic transactions within the SysTrack interface for easy comparison of synthetic and real user data. Take the earlier example of slow Outlook launch times: By viewing the data side-by-side, IT can immediately identify potential causes of slowness and then use SysTrack to find the root cause of the issue.

Other benefits of viewing synthetic data in SysTrack include:

  • Smarter testing: Synthetic transactions identify potential problem points; SysTrack data shows specific resource demand, so IT knows where to make improvements
  • Proactive fixes/faster time-to-resolution: Alarms can be set to trigger when a synthetic transaction reaches a threshold, enabling IT to fix problems before real users are affected
  • Better SLA management: IT can use synthetic transactions to trigger when guaranteed uptimes aren’t being met; IT can investigate causes in SysTrack and determine if the issue is on the provider’s side   

synthetictransaction.PNG

An example synthetic transaction graph in SysTrack
Step One: Investigate a synthetic transaction in SysTrack

realuserimpacts.PNG

A graph showing real user impacts in SysTrack that correlate with synthetic transaction monitoring
Step Two: View performance details based on SysTrack data to begin analysis and identify areas for improvement

Today’s complex end-user computing environments demand nuanced IT solutions. Increased reliance on externally-provided services means that IT visibility will continue to become even more business-critical in years to come.

Want to learn about how to get more out of your data? Read about our survey tool and other new SysTrack features.