WO2009018228A1 - Trial optimization system and method - Google Patents

Abstract

Trial optimization is a system and method of persuading the maximum number of users to buy a product after the trial period expires. The goal is to determine where users enter and exit the buying process, and then modify variables to encourage trial users to purchase. Trial optimization comprises three components: live messaging, live bits, and live metrics. With live messaging, vendors can reach users through targeted in-application messages. These messages are contextualized. Live bits enables streaming of data updates straight to a user's desktop, allowing businesses to customize updates. Live metrics enables vendors to capture information about how end users utilize products. Live metrics collects details from the installed user base and sends them to a central server which aggregates the data. Through measurement and analysis of behavior, software publishers can pinpoint spots in the trial process where customers lose interest and turn more testers into buyers.

Description

TRIAL OPTIMIZATION SYSTEM AND METHOD

This application claims the benefit of U.S. Provisional Application No. 60/952,486 filed 27 July 2007, entitled "Trial Optimization," which is incorporated herein by reference

FIELD OF THE INVENTION

The present invention relates to software publishing. In particular, it relates to downloading software trials and updates.

BACKGROUND OF THE INVENTION

A software publisher is a publishing company in the software industry that works between the developer and the distributor. In some companies, two or all three of these roles may be combined (and indeed, may reside in a single person, especially in the case of shareware). Software publishers often license software from developers with specific limitations, such as a time limit or geographical region. The terms of licensing vary enormously, and are typically secret. Developers may use publishers to reach larger or foreign markets, or to avoid having to focus on marketing. Or publishers may use developers to create software to meet a market need that the publisher has identified.

In addition, Electronic Software Distribution (ESD) refers to the practice of allowing users to download software products electronically (and primarily over the Internet) as opposed to receiving physical media. Although not all software vendors discount the prices of electronically distributed software from the price of the physically distributed versions, such a discount is common, as electronic distribution can typically be much less costly for the vendors than its conventional counterpart. ESD as a service can be further broken down based on straight purchase of the software and try-before-you-buy (TBYB). TBYB allows the consumer to trial the product for a length of time or number of activations and then, through the software interface, purchase the software from the publisher. Software publishers face several challenges in convincing consumers of the value of their product. For example, the software should meet the user's needs and deliver what it promises. Furthermore, it should be easy to use. Most consumers will not spend money on a software product without some degree of confidence that it will perform as expected. The best way to prove the value of the product, and a strategy that has been widely adopted by publishers, is to offer a trial license, giving users the chance to test the software before committing to a purchase.

The trial license is a cornerstone of online software sales. It is the primary business driver for smaller software companies, with sixty percent or more of revenues generated as a direct result of trial conversions to paid licenses. It is therefore critical to maximize the number of trial users who convert to a paid license. The more conversions, the higher the revenues.

Since the birth of software, developers have been eager to sell their intellectual property to others who need whatever functionality their application provides. Over the years, popular software applications have come to be "metered" based on factors such as the number of users, machines or central processing units (CPUs) to ensure copyright control, prevent illicit use, and extract all possible value from the sale of the asset. This is known as digital rights management, and it plays a critical role in trial licenses as well as outright sales.

In today's world, one thinks of digital rights management as a way to enforce

"payment for fair use." If a user pays for a license to use a software application, they gain fair use. Digital rights management solutions allow the software vendor to control "fair use" based on business rules they define. Fair use can take on several forms, such as a perpetual license (pay once and use forever), subscription license (pay at set intervals; use as long as the payment stream continues), pay per use (pay once, use once; pay again, use again) and trial license (free use of the product or a portion of the product for a limited period; when that expires, the product shuts down unless a payment is made). Each of these license models poses unique challenges, but they all start from the basic premise of controlling how the application behaves based on whether or not a payment has been received. What the trial business model does differently is that it provides free use of the application for a temporary period to allow the prospective buyer to evaluate the product. If the user decides not to purchase the software, the developer or vendor is protected from intellectual property theft by digital rights management technology. The application simply shuts down and can no longer be used.

For consumers who are not yet sure whether they want to buy a given software product, trials are a low-risk persuasion tactic. If the consumer is allowed to try the product's features and functions before committing to buying it, there is a better chance to turn that tester into a paying customer. Trial licenses have proven to be far more successful in converting trial users into buyers. Even large, well-known software brands have been shown to increase their revenue by ten percent or more by adding a trial option. Smaller brands derive sixty percent or more of their revenue from trial users who convert to paid licenses. The trial license is the lifeblood of these businesses. As such, it is imperative for these vendors to convince as many trial users as possible to convert to paid licenses.

There are a variety of reasons why users who express interest in a software product fail to follow through to the purchase stage. One reason is poor download page messaging. Frequently, the creative design on the download page does not effectively communicate the value of the product. If the shopper is not convinced of the benefits, they do not proceed to the download start. Another reason are unexpectedly long downloads. Some customers drop off between the download start and download stop because of unexpectedly long downloads that were not properly communicated on the download page. This can be addressed by tactics such as revising the download page text to properly set expectations and/or keeping the customer busy during the download (playing a game, reading an advertisement, listening to music, etc.). Bandwidth problems, another reason for failing to purchase, involve long waits in downloading large file sizes (hundreds of megabytes to gigabytes) if the user lacks a good connection or sufficient bandwidth. If this the case, the product design can be altered to support a small initial download, and then have the rest of the file downloaded by the product itself during the first product use. Furthermore, the primary reason that users disappear between the download stop and install start is that they cannot find where they stored the downloaded file. This can easily occur using standard hyper text transfer protocol (HTTP) downloads. The problem can be easily rectified by using a download manager equipped with technology that can trigger the installation automatically, yielding a near 1 :1 conversion rate.

Most customer fall-out between install start and install stop is related to installation complexity, poor communication of installation activity, and/or installation routines that require a re-boot (a step that is notoriously bad for conversions, since customers who do not understand that a re-boot is required will never get to the product use stage). To address these issues, clear explanations of what is happening to the user's computer during the installation process should be provided; complexity eliminated so that the user can simply select "next;" and use the time elapsed during the installation routine to reinforce the benefits of a product so that users will feel it is worth the effort to complete the installation.

