Showing posts with label cart abandonment. Show all posts

Monday, January 27, 2020

Adobe I/O Events: Webhooks and The Triggers API Call

Companies around the world are continuously evolving and finding creative ways to optimize and improve the user experience across numerous platforms. The latest buzzword in that shift is Serverless Computing which is slowly shifting the narrative by allowing you to deploy abstracted code to tackle specific use cases as opposed to setting up massive a Server infrastructure. Now, I'm not saying that the latter is going away but activating specific actions is what some companies are slowly moving towards without necessarily relying on 3rd party hosted solutions. One such use case where Serverless can help is Triggers which I wrote about last year.

I also gave an overview of Adobe I/O where I wrote about the four I/O components and I/O Runtime is at the helm of it all. In this article, I'm going to walk through the application of application of Adobe I/O Events in Triggers. I'm also going to cover how to setup webhooks on your machine (Mac in my case) and leverage a script the Adobe development team wrote to use your machine to "listen" for incoming Triggers. So let's get started.

Triggers Architecture with Adobe I/O

Below is a high level architecture diagram I created to show how the Triggers API would interact with the various Adobe I/O components primarily Runtime and Events. Please note that this is a subset of what all is possible with I/O and an overall Adobe I/O architecture diagram is still in the works which will show the complete picture.

The steps till #7 in this diagram are almost the same as any regular Triggers lifecycle which I covered in my previous post so here, I'll cover everything from step 8 onwards. If some steps are not clear, don't worry as I will cover these in more detail later in the post. So, let's walk through these in more detail:

8a - A user subscribes to the Triggers API using Runtime by creating a webhook. A prerequisite is to subscribe to the Triggers API which is done in the Admin console (covered later).
8b - The webhook is registered in the Adobe Admin console which is validated by the Event Gateway.
9a - The Analytics Trigger is sent to I/O Events as soon as the trigger is executed (E.g. cart abandonment, some page is viewed etc.).
9b - I/O Events sends the Trigger JSON payload to the client which is collected at some endpoint leveraging Runtime via a POST request.
9c - A Runtime action is invoked as a custom event to send the JSON payload to a 3rd party Email Service Provider (ESP). Please note Adobe Campaign will automatically receive the JSON payload (step 7).
10 - Runtime action is invoked to query data and receive the output.
11 - This output is sent to an SFTP location to Adobe Campaign or other ESPs via another action.
12- ESP sends an email or SMS tied to the trigger payload and conditional logic.
13 - User clicks on the email and is routed back to the site.

Listen for I/O Events Via a Webhook

In this section, I'll cover some steps on how to setup a webhook using ngrok which is a tunneling software that allows you to convert your local site URL into a public facing URL. Please note that I'm not using the Runtime AIO CLI to do this but I have it installed on my machine and the instructions to install it can be found here.

Setup ngrok

Download ngrok from https://ngrok.com/ and run the ngrok application from your Terminal or Command Prompt pointing to the folder where the application is located. In my case, it's located in the /openwhisk folder and I'm creating an ngrok URL tied to my localhost on port 3000 by executing the command ./ngrok http 3000. I'll cover why I chose 3000 later.

Once executed, you'll get the public facing URL for your localhost which is https://c926b37a.ngrok.io/ in my case. Please note that this URL is only public facing for 8 hours but I believe there's a paid version to make reserved URLs.

Create a Webhook "Listening" Server

In this section, I will execute some code written by the Adobe I/O Events development team (A big Thanks for them!) that I retrieved from the Adobe Github page which has additional instructions on how to set this up as well but the main thing is to install this package on your machine. The command to run is npm start (Node.js) once you've installed the package to run the app.js file.

Once it executes, it publishes an HTML page on port 3000 which allows us to create our webhook. Note that this is the same port on which I created my ngrok URL. On this page, I enter a path (trigger) which creates a webhook as https://c926b37a.ngrok.io/webhook/trigger that will "listen" for any incoming triggers.

Register Webhook in Admin Console

The first step is to create an integration with Analytics Triggers in the Adobe I/O admin interface. Follow these steps to create it.

Once the integration is complete, the next step is to click on the "Events" tab of your integration and register & test your newly created webhook. Note that I'm registering the same webhook created in the previous step which is https://c926b37a.ngrok.io/webhook/trigger.

