Best Practices from Oracle Development's A‑Team

Abandoned Cart messaging via Eloqua, Part 1

Michael Sullivan
Principal Cloud Solutions Architect

Oracle Commerce Cloud has built-in Abandoned cart events which facilitate one to implement email notifications directly to known contacts. Not surprisingly, there exists a robust Commerce Cloud integration with Responsys primarily for B2C clients to do just that.

But what if your client has Eloqua instead? And given that, why would you want to use Eloqua’s email system for abandoned cart notification instead of “rolling your own”? For starters Eloqua has much more sophisticated mechanisms for dealing with bouncebacks, unopened emails, opened emails, opt-ins/opt-outs, etc. as well as facilitating easy-to-use conditional campaign logic via their campaign canvas and program canvas. Further, if your client is already using Eloqua for nurturing their B2B customers then it makes sense for Eloqua to be involved with the abandoned cart process since a sophisticated abandoned cart strategy often can often evolve to something quite nuanced — for example, perhaps only contacts in certain segments should get such notification.

Note: this blog post does not conflict with nor overlap with the standard Oracle Commerce Cloud + Oracle Marketing Cloud integration as that refers specifically to an OCC integration with Responsys not Eloqua

The old way of doing it

Back just a few years ago, it was straightforward to post your own email payload via Eloqua using its SOAP APIs as shown below:

Commerce Eloqua email design.#0

However, with the Eloqua’s deprecation of SOAP and the advent of REST 2.0 APIs such simple integrations are no longer possible. Instead one must use a more indirect approach.

Note: some of the old SOAP APIs were simply exposed as REST endpoints in Eloqua's REST 1.0 implementation and as such, some folks discovered that they could use these now unsupported REST endpoints to achieve the above functionality. Needless to say, one should never use unsupported features, even if they "work" — you never know when such behavior will be turned off. Caveat Emptor.

Assumptions for this blog:

• This use case is about a B2B Client where all contacts/accounts already exist in Eloqua — i.e. there are no “unknown” contacts

• We assume you are using Oracle Commerce Cloud

• We assume you will be using the Eloqua 2.0 REST endpoints

• The bulk of the email content would be cart-specific, thus would need to originate with OCC

Pattern #1

This is the simplest of “integrations” wherein you send a generic abandoned cart notification to your customer (Note: Eloqua will require a contact ID from you). The generic email would be an asset stored in Eloqua. While not particularly sexy (or effective), at least you get the benefit of Eloqua’s nurturing logic i.e. ability to deal with bouncebacks, opened vs. not opened, click throughs, out-of-office, etc. Not surprisingly, most clients seeking abandoned cart functionality would likely avoid this pattern as it is not personalized.

Commerce Eloqua email design.#1

The Eloqua endpoint used for the above is: /api/REST/2.0/assets/email/deployment

Pattern #2

This pattern picks up where the old SOAP pattern left off. Only, you can no longer create/send an email in the same request. Instead, you would likely implement an OCC webhook service that first creates & saves an email asset in Eloqua, then waits for a fixed amount of time, then tells Eloqua to send that personalized email to your contact. Somewhat chatty. A bit slow and also not scalable — i.e. this pattern is not recommended if the number of emails will ever be large (recall that you are saving each personalized email as its own asset within Eloqua!).

Commerce Eloqua email design.#2

The Eloqua endpoint used for the above is: /api/REST/2.0/assets/email/deployment

Pattern #3

This is the “recommended” pattern. You will need to deploy an AppCloud Content Service (typically hosted on OPC/JCS) that will inject the dynamic content into the email at runtime as shown below:

Commerce Eloqua email design.#3

You will also need to create an Eloqua email template that uses your custom AppCloud Content Service to inject the personalized content where you want it to show up. With this pattern there is just a single email asset for all abandoned cart notifications with the personalized content being filled in by the callback to the Content Service. If it is not obvious, the initial call to the Eloqua endpoint is exactly the same as for pattern #1 above.

The Eloqua endpoint used for the above is: /api/REST/2.0/assets/email/deployment

Note: By default, the Abandoned cart event fires after 20 minutes. This and other settings can be modified. Navigate to Settings -> Extension Settings -> Abandoned Cart Settings. You can now configure the number of minutes until the webhook is fired. For testing, you can set it to a low value.

Steps to implement this pattern:

    1. 1.) Register as an AppCloud provider: http://docs.oracle.com/cloud/latest/marketingcs_gs/OMCAB/index.html#Developers/AppCloud/Concepts/first-steps.htm%3FTocPath%3DAppCloud%2520Developer%2520Framework%7CGetting%2520Started%7C_____1
    1. 2.) Develop your AppCloud Content Service: http://docs.oracle.com/cloud/latest/marketingcs_gs/OMCAB/index.html#Developers/AppCloud/Develop/develop-content-service.htm%3FTocPath%3DAppCloud%2520Developer%2520Framework%7CDevelop%2520Apps%7C_____5
    1. 3.) Register your Content Service App: http://docs.oracle.com/cloud/latest/marketingcs_gs/OMCAB/index.html#Developers/AppCloud/Register/register-content.htm%3FTocPath%3DAppCloud%2520Developer%2520Framework%7CRegister%2520Your%2520App%7C_____3
    1. 4.) Publish and Maintain your app: http://docs.oracle.com/cloud/latest/marketingcs_gs/OMCAB/index.html#Developers/AppCloud/Release/publish-app.htm%3FTocPath%3DAppCloud%2520Developer%2520Framework%7CPublish%2520and%2520Maintain%2520Your%2520App%7C_____0
    1. 5.) Install the Content Service in Eloqua: http://docs.oracle.com/cloud/latest/marketingcs_gs/OMCAA/index.html#Help/Apps/DynamicContent/Tasks/InstallingDynamicContent.htm%3FTocPath%3DApps%7CDynamic%2520Content%2520app%7C_____1
    1. 6.) Configure the Content Service in Eloqua: http://docs.oracle.com/cloud/latest/marketingcs_gs/OMCAA/index.html#Help/Apps/DynamicContent/Tasks/AddingDynamicContent.htm%3FTocPath%3DApps%7CDynamic%2520Content%2520app%7C_____2
    1. 7.) Verify sending the email: http://docs.oracle.com/cloud/latest/marketingcs_gs/OMCAA/index.html#Help/Emails/Tasks/SendingTestEmails.htm
  1. 8.) Develop an OCC webhook to “kick off” the above pattern: http://docs.oracle.com/cd/E65426_01/Cloud.15-3/UsingCC/html/s1601configurewebhooks01.html

Other Links:

Diagram showing the overall Content Service callback flow between Eloqua and a typical Content Service:



One final note:

Since the email template is entirely hosted and served by Eloqua, there are other ways we could employ to tell Eloqua to send the email to our contact rather than pinging Eloqua's APIs directly via an OCC webhook as described above. We will explore these other options in future blog.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha

Recent Content