Furthermore, customers who complete the installation process but never progress to the product use stage typically have lost their enthusiasm for the product somewhere along the way. Communicating the product's benefits early and often can help maintain user interest, while having the installation routine automatically launch the application can achieve a near 1 :1 conversion ratio at this stage by ensuring that users will at least look at the product.

Additionally, consumers who fail to make the leap from trial use to product purchase may still not be convinced of the product's benefits. The best approach to overcoming this problem is to automatically walk users through the primary points of value during the first launch. It is also important to accompany this information with a clear call to action (i.e., "Buy now"). In addition, effective and consistent communication regarding the values and benefits at every stage will help reinforce the purchase.

Clearly, no matter what is done, not every trial user will become a paid user. For every hundred people who try the product, from half of one percent to two percent of the people will purchase the product. Within select product categories, user populations or software brands, the actual trial conversion rates may vary broadly. A rapidly growing product or product category may see a growth phase of significantly higher conversions, while products in very competitive categories may see lower. Conversion rates will also vary by download site. Download sites that contain many competing products may result in lower conversion rates than what would be found on a software publisher's own site, or one with fewer competitors.

The previous method of trial download was selling software through various channels, such as retail, direct, or online. The previous method urged users to register later or at the time of sale. Sending email and postal mail to market new products and updates is also popular. Companies also send physical updates or host downloads for updates. Unfortunately, they also conduct focus groups to assess user program usage and user behavior which can be costly.

This previous method is no longer efficient for the modern day. For messaging and customer contact, the registration data can be incomplete or inaccurate, the end user may not be the purchaser, and the user may have changed or not registered. Moreover, the email and postal notices may not be received due to wrong user filters, poor data, etc. As per product updates, the cost of sending physical updates is high, with higher costs to support older software releases. Last but not least, assessing customer behavior is very expensive and can be easily skewed by small sample size.

Accordingly, there is a need for a system and methodology to help software vendors increase sales by increasing trial conversion rates. The present invention provides a solution to these needs and other problems, and offers other advantages over the prior art.

BRIEF SUMMARY OF THE INVENTION

The present invention is related to a software system that solves the above- mentioned problems. Trial optimization provides software developers and hardware suppliers with a framework and tools to manage ongoing software updates, measure customer product usage, and reach all product users through in application messaging. Messages and updates are tailored to the specific needs of end users. When collating product usage information, no personal customer details are collected. The anonymity of end users is assured.

In a preferred embodiment, a trial optimization system and method has three main components, including: live messaging, live bits, and live metrics. With a live messaging tool, vendors can reach all active users through targeted in application messages such as when the user starts up the application. These messages are contextual ized such as offering upgrades during startup or offering discounts on full versions of products once trial periods have expired. The live bits tool enables streaming of data updates straight to a user's desktop. This allows businesses to customize update and messaging policies. The live bits tool also limits notices of updates to customers based on their specific version and product identification. The live metrics tool enables vendors to capture general information about how end users utilize their products along with installed platform and version information. The live metrics tool collects details from the installed user base and sends them to a central server which aggregates the data. The information could be product version, hardware platform, frequency of use, and operating system types. Live metrics usage reports give a picture of overall usage patterns across the installed user base rather than reporting on the specific behavior of any individual user. Individual installations are identified by an anonymous identification so that end user confidentiality is assured.

Moreover, trial optimization is a process of persuading the maximum number of users to buy a product after the trial period expires. Trial optimization utilizes tools used to analyze website traffic and shopping cart behavior. The goal is to determine where users enter and exit the site and the buying process, and then modify site design or other variables to encourage trial users to become paying customers. Through careful measurement and analysis of online behavior, software publishers can pinpoint the precise spots in the trial process where customers lose interest. They can then take action to remedy those problems by refining download processes, installation procedures, site design or other variables. This in turn helps turn more "software testers" into buyers. Advantages of trial optimization are increased revenue, reduced support costs, better relationship with customers, and increased return on investment (ROI). The trial optimization system seeks to send messages all end users. Further, it manages and delivers program updates to end users. Furthermore, it measures and gathers anonymous customer usage information.

Another advantage of the trial optimization system is that the messaging reaches all end users and messages are delivered contextually at the start of the program. Thus, the messages are far more likely to be clicked. Further, eligible users are notified of program updates and updates are made available by download resulting in a huge cost reduction. Vendors can track adoption, and there is also a considerable reduction in customer support costs. For user behavior, a customer can easily create a program to measure user usage and get larger customer groups with large data samples over time. Additionally, the customer can track changes during the setup process.

Additional advantages and features of the invention will be set forth in part in the description which follows, and in part, will become apparent to those skilled in the art upon examination of the following or may be learned by practice of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates screen shots for downloading components of trial optimization.

FIG. 2 shows a developer modifying an application shortcut from a target address.

FIG. 3 shows a developer running a trial optimization wizard.

FIG. 4 illustrates a developer copying target application setup files.

FIG. 5 illustrates a user starting a wrapped application for trial optimization.

FIG. 6 shows a flow diagram of live messaging with trial optimization.

FIG. 7 illustrates an example screen shot of a welcome message.

FIG. 8 shows an example screen shot of what a user sees with an add - on sale.

FIG. 9 shows an example screen shot of a third party offer. FIG. 10 shows an example login screen shot for an administration console in trial optimization.

FIG. 11 illustrates an example main menu screen shot.

FIG. 12 illustrates a series of manage user screen shots from an administration console.

FIG. 13 shows a series of manage product screen shots.

FIG. 14 shows a sample manage messages screen shot in an administration console.

FIG. 15 illustrates an example manage updates screen shot.

FIG. 16 shows a reporting screen shot in an administration console.

FIG. 17 illustrates a flow chart of a user experience with live metrics tool.

FIG. 18 illustrates a flow chart for a live metrics tool setup.

FIG. 19 describes a flowchart for live metrics tool working in an application.

FIG. 20 illustrates a flowchart for live metrics tool working with PONG messaging system.