Once you save it, a challenge will be sent as a GET request to this webhook to check if it's active.

If it's live, then you'll see the "Active" status in the admin console page which means your webhook is now ready to listen for Triggers.

Create and Test Your Trigger

For the purpose of this post, I've created a very simple Trigger Action to fire when a user visits my homepage called "sandbox-home" and visited my page a few times.

Aside from the Triggers UI, I can also see five Trigger events posted on the app.js page actively listening for the events. Based on my test, it took the between 20-30 seconds for me to receive the webhook (see below) and I got 5 triggers (POST requests).

Parse the Trigger POST Response

Finally, you can parse the trigger response by expanding the POST request. In the JSON response, we can see that there are two main components of the call where the first one has information about the timestamp, IMS org among others and the second one is the actual analyticsHitSummary payload that contains all the "enriched" data from Adobe Analytics. Please note that a valid use case for this would be to send this to a 3rd party Email Service Provider given that Adobe Campaign receives it automatically. Please note that the customer ID (used to link ACS with a customer ID) captured on your site needs to be sent in an eVar as part of the Payload.

BONUS: Send a Slack Message When a Trigger Occurs

Now, this section is just to show how to send a message to a Slack channel when a Trigger fires. Please note that this is probably not a good use case for Slack given the frequency of Triggers so some better use cases will be server maintenance notifications, code publishing notifications, new members added or removed, fraud detection among many others. I'll just use the Triggers API to show how it works:

Enable Incoming Webhook for Slack

In this step, we will integrate our webhook with Slack to send a Trigger response to a Slack channel when an event occurs. You can do that by going here which is the regular process. In my case, I went here and added this app to my Slack workspace and channel called #trigger-channel.

Once you complete the integration, you'll receive your Slack Webhook URL which looks like this: https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX

Once the integration is complete, you can send a POST request to the hook and post a custom message like I did via Postman.

Once it's done, you'll see a bunch of messages stating the the integration is setup including a "Hello World" message which I sent.

Next, I'll show you how to enable Slack to receive your Triggers webhook.

Modify Code In app.js

Modify the app.js file and update your webhook URL and channel name.

Next, we'll modify the Triggers payload to customize what we want to send to our Slack channel. In my case, I want to display my ECID and URL which I've slightly modified in the script written by the Adobe I/O team.

Monitor Triggers in Slack

Finally, we can see that we got 5 Trigger responses in our Slack channel as well like we saw in the Triggers UI and the ngrok "listening" page. Again, not sure if this a good use case for Slack but you can use the model for other use cases which are more pertinent.

So, that was it! Hope you found this helpful for your own use case on how to use I/O Events. Are you using Adobe I/O in any form today?

Sunday, December 8, 2019

Drop Off Rate Calculator

Saturday, June 22, 2019

Send Real-Time Adobe Analytics Events to Adobe Campaign via Triggers

Triggers are part of the Experience Cloud Activation Core Service and have been in existence for a few years now. There's a lot of documentation already out there but with this post, I'll fill in some gaps that exist in the public facing documentation. I will also provide a quick overview of Triggers from my sandbox account, cover common use cases, share a logical architecture diagram and discuss the provisioning process along with some common access issues. Let's get into it!

Overview of Triggers

Triggers allow marketers to activate Adobe Analytics events in Adobe Campaign to re-market and engage customers via emails and other channels. Adobe Campaign is the main solution that leverages Triggers to send emails or SMS based on an action performed on the site in near real-time. I will be covering the integration between Triggers and Adobe Campaign Standard (ACS) at a high level.

We can access Triggers by going to the Activation site and clicking "Manage Triggers" (provisioning covered in the next section). There are 4 types of Triggers we can create which are:

Abandonment (Send an email or SMS after a gap of between 10 minutes to 2 hours)
Actions (Send an email or SMS if a particular action is performed on the site)
Session Start (Send an email or SMS if an action occurred at the start of a session)
Session End (Send an email or SMS if an action occurred at the end of a session)

Below is the UI we see when we create a new Trigger based on an abandonment.

Once created, Triggers will start collecting data immediately based on the conditional logic. In my actual example, I've created a simple Trigger based on an action tied to a particular Page Name.

Few Considerations While Using Triggers

