How much customisation of the eCommerce process can be done?

One of the most popular questions I get about our eCommerce software solution is how customisable is the actual ecommerce process, known as the ecommerce Funnel.

The ecommerce Funnel consists of the following steps:

  • Add to Cart
  • Cart Summary
  • Checkout Page
  • Payment Page
  • Completion Page
Shopping Cart Summary Page

Shopping Cart Summary Page

Checkout Page

Checkout Page

Payment Page

Payment Page

It’s been streamlined to reduce the cart abandonment and increase the sales conversion rate of the websites and is a very simple process. The ecommerce software we have built can be customised extensively depending on your specific business needs. However there are additional costs involved in there are pros and cons to each customizable feature.

Changing the eCommerce Funnel

It is possible to customise the above ecommerce funnel without changing the basic core of the software. For example we could remove the Cart Summary Page from this process easily by updating:

Settings :: Shopping Cart Settings – choosing the option:

Shopping Cart Do you use an AJAX (On Page) Shopping Cart?

This will then redirect the user directly to the checkout page.

Remove Shopping Cart Summary

Remove Shopping Cart Summary

Complex Customisation of the eCommerce Funnel

More complex customisation of the eCommerce funnel can also be done by changing the location and names of the relevant scripts. To do this:

Advanced Settings :: Advanced Settings

And then changing the paths of the event pages such as:

  • Category URL
  • Cart URL
  • Checkout URL
  • Members URL
  • Payment URL
  • Thanks URL
  • Custom Bootstrap CSS
Custom Scripts

Custom Scripts

Any customised pages would then be saved in the folder:

/cgi-bin/cart/custom/ or CSS:

/custom/

Then these pages would not be altered in any future upgrades.

There are however issues with changing these scripts in the long term. If any of the major “core” scripts are pointed to customised versions they will not be updated in any future platform wide upgrade. We only upgrade the “core” of the software we never automatically update the customised scripts. It’s important to balance the desire to make cosmetic or minor changes in these scripts to the likelihood that small incremental updates are made to the core software on a very regular basis.

Custom Elements at Specific Events

In designing and deploying our software we have included customisable elements at specific events in this process. This allows us to add custom coding without changing the core of the software. This is extremely important as it means that we can update the core software without causing custom elements to break or the website to stop working.

The events we can create custom elements to are:

  • When a product is added to the shopping cart
  • When the checkout is saved
  • For Delivery Cost calculations
  • On the payment option page
  • On the thank you page

The types of customised events that may be added for each are described below:

When a product is added to the shopping cart

Business rules to add special giveaways can be added to the software here, such as free chocolates if a specific product is purchased.

The rule would also be validated before the payment is complete to ensure that the original item or condition was still met.

When the checkout is saved

Business rules for adding items to the shipping cart for specific locations IE free items or addons etc that require the software to know the delivery address.

This event happens before the details are saved so an event may be created that returns the customer to the checkout page with an error message can be created at this point.

For Delivery Cost calculations

This allows more highly customised business rules for delivery costs or allows integration with third party services to calculate delivery. Services such as courier companies that you may want to have the price for ordering. These events are triggered however every time a page is viewed so third party integration should only be activated at events such as:

Checkout Save, and then validated on the Payment option page.

On the payment option page

If there are business rules for special giveaways that are linked to specific products, areas of delivery etc that need to be validated when the customer has entered their delivery address, these would be placed in here.

An example of this may be where you have a free teddy bear for all people ordering in a list of postcodes. We would want to validate at this point of the transaction that the delivery address is indeed in the area and if not to remove the free item from the cart.

We do this on the payment page in case the customer completes part of the transaction in another window whilst still viewing this page.

On the thank you page

Custom tracking events that are not already included as standard such as:

Affiliate commission tracking

Remarketing (although we do use Google Remarketing and Tracking codes already)

Other tracking of order fulfilment

Other areas of customisation may be the triggering of third party drop shipping fulfilment.

Technical Architecture

The customised scripts are always located in the folder:

/cgi-bin/cart/custom/

and for non executable scripts in the folder:

/custom

The specific event custom scripts are located in the file:

/cgi-bin/cart/custom/custom.pl

There is are empty subroutines for each script in this file.