FIG. 21 shows an example PONG message window screen shot.

FIG. 22 shows a diagram of a sales funnel in trial optimization.

FIG. 23 illustrates a diagram for using self selection to segment customers.

FIG. 24 shows an example spreadsheet for use in trial optimization.

FIG. 25 illustrates a screen shot of one way of communicating with a customer in an application.

FIG. 26 illustrates an example of a user experience product detail page.

FIG. 27 illustrates an example of a product trial detail page. FIG. 28 shows an example opt out cart screen shot.

FIG. 29 shows an example cart abandonment message.

FIG. 30 illustrates a screen shot of a main menu page for utilizing live messaging tool.

FIG. 31 illustrates a show segment page.

FIG. 32 shows an add segment page.

FIG. 33 illustrates a new segment message.

FIG. 34 shows a screen shot for product administration.

FIG. 35 shows a screen shot of an edit segment page.

FIG. 36 illustrates a message for segment updates.

FIG. 37 shows a delete segment page.

FIG. 38 illustrates a message for segment deletion.

FIG. 39 shows an add live messaging page.

FIG. 40 shows a live messaging details table.

FIG. 41 further shows an add live messaging page.

FIG. 42 illustrates a screen shot of FIG. 41 with the options for subversion expanded.

FIG. 43 further illustrates a screen shot of FIG. 42 with an option for enter subversion selected.

FIG. 44 shows a screen shot of a segment identification (ID) field options expanded.

FIG. 45 shows a screen shot with a buy now uniform resource locator (URL) box selected.

FIG. 46 illustrates a message for new PONG insertion. FIG. 47 illustrates a message for updating a PONG.

FIG. 48 shows a screen shot of live messaging with tabs and a banner image.

FIG. 49 shows a live metrics file packaged in the sources of a dummy application.

FIG. 50 illustrates a screen shot for a modified shortcut.

FIG. 51 shows an application sources folder.

FIG. 52 illustrates setup files copied into an application sources folder.

FIG. 53 shows an images folder.

DETAILED DESCRIPTION

In a preferred embodiment of trial optimization described below, there are no changes required to an independent software vendor (ISV) source code. Trial optimization is implemented with less than thirty lines of "wrapper" code added to the setup, and a wizard creates this code. The "wrapper" calls an application and initiates message delivery by connecting the client agent and the server side component. To get started with trial optimization, a user would first download trial optimization components and then modify application shortcuts. The user would run a wizard and wrap the application to begin a startup process.

Referring now to FIG. 1, for downloading the components of the system, a developer extracts contents of a trial optimization developer's kit 100 to a folder 102. FIG. 2 shows the developer modifying 106 an application shortcut 108 from a target address 104. Next, FIG. 3 shows the developer running a trial optimization wizard. In step one 110 of the wizard the developer enters product information. In step two 112 of the wizard the developer enters message settings in the fields provided. In step three 114 of the wizard the developer enters customization settings. All three steps are saved to a configuration data file 116. Furthermore, in FIG. 4 the developer 118 copies target application setup files 120. These files are copied to an application sources folder 124. The developer 118 then creates 122 a wrapped installation installer 126. As shown in FIG. 5, a user 128 starts 130 the wrapped application 132 which then calls 134 the target application 136 and a live messenger 138. FIG. 6 shows a flow diagram of live messenger 138. The user starts the application and in the background 140, a live ware client checks a registry entry 152 to see when the last message was delivered. Depending on a defined time interval, the application pings 144 a server 150 for a message for the user's defined product identification (ID). Next, the server component delivers 146 the message. The message can be delivered based on segmentation information like operating systems (OS), program usage, and locale to better match user targets. Error messages never display if a connection is unavailable, server side message is unavailable, unusual proxy, or firewall issues prevent connection. The message is displayed 142 in an appropriate screen 148.

The potential uses of live messaging are to increase the conversion rate. Live messaging also can be used to sell product upgrades, sell add - on products, maintenance plans, services, training, books, related company products and third party products. Furthermore, live messaging can be used to provide tips, techniques, training events and web seminars.

Moving onto FIG. 7, an example screen shot of a welcome message 154 the user would see on first launch of the application is shown. FIG. 8 shows a sample screen 156 of what the user sees with an add - on sale. The user receives the offer when their attention is focused and therefore more likely to purchase. FIG. 9 shows a third party offer example 158. The business can send offers for partner's software, thereby increasing third party sales. Live messaging works effectively by reaching every customer at the best contextual time and reaches the actual user, not just the purchaser. There is no way to block messages without manually turning them off, and one can send different messages to different product IDs. With live messaging, the user can expect to increase trial optimization conversion and increase direct sales.

Furthermore, in another preferred embodiment a live metrics tool tracks customer usage and allows the business to better understand how the programs and hardware are used. The business can gather anonymous usage information by product version, track which features are used and which are infrequently used, and determine how often a product is used and for what duration. Also, the hardware manufacturers can measure any function accessible by the driver. Advantages include gathering large samples of anonymous user information over large periods of product usage. Live metrics has an inexpensive, aggregated approach which allows vendors to make sound future product decisions and investments based on extensive product usage.

Live metrics tool includes substantial reporting capabilities such as registration statistics, download data, setup data, application data, usage intensity, frequency of usage, operating system statistics, and trial conversion rate. An administration console allows secure accessibility from the internet. The administration console can manage users, product IDs, messages, updates and product segments. The console also allows access and export reports. FIG. 10 shows an example login screen 160 for the administration console.

Referring now to FIG. 11 , an example main menu screen 162 is shown. Here the business can alter user administrator settings 164 by adding or changing users and editing login settings. The business can also change product settings 166 by managing live bits tools, live messaging and segmentation information for the administration console. The business can view and change report settings 168 by download data, registration data, setup data, application data, absolute usage, usage intensity, operating system stats, and trial conversion. Finally, the business can click under help 170 to view a user manual, view steps to methcize, or to download the application wrapper.

