#2 - Lifecycle program

If you find yourself having a hard time getting started there's two great questions to ask yourself. They'll help you start to design a journey.



How would someone enter this journey? There's four common ways for a profile to enter a journey



What components do I need to create the journey? Open a notepad and visualize what components you'll need to have to be able to create the journey. In this case:



Everything you need for offers has already been prepared, so you could do this use case without even looking at offer management. However, we're here to learn more, right? Let's dive a little deeper into how you create and manage offers, how representations work and how to set up eligibility rules and ranking formulas.

In Adobe Journey Optimizer you can manage offers under Decision Management. Let's start by having a look at Components, these are building blocks you need to start creating offers. After that we'll look at Offers., this is where you create your offers, add them to collections and create decisions for the Offer Decisioning Engine to use.

Placements These are the different representations for your offers. As you might imagine your offer should show up in different channels and these might have different requirements on how the content should be displayed. For example, you could have an image in an email and a text-version in a push notification. Collection qualifiers These are tags you can add to your offers so you can easily group them later. Rules As the name implies, these are rules you can add to your offers to determine eligibility. Offers can have their eligibility based on audiences or rules. The main difference between the two is that audiences use the current qualification status for the profile whereas rules execute at run-time. This means that when you have a batch audience (which updates once every 24hr) you might find yourself determining offer eligibility based on "old" data. Rules run at runtime, which means you can write a set of rules and it will check them when the offer is being requested. This means you'll always use the latest information. This is mainly relevant when talking about batch use cases. In cases that the audience is streaming or edge it's usually better to use the audience instead of rules. Ranking After the Offer Decisioning Engine has determined that you are eligible for multiple offers, it needs to figure our which one is most relevant. Offers come with a "priority" attibute in which you can define a base-level priority for this offer. For example, you might say that selling a mortgage is more beneficial to ING than selling car insurance and you can manage this by giving the mortgage offer a higher priority. However, in many cases you might want to use customer information to influence this priority. For example if the customer has recently showed interest in car insurance you'll want to prioritise this offer higher as the likeliness that the offer will be accepted is now way higher. This is where Ranking formulas come in. You can write additional expressions in here that can leverage customer data to change the priority for each offer.

Offers In this tab you can create all your offers, including the start- and enddate of the offer, attributes, qualifiers, different representations, the offer eligibility and the priority. Even though all offers have been prepared for the use case, try making another offer. Collections In collections you can define groups of offers that logically belong together. These groups will be used while making decisions to define what offers the Offer Decisioning Engine should consider. Decisions This is where you create decisions for the Offer Decisioning Engine to use. Decisions contain one or multiple scopes of offers it should consider when detemining the best offer for the customer. You can define what representations can be used and from which offer collection the Offer Decisioning Engine should pick from. Whenever you request an offer from the Offer Decisioning Engine you have to tell the Engine which decision it should use.

When building a journey it's important to be concious about how customers flow through the journey. Journeys in Adobe Journey Optimizer are per profile, instead of as a group like in most traditional marketing automation systems. This means that every profile runs though the journey alone and therefore every action on the canvas will be considering the individual rather than the mass.

In the past you likely selected a group of customers, then split this group based on some condition, excluded a few and then send an email to the remaining customers. In Adobe Journey Optimizer you'll instead build your journey asking yourself "If a customer does [something], I want them to [next step]". It might not sound like a big difference, but just imagine yourself how a "Wait"-activity would work in both of these scenarios.

So based on this change in perspective, how would your journey look?



When creating a message you can ask the Offer Decisioning Engine to include a relevant offer inside the message. Depending of the type of message you're creating this will be available in the UI as a component or through the personalization menu.

In the email designer there is a dedicated content component for an Offer decision. You can find it in the left menu under Components > contents > Offer decision. You can then define the representation and decision scope you'd like to use.



In push notifications you can use the Offer Decisioning Engine through the personalization menu. Click on the -icon to open the personalization menu. You'll find Offer decisions in the left menu.

You can run simulations for your offer decisions directly in Adobe Journey Optimizer. This is available under Decision Management > Offers > Simulation. Before you do this, you might want to check your test profile to see what products you have active (you should not receive offers for these) and what your propensity scores are (these should influence the offer priority).

When you run your simulation, make sure to increase the requested offer to 3, so you can see the top 3 offers for your test profile. For the tech-savvy After you run your simulation you can click  View code to see the request and response payloads of the Offer Decisioning API.

The resulting journey should look something like the image below.

The focus on this use case was not the journey. It was all about using the Offer Decisioning Engine. You were able to see how offers are created, managed and displayed in different channels. Maybe you even created your own offer along the way. You can now run this journey in test mode to receive the email and see your offer! An example of this journey is available, called [Example] Lifecycle program.