No more shopping cart abandonment on your online store!

blog | April 16, 2020 | Kumudika Rupasinghe

Doing the right thing at the right time in the right way makes things easier. Choosing the right solution makes even a difficult task simpler. Serverless is one such choice made by most of the companies for a better experience. Serverless can be the answer for most of the sales and marketing problems like booking anomalies, shopping cart abandonment, click fraud, solid lead generation and crippling data decay encountered by small to large scale companies. In this article let’s discuss one such problem and how serverless becomes the solution.

Meet Pam! Pam is a digital marketing strategist who works in large-scale retail business cooperation which hosts their online shopping portal in AWS cloud. When she analyzed the monthly online sales report, she noticed the monthly conversion rate is very low – 10%. From further investigations, she figured out the reason behind this matter and brought this problem to the attention of the marketing team.

Problem: Shopping cart abandonment

About 90% of the people who add items to the shopping cart, exit the online portal without purchasing.

Marketing team suggested the following solution to minimize shopping cart abandonment:

Business Solution

Automatically send an email to the customers who have abandoned shopping carts with items and haven’t checked them within 24 hrs. That email reminder also includes a link to return to the cart.

To discuss the technical capabilities of the suggested solution for shopping cart abandonment, Pam gathered a meeting with the technical team and directed this problem to them. After discussing with the technical team, they came up with the following solution:

Technical Solution

The web portal already uses Amazon DynamoDB for storing shopping cart details. As the cart_details table grows rapidly, the technical team decides to keep it as a temporary table and move entries which complete 24 hrs to a separate new table called history. Then, configure a DynamoDB Stream on the history table and invoke a Lambda function for every new entry, and send emails using Amazon SES to the relevant customer, containing a link to the cart. Meanwhile, the entries will expire after a particular time and permanently get removed from the history table.

What is in the scope?

This article will cover the area that starts from a new entry in the history table, and the sending of an email to the relevant customer with a link to the cart.

Process flow

What the technical team is expecting to do is, configure two Lambda functions as add-db-entry and send-email. Firstly, expose an API Gateway HTTP endpoint which accepts POST requests with a JSON payload and triggers the add-db-entry Lambda function which processes the request and inserts a new entry to the history DynamoDB table. Then, enable a DynamoDB Stream on that table. Configure the send-email Lambda to poll this DynamoDB Stream and, when it detects a new stream record, send an email to the relevant recipient using Amazon SES.

As the company is already migrating to a serverless environment, the technical team has decided to use SLAppForge Sigma, the simple, browser-based IDE for application development. They start with a free account and create a new Sigma project by entering just a few details as below. The base platform is AWS and the primary language is Python.

projectcreation

Let’s imagine we are the technical team 😉

Step 1: Creating `add-db-entry` Lambda and adding the API Gateway trigger

The project comes with a default Lambda function with the handler code snippet. Let’s rename it as add-db-entry Then to define an API Gateway endpoint to accept requests and set it as the trigger for our Lambda, drag an API Gateway resource from the resource panel on the left and drop it on top of the red coloured event variable of the function handler. Then on the configuration panel, fill the API details for a POST request (if you wish to make the API call from Sigma’s Toolbox, make sure to enable CORS in your API). When you click Inject after a successful configuration, the eventvariable would turn green.

API Gateway

The exposed HTTPS endpoint will accept POST requests with a JSON payload which carries data of the customer: Name, Email and URL. After integrating API Gateway with the Lambda function, the request payload received by the API will be injected to the Lambda function as the event object.

Sample JSON payload may look like this

{ "Name": "Kumudika", "Email": "kumudika.customer@some-email-domain.com", "URL": "http://online.business/checkout?cart_id=12345" }

Step 2: Extract values from the API request

After the API request payload passes data to the event object, we have to extract the necessary information such as the customer name, email and cart link from the request and assign them to variables for further use as follows.

Step 3: Creating the DynamoDB table and adding a Put Document operation

Then drag-n-drop a DynamoDB resource, right below the url = event['URL'] line from the resource panel and in the New Table tab, set:

Table Name = history
Partition Key = Name
Operation = Put Document

Enter Name, Email and URL as fields of the item (document), and click the Inject button.

DynamoDB

Once you are done, the code will look like below.

Step 4: Creating `send-email` Lambda and adding the DynamoDB trigger

Click plus sign next to the root directory in the Project tab and create a new Python function file named send-email. Then drag the already existing DynamoDB resource from the resource panel and drop it on the event variable of the function handler. Ensure that the table history, and set:

batch size = 100,
Starting Position = Latest,
Streaming Mode = New Image (entry data after the update)

and inject the trigger.

Step 5: Extracting the values from the trigger event

Add the following code into send-email.py file to extract values from DynamoDB trigger event.

Step 6: Sending the email

Now, drag-n-drop an SES resource, right before the return line of the send-email Lambda. For this article, let’s assume we have already verified our send and receive emails from AWS side. (If you haven’t, you can verify them via the Register A New Email tab of the resource configuration pane; in production, we would be requesting a SES limit increase from Amazon so that only the send address will have to be pre-verified). Then from the Use An Existing Verified Email tab, provide the relevant details.

Amazon SES

You can test the email sending flow by giving your email address as the receiver’s email. But before the final deployment to production, change the receiver’s email address from the code to the variable email.

The final send-email.py code will look like this:

(If you decide to copy-paste above code, remember to change the Source and ToAddresses emails on the ses.send_email() call!)

Step 7: Deploying the project

If you are done with the code changes, let’s save everything. Click the Save Project button on the toolbar and commit your changes to GitHub/Bitbucket/GitLab. And then click the Deploy button and your project will be deployed to the AWS account you had configured in Sigma.

Once the deployment is successful, you’ll get the deployment summary. Copy the API endpoint URL from the output parameter section.(If you accidentally closed the deployment pop-up, you can always view the output parameters via the Deployment tab of Project → Show Info.)

API endpoint

Step 8: HTTP request

Then, using an HTTP client like Postman, make a POST request to the above API endpoint URL. The request message body should be as in the following structure.(Make sure to update the Email field with a SES-verified email.)