Common Media Client Data (CMCD) is an industry standard open specification created by the Consumer Technology Association used for communicating playback metadata. Akamai offers support for both CMCD v1 and CMCD v2.

End users’ media players understand playback behavior better than a content delivery network (CDN) can with limited server-side data. Media players use CMCD to send expanded playback information like buffer health, bitrate, and session IDs to Akamai and other CDNs. You can use CMCD for multiple purposes:

Data for segment prefetching. Your media player can include prefetching "hints" in CMCD metadata. This is supported for content that's segmented into individual objects, as well as byte ranges for prefetching parts of much larger media objects.
Data stored in logs for troubleshooting. More data = more help fixing problems. Akamai customer support can quickly access this log data to help reduce troubleshooting time.

Configure CMCD

CMCD on Akamai works by default with Adaptive Media Delivery. Unless you need to implement segment prefetching or other, more advanced CMCD logic, there's nothing you need to manually configure for CMCD to be enabled in your delivery configuration.

For setups that require prefetching or custom CMCD logic, you can make some client-side and delivery-side adjustments, along with the CMCD behavior, in your AMD rule configuration. See Configure prefetching.

Differences between CMCD v1 and CMCD v2

As of April 2026, the CMCD specification was updated for v2 in CTA-5004-B. CMCD v2 introduces features like multiple transmission modes (Request, Response, and Event modes), improved playback metrics and observability, and real-time telemetry. See the table below for some key differences between versions 1 and 2:

Feature	CMCD v1 (CTA-5004)	CMCD v2 (CTA-5004-B)
Transmission modes	Request Mode only	Request, Response, and Event Modes
Data delivery	Tightly coupled to media segment requests	Decoupled, and can trigger via timers or specific events
Reporting endpoints	Sent back to the delivering CDN	Multi-endpoint, and can send directly to external analytics
Player state	Implicit; inferred from buffer and bitrate	Explicit sta key, for example: Playing, Paused, Rebuffering
Network metrics	Limited	Includes TTFB, TTLB, and HTTP response codes
Primary focus	CDN log enrichment & basic edge optimization	Real-time observability, dynamic Multi-CDN steering
Analytics dependency	Usually requires heavy, proprietary SDKs alongside	Capable of acting as a lightweight, generic telemetry replacement

Additional keys for CMCD v2

There are several keys newly supported with CMCD v2:

df: Dropped frames
e: Event trigger
ltc: Live latency
msd: Media start delay
pt: Playhead time
rc: Response code
sn: Sequence number
sta: Player state
ts: Timestamp
ttfb: Time to first byte
ttld: Time to last byte
url: Request URL

Add CMCD log data support

CMCD data is gathered automatically for visibility purposes, and you can set up a CMCD log stream using DataStream 2.

When creating your stream, use the following guidelines:

The selected property must use Adaptive Media Delivery (AMD)
When selecting a data set, you can select one or more of the available log sets under Common media client data: CMCD, Delivery type, Delivery format, and Media encryption

Below is a sample extracted, and aggregated, payload from a CMCD v1 log:

//1.0@U/bl=9600,cid=%22ffmpeg-2s-synthetic%22,d=2000,dl=9600,mtp=6200,nor=%22segment_23.ts%22,ot=av,sf=h,sid=%22773a7679-225d-4c72-ae89-03fdf0406343%22,st=v,tb=0

And for CMCD v2:

//2.0@U/cid=%22ffmpeg-2s-synthetic%22,d=2000,dl=0,mtp=10000,nor=(%22segment_1.ts%22%20%22segment_2.ts%22%20%22segment_3.ts%22),ot=av,sf=h,sid=%22ce7d0e6b-d9f4-4547-b412-4c08a1f3cd3c%22,st=v,sta=p,su,tb=0,v=2

For specifics on setting up a stream for CMCD data, see our DataStream 2 documentation on Data set parameters.

Configure prefetching

Set up your media player to send CMCD data from a requesting client. Data can be sent to Akamai using either of these methods:

One or more custom HTTP request headers
An HTTP query argument

A single request shouldn't include both CMCD headers and query arguments. If one does, Akamai ignores the query argument.

Guidelines are laid out in the CMCD specification. Look to it for the latest recommendations on transmitting information in your requests.

📘
CORS-restricted clients and CMCD data
A CORS-restricted client (such as a web application running inside a browser) has to make a preflight OPTIONS request against a CDN before it can request an object that includes custom CMCD headers. The HTTP query argument method is recommended for browser clients, while the custom HTTP request header method is recommended for all other clients.