We can create up to 100 Triggers.
We cannot bring in any calculated metrics or segments created in Adobe Analytics.
There's no way to select a Visitor container like we can in the Analytics Segment UI.
Values from Adobe Analytics reporting don't automatically populate in the dropdown menu when we use the "Equal" operator.
For Products or other dimensional data, there's no way to know which particular product has been added to the cart etc. so all the data is sent as it comes in. Prior manipulation of data will have to done to specify exactly which product was sent.
The conditional logic to create Triggers can get really cumbersome and there's a lot of flexibility provided around boolean logic and Containers provided in the Triggers UI.

Common Use Cases For Triggers

There are numerous use cases that can be met using Triggers and below are some examples. Please note that for these to work properly, the user would have to be signed in.

Abandonment (Time Bound)

A user abandons the cart or form and needs to be contacted within 10 minutes
A user signs up for an offer and you need to send a confirmation email
Notify of a shipment or password reset
A user purchases a product

Actions (Event Driven)

A user views a promotional video
A user completes a survey
Personalize email to show last product viewed
Confirm when a prospect opts-in for a newsletter

Session Start and End-I haven't used these yet

A user visits a campaign landing page after clicking on an ad
A user did not sign up for a form and exited the site

Aside from these, we can leverage the propensity score attribute to NOT trigger an email if a user is likely to visit the website in the next 30 days.

Triggers Provisioning

Email the Digital Request Alias

Anyone can can email the Digital-Request@adobe.com alias to get Triggers enabled for their Experience Cloud Org. This team will enable Triggers in the Admin Console as well as enable Triggers in Adobe Campaign Standard (They create an additional ticket). Below is what needs to be communicated in the email:

Marketing Cloud Company Name
IMS ORG ID
Analytics Login Company (could be same as marketing cloud company name)

Map Report Suites to the Experience Cloud Org

All Adobe Analytics Report Suites need to be mapped to the correct Experience Cloud Org as explained here.

Enable Triggers in the Admin Console

In the Adobe Admin console, we need to turn on the toggle to enable Triggers as shown below.

Create Data Sources

Create a data source in Customer Attributes to capture authenticated users which includes an integration code. This is needed to tie users logging in to the website with profile data in Adobe Campaign Standard. Please note that the user ID is hashed and needs to be reconciled in Adobe Campaign Standard (covered below).

Sync the Hashed User IDs with the Experience Cloud

This is a very important piece of this integration and is a required step to sync Customer or Declared IDs captured on the site with AAM or Customer Attributes and eventually with Campaign. This can be done easily in a Tag Manager like Launch.

Reconcile Triggers with the ID Service in Campaign Standard

The final step is to reconcile the an encrypted ID with a Declared ID data source in Adobe Campaign Standard. Below is an example of a Declared ID data source in ACS which is a new data source that needs to be created tied to the authenticated Customer ID by going to Administration -> Application settings -> Shared Data Sources. The link below the image covers this step in more detail.

Here's some more information on how to configure Triggers to send emails in Adobe Campaign Standard:

Triggers are also Accessible via Adobe I/O

I recently wrote about Adobe APIs last time and covered how to create an integration in Adobe I/O but this link covers how to connect with the Triggers API.

Common Access Issues

I recently ran into some issues while trying to access Triggers and had to log tickets internally at Adobe so if you run into these issues, you'll have to ask your Campaign consultant to log these on your behalf.

The first issues I ran into was around not being able to create a trigger. The fix for this was to map the report suites to the Experience Cloud (covered above).

This is an issue which I'm currently facing for a client where I'm unable to create an authenticated Customer ID Data Source. I had to log an internal ticket to get this resolved.

Simplified Integration Architecture

Below is a simplified architecture diagram I put together to outline the integration between Analytics and Adobe Campaign Standard using Triggers. I've leveraged some internal documentation to provide more details primarily around steps 4-6. Below is a screenshot of that and a summary of the various steps.