FIG. 12 illustrates a series of manage user screens 172 in the administration console as a sample. Furthermore, FIG. 13 shows a series of manage product screens 174 and FIG. 14 shows a sample manage messages screen 176 in the administration console. FIG. 15 illustrates a manage updates sample screen 178. This screen shows an example of managing the live bits tool, with fields to fill in product IDs and descriptions. FIG. 16 shows a reporting screen 180 in the administration console. By choosing a product name, start and end date, a report will be run for trial conversions. In a preferred embodiment of trial optimization, a live loops tool is utilized to communicate between clients and servers. Live loops is an application independent hypertext transfer (HTTP) based protocol that enables seamless communication between clients and servers. It supports a wide range of libraries that support specific functions required in client applications. Live loops application utilizes industry standards and works over firewalls and proxies. It can be used for registration, surveys, application updates, etc. In a preferred embodiment of trial optimization, a live bits tool informs users of new program updates. Vendors can then automatically send updates and detect if the user is eligible for the update. Advantages include reduced customer support costs since significant number of support calls can be tracked to outdated versions. Moreover, the traditional physical fulfillment costs are reduced. Live bits also highlights the value of maintenance contracts.

Referring back, live metrics supports client application setup tracking, usage tracking, data submission, and reporting.. It can also be used in a variety of applications like improving conversions, product usage and more. Using live metrics the user can track usage, determine what to track and how, gather client system information, and have opt-in decisions. FIG. 17 illustrates a flow chart of a user experience with live metrics tool. Live metrics workflow at the client side begins with the user 184 manually initiating a wrapper setup 186 on a user machine 182. The setup 186 will then ask the user 194 for permission to participate 188 in live metrics. This involves capturing various details like setup launch time, end time, setup status, user's machine configuration details, etc. If the user 184 chooses yes, then a unique ID is generated and stored in a registry. It installs a live metrics framework on the user's machine 182, launches the target setup, and collects information about the user's machine 182 details. These details are written to a metrics file 192. This is an extended markup language (XML) file and contains a unique ID. At this point the installation as seen by the user 184 is complete. The metrics file 192 is then uploaded to a server 194. If the user 184 chooses no, then the wrapper setup 186 launches a target setup that completes the installation and stops 194.

Again referring to FIG. 17, live metrics workflow at the server side begins when the metrics file 192 is uploaded to the server 194 and it is seen by a batch process running on the server 194. The batch process parses the metrics file 192 and the parsed file so obtained is inserted into a database 196.

FIG. 18 illustrates a flow chart for live metrics setup. Client side activity begins 198 with the user manually launching an application shortcut 199. The user decides 200 whether to participate in live metrics or not. This would allow capturing machine specifications. If yes, then a unique ID is generated 202 and stored in a registry. Then the live metrics framework is installed 204. If no, then the process heads straight to launching 206 a target setup. It will then check if a metrics upload time period has lapsed. This can be set to a week or a month or any specific time period. If the user has agreed 209 to information capturing, then it captures 210 information such as setup status, setup launch time, end time, computer configuration and writes to a metrics file 214. Installation is then complete 216 and the metrics file 214 is uploaded to the server. If the user has not agreed 209 to information capturing, then the process skips capturing information and instead installation is complete 212 and the rest of the process stops 208.

In another embodiment of trial optimization system and method, for the server side activity, the server first saves 220 the file 222 locally. A batch process that runs once a day on the server processes the uploaded files. The batch process parses 224 the uploaded files and inserts data into the database 226. From the database 226 there is reporting 228 of the information in the file 222 and then the server side activity stops 230.

Referring now to FIG. 19, a flowchart for live metrics tool working in an application is described. Application client side activity starts 232 by the user manually launching 234 the application shortcut. This shortcut, which points to the wrapper application, launches the wrapper application. It will then check 236 if the metrics upload time period has lapsed. This can be set to a week or a month or any specific time period. If yes, then it uploads 238 the existing metrics files to the server and then launches 240 the target application. If no, then it will directly launch 240 the target application. System information such application status, launch time, end time etc. is again captured 242 and saved to a metrics file 246. The launch is then complete 248 and the process stops 250. The server side activity starts with the server saving 252 the file 254 locally. A batch process that runs once a day on the server processes the uploaded files. Then, the batch process parses 256 the uploaded files and inserts data into the database 258. As with FIG. 18, reporting 260 is done and the process stops 262.

For reporting with the live metrics tool, details are inserted into a database by a batch process that parses the XML based metrics files and decrypts if necessary. These details or the data in the database can be used to generate reports as per the user specifications and requirement. The process by which live metrics tool gets integrated with a third party application is that first a customer hands over the setup of the product with which they want live metrics to be integrated. A live metrics setup is then built around the product setup. This setup includes live metrics framework components and modifications to application shortcuts to point to live metrics launcher application. The product with a wrapped Live Metrics function is returned to the customer. The product is then ready to be distributed. Logins for reporting access, etc. will be determined and managed separately. An example metrics file code is shown below:

<?xml version="1.0" encoding="ISO-8859-1 " ?> - <installation_data>

<computer_name>MYMACHINE</computer_name> <installation_uniq_id>43191 d98-5d34-4103-be42-

226a55c2312a</installation_uniq_id>

<product_version_no>10.1.0.238</product_version_no>

<setup_file_atthbute>32</setup_file_attribute>

<setup_file_modification_date>July 16, 2004</setup_file_modification_date>

<setup_file_modification_time>02:09:36</setup_file_modification_time

>

<setup_file_size>117200</setup_file_size> <installation_date>March

10, 2006</installation_date> <installation_start_time>19:12:28</installation_start_time>

<operating_system>WindowsXP</operating_system>

<operating_system_major_version>5<operating_system_major_versio n>

<operating_system_minor_version>5<operating_system_minor_versio n> <user_group>ADMINISTRATOR</user_group>

<service_pack>2</service_pack>

<installation_status>setup_completed_successfully<installation_status > <installation_finish_time>19:13:11 </installation_finish_tinne>

<installation_directory_exists>no</installation_directory_exists>

</installation_data>