Client-side data for prefetching

To support segment prefetching, the CMCD data sent by your media player needs to include the buffer length (bl) key, along with the next object request (nor) and (optionally) next range request (nrr) keys:

Key Description

Buffer length (bl) This is the buffer length for your player. AMD uses bl parameter feedback to ensure effective prefetching based on the momentary buffer fill grade. If the bl is exceeded, CMCD prefetching is disabled for client players, leaving them with a comfortable amount of buffered content.

Key	Description
Buffer length (`bl`)	This is the buffer length for your player. AMD uses `bl` parameter feedback to ensure effective prefetching based on the momentary buffer fill grade. If the `bl` is exceeded, CMCD prefetching is disabled for client players, leaving them with a comfortable amount of buffered content.
Next object request (`nor`), or Next range request (`nrr`)	Depending on how your player is requesting your segmented config, you need to include one or both of these keys. `nor` can be used by itself, and `nrr` can only be used when combined with `nor` (CMCD v1 only). `nor`. This is the relative path to the next object. Include this if you store your media segments as individual objects. AMD constructs the prefetch URL for a segment that's relative to the requested segment. These points apply to CMCD prefetch requests with the `nor` key: URL backtracking is supported with advanced metadata. The extensions in the URL sent by the client player that initiates the prefetch and the `nor` prefetch URL need to be the same. Likewise, the file name in the `nor` field should match the triggering request’s file name. Prefetch is applied only for HLS and DASH URLs. Multiple URL prefetch for `nor` is supported by CMCD v2. `nrr`. This applies if the next request will be a partial object request. Its string designates the byte range to be requested. You'd include this if the target media is stored in one large contiguous object and byte-range requests are used to get individual segments. CMCD v1 (required): The `nrr` key must be used with the `nor` key where the file name requested in the `nor` key is the same as the one included in the triggering request. CMCD v2: `nrr` is merged with `nor` for CMCD v2 and is not required. Range information formerly specified with `nrr` is now represented with the `r` parameter (in bytes) within the `nor` key. For example: `nor=("segment8.ts";r="2000000-4000000" "segment8.ts";r="2000000-8000000" "segment8.ts";r="2000000-10000000")` 📘 Partial object caching and prefetching The minimum object size for partial object caching is 10 MB. Anything smaller and the entire object will be prefetched, which defeats the purpose of prefetching. There is a 10-fragment limit for prefetching. If the byte range in your request exceeds this, prefetching won't be applied. See the CMCD specification for instructions on including these values in a request from your media player.

Next object request (nor), or
Next range request (nrr)

Depending on how your player is requesting your segmented config, you need to include one or both of these keys. nor can be used by itself, and nrr can only be used when combined with nor (CMCD v1 only).

nor. This is the relative path to the next object. Include this if you store your media segments as individual objects. AMD constructs the prefetch URL for a segment that's relative to the requested segment.
These points apply to CMCD prefetch requests with the nor key:
- URL backtracking is supported with advanced metadata.
- The extensions in the URL sent by the client player that initiates the prefetch and the nor prefetch URL need to be the same. Likewise, the file name in the nor field should match the triggering request’s file name.
- Prefetch is applied only for HLS and DASH URLs.
- Multiple URL prefetch for nor is supported by CMCD v2.
nrr. This applies if the next request will be a partial object request. Its string designates the byte range to be requested. You'd include this if the target media is stored in one large contiguous object and byte-range requests are used to get individual segments.
- CMCD v1 (required): The nrr key must be used with the nor key where the file name requested in the nor key is the same as the one included in the triggering request.
- CMCD v2: nrr is merged with nor for CMCD v2 and is not required. Range information formerly specified with nrr is now represented with the r parameter (in bytes) within the nor key. For example:
```
nor=("segment8.ts";r="2000000-4000000" "segment8.ts";r="2000000-8000000" "segment8.ts";r="2000000-10000000")
```

📘
Partial object caching and prefetching

The minimum object size for partial object caching is 10 MB. Anything smaller and the entire object will be prefetched, which defeats the purpose of prefetching.

There is a 10-fragment limit for prefetching. If the byte range in your request exceeds this, prefetching won't be applied.

See the CMCD specification for instructions on including these values in a request from your media player.

Delivery-side requirements

Set up your AMD property to receive CMCD data based on how the client is sending it. You can do this with either custom HTTP request headers or query arguments.

Use custom HTTP request headers

There are multiple methods you can use to incorporate support for CMCD headers.

