Adobe Target offers a few ways to leverage Adobe Target server-side. This is a video about the implementation of Adobe Target’s server-side delivery API. Traditionally, Adobe Target is installed client-side via a tag management platform, with server calls made out. In the client-side world, the visitor API service is on top, followed by the Adobe Target call and the Adobe Analytics call. The Adobe Target delivery API allows for standard HTTP requests, and Adobe also has SDKs for Node.js and Java. There are some limitations to processing cookies or redirect calls, but there are workarounds. Integrating the experience cloud is a common issue, but this can be resolved by putting the visitor ID service before the Adobe Target call. The video provides an example of a server-side call and passing parameter value pairs. Overall, this video provides a basic overview of Adobe Target’s server-side delivery API.
Transcript: (00:00) a couple weeks back we got a comment a request from psy looking for us to do a video on server-side implementation of adobe target i replied you know um you know what exactly because it is a very very broad topic and it looks like uh detail about implementation of server-side delivery api so i put this together sai please let me know if there’s if there’s any questions and if uh other folks out there would like me to do a quick video on anything adobe target to be approval related certainly let me know very happy to easily do it (00:30) so what is server side adobe target in the implementation so uh adobe target uh traditionally uh for the most part if at least in terms of like the customer user base client side where you install adobe target through a tag management platform and then server calls are made out and there could be a global mbox there could be client-side inboxes or i should say adobe target server calls they’re commonly referred to as mbox recall uh mbox recalls but here you can see these inbox calls or adobe target server uh calls taking place client-side (01:08) what happens is a call goes out to adobe servers and it responds with any activities that are in place it also passes data to adobe target as well client-side here you can see in the mia provo chrome extension examples of a lot of client-side activities and passing data to the adobe target server call including our first party id that we use and you can also see the adobe marketing cloud visitor id commonly referred to as the ecid this is what enables a for t so this is the client side world where you have one the visitor api service on (01:46) top that’s with the marketing cloud id number two is the adobe target call and then number three adobe analytics call would traditionally happen after that but thanks to this id we don’t have to really worry about that sequence the main thing is that the visitor id service fires before adobe target and adobe analytics so um as far as like the the options that are available so you’ve got the adobe target delivery api which is just standard http requests or https calls um that from any device it could be from (02:22) anything that’s connected to the internet that supports these protocols but adobe actually has several sdks node.js so if your application is using node.js they could just simply uh install this sdk and they’re off to the races they can make all the configurations um that they need to do that then there’s the java sdk both work wonderfully i’ve got a lot of mia provo customers that are using it as well as using the delivery delivery api which is just standard http request one thing for uh to consider there are some (03:03) limitations in terms of processing cookies or redirect calls but there’s ways around this you can kind of have the application read cookies and then pass the information along but the big thing i wanted to highlight here is the integration with the experience cloud many of the companies um i’ve heard from me approval customers as they they’ve they’ve installed the server side uh delivery apis everything’s working great in terms of changing the visitors experience but a for t broke because they didn’t put the (03:35) visitor id service before the adobe target call this only happens uh where the adobe target delivery api on face on first load if that cookie isn’t there for the experience cloud id that’s when there’s a disconnect between adobe target and adobe analytics but it’s a pretty easy fix and actually makes perfect sense to put the visitor id service service side as well that will resolve that automatically i’m going to include a couple links in this video you know link to this documentation which outlines you know (04:07) getting started there’s also this documentation that i love i love the developers adobe target.com because there are lots of legacy stuff in there and also the kind of like the updates that have been made um and so here here you can see examples of making uh the post requests and how that comes together but i went ahead and i created uh an activity in adobe target just so like the business side can understand what’s going on and so i’ll bring up uh to do visual code uh right here so here i’ve got (04:41) an example post so this is like a server side call and so what happens is if if this was running on miyaprova’s website for example this code i should go back so this this code would actually fire before anything is returned to the browser here you can see an adobe target server call mbox and i’m passing parameter value pairs you can pass this along any type of data that you might have server side which is wonderful your client code that’s what makes up this part here you can get that in the admin section of adobe target but you’re (05:19) going to want to pass in the session id that’s something that your application would typically manage standard 30 you know 30 sec 30 minutes of inactivity um and then an id this is the adobe target id that can be retrieved or this is you would also pass along here the experience cloud or marketing cloud id uh as well as your first party id as well and so it’s pretty straightforward it makes a call you can see here i made a call pretty fast uh most of the time let’s look on dns lookup so and this is uh microsoft uh (05:53) visual code and here’s the response um i got the adobe target response here the telemetry service the unbox name here’s the code my offer that got returned back to the page these are response tokens which very very fun things we we make heavy use of them at mia provo but it’s profile attribute data that’s mapped to this visitor id and so what’s happening here i’ll jump back to adobe target you have to use form based adobe target because you’re actually using um an mbox or a server call name (06:27) that’s not the global mbox you can’t use target global mbox as the name of the server call it won’t work because that’s reserved for the client-side global deployment of adobe target as far as what the response is you can do anything typically with server-side testing it’s json where you can pass back and then your application when it sees experience or whatever data you’re passing back your application would then do something with it you can see here i was uh given experience c but let me just update this (07:00) to see if i get a different value i’ll close this response i’ll even update the session id so it’s a little bit different i’ll send the response and there i got experience a because i was a different visitor id but i can make this request all day and i’ll always get experience a because it’s adobe targets of you know a visitor based uh testing platform uh but yeah that’s how it all works comes together um the uh a for t uh should work fine there’s also a really cool thing to consider i’ll actually two things i want (07:37) to add on here um as far as mia provo customers mia provo lives in an api world so any and all server-side testing that’s done in adobe target is is managed within miyaprova is available for program assignment alerts monitoring real-time reporting all of that good stuff is is available from a mia provo standpoint the other thing that’s pretty cool that i don’t um don’t see talked about enough is the coordination with adobe target client side and server side so let’s say i were to put on my blog adobe target (08:13) server side okay and then i would go in adobe target with the visual editor here and modify some content just modify something that is on both the client-side space and server-side space so let’s say i modify the about me approva section here okay if i go to the blog that’s the server-side area the adobe target server-side delivery apis will automatically look to see what other tests that you’re in and actually apply these changes server side so that you would see the changes to your client side so something really really cool (08:51) thought it would be helpful to highlight here but thank you again psy if there’s any other questions hopefully this answered it but if not let me know take care
Leave a Reply