Personalizing Consumer Experiences Everywhere with Adobe Target
If I could shout one thing from the mountaintops, it would be, “You can optimize more than just your website!”
So few people realize that Adobe Target lets you optimize and personalize everywhere customers interact with your brand — your traditional web and mobile touchpoints, but also smart cars, VR/AR applications, soft drink machines, digital assistants, kiosks, gaming consoles, point-of-sale (POS) devices, and other non-traditional touchpoints. In a way, this is no longer optional for enterprises because their customers are already connecting with them across multiple channels.
If you’re not using Target beyond your traditional touchpoints, you may not know you can or it might feel too complicated. In this post based on a recent webinar I delivered, I want to change that by telling you how you can extend Target to other touchpoints by using it server-side, namely:
- How using Target server-side works
- When to use it
- Fallacies about using it
- How to deploy it
You may be surprised to discover that it’s not so complicated.
Traditional web and mobile touchpoints
You may already be using Target on your web and mobile sites. Target makes that easy with a simple deployment along with an intuitive workflow and visual interface for creating experiences. When using Target client-side, your visitor’s browser (the client) makes a direct request to Target for the appropriate content to provide for a particular location. Target sends back that content, and the client browser renders it.
Using Target for mobile apps works much like the web or mobile browser does. A software development kit (SDK) allows your app (the client) to make a direct request to Target for the content for a specific location in the app interface. Target responds by sending back the appropriate content in the form of an XML, JSON, or plain-text string. The app then decides how to use that content.
In this client-side approach, there’s no “middle man” between the client and the Target server; the client interacts directly with the server. It’s pretty ideal for most web and mobile touchpoints, especially now that you can create experiences for your mobile app in the new visual experience composer for mobile apps.
Gaming consoles, soft drink machines, digital assistants, etc.
What happens when you don’t have a browser and the content isn’t text or images? What if the experience is a response from Alexa or a personalized soda flavor from a soft drink machine? What if internal security requirements prohibit a browser from interacting directly with the Target server? You want Target to decide what content to deliver to your customer, but you need your server to act as the go-between with Target. That’s when you would use Target server-side.
Using Target server-side makes your server that middle man between the visitor and Target. The client (which could be a browser, but doesn’t have to be) makes a request to your server. Your server passes the request along to the Target server in an API request. Target determines what content to return to your server and your server renders it, or if Target is sending it to a web or mobile touchpoint, the Target server packages it up in a JSON object with some logic to run in your visitor’s browser or app.
Using Target server-side removes the need for a browser or app. You can optimize and personalize pretty much any touchpoint that can make a web request to an application server and receive a response. Server-side lets you completely abstract the concept of the form of the content, which can be spoken words, text, an image, a temperature, a flavor — you get the idea.
When to choose server-side over client-side Target
You want faster performance. If you’re creating a more integrated backend or application environment — for example, if you use a single backend application for both your web and mobile sites — you may want to manage all your Target activities from one location, but have them show up across multiple devices. In such cases, you can deploy your activities faster server-side because you are managing content requests all on one server.
You need to render server-side. This can be the case if you’re building your application or site on a popular development framework like React or Google AMP. These frameworks may limit your ability to do things client-side, like render or report, or make a client-side request. They may also prevent you from creating or dynamically changing HTML or they may maintain a virtual state of your web page server-side. In these circumstances, you can only make modifications server-side.
You require more security and control. In other cases, strict internal requirements for security and control may prohibit you from using a JSON, XML, a text string output file, or an SDK for an app. For example, your app may be used in a healthcare setting that mandates maintaining privacy of patient information. By using Target server-side, you can insert your server with added security controls between the app and Target.
You wish to personalize cross-channel. Server-side is also ideal for cross-channel personalization because you work with a single customer profile that gets enriched each time a customer interacts with you from a given channel. Consider how this can not only help you connect the customer experience across your online channels, but also bridge the online and offline experience for your customer:
A shopper in your physical store selects a product and provides his or her phone number at the point of purchase. When entered into the POS application, this phone number serves as a key to unlock all the information associated with that visitor. That information lets you present tailored offers to the customer and further enrich the customer profile with purchase details.
Your physical store is not a browser, so client-side does not work. Using Target server-side lets you connect the customer’s in-store (offline) data with his or her online data through the POS application and push out an instant offer to the POS application via an API.
The not-so-difficult task of deploying Target server-side
I hope you’re excited about using Target everywhere using the method that works best for a given circumstance. To be clear — you can use Target client-side and server-side. I recommend looking at your different use cases and deciding which method makes the most sense to use for each.
Deploying Target server-side is pretty straightforward. If you’re running a Node.js application, all our APIs are beautifully bundled into an SDK that exposes some functions that simplify using Target server-side. If you run on Java, .NET, or Ruby on Rails, we have RESTful APIs on our Adobe-wide developer’s portal, Adobe.IO, that you can work with directly to deploy Target.
Also, many of you may have concerns that you need a developer to help you create each activity if you use Target server-side. Not true! When you do an API integration or deployment, there’s usually a one-time set of activities you must perform — that’s also the case with deploying Target server-side using APIs.
One thing to remember: you create server-side activities using the form-based composer rather than with the visual experience composer that you use client-side. It’s pretty easy to use.
By the way, many customers worry that they’ll lose the valuable integrations of Target with Adobe Analytics and Adobe Audience Manager that they have with their client-side deployment. Put that worry to rest. Those key integrations also work server-side.
Don’t trust me, try it yourself
I hope I’ve made my point — that you can test and personalize well beyond traditional web and mobile touchpoints. To learn more, listen to the webinar. And if you’re headed to Summit in Las Vegas, please sign up for our labs and get some hands-on experience using Target both client-side and server-side. I think these practical labs will make evident how Target opens the door wide for personalizing everywhere.