Method	Description
Create a new AMD property	If this is a new property, support for CMCD is automatically added to the Default CORS Policy Rule. The `CMCD-Request`, `CMCD-Object`, `CMCD-Status`, and `CMCD-Session` request headers are included in the New Header Value field for the Modify Outgoing Response behavior that's set up for Access-Control-Allow-Headers.
Create a new version of an existing AMD property	If the property contains the Modify Outgoing Response Header behavior, either standalone or as part of the Default CORS Policy Rule, Akamai automatically adds the `CMCD-Request`, `CMCD-Object`, `CMCD-Status`, and `CMCD-Session` request headers if the following apply: Action is set to Modify or Add. Select Header Name is set to Access-Control-Allow-Headers. New Header Value is not set to `*`. This is a wildcard indicating all headers.
Add a separate instance of the Modify Outgoing Response Header behavior	If you're not employing the Default CORS Policy rule, you can include the Modify Outgoing Response Header behavior in another rule. The behavior's settings need to be configured as follows: Action is set to Modify or Add. Modify replaces any Access-Control-Allow-Headers in a request with what's set in New Header Value; Add appends what's set there to any Access-Control-Allow-Headers received in a request. Select Header Name is set to Access-Control-Allow-Headers. New Header Value. Enter the following CMCD headers: `CMCD-Request`, `CMCD-Object`, `CMCD-Status`, and `CMCD-Session`.

Use query arguments

To use query arguments, you need to set up the Cache Key Query Parameters behavior while avoiding CMCD headers.

Task	Description
Configure the Cache Key Query Parameters behavior	Make sure CMCD query arguments are not cached. CMCD data changes with each request. Caching these arguments increases the load on your origin server and affects performance. The Behavior field in your Cache Key Query Parameters behavior in your delivery property should be set up using either of these methods: Exclude all parameters (recommended). This is the default setting for this behavior in a new property. Include only specified parameters. If you need to cache some of your query arguments, set Behavior to this setting, and set Parameters to only the query arguments you need cached. Make sure all CMCD-related query arguments are left out.
Avoid CMCD headers	Ensure that requests from the player don't include CMCD headers, because they'll take precedence.

Task

Description

Configure the Cache Key Query Parameters behavior

Make sure CMCD query arguments are not cached. CMCD data changes with each request. Caching these arguments increases the load on your origin server and affects performance. The Behavior field in your Cache Key Query Parameters behavior in your delivery property should be set up using either of these methods:

Exclude all parameters (recommended). This is the default setting for this behavior in a new property.
Include only specified parameters. If you need to cache some of your query arguments, set Behavior to this setting, and set Parameters to only the query arguments you need cached. Make sure all CMCD-related query arguments are left out.

Avoid CMCD headers

Ensure that requests from the player don't include CMCD headers, because they'll take precedence.

Add CMCD segment prefetch support

To include support for prefetching, add the Common Media Client Data support behavior to your AMD property, and set the CMCD Segment Prefetch option to On. Add the behavior to the same rule tree where you configured other settings for CMCD support:

The same rule. Its match criterion needs to be met in a request to apply all of the CMCD-specific settings you defined.
A child rule. The parent-level rule contains settings to apply CMCD support via headers or query strings. The child rule can be set to have its own unique match criterion so that only those requests apply segment prefetching.

Test your setup

Make sure your player supports CMCD, and thoroughly test your prefetching configuration on the staging network. Verify interactions between your player and origin server before fully enabling your property on the production network.

Caveats and known issues

Review these points before adding CMCD prefetching to your property:

Issue	Detail
CMCD prefetching takes precedence	If you've set up Origin-assist prefetch, CMCD prefetching will override it.
CMCD prefetching may significantly increase log sizes	Log entries can increase from 300 bytes in size, up to 512. Take this into consideration when gathering and storing log data, for example, with DataStream 2.
Custom prefetch solutions may create issues	If you have a custom solution in place, for example, through advanced metadata, and you apply CMCD prefetching, this can lead to duplicate prefetch requests. This can create a higher load on your origin and slow delivery. Talk to your Akamai account team if you have a custom configuration.
CMCD prefetches can amplify a DOS attack	This can happen if prefetching inadvertently triggers a prefetch of a much larger object. For example, if a proper range isn't specified, a byte range request could request a full VOD asset that's supposed to be segmented. Make sure your player is properly requesting byte ranges to avoid this.
CMCD prefetching isn't supported with Media Encryption for DASH	N/A