Jack Chawla
Director, Live Web
eGain
jchawla@egain.com
|
Search Our Catalog of Articles
Chat & Proxy Based Co-Browsing: A Robust Solution
Overview
According to Giga, web-sites convert only 2% of shoppers into buyers. Recent surveys show that 90% of customers prefer to talk to an agent and 60% refuse to buy unless Live assistance is available. Approximately 8% of the shoppers who abandoned the cart would have bought if live assistance were available.
Also, Forrester recommends that companies with more than 10% of their traffic from dial-up ISPs must offer online chat.
Numbers like these have convinced most businesses that live assistance on the web-site is must have and are rapidly installing live chat on their web-sites. While most chat products are very effective in allowing customers to chat with agent for live assistance, almost all of the products fail to provide effective tools to allow customer and agent to co-browse personalized and authenticated web-pages, fill out complex forms, share shopping carts and finish ordering transactions,
thus failing to 'hold customer's hand' during critical phase of sales and customer service process.
This is because most products use URL-Pushing technology for co-browsing. The architecture and limitations of URL-Pushing are described below.
URL-Pushing Architecture
In URL-Pushing co-browsing, the browsers directly contact the web-site and fetch the pages. The co-browsing service listens for events such as page unload, new page load, form field exit, etc. and synchronizes the browsers in the co-browsing session when the appropriate event occurs. For example, if agent in session goes from yahoo.com to amazon.com, customer browsers in the session also will directly contact amazon.com to fetch the page. As each browser fetches pages directly from the web-site, the following issues might arise during the co-browsing session:
- Double Form Submission: When one user in a session submits a form, all users do the same. Without server side modification,
multiple forms will be submitted with the same information. For example, if a customer places an order for a computer by clicking the 'Submit' button, the agent will also automatically do the same, resulting in two identical forms submitted to the web server and thus two orders for the same computer.
- Cookies: Many implementations of personalized pages, shopping carts, etc. use cookies on the browser to identify the user. Therefore, each user in a co-browsing session will have his/her own cookie information and will see different views of the same page. For example, an agent will not be able to see the shopping cart of the customer and thus can't help the customer finish the shopping transaction.
- Authentication: Since each browser authenticates directly with the web-site, not all parties in the co-browsing session can access all web pages. For example, if agent wants to show the customer a web page that the customer is not authenticated for on say, Gartner.com, the
agent cannot show the page with URL pushing architecture.
To overall the limitation of URL-Pushing architecture, the co-browsing needs to move to Proxy-Based architecture found in new breed of application called Co-Browsing Proxy Server (CPS).
Proxy-Based Architecture
In a Proxy-Based co-browsing, the browsers do not directly contact the web-site. Instead, all browsers are connected to a CPS. CPS sits between client browsers and web-sites, communicates with the web-sites and serves the pages to the browsers in the session. The CPS rewrites the pages to point all the links to itself, as well as perform other functions such as listening for certain client side events, rewriting the form breaking code to make co-browsing work within a frame, etc. When a user clicks on a link (which has been rewritten to point to the CPS), the CPS fetches the page, rewrites it, caches it, and updates all other browser in the co-browsing session with the cached page.
Since
CPS does the communication with the web-site rather then multiple clients in session, double form submission is no longer an issue. Thus, URL-Pushing architecture is not ideal for co-browsing and is best used for pushing pages to customer from agent. For true co-browsing, Proxy-Based architecture is required.
Co-Browsing Proxy Server Features
Here is the list of features to look for in CPS:
- Support for Advanced Internet Technologies. Support for dynamically generated pages, username/password authentication, cookies, order submissions, and other critical Internet technologies. This ability is a "must have" to successfully co-browse most eBusiness web-sites.
- Firewall Friendly. CPS should be able to use regular HTTP and HTTPS port to allow co-browsing with majority of customer base. For example, customers of financial companies often use co-browsing services from behind corporate firewall.
- Joint Form Filling. CPS
should allow participants to jointly complete web forms. For example, when one participant enters text into a web form in the "shared browser", it automatically appears in all other participants "shared browser". The common scenario is for an agent to help a customer fill out forms on web-sites.
- Browser Snap. This feature collects the necessary information (e.g., URL, cookies, and form contents) from a customer's browser to initialize the co-browsing session. This allows an agent and customer to begin a co-browsing session on the web page where the customer is experiencing the problem, even if the customer is on an authenticated, personalized page with a form partially completed. For example, if customer is in middle of filling out an application form to open IRA account and needs help, the agent should be able to see the form with fields already filled in to prevent the customer frustration of filling out the same form again.
- Business Rules. Businesses
should be able to implement business rules to comply with external agency rules, e.g. SEC, or internal rules. For example, a business rule can be written to restrict agents to submit trading forms on financial web-site to comply with SEC.
- URL Restrictions. CPS should allow co-browsing session to be restricted to web-sites and/or sections of web-sites.
|