— May 21, 2019
Why DOM cobrowsing is different (and better)
We hear it on our sales calls sometimes: “Oh, we’ve tried cobrowse, it didn’t work.”
Cobrowse technology has been around for years and many organizations have tried, with varying success, to deploy it on websites, in SaaS apps, and for digital transformation projects with the goal of enabling agents to share a browser view with customers for collaboration and support.
We had a recent conversation about cobrowsing with analyst Dr. Brent Kelly, founder of consulting firm KelCor and noted expert in contact center technology and operations. Dr. Kelly wrote up his findings in an article for No Jitter here.
The bottom line is, all cobrowse is NOT the same. There are different technical ways to create a cobrowsing experience. Some methods are better than others. If you’ve been disappointed by cobrowse in the past, or if you are confused by why cobrowse works great when deployed by one provider but not by another, read on to learn the critical elements for success.
What’s the best way to do cobrowse? Here is a recap of Dr. Kelly’s assessment:
Cobrowse Method #1: Generating screenshot representations of web pages
A snapshot of the web page is sent from the customer’s browser to the agent. The image will be retransmitted at some predetermined frequency to imitate movement or animation (scrolling, mouse actions, etc.).
Why it fails:
The images would typically be compressed, affecting quality (pixilation, fidelity, etc.). Some graphics might not render. Agent annotations (i.e., when the agent highlights page elements to guide the customer’s navigation) can be delayed on the customer’s screen and/or may not display properly or in the right place. Performance at scale quickly becomes an issue — image files are relatively large, so this method can be a significant burden to the server and networking infrastructure of high volume contact centers.
Cobrowse Method #2: Sending a video representation
Similar to the screenshot method described above, but the image frames are converted to a compressed video stream (often it is WebRTC).
Why it fails:
Similar to the method above, video files are even larger than screenshots, and so this method is an even larger resource hog. We have had to replace this type of cobrowse in several high volume deployments because it demos OK but it is unable to scale. It is tricky to mask private and secure information on your customer’s screen (social security numbers, credit card numbers, passwords and user names, etc.) so this can expose you to GDPR and PCI compliance risks. Because WebRTC combines video with audio it is difficult to integrate WebRTC-based cobrowse with existing call center voice technology. Also, WebRTC is not supported by some browser versions so if your customers are using old browsers you may run into trouble that can be difficult to quickly and easily resolve.
Cobrowse Method #3: Rendering using the Document Object Model (DOM)
The DOM method of cobrowsing was pioneered and refined by Glance (in fact, we hold several patents related to it). Here’s how Dr. Kelly describes Glance’s DOM-based cobrowse
It sends the actual DOM elements (HTML, CSS scripts, etc.) from the customer’s Web page to the agent for full-fidelity viewing. This is the most accurate way of sharing a Web page or app screen with an agent because the fonts remain crisp and the images maintain their quality, with 100% compatibility across any browser in use. If an agent marks up the screen, the annotations get inserted into the HTML code and are displayed perfectly on the customer’s side.
Why this is the best technical approach for cobrowse:
As Dr. Kelly notes in his article…
Using the DOM method has some significant advantages:
- It’s computationally efficient.
- It’s bandwidth efficient.
- Web pages display properly, with no artifacts or distortions.
- Annotation works properly.
- It’s 100% compatible with any browser.
(Editor’s note: I would add that our DOM-based cobrowsing is better
for data privacy and security compliance than other methods. For example, when we mask private data it is redacted from the DOM before it ever leaves the customer’s browser, completely eliminating the GDPR or PCI risk.)
A cautionary note about proxy servers:
Some cobrowse providers leverage DOM sharing via a proxy server. Using a proxy introduces several critical problems. First, it results in a very disruptive customer experience, forcing the customer to re-log-in to a new session of your website or app and then finding their way back to the page where they were experiencing the problem. Also, it can expose you and your customers to man-in-the-middle attacks. Glance Cobrowse does not use proxy servers, and our competitors who do use proxy servers will almost certainly fail any rigorous security review.