Device Characterization (DC) provides additional ways to speed up and optimize your content based on the requesting device's features and capabilities. Property Manager provides two behaviors for controlling these functions: Device Characterization - Forward in Header and Device Characterization - Define Cached Content.

How it works

This behavior works with DC to first identify the requesting devices' characteristics, and then
pass them to the origin server in the HTTP request via the X-Akamai-Device-Characteristics request header.

Definitions

Forwarding. In this context, sending information about the requesting end-user device from the edge server to the origin.
Caching. Storing content on the edge server so that subsequent requests for the same content don't have to go to the origin.

What a DC header might look like

The X-Akamai-Device-Characteristics header uses syntax identical to a cookie header. See an example of a header sent when an Android mobile phone visits a DC-enabled page. In this case, DC is configured to send three characteristics: brand_name, is_tablet, and device_os.

X-Akamai-Device-Characteristics: brand_name=Google;is_tablet=false; device_os=Android

Typical characteristics available for forwarding

Akamai continuously improves the database behind DC, so the list of available characteristics changes over time. Typical characteristics include:


Characteristic	Data Type	Description
`resolution_height` `resolution_width`	integer	The screen height/width, measured in pixels.
`physical_screen_height` `physical_screen_width`	integer	The height/width of the screen, in millimeters.
`max_image_height` `max_image_width`	integer	The maximum height/width, in pixels, for an image to be viewable when the page renders in a mobile-optimized format.
`device_os`	string	The requesting device's operating system (for example, Android, iOS, Windows 10).
`device_os_version`	string	The request device's operating system version.
`mobile_browser`	string	The requesting device's browser.
`mobile_browser_version`	string	The version of the requesting device's current mobile browser.
`brand_name`	string	Device maker (for example, Samsung, Apple).
`model_name`	string	Request device's model (for example, SCH-I110).
`marketing_name`	string	The device model's commercial name (for example, Samsung Illusion).
`pdf_support`	true/false	Indicates if the requesting device can read PDF files.
`dual_orientation`	true/false	Indicates if the requesting device can rotate displayed content, which swaps the height and width dimensions.
`ajax_support_javascript`	true/false	Indicates if the requesting device supports JavaScript.
`cookie_support`	true/false	Indicates if the requesting device's browser supports cookies. However, note that cookie support doesn't indicate that the cookies exist. Also, even if the native browser doesn't support cookies, they might be supported via other methods.
`is_mobile`	true/false	Indicates if the requesting device is a mobile device.
`is_tablet`	true/false	Indicates if the device is a tablet; this is a subcategory of mobile device.

Special considerations for Apple devices

Most manufacturers of mobile devices include information in the device's user-agent string that identifies the hardware revision of the device. However, Apple has a policy of not including this information. For Apple devices, DC can identify the iOS version and the browser version, but it cannot distinguish between different models of the same product.

In contrast, consider this user-agent string:

Samsung Galaxy S3: Mozilla/5.0 (Linux; U; Android 4.1.1; en-us; SGH-T999 Build/JRO03L) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30

Unlike the Apple products, this Samsung user-agent string includes the model number.

Implementation

Before the edge servers can forward and cache device characteristics, you need to create one or more rules that include the DC behaviors. These are the high-level steps for getting started:

Create a rule, and determine match criteria.
Add the device-header forwarding behavior, and then select which characteristics to forward.
Add the Device Characterization - Define Cached Content, and then select which characteristics to use to create the cache keys.

Step 1: Create a rule and set its match criteria

As with other Property Manager rules, DC rules consist of two parts: match criteria and behaviors. To optimize content and/or cache content by device type, include one or more match criteria that use the device characteristics options.

To create a rule for your DC configuration, perform the following steps.

How to

In the Akamai Control Center, go to the property page.
Under Manage Versions and Activations, go to the Version History tab and select a version link.
At the top of the Rules list, click Add.
Select a rule template (for example, the Blank Rule Template).

👍
To narrow down the All Templates list, select a category in the left column.

Click Insert Rule.
In the Criteria section, click the Add Match button, and indicate the conditions that will trigger Device Characterization. Create additional match criteria as needed.

Step 2: Configure Device Characterization - Forward in Header

Select which device characteristics to forward to the origin. The more characteristics you select, the bigger your forward header will be, which may adversely affect performance between the edge server and the origin. Aim to maximize device-specific content delivery and minimize the number of characteristics you forward to do so.

How to

In the Behaviors section, click Add Behavior.
Scroll through the behavior menu on the left, and select the Device Characterization - Forward in Header option.
Click Insert Behavior.

A new DC behavior appears in your rule.

Click the Send These Characteristics field to select what to include in the forward header. You can use the mouse to select from the drop-down menu, or start typing in the box to search the options. Click the X to remove a selection.
Click Save.

Step 3: Configure Device Characterization - Define Cached Content (optional)

Select which characteristics are added to the cache key. Every unique combination of values of the characteristics you select will produce a separate cache entry. Therefore, it is recommended that you include only characteristics that request different content for different values.

👍
Consider how characteristics selected in this behavior relate to the device characteristics in the match criteria. You will probably find that the characteristics with boolean values (like is_mobileand is_tablet) are the most effective.

How to

In the Behaviors section, click Add Behavior.
Scroll through the behavior menu on the left, and select the Device Characterization - Define Cached Content option.
Click Insert Behavior.

A new DC behavior appears in your rule.

Click the Cache Based on These field to select what to include in the cache key. You can use the mouse to select from the drop-down menu, or start typing in the box to search the options. Click the X to remove a selection.
Click the Save.

📘
Adding a greater number of characteristics to the cache key (especially if you select characteristics that have many values) can negatively affect performance and offload.

Tips and best practices

Akamai recommends that any characteristic you add to your cache key you also add to your list of characteristics to forward. Then, you can use the X-Akamai-Device-Characteristics header to monitor what is being added to your cache key. Likewise, the characteristics in the rule's match criteria should align with the characteristics used in the behaviors. Also, your servers should provide different content based on the values of the characteristics in your cache key.

A good way to approach DC configuration is to begin by describing how you want to classify devices. For example, you might simply divide them by device type: desktop, mobile device, or tablet. Or you might also want to distinguish high-end mobile devices from low-end devices. Create a rule for each class, and use the match criteria to identify all the devices that belong in that class.