Referring now to FIG. 20, a flowchart for live metric tool working with PONG is shown. PONG is a pinging component that is used to serve messages such as upgrade information to a client machine. For purposes of this document, PONG is similar to the live messaging tool. PONG, as a separate executable component, functions with live metrics tool on the client side by first (start 306) running 308 on the client machine and accepting a product ID. It then connects 310 to a server 294 and transfers product ID (this step can be integrated with live metrics level data submissions to the server). The server 294 looks up 296 the database 298 for any messages that map to the product ID. It then asks 300 if there is a message. If yes, then the message content 302 is sent to the client 312 and displayed 314. The process is then stopped 316. Message content 302 can include uniform resource locators (URLs), hyper text markup language (HTML) files, text, etc. The most common kind of messaging content is a URL that can further take the user to additional information, download pages, and special offers. If there is no message at step 300, then the process stops 304.

A PONG message window 318 is shown in FIG. 21. The actual presentation and content can be controlled by the client application or the PONG component on the client machine. This image is illustrative. The sample data present in the PONG database is shown in Table 1. Actual data will vary.

Table 1 - Pong Database

Essentially, trial optimization consists of three iterative steps: measure, assess, and modify. Measure means to track traffic through the website, what pages are viewed and in what order, and where the traffic leaves the site. Assess is based on the metrics generated by the previous step, determine why the traffic followed the measured patterns, and identify changes that can be made to reduce the number of people who fail to complete the sales cycle. Modify is to implement the recommended change, or a series of changes, and run A/B (comparison) tests between different changes to determine which one yields the best results. These steps are repeated on an ongoing basis to evaluate the results of any changes and fine-tune strategies accordingly. In this way, software vendors can achieve incremental increases in trial conversion rates that can translate into significant dollars. Referring now to FIG. 22, the goal is to move more consumers from one end of a sales funnel 322 and out the other. Traffic enters 320 the top of the funnel (entry to a shopping cart), and the goal is to get everyone to drop through the bottom 326, that is, becoming a customer by purchasing something from the site. Optimizing the shopping cart involves measuring where people fall out of the funnel (site flow 324). For example, this could be at the home page, product detail page, store or catalog page, or the shopping cart page. With an understanding of where, one can then assess why, identify alternatives to reduce the fall out, implement and test those changes, and start the process again.

With the tools of trial optimization, software developers can measure traffic through the various stages of their trial product and then optimize the process to increase the number of trial users who convert to a paid license. The idea is to identify the purchase barriers that trial users might encounter between signing up for a trial and actually buying the product, and then remove those hurdles to push more people through the funnel.

Trial optimization involves understanding user behavior related to a trial application, and then altering variables such as web page design or explanations of product benefits in order to change that behavior and thereby drive conversions to a paid license. Trial optimization is unique to every product and every site. Very rarely will two different trial products demonstrate the same behavior. Very rarely will one software product behave the same on separate download pages or download sites. This complexity can be reduced by establishing a standard measurement process related to trials that can be applied across all products and all sites. With this kind of measurement process, one can measure performance and compare results for any combination of products and sites. The standard trial optimization measurement process is comprised of the following stages: Download page hit, Download link click-through, Download start, Download stop, Install start, Install stop, Product use / start, Product use / stop, Shopping cart, and Order confirmation (payment completed).

Using the funnel presented earlier in FIG. 22, these stages can be portrayed as a trial optimization funnel. Trial optimization is an attempt to minimize the fallout or drop-off at each level of the funnel in order to maximize the number of people that reach the bottom, or paid use. The first step is to measure the funnel. The goal is to be able to trace the flow through the funnel. In other words, it is to trace how many people come and go at each stage of the process. Referring now to FIG. 23, a diagram for using self selection to segment customers into price and time sensitive streams is shown. It will be understood by one of ordinary skill in the art that customers are either price sensitive or time sensitive. Buyers who purchase directly 328 are time sensitive. They need the software immediately, and are the ideal customers because money is exchanged directly. However, some customers are both time and price sensitive. For instance, free trial opt out customers 330 have a free trial for a specified time period. After the specified time they will be charged 332 for the software unless they take an action, such as canceling 334. These customers are also good for the business. Free trial opt in customers 336 are price sensitive because the trial expires after a certain period of time and the customer needs to choose whether to continue and pay 338 or do nothing 340. FIG. 23 shows just one area of information to analyze for trial optimization.

To collect the data required to generate information for trial optimization, four tools are necessary, namely web analytics, a download manager with metrics capture capability, an in-product measurement tool, and e-commerce revenue reporting. These four tools will provide insight into how the funnel functions. Web analytics systems that collect data on website traffic patterns provide valuable information on how many people enter the funnel, navigate to a download page, and the path taken by users to get to the download stage or page. These systems also provide visibility into the number of people who move from the trial product into the shopping cart, and then to converted or paid use as reflected on the order confirmation page. A download manager that is capable of measuring and reporting on download statistics will help one track users from the start of the download to completion to determine how many abandon the process along the way. Additional information such as operating system, total bytes transferred, start and stop time stamps, and a success flag indicating whether the download was completed successfully can reveal download difficulties that may be sabotaging the trial process. In-product measurement tools such as third-party products that essentially wrap an installer with an installer for a measurement application can uncover problems in the installation process. This third-party installer, which can be branded to ones' standards, installs the metrics tool and takes a time stamp of the start of installation. It then initiates the actual product's installer. When the product install is complete, the metrics tool records a time stamp of the installation completion stage, then exits. All of this information is written to disk for transmission to a central server at some predetermined time and frequency.

An e-commerce provider's revenue reports will provide revenue information that indicates how many people actually reach the purchase stage. This can be combined with data from a web analytics tool showing traffic to the order confirmation page to paint a complete picture of the number of people who succeed in moving through the entire sales funnel. With all of these tools deployed, the focus shifts to gathering the data. It is important to collect enough data to ensure that one has sufficient information to determine user behavior patterns. For manual calculations, data is collected for at least three to four weeks, depending on download volume. For automated analyses, the analytic software will provide the statistically significant sample size based on expected volume in a given time frame. When the measurement period is complete, it is possible to develop a spreadsheet 342 that is similar to what is displayed in FIG. 24.