1 - AEM Services the page
2a - ECID Service is called and relevant IDs are returned back to the page
2b - If the visitor is logged in, an Authenticated "Declared ID" will be paired with the ECID
3 - Analytics image request fires and page/event level data gets sent to Adobe Analytics
4 - Real-Time Events sent via Analytics are detected using the Triggers State Machine
5 - Events are "enriched" with the Customer ID sent from the ID Service
6 - The enriched trigger events are sent through Pipeline Services and made available to Campaign. ACS "listens" for Trigger data that comes in as IDs starting with analyticsHitSummary
7 - Campaign queries data sources to build personalized multi-channel messages
8 - Campaign ingests/shares data from/to other data sources
9 - ACS delivers marketing messages across channels (Email, SMS) based on Triggers
10 - Customer clicks on the email and is routed back to the client website

So that was it! I hope you found this post helpful and hope that it will pique your interest in Triggers if you aren't already using it. Here's a link to another post where I've written about how to use webhooks to listen for Triggers.

Sunday, January 20, 2008

10 Ways to lower Drop off Rate in a Conversion Funnel

My last article mentioned ways to measure the drop off rate but through this article I’ll try to list ways by which you can reduce the drop off rate. Drop off Rate and Conversion Rate are two sides of the same coin as the below points would relate to both equally. A Conversion Funnel can start from the homepage, a search results page or a campaign specific page. Now let’s look at some of the ways by which we can reduce drop off rate:

1) A/B or Bucket Testing: A/B testing means testing many variants of the Conversion pages (Homepage, Product View etc) by sending a proportion of traffic on each page and eventually determining which page led to the minimum drop off or the highest Conversion. The important factor to keep in mind while conducting A/B test is that one of these pages should be the control (the original page). We can test pages by changing button color, size, text, placement etc or by modifying forms in order to minimize the customer drop off during the Registration process. Eventually by using a unique page name/bucket page name we should be able to determine which page performed the best.

2) Segmentation Tests: These are different than Bucket Test because in Segmentation we are looking to target certain segments of customers/users. We target customers based on their status (New user, not yet registered and Registered Customer). The “not yet registered” customer segment should see the login page so that he can continue the Conversion process where he left it. Similarly new users would see a different page and registered customers see a page only listing products of their choice. We can also segment customers according to their country (I.P.), Campaign Tracker ID, Direct/Indirect source of traffic. Ultimately we want to be able to determine which segment has the lowest Drop off/Highest Conversion rate.

3) Products Out of Stock: This is one of the mistakes that online retailers might make in order to make a customer purchase a product by pretending that the product is in stock when it is not. When the customer actually believes and purchases the item then guess what he gets an error message saying “Payment failed as Product out of stock”. I’m not saying this is a common practice but this scenario is possible and when it does happen it will surely leave a bad mark on that customer and maybe potential customers. So if a specific product is out of stock, then make sure you don’t display it.

4) Detailed Product Description: One of the reasons why sites like Amazon and Dell are pioneers in Online Shopping is because they make sure they provide the in depth coverage of the product. The users should also be made well adept with the specs of the product before they enter the cart with detailed textual description along with pictures. Sometimes including user comments also help.

5) Hyperlinks to Popups: While in the Conversion Funnel, a user might be distracted to click on a link/button that he finds appealing and this is the time when most customers leave the page. So in order to minimize that point of drop off, try to create links that open a new browser window/popup in order to retain the users on that page. It is however a highly debatable point because we need to be able to measure the links which lead to the customer exiting from the Funnel (Exit links). So I would suggest you to include links to Terms and Conditions, Privacy Policy, Product Specs and others in the form of popups so that you do not loose the customer in case he doesn’t go back in the Conversion process.

6) Trust: If your company is a public company/Fortune 500 company, always mention it on the Conversion funnel pages. In case of other companies, be sure to display a secure page icon (Verisign) on the encryption pages in order to generate a sense of trust for the customers. Having a privacy policy and terms of conditions page is also very important. A clearly defined Privacy Policy goes a long way in making the user feel secure before making a payment.

7) Shopping Cart Indicator: It is very important for visualize the Shopping Cart through a Step indicator on Conversion Cycle pages. As soon as the user selects a product you need to make him feel as if he’s entering a Shopping Cart and also listing what step it is so that he knows exactly where to go next.

