Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new

Learn more

View all

Sign in to view all badges

Homework Assignment #1 An Introduction to On-Device Decisioning


#1 Introduction to On-Device Decisioning Introduction

Welcome to the On-device Decisioning Alpha program for Adobe Target's Web SDK. What problem are we trying to solve with On-device Decisioning? Well currently, Adobe Target's Web SDK requires a server call to retrieve an experience to deliver to end-users. While a server call can guarantee that the experience being shown to a user is the most relevant at that given time, it can have adverse impacts to performance. Performance is key when rendering experiences to your end-users since it can impact user experience, conversions, revenue, and retention.

Now, our alpha version of the Web SDK can cache your AB and XT campaigns on-device, perform in-memory decisioning, and return experiences to your users at zero-latency. It also offers the flexibility for you to choose to deliver the most relevant and up-to-date experience from your experimentation and ML-driven personalization campaigns. In other words, when performance is important to you, you can choose to utilize cached decisioning. But when the most relevant and up-to-date experience is needed, a server call can be made.

Familiarize yourself with the Web SDK Alpha

We introduced the new On-Device Decisioning functionality to the 2nd major version of At.js. Most of the functionality is the same, but we did introduce a few new things:

  1. A new field called decisioningMethod which can be set as on-device, hybrid, or server-side

    "server-side"All decisioning is performed on the Adobe Target Edge servers, like it was before on-device decisioning.
    "on-device"All decisioning is performed on-device which is helpful for latency-sensitive situations, but may result in incomplete results in cases where all resulting activities could not be executed on-device. The mboxes which contain incomplete results will be noted in the response.
    "hybrid"Decisioning will first be attempted on-device, but any case where one or more of the resulting activities could not be fully executed on-device will result in the decisioning will be performed remotely, adding additional latency.

    We will focus on "on-device"  for this homework assignment.

  2. A new function called getAttributes, but more on this at a later time. 

Getting started

It's easy to get started with the alpha version of at.js. Simply download the alpha build of at.js and include it in the head of the html document where you want to use it. If you already have a project that uses at.js, you can replace the at.js file with the alpha version after downloading it.

Download at.js with On-Device Decisioning (right click and "Save as...")