With the data gathered, the trial optimization process moves to the analysis and assessment phase. The objective here is to determine where prospective customers leave the sales funnel and why. In an ideal world, every user will move through every level of the funnel from top to bottom, creating a 1 :1 conversion ratio between every stage. That is, every person who hits the download page will initiate the download. Everyone who initiates the download completes the download successfully. But this never happens. There is always fallout from one stage to the next. The data gathered can provide valuable insight for reducing this fallout moving forward. First, compare the actual revenue gained to what the revenue could have been with a complete 1 :1 conversion ratio all the way through the funnel. The difference between these two amounts is the revenue opportunity. In the example in FIG. 24, if all 24,234 site visitors who visited the download page had purchased the product after the trial period, the total revenues would have been $1 ,078,413 instead of $12,771.50. Thus the lost revenue from people who failed to buy was $1 ,065,641.50. With the revenue opportunity understood, the analysis shifts to reviewing the conversion from stage to stage to identify the points where most prospective customers leave the funnel. Again looking at FIG. 24, the three biggest points of loss are conversion from product use to paid license (approximately 91 % fall-out), conversion from download start to download complete (approximately 45% fall-out), and conversion from install start to install stop (approximately 37% fall-out). The customers lost in these three stages alone account for over 12,000 units or approximately $542,000 in lost sales. Focusing on reducing the fallout in these three areas can make a substantial difference in this vendor's bottom line. To do this, it is necessary to perform an in-depth analysis of the customer's experience at each stage to determine what went wrong.

Once one has identified the areas where they are most vulnerable to losing users who are evaluating the trial software, the process shifts to determining how to alter the trial experience at the highest-risk points in the funnel to increase retention rates. Depending on where most shoppers are dropping off, options range from changing the download page's creative design, download-related messages, or download or installation routines to revising benefits messages and beyond. To be certain that the business is making the best choices on changes related to web page layout and marketing messaging, testing several different variations to determine which page configurations, benefit statements or combination of elements deliver the best returns. This can be accomplished with A/B or multivariate testing that compares different permutations against customer behavior. Trial optimization is an iterative process that must be repeated on an ongoing basis for continuous improvement. The user measures whatever changes they have made at a given interval, analyze the results, and determine what else one can do to drive trial conversions. For this, the user needs to understand behavior inside the product tool.

FIG. 25 illustrates a screen shot 344 example of a way of communicating with a customer in an application. FIG. 26 illustrates an example user experience product detail page 346. A try now 348 button allows the user to proceed to trial download. FIG. 27 illustrates an example product trial detail page 350 that the user would see when downloading the trial product. FIG. 28 shows an example opt out cart screen shot 352. Here the user can sign up for a trial offer and simultaneously opt out. FIG. 29 shows an example cart abandonment message (or POP) 354. This message shows one way of communicating to the customer that they can proceed with trial download without paying immediately for the product, thereby increasing the chance that the customer will change their mind about abandoning.

In another preferred embodiment of trial optimization system and method, there is a live messaging component that is used to serve messages such as upgrade information to a client machine. Live messaging works alongside a segmenting component that is used to add, edit, and delete messages among segments of existing products in a database. A screen shot 356 example for using the live messaging pages is shown in FIG. 30. On a main menu, users will have access to submenus. Here they can view, add, edit, and delete segment details or they can add, view, edit pong, and edit live messaging details (shown in circles 358). It will be understood by one of ordinary skill in the art that a segment is a set of certain criteria based on operating system, usage count, number of days since last used and average time usage on which live messaging will be shown to the user. To add new segment or to edit the existing segment the user clicks on Add/View/Ed it/Delete Segment details 358 link on the main menu page from FIG. 30. After clicking on this link, a show segment page 360 will be displayed as seen in FIG. 31. Here the user can edit 362, delete 364, or add segment 366. Add segment 366 will insert the information for a particular segment. On click, an add segment page 368 is shown as seen in FIG. 32. Table 2 explains details about fields on the add segment page 368.

Table 2 - Segment Page

After filling in the fields the user needs to click on add 384. User will receive a message 386, saying that "New Segment is inserted" as shown in FIG. 33.

To edit the information for particular segment, the user clicks a segment under an edit column 388 as shown in FIG. 34. On click, an edit segment page 390 will be shown, as seen in FIG. 35. After editing the information the user can click on update 392. It will be understood that the fields shown are similar to those described in Table 2. User will receive a message 394, saying that "Segment entry is updated" as illustrated in FIG. 36. Referring back to FIG. 34, to delete information for a segment, the user can click under a delete column 396. On click, a delete segment page 398 will be shown as seen in FIG. 37. From there the user clicks on a delete button 400. As illustrated in FIG. 38, if the user confirms the deletion, the segment will be deleted and a message 402 saying "Segment is deleted" will be shown to user.

To add new a new live message or to edit the existing live message the user would click on 'Add/View/Edit Pong/Live Messaging details' link from FIG. 30. After clicking on this link an add live messaging page 404 will be displayed as shown in FIG. 39. On this page, live messaging is associated only with active products. To insert the information for particular live messaging, the user first selects a product from a product name drop down box 406. When the user selects the product then a live messaging details table 408 will be shown, as illustrated in FIG. 40.

To insert information for particular type of live messaging, the user clicks on an add pong/live messaging button 410. On click, an add live messaging page 412 (or add pong) displays, as shown in FIG. 41. Table 3 explains the fields shown in FIG. 41.

Table 3 - Edit and add live messaging

FIG. 42 illustrates a screen shot 462 of FIG. 41 with the options for subversion expanded. FIG. 43 further illustrates a screen shot 464 of FIG. 42 with an option for enter subversion selected. FIG. 44 shows a screen shot 466 of segment ID field options expanded. FIG. 45 shows a screen shot 468 with the show buy now URL box selected, revealing a field for buy now URL. After filling the required information to add or edit the live messaging into the database, the user can click on an add pong button 470 (See FIG. 41). A message 472 saying "New Pong is inserted" will be shown to user, as illustrated in FIG. 46.

