Adobe Target can be deployed client-side or server-side. This brief tutorial will cover web-based server-side delivery via API and assumes familiarity with the Delivery API specs (see link below) and access to the Adobe Target UI. The Target Server-side Delivery API documentation can be found at: https://developers.adobetarget.com/api/delivery-api/.

The following process occurs in a server-side implementation of Target:

• Step 1: a client device makes a request for an experience through your server
• Step 2: your server sends a request to Target via the Delivery API
• Step 3: Target sends a response back to your server with a decision on which experience to serve a visitor
• Step 4: your server interprets the Target response and delivers the correct experience to the client device

We are going to focus on Steps 2 & 3 in this brief tutorial. Ideally you will have access to an Adobe Target account and the Postman API test application to try this tutorial out yourself, but the concepts can be easily followed even if not.

We are going to begin by working with the Adobe Target Delivery API. From the API page above, please scroll to the Postman Collection and then open the Collection in Postman.

In the Postman UI, select the 'Web Delivery API Call' in Collections (1). Then modify the actual POST call and replace 2 instances of 'demo' with your actual Target client code value e.g. 'jimdemo' in screenshot below (2). If you do not know your Target account client code value, it can be easily found under the Administration > Implementation menu. Now Send the API call to Target by clicking the blue Send button (3). You should see a 200 status response from Target (4) confirming a successful call to your instance of Adobe Target.

Now select Body in the POST call (1) and change the name of the API request to 'target_feature_flag' from the existing value (2). This custom name will identify the specific API call to Target. Send the API call again (3) and evaluate the response to ensure your new API call name is returned (4).

Moving to the Target UI, let's start with building the response that Target will deliver back to your server/application. We'll create a simple JSON offer that will act as a flag or trigger for a specific test audience - that audience that would then receive the feature rollout. In the Target interface, go to the Offers menu in Target (1), create a new Offer (2), choose the JSON Offer type (3).

Let's name our JSON Offer "Feature Flag v1" (4) with the value {"enable":1} (5) and Save the Offer (6).

Now let's build the Target Activity that will deliver our Feature Flag response. In the Target Activity menu, Create an A/B Test as you normally would and select the 'Form' Experience Composer option per below, and pick a Property (e.g. 'No Property Restrictions') if your account has Properties enabled.

In the Target A/B Test 3-Step workflow, give your Feature Flag test a name (1), add an Experience B, and then select your API request name ('target_feature_flag') from the 'Location' dropdown menu (2). Please note that it may take several minutes for your API request name to appear in this dropdown after you have sent the API call using this name in Postman (you can also try a hard refresh of the page if it does not appear).

Next we are going to plug-in the JSON Offer that we created earlier into this A/B Test Activity. Under the 'Content' section (1) change the Default Content to the JSON Offer (2) that we created ("Feature Flag v1").

Click the blue 'Next' button in upper right to move to step 2, the Targeting step. On the Targeting page, change the traffic allocation so that 100% of traffic will enter Experience B (1) in this Feature Flag test example; so we are sure to call only our new JSON Offer using the API for this tutorial. Now hit 'Next' again to complete the Goals & Settings in step 3.

On step 3 you must setup at least one Goal Metric, all other settings are optional. If enabled, you can choose Adobe Analytics (A4T) or Adobe Target for the 'Reporting Source'. For this Postman demo, a Target-based metric might be easier to quickly see reports with conversions. Pick Adobe Target as the Reporting Source, then (1) Conversion > Viewed an mbox > then pick the same "target-feature-flag" Location name. This approach will convert 100% of visitor requests for our tutorial but you can also use/select a different API name that would only convert if you fired a second API request to Target using that name. Next, 'Save&Close' the Activity (2), and then be sure to Activate your newly created Activity from the test Overview page so that it is now 'Live'.

Now let's return to Postman. Simply Send the same POST API call again (1) and examine the response to your Target API request. You should verify your API call name (2) and now see your JSON Offer being returned (3).

Congratulations, you have just successfully used the Adobe Target Server-side Delivery API! From here, to build an actual Feature Flag test, you would instrument your web application to make the RESTful API call to Target (in a similar manner to what we outlined here in Postman) and build a mechanism in your application to show, or not show, your new feature based upon the customizable Target JSON response(s) to the API call. Please note that there are also other API considerations (e.g. maintaining visitor session id values) that are more properly outlined in the Target Delivery API documentation. There are also sophisticated software development kits (Java SDK and Node.js SDK) that use this Target Delivery API and remove the complexities of managing cookies, sessions, and integrating with Experience Cloud products. Also see: https://adobetarget-sdks.gitbook.io/docs/.

Good luck with your efforts and keep in mind that a key benefit to using Adobe Target for Feature Flagging is that you can easily evaluate the effectiveness of your new feature rollouts against any KPI or segment already defined in Abobe Analytics using Analytics as a data source for your Target activities (A4T).