8) Simple Registration Process: Try to make the registration process as simple as possible and try to minimize asking questions about PII (Personally Identifiable Information). Make sure the spellings are correct in the Registration process as it can really leave a bad taste for the user experience. Include as much predefined information as possible to reduce the amount of information the user has to fill in. For e.g. If a user has selected UK as the country then if possible auto populate the City, County, Country Code in the drop downs/text boxes and let the user select from that list rather than him entering it manually. Also radio buttons can work better then drop downs in most scenarios especially if there are only 2 choices.

9) Search Functionality: It is usually not advisable to include a search text box in between the Registration process but having it would only make things better. I say this because if a user wants to search for any information then he might want to exit the cart and go back to the Homepage. But if you have a search box which displays results in the form of a popup then you reduce your chances of jeopardizing your Funnel process by retaining the user on that page.

10) Web Analytics Tool to Measure KPIs: Finally the most important step is proper configuring of your Web Analytics tool to measure relevant KPIs or metrics. The Web Analytics code implementation according to the pages is of pivotal importance which hold true for Bucket Testing or Segmentation. The KPIs/metrics that might be of up most importance in case of the Conversion cycle can be Drop off Rate, Conversion Rate, Time spent on page, Exit Rate and Click Tracking.

These were just some of the ways that can help you maximize your ROI in terms of Conversion as there might be a lot more. I hope you like this article and if possible, let me know your thoughts about it.

Sunday, January 13, 2008

Funnel Drop Off/Abandonment Rate

Drop Off or Abandonment Rate measures the number of visits/visitors who left a conversion process (funnel) without completing it. Any process with 2 or more actions on the site can be considered a conversion process but what you define as a conversion depends on the purpose of your site and your business objective.

Before I continue, I want to mention that Drop Off Rate is the opposite of Conversion Rate. Conversation Rate is typically calculated as (Visits of the Last Conversion Step)/Visits of the First Conversion Step) X 100. Some of the commonly used conversion funnels are eCommerce shopping carts, registration forms or lead forms.

Abandonment Rate helps identify the steps in the funnel that are causing users to drop off. Conducting analysis of those steps will help us take necessary steps to minimize the drop offs and optimize the conversions.

There are 2 ways to calculate Drop Off Rate and each of them provide the data in slightly different ways. Both of them are correct ways to calculate and are commonly expressed as a percentage:

1) Drop off/Abandonment rate = ((Visits of the Last Conversion Step-Visits of First Conversion Step)/Visits of the First Conversion Step) X 100. Let’s assume that we want to use Product as the first step of the conversion process and that step gets 10,000 visits. But of those 10,000 only 7,000 continued to the next step of adding the product to shopping cart. Then in the next step only 2000 out of total 10,000 that started the process continue to Registration form and finally 1,200 out of 10,000 got to the final confirmation page. This means we saw 30% abandonment between Step 1 and Step 2 ie. ((7,000 -10,000))/10000)*100. Abandonment was 80% from Step 1 to Step 3 ((2,000 – 10,000)/10,000)*100. Final abandonment rate was 88% ((1,200 – 10,000)/10,000)*100. Though this calculation gives us a good idea of final drop off rate and conversion, it can be a little misleading.

2) Drop off/Abandonment rate = ((Visits of the Current Conversion Step-Visits of the Previous Conversion Step)/Visits of the Previous conversion Step) X 100. This calculation takes into account the previous conversion step and the current conversion step. In the Funnel, we see that 7000 visits are measured on the Add to Cart page (Step 2) and only 2000 continue to the Registration form so the calculation based on this formula would be ((2000-7000)/7000)*100 which is -71%.

Based on the above formulas, it looks like the first one seems better in terms of Funnel visualization but personally I like the second formula better. I say this because in the second funnel, we are only considering the respective conversion steps in the calculation and not just Step 1 (Products) because Step 1 is entirely a separate user experience. According to me, the Drop Off Rate should be calculated based on two consecutive conversion steps as they are independent of the user acquaintance on the other pages of a funnel. These 2 pages alone can determine how we can improve the conversion rate at each step as these are not based on the Products page experience. For e.g. The Registration form design and engagement is totally different than what it is on the Products page.

Here's a link to a calculator I built which includes these two calculations for you to use. Please note that the first calculation only takes in the first and last step as it only calculates the drop off rate based on the first and last steps.

Here's a link to a post I wrote to cover some steps on how you can reduce funnel drop off. I hope you like this post and would love to hear your opinion on it.

Product Management Insight