Referring back to FIG. 40, by clicking on a particular live messaging ID, related information of that live messaging will be then shown in all the fields. The user can modify the required fields or clear all the information from the fields which are on the add live messaging page. After editing the information, the user can click on add pong button 470 (See FIG. 41). A message 474 saying "Pong ID xxx is updated successfully" will be shown to user, as illustrated in FIG. 47.

As described previously in Table 3, a live messaging window supports maximum of six tabs. FIG. 48 shows an example screen shot 476 of live messaging with tabs and a banner image at the bottom. The pages which need to be displayed on the live messaging tabs can be in HTML, active server page (ASP), active server page framework (ASPX), hypertext pre-processor (PHP) or any browser supported format. In a preferred embodiment, the size of the page is pre-defined to prevent scrolling. Links can be assigned to selected parts of the images on the page by mapping the image with links. The image 478 at the bottom of the live message screen shot 476 is known as a banner Image. The banner URL, specified at the time of adding live messaging (See FIG. 41) will direct to this banner image. In a preferred embodiment of trial optimization system and method, metricize means to enable an application to report metrics data. Live metrics supports client application setup tracking, usage tracking, data submission, and reporting. It can also be used in a variety of applications like improving conversions, and product usage, thus helping vendors to gauge user patterns and analyze trends. The process of enabling any third party application to report metrics data is referred to "metricizing" hereafter.

Each application that is to be methcized is wrapped in a setup called as a LIVEMETRICS Wrapper setup. The LIVEMETRICS Wrapper setup acts as a container for the end party application that is to be metricized. The LIVEMETRICS Wrapper setup displays a dialog box that will ask the end user for permission to report metrics data. Based on whether the end user opts to report metrics data, the requisite files will be installed on the user's end machine. The setup invokes the third party application setup and reports metrics data to the server (if the user agrees for metrics data to be collected). The process does not require changes in the sources of the third party application files. The only changes that are required would need to be done in the sources of the setup file. The pre-requisite of any third party tool that is to be metricized is that each product should have its own LiveMetrics.ini file. Also, each product should have a globally unique identifier (GUID). The LiveMetrics.ini file contains information about target setup, live message setting information, XML file upload setting and vendor settings which will in turn be used by the LiveMethcs Wrapper file to identify the product being installed. This file is created and then placed into the folder that contains the sources for the setup. The information that is to be contained in a LiveMetrics.ini file is product information such as application name, product GUID, version number, product name, setup title, company name, company banner name, show participation dialog, optln, SubVersionRegKey, SubVersionRegPath, ShowLiveMessage, BUILDREGKEY, and BUILDREGPATH. Descriptions of the various fields related to product information are shown in Table 4 (assuming that an application "Foo" is to be metricized). Table 4 - Fields related to product information utilized by live metrics tool

Table 5 shows descriptions of the various fields related to Live Message setting.

Table 5 - Fields related to live message settings

Table 6 shows descriptions of the various fields related to XML file upload in trial optimization.

Table 6 - XML file upload fields

Table 7 shows descriptions of fields related to customization.

Table 7 - Customization Fields

Table 8 shows descriptions of the various fields related to vendors in trial optimization.

Table 8 - Vendor fields in trial optimization

Information provided in the LiveMetrics.ini file is used to map a user with a product via a GUID and thus track usage data. Table 9 shows descriptions of the various fields related to updates. Table 9 - Fields related to updates

A sample "LiveMetrics.ini" file packaged in the sources of a dummy application called "Foo" is shown in FIG. 49. Once this file has been created, it is placed in the folder containing the setup sources. Setup sources in trial optimization only need to be modified as far as shortcuts to an application are concerned. Basically, all shortcuts to the application or any related files are modified to invoke their target applications via the wrapper executable installed by live metrics. Shortcuts for a target application can be metricized to collect data for the application. Shortcuts are placed by the setup program and are modified if the application is collecting metrics data. Modification for a shortcut has to be done in the setup sources of the target application. If a shortcut for an application is not metricized, then no modification is necessary in setup sources. To modify an existing shortcut of the application, all shortcuts of the application that are to collect metrics data in the setup sources must be identified. The shortcuts are modified in the following manner:

"<wrapperpath>"<space>"<appname> <parameterlist>..." Thus, <wrapperpath> is the path where Live Metrics wrapper is installed. The live metrics wrapper will typically exist in a path such as "\Program Files\Common Files\LiveMethcs\<appname>\LMWrapper.exe". In case of application "Foo" it will be "\Program Files\Common Files\l_iveMetrics\Foo\LMWrapper.exe". Furthermore, <space> is blank space that should be provided after the <wrapperpath>. Also, <appname> is the third party application that is to be launched on clicking the shortcut. This information will be read from the LiveMetrics.ini provided with the package. In case of the "Foo" application, it will be <space>"C:\WINDOWS\system32\Foo.exe". Finally, <parameterlist> indicates the list of parameters that are to be passed to the application. If Too" requires a parameter 7a /s" to be passed, then this information is entered as: "\Program Files\Common Files\LiveMethcs\<appname>\LMWrapper.exe" <space>"\WINDOWS\system32\Foo.exe IaIs". An example screen shot 482 for a modified shortcut is shown in FIG. 50.

With these changes, the application is ready to be metricized. First a folder 484 for application "Foo" is installed and application setup sources are copied. In this folder, another folder 486 is created called "Application Sources" as shown in the FIG. 51. Then, setup files are copied of the application that is to be metricized into a folder such as the applications sources folder 488 shown in FIG. 52. Also, the

LiveMetrics.ini file 490 is copied into this folder. As illustrated in FIG. 53, to display the logo or banner on setup dialogs, an images folder 492 is created inside the application sources 488 folder with two images with different resolutions (494 and 496) and an lcon.ico file 498 of the application. The specifications for the images are explained in Table 10. This is the last step in the process. The application that is to be metricized is ready for distribution.

Table 10 - Image specifications.

Image Name Width (pixel) Height (pixel) Resolution (dpi)

