Conversion Ratio

Abstract

Before a shopper converts into a buyer there are a lot of steps to be taken. In each of these steps a portion of shoppers discontinues their purchase and the remaining part finalises the transaction. The conversion ratio is defined as the number of shoppers that finalise their transaction in com- parison to the number of shoppers that start a transaction, expressed as a percentage. Because Adyen handles the payments, it is an important part of the process. Chapter 1 states the main goal of the project as to gather information about the course of the payment sessions of consumers buying at on-line shops and explains why off the shelf solutions like Google Analytics are not feasible. In this chapter three sub-goals are defined. 1. Live data feed for merchants. 2. Data for marketing material. 3. Form a basis for an article. Next technologies that are currently in place are analysed. First the infrastructure of the Hosted Payment Pages (HPP) is discussed in Chapter 2 and how Skins can be used to customise the appearance of the HPP. Finally the difference in the payment flow between the Multi Page Payment (MPP) and One Page Payment (OPP) is explained as well as the information that is currently included in the log files. In Chapter 3 the problem is analysed and the main question for the project is defined as: ”How to measure and present the Conversion Ratio on the Hosted Payment Pages?” To answer this question the process is decomposed in five distinct steps. 1. Log the required data. 2. Make the logs machine readable. 3. Centralise the log information. 4. Store the data. 5. Visualise the data. This decomposition is applicable for a generic logging framework. As such, the individual steps, which are treated in subsequent chapters, start with a generic part and end with a project specific part. In Chapter 4 the flow of events within a payment session is analysed. With this information additional data to be logged, like the IP address of the shopper, is determined to produce rich statistics. Finally the validation of payment sessions through state machines is discussed. Chapter 5 discusses various logging formats ranging from CSV files to directly logging to a database. These formats are compared as how useful they are when read by a machine to detect interesting patterns as well as how readable they are for humans in case of an error. Before a format is chosen, the file based formats are tested on how well they perform when being parsed. An optimal solution is to simultaneously log to a database for pattern recognition and log to CSV in case an error occurs. With the logs available in a suitable format the information has to be gathered on a central system. Chapter 6 considers two possible centralisation strategies that can be used. After the two strategies, file transfer and database replication, have been analysed, they are evaluated with regard to load balance, network capacity and security. Database replication is considered to be the preferred strategy to be used because it spreads the load more evenly over time and the mechanism is built into the database system. Chapter 7 talks about how the data is stored once it is available on a central location. First a generic approach is discussed that can be applied to logging in general where a distinct split is made between the log4j part and the application specific part. Then a conversion specific approach is taken which handles data extension, aggregation and validation. Finally an additional aggregation step is discussed for performance enhancement. As the statistical information is now stored the data needs to be visualised in a intuitive way. First several use case are discussed in Chapter 8. To be able to handle with more use cases a template framework is developed which can contain multiple chart types. Next the statistic types are discussed that enable specific calculations to be performed for a specific statistic and hide the data processing from the templates and chart types. After that the user interface and the structure behind it are examined. Finally the extendibility of the system is outlined together with performance enhancements. Chapter 9 covers software quality and testing. Initially unit tests were developed to test an important building block of the system, the state machines. With the unit tests written a code coverage analysis is performed to see how well code is covered by tests. Because of some imper- fections in the logging, not all logged sessions adhered to the state machines while they were in fact valid. For these sessions to be taken into account some shortcuts were added to the state machines. Regression testing enables these sessions to be used while still preserving the quality of the software by explicitly testing for these sneak paths. In Chapter 10 the conclusions of Chapters 4 through 8, regarding the five distinct steps in the process, are consolidated. After that, conclusions are drawn about the three sub-goals as outlined in Chapter 1. Regarding the live data feed for merchants the project has been successful. Merchants that got a glance of the user interface during development were very enthusiastic about the possibilities the system gives them. The goal of providing data for marketing material also has been met. On multiple occasions during the development, sales employees used the statistical data and its graphical representations as a Unique Selling Point to show Adyens expertise in the payment process. During the project a basis has been formed for a newspaper article, as well as a scientific article, thereby fulfilling the third goal. The newspaper article concerns the conversion ratio of PayPal payments. PayPal does not perform as well as other (localised) payment methods in the Netherlands, while introducing higher costs. A scientific article can be written on the basis of the generic logging framework and the preparations that have been made during this project for this framework. During the process, a broad range to topics was touched but not all could be researched within the scope of the project. In Chapter 11 several recommendations are made for topics that should be investigated further. These topics include the creation of a generic logging framework that can be used throughout the platform as well as system that allows merchants to upload multiple Skins and compare the results. Finally more research can be done on pattern recognition to improve the rate of successfully reconstructed sessions as well as the creation of a generic framework to measure performance throughout Adyen’s platform on multiple levels. In order to be feasible, all of these frameworks should be highly scalable to cope with large amounts of data. They should also be generic enough to be applied on multiple levels, ranging from the application level to a platform level.