There are significant differences between UserView Monitoring and ServerView Monitoring.

On the one hand, UserView Monitoring utilizes a regular Internet Explorer browser to both records and then replay a multi-step path through an application, such as a shopping cart or log-in. Because UserView Monitoring uses a regular IE browser it is capable of emulating actual browser events during monitoring, such as mouse clicks, text typing, and hovers. These events are executed by the UserView Monitoring browser (see pic. 1). The regular browser aspect of UserView Monitoring can be coupled with a virtual keyboard/mouse “Picture match” technology, which enables the monitoring to step through very complex web applications running Rich Internet Applications (RIAs), including: SilverLight, Ajax, Flex, Flash, JavaScript, applets, add-ons, and other webpage objects that interact dynamically with a browser. Additionally, UserView is able to record a video capture of the page interaction as issues are detected.


On the other hand, ServerView Monitoring utilizes HTTP/HTTPS requests between a custom “synthetic” browser and the server to conduct monitoring. While ServerView Monitoring can also be recorded and replayed for monitoring applications, it is specifically useful when monitoring the server performance associated with a web application. Also, ServerView Monitoring supports dynamic variables, cookies, secure sites. ServerView Monitoring uses a custom process (not a regular browser) to replay the recorded steps, so it is not recommended for websites that heavily use RIAs, such as JavaScript or Ajax.

One way to check which type of monitoring is most appropriate is to simply test one of the pages that you want to monitor. If the page contains javascript, which may manipulate content or load it additionally from your or third-party servers, then  UserView Monitoring is recommended.

Due to these differences, there is also a difference in the response time measured by each task type.

See below for an example of the differences:

The website has an edit field. If the number “1” is entered into the edit field, the javascript will make a request to, which should return a “Username too short” string and display it as HTML.

Because a UserView Monitoring script emulates the action of a real browser it will perform the following steps: load the page, find the edit field, and input “1”; the final action is a keyword validation that the “Username too short” string is displayed in the HTML:

UserView Script

// script_version=1.4; recorder_version=; date=17.11.2010; IE=8.0.6001.18702;

DMBrowser dmb0 = null;

Step(1, @” –”);

dmb0 = Tabs.NewTab();


dmb0.TextField(“//INPUT[not(@NAME) and not(@TYPE)]”).Click();

dmb0.TextField(“//INPUT[not(@NAME) and not(@TYPE)]”).TypeText(“1”);

DMAssert.CHECK(@”Searching for ‘Username too short ‘”, ()=>dmb0.Text.Contains(@”Username too short “), dmb0);

ServerView Monitoring performs this task differently: it emulates low level HTTP(S) requests. For example: if the previous UserView Monitoring example is converted to a ServerView Monitoring process the monitoring is conducted as two HTTP tasks with GET requests:

ServerView Tasks