Banner24b 497 65 72

Banner256 497 65 96

It is to be understood that even though numerous characteristics and advantages of various embodiments of the present invention have been set forth in the foregoing description, together with details of the structure and function of various embodiments of the invention, this disclosure is illustrative only, and changes may be made in detail, especially in matters of structure and arrangement of parts within the principles of the present invention to the full extent indicated by the broad general meaning of the terms in which the appended claims are expressed. For example, the particular elements may vary depending on the particular application for the web interface such that different dialog boxes are presented to a user that are organized or designed differently while maintaining substantially the same functionality without departing from the scope and spirit of the present invention.

Claims

CLAIMSWhat is claimed is

1. A trial optimization system on an end user machine which interacts through a communication network with an electronic commerce system, comprising: a live bits module operatively configured to maintain real-time streaming of customized data updates on the end user machine; a live metrics module operatively configured to collect and send information about customer behavior to a central server; and a live messaging module operatively configured to receive an in - application communication for a customer, the communication being related to potential software download purchases and being based on an aggregated report of customer behavior information and analyzed website traffic patterns.

2. The trial optimization system of claim 1 wherein the communication comprises a web page design.

3. The trial optimization system of claim 1 wherein the live messaging module is configured to sell an item selected from a group consisting of: add-on products, product upgrades, maintenance plans, services, training, books, related company products, and third party products.

4. The trial optimization system of claim 1 wherein the live messaging module is configured to provide an item selected from a group consisting of: tips, techniques, training events, and web seminars.

5. The trial optimization system of claim 1 wherein the live messaging module receives contextual ized messages based on product version identification.

6. The trial optimization system of claim 1 wherein the live bits module is operatively configured to detect if the end user machine is eligible for a realtime product update.

7. The trial optimization system of claim 1 wherein the live metrics module is operatively configured to gather anonymous end user machine information based on product version identification.

8. The trial optimization system of claim 1 wherein the live metrics module is operatively configured to track frequency of use of software features.

9. The trial optimization system of claim 1 wherein the live metrics module is operatively configured to gather customer behavior information selected from a group consisting of: demographics, preferences, and behaviors.

10. A trial optimization system on an electronic commerce system which interacts through a communication network with an end user machine, comprising: a reporting module operatively configured to aggregate received customer behavior information from the end user machine into a report; an analytics module operatively configured to analyze website traffic patterns of users progressing to a download page; and a communications module operatively configured to send a communication to a customer related to potential software download purchases based on the report and analyzed website traffic patterns.

11. The trial optimization system of claim 10 further comprising client trial optimization components operable on the end user machine wherein the client trial optimization components comprise: a live bits module operatively configured to maintain real-time streaming of customized data updates on the end user machine; a live metrics module operatively configured to collect and send information about customer behavior to a central server; and a live messaging module operatively configured to receive the communication for a customer.

12. The trial optimization system of claim 10 wherein the communication comprises a web page design.

13. The trial optimization system of claim 10 wherein the communication comprises a contextual ized message to sell an item selected from a group consisting of: add-on products, product upgrades, maintenance plans, services, training, books, related company products, and third party products.

14. The trial optimization system of claim 10 wherein the communication comprises a contextual ized message to provide an item selected from a group consisting of: tips, techniques, training events, and web seminars.

15. The trial optimization system of claim 10 wherein the reporting module is operatively configured to gather anonymous end user machine information based on product version identification.

16. The trial optimization system of claim 15 wherein the communication module is operatively configured to send contextual ized messages based on product version identification.

17. The trial optimization system of claim 10 wherein the reporting module is operatively configured to detect if the end user machine is eligible for a realtime product update.

18. The trial optimization system of claim 10 wherein the reporting module is operatively configured to track frequency of use of software features.

19. The trial optimization system of claim 10 wherein the reporting module is operatively configured to gather customer behavior information selected from a group consisting of: demographics, preferences, and behaviors.

20. The trial optimization system of claim 10 wherein the reporting module is operatively configured to generate the report where information in the report is selected from a group consisting of: registration statistics, download data, setup data, application data, usage intensity, frequency of usage, operating system statistics, and trial conversion rates.

21. The trial optimization system of claim 10 wherein reporting module is operatively configured to generate the report utilizing a segmented customer list.

22. A method performed by an electronic commerce system and an end user machine interacting through a communication network, comprising steps of: gathering customer behavior information from the end user machine; aggregating the customer behavior information at a central server into a report; analyzing website traffic patterns of users progressing to a download page; and modifying a communication to a customer related to potential software download purchases based on the report and analyzed website traffic patterns.

23. The method of claim 22 wherein the modifying step comprises modifying the communication wherein the communication is a web page design.

24. The method of claim 22 further including a step of sending the modified communication to the end user machine wherein the communication comprises a contextual ized message to sell an item selected from a group consisting of: add-on products, product upgrades, maintenance plans, services, training, books, related company products, and third party products.

25. The method of claim 22 further including a step of sending the modified communication to the end user machine wherein the communication comprises a contextual ized message to provide an item selected from a group consisting of: tips, techniques, training events, and web seminars.

26. The method of claim 22 wherein the gathering step comprises gathering anonymous end user machine information based on product version identification.

27. The method of claim 26 wherein the modifying step comprises modifying the communication to be a contextual ized message based on product version identification.

28. The method of claim 22 further comprising a step of detecting if the end user machine is eligible for a real - time product update.

29. The method of claim 22 wherein the gathering step comprises gathering tracking information about frequency of use of software features.

30. The method of claim 22 wherein the aggregating, analyzing and modifying steps are repeated such that communications to the customers are optimized to induce software download purchases.

31. The method of claim 22 wherein the gathering step comprises gathering customer behavior information selected from a group consisting of: registration statistics, download data, setup data, application data, usage intensity, frequency of usage, operating system statistics, and trial conversion rates.

32. The method of claim 22 wherein the gathering step comprises gathering customer behavior information selected from a group consisting of: demographics, preferences, and behaviors.

33. The method of claim 22 wherein the aggregating step comprises utilizing a segmented customer list in creating the report.