Programmatic Conversion Funnel Analysis using Rails & React

Introducing a new strategy tool for basic conversion analysis

As a growth marketing professional, one of the most common activities I engage in is to strategically break down the conversion funnel of clients and develop a deep understanding of where and how much value is evaporating, so I can determine which area I will operate in to deliver conversion uplift.

These calculations are quite simple on paper, but become increasingly complex based on the number of steps involved a particular funnel. The larger it is, the less clear the picture becomes.

Specifically, keeping track of certain assumptions can quickly lead to basic insights that tell an important and detailed story about the business. These stories are often the crux of new activities as they are specific about where the business is hurting the most, and to which degree the company will benefit by fixing these issues.

This led me to creating Leakfinder, a small but powerful application designed to enable marketers like myself to quickly navigate across high level conversion questions like:

1. Granted the current funnel performance, what is the revenue runrate daily, weekly, monthly and yearly?
2. Regardless of how many funnel steps there are, what is the conversion rate breakdown from each step to the next?
3. What is the ensuing conversion value for each event in the funnel?
4. How much value is being lost at each stage of the conversion funnel?

These four main questions can be determined granted a small amount of information, namely, the value of each final conversion (i.e. average order value) and the funnel event counts for each funnel step.

Technical Approach

When considering the project, I decided that I wanted to build it like a calculator. You throw in some inputs — regardless of your specific use case — and it delivers a generic (but useful) set of metrics derived from those inputs.

Since the ultimate goal of Leakfinder is to act as a lead generation asset for Cohort, I figured it should also be set up to capture emails prior to delivering conversion insights.

Finally, it should probably be a single page application so page refreshes don’t get in the way of the user experience, and so that the calculator feel can be achieved without its users feeling like this is a Wordpress website.

Technology-wise, the application backend is served by a Rails API whose purpose is to compute and persist calculation requests received from the front-end, which runs on React for the user interface and Redux for state management. I ended up sticking with Tailwind.css mostly because I need more practice with it as a utility-first framework.

Redux was especially useful in this case as it gives a standardized way to commit form inputs to a greater application “state” which any part of the application can access or contribute. Perfect for a calculator.

Building Leakfinder

The process of getting the app off the ground was fairly straightforward:

• Create the Rails app with --api flag
• Prepare the React App with create-react-app in the client folder, which sits in the root of the Rails app
• Configure a procfile and the proxy so that requests coming from the React app running on port 3000 are accepted by the Rails app running on port 3001. Otherwise, cross origin requests would likely stop the app from working. I used Foreman to manage both servers with one command
• Configure Rails routes to display specific information about a given calculation
• Add in controller actions to support the new routes.
• Configure the Rails serializers and populate a seed file to play with
• Conceptually, the data model is very simple. Users are only identified by the email they submit with, and the user model and then owns the ensuing calculations created. This helps me keep track of how many calculations were done by an individual email address in the back office.

• With the data schema ready to go and migrations complete, I started building out the methods for the Result attached to each calculation.
• First, I built a Runrate method that takes into account a time horizon and the defined conversion worth (i.e. Average Order Value = 150). The runrate outputs a hash of 4 revenue dimensions across daily, weekly, monthly and yearly runrates.
• Then, I created the algorithm to find the conversion rate between each stage of the funnel. This was interesting because I’m giving full control to the user relative to the number of funnel steps they can enter, which introduced the need for some meta-programming across the application to take into account whatever number of funnel steps might be defined by the user.
• Lastly, I created the algorithms to find the conversion value of each event in the funnel and the leaking revenue at each stage of the funnel based on the conversion rates and conversion values.
• Once the logic was taken care of, I focused some more on API design by defining the way the eventual front-end form would need to submit information. I defined separate strong parameters for the Rails controller such that the user and the calculation can be created along each other without having to double-tap the server.
• Finalize the Calculation create action, which would create a user, the calculation, their assumptions, the funnel steps, and manage the relationships in between, before returning a calculation object
• With the API working successfully, I moved my attention to the Rails app and user interface, starting with some basic routes and navigation.
• I containerized most of the important elements of the app, namely the FormContainer and ResultContainer, where most of the components of the app live
• Prepared the Redux store, populated the app reducer and prepared the form and form-step containers where the data inputs would come from.
• Each step contained text inputs which were committed to the local state of the component and then, by dispatch actions, over to the Redux store.
• When the final form element (email) is filled in, two API calls are made at the Result container. The first (1) is a POST call to the rails controller with a hash of information about the user, the calculation, its assumption and funnel steps. The second call (2) is a GET request to query the result information of the new calculation, to be used to populate the result container.
• From there, the ResultContainer is simply assigning the result values to its props, and then makes those props available to the individual result presentational containers such that they display accurate information without having to manipulate the data whatsoever.
• Preparing to throw this up on a Heroku instance so anyone can play with it.

Leakfinder on GitHub