After downloading at.js, you will need to set a few properties on the targetGlobalSettings object. Normally these values are set for you if you download at.js from the Setup->Implementation area of the Target Admin. But during the alpha, you will need to manually set the clientCode and imsOrgId. You can find these values in the Setup->Implementation area of the Target Admin. Just click the "Edit settings" button and a modal will display these values for you to copy and paste.

    <script type="text/javascript">

        window.targetGlobalSettings = {
            clientCode: "yourClientCodeHere",
            imsOrgId: "imsOrgId@AdobeOrg"

    <script type="text/javascript" src="at.js"></script>

On-Device Decisioning Method

Starting with the alpha release, at.js can be configured to run in on-device decisioning mode. In this mode, at.js loads a rules definition file on startup and uses it to determine the outcomes for subsequent getOffers calls instead of making repeated requests to the delivery API each time. This can greatly improve performance if you are concerned about network latency and would like to limit the number of requests made to target edge servers.

By default, at.js is configured to always make a request to the target delivery API for each getOffers call. But you can configure it to use on-device decisioning mode instead using the decisioningMethod setting. Specify the decisioningMethod in targetGlobalSettings.

window.targetGlobalSettings = {
    clientCode: "yourClientCodeHere",
    imsOrgId: "imsOrgId@AdobeOrg",
    decisioningMethod: "on-device"

Once configured in this way, your app can make standard at.js method calls and get offers that are determined locally.


Additional Configuration Options

The only configuration option required to use local decisioning is decisioningMethod. But you can specify other options that influence local decisioning in targetGlobalSettings.

Name Type Required Default Description

decisioningMethodStringNoremoteDecisioning Method (on-device, server-side or hybrid)
pollingIntervalNumberNo5000Polling interval for the local decisioning artifact (in ms)
artifactLocationStringNoNoneA fully qualified url to a target decisioning JSON artifact. Overrides internally determined location.
artifactPayloadObjectNoNoneA target decisioning JSON artifact. If specified, it is used instead of requesting one from a URL


Not all target activities can be decided locally.

Audience Rules

Some activities are not supported due to audience rules. Below is a list of audience rules with an indication if they are supported by on-device decisioning or will require a request to target edge servers to fulfill:

Audience RuleOn-Device Decisioning MethodServer-Side Decisioning Method
GeoNot SupportedSupported
NetworkNot SupportedSupported
MobileNot SupportedSupported
Operating SystemSupportedSupported
Site PagesSupportedSupported
Visitor ProfileNot SupportedSupported
Traffic SourcesNot SupportedSupported
Time FrameSupportedSupported


Go for a spin and try out a sample

We provided a  sample for you to try out to help you warm up to this new functionality. Going through this will definitely help you get up to speed. The samples are located in this repository -

Less Talking, More Action!

On-device decisioning works by defining your Target activities as a file of which will be downloaded and cached on browsers of your users. Our Web SDK knows how to interpret the file and make decisions locally on your users' browsers.

  1. Download the the alpha build of at.js  and configure the targetGlobalSettings object with your clientCode, imsOrgId, and decisioningMethod as on-device.
  2. Deploy the alpha build of at.js to a development or staging environment for testing purposes.
  3. Go to the Target UI for your organization, and create and activate a form-based composer or VEC AB activity that uses audience rules that is supported by on-device decisioning. TIP: You must create a new activity after deploying the alpha build of at.js so that the file can be generated. Also, after creating and activating the new activity, it may take up to 5 minutes or more for the file that contains the activity to be generated and propagated to the Akamai edges. This is because we have a cron job set to monitor any new activities for on-device decisioning every 5 minutes.
  4. Wait for about 5-10 minutes and browse to your webpage that you have the alpha build of at.js deployed. Make sure that the activity is executed correctly.
  5. Try launching more than one on-device decisioning form-based composer or VEC AB activities!

Gitbook Documentation (WIP)


2 Replies
Level 1
Level 1

Hi Adobe Team,


We have a few questions that have come up during our testing. We are still pressure testing and will have many more questions as we move forward 🙂


1. getOffer - no targetglobalsettings - How do we set executionMode inside of getOffer()? Is there an example in github (we could not locate one)?

2. The default mbox is target-global-mbox which is fetching in delltechnologies activities as part of the rules.json file. This will be fine for a delltech implementation, but we would like to know how to disable that. Is it an autocreated setting?

3. This is probably going to be for a future homework but it came up during our testing. Where will the Visitor ID service script placement be? Does it need to load before AT.js like it does today?
4. How do we validate SDID stitching for A4T or is it different with "local" mode?

5. How do we pass/set mbox params via our getOffer()? Is there an example in github (we could not locate one)?

6. If we want a "local" getOffer mbox and a "remote" getOffer mbox, do we combine them into one comma seperated getOffer or create seperate getOffers? Is there an example in github (we could not locate one)?

7. bundle_toggle.min.js:formatted:6406 POST https://localhost:5000/rest/v1/delivery?client=dellinc&sessionId=4a71f5e38a6742cdb92fa1b77a0ede8d&version=2.4.0 net::ERR_CONNECTION_REFUSED We keep seeing this error in console.

8. Audience Rules:
Operating System - not working - scrub=alpha, scrub=beta Examples
Site Pages - Current page URL working - scrub=bravo
Browser - testing Chrome Browser working - scrub=charlie
Custom - testing page.url - not working - scrub=delta - need to know how to pass params to the mbox to test custom targeting

9. rules.json - polling - each fetch is successful w/a size of 8.8kb which indicates it's downloading the file every attempt to fetch? Shouldn't it only download once unless there is a change?

10. rules.json - When navigating to different pages it downloads the file each time we hit a new page. Shouldn't it be cached unless there is a change?

11. Once we figure out how to pass in the mbox custom parameters, how do we access/retrieve them (default - browserWidth and custom - pagename) via the offers.... '${mbox.whatever}' ? Is this different from today's methods?

12. Suddenly today the rules.json stopped updating. After several hours, it still had not updated. I am unsure if it is as a result of the complex targeting rules we were testing or if another issue.

13. Shutting off the activity does not stop the rules.json from serving the previously cached rules.json file. Is this expected?