Simplified URL tags

Dynamically serving creatives into HTML email or newsletters is not supported by DoubleClick.

You can use simplified URLs in the following cases:

  • Environments where devices don't support JavaScript tags.
  • As redirects for trafficking on other ad servers.
  • Applications where an SDK is not provided, such as BlackBerry.

Simplified URLs follow this format:

  • For non-SSL:
  • For SSL:
Simplified URLs have some limitations:
  • They don't work with AdSense, Ad Exchange, or AdMob dynamic allocation.
  • You may not be able to use cookies from apps for tracking or other purposes.
  • They are not eligible for Active View reporting.

The sections below describe the contents of the request-type and parameters sections of these URLs.

Request types

DFP supports the following values for the request-type section of the URL.

Request type Description
ad If the request URL contains /ad, the ad server returns an image creative or an internal redirect to an image creative.

Only used for creatives that are images or redirect to images. If there is any custom code (HTML, XML, etc.) nothing will be returned for this call.

Generally paired with a jump tag for handling clicks.

Example tag:

<img src="">
jump If the request URL contains /jump, the ad server logs an ad click and returns a redirect to the landing page of the creative.

Example tag:

<a href="">

<img src="">
adx Returns the raw code of the creative trafficked in DFP.

If the request URL contains /adx, the ad server returns returns a creative without any rendering code wrapping it. This is useful when there is special rendering that needs to be handled by the client, such as for a video player.

Example request URL:

A request URL containing /clk is used by the ad server to log an ad click for the specified ad. This is useful for logging clicks for ads that are not served by DFP.

Note that /clk:

  • is only intended for use with click-tracking line items.
  • is only supported by DFP Premium.


Example tag:

<a href=""></a>

Base URL

The base URL for all ad requests is SSL requests should use



DFP supports the following values for the parameters section of the URL.

Parameter Request type Required/Optional Description
iu ad

required The code of the ad unit of the DFP network. To include multiple level ad units, use the slash (/) as a separator between different levels.

sz ad
required Creative size specification. To include multiple sizes use the pipe (|) character as a separator between them.

sz=320x50 for a single size
sz=320x50|300x50 for multiple sizes
t ad
optional Slot-level key-value pairs. Each key and value is separated by the equal sign = character; key-value pairs are separated by the ampersand & character. Each key and value should be URL encoded individually and then the entire string should be URL encoded. For example:

t=genre%3Daction%26movie=Mr+%2526+Mrs+Smith would assign the key "genre" to the value "action" and the key "movie" to "Mr & Mrs Smith". (Note the & is singly encoded to %26 where it separates the key-value pairs, and doubly encoded to %2526 when it occurs within a value).

Use excl_cat as a special key for competitive exclusions.

Competitive exclusion examples:
  • Just exclusion labels: t=excl_cat%3Dairlines
  • Including other key values: t=interest%3Dsports,news,games
The following characters are not permitted in keys or values: " ' ! + # * ~ ; ^ ( ) < > [ ] = . So for example, the query t=a%3Db%252Bc (setting the key "a" to the value "b+c") doesn't work. Spaces are allowed in values (escaped as %20 or +) but not in keys.




c ad
required Correlator/cache-busting parameter. This is a random number (can only include 0-9; letters are not permitted) that's used to ensure that a fresh call to the ad server happens every time the page loads, avoiding discrepancies in impression counts. Ad requests work without the correlator/cache-busting parameter, but omitting this parameter can lead to under-counting of impressions, negatively affecting both the advertiser/client and the publisher sites/apps.

m adx optional Set the mime-type value on the HTTP header to a desired value.

submodel ad

optional Mobile device hardware information (model), which overrides the automatic detection done by the ad server.


Possible submodel values are listed below. Note that you must encode the submodel value, so iPhone1,1 would be iPhone1%2C1.
  • iPhone (first gen): iPhone1,1
  • iPhone 3G: iPhone1,2
  • iPhone 3GS: iPhone2,1
  • iPhone 4 (GSM): iPhone3,1
  • iPhone 4 (GSM): iPhone3,2
  • iPhone 4 (CDMA): iPhone3,3
  • iPhone 4S: iPhone4,1
  • iPhone 5 (GSM and LTE): iPhone5,1
  • iPhone 5 (CDMA and LTE): iPhone5,2
  • iPhone 5c: (GSM and CDMA): iPhone5,3
  • iPhone 5c (GSM and CDMA): iPhone5,4
  • iPhone 5s (GSM and CDMA): iPhone6,1
  • iPhone 5s (GSM and CDMA): iPhone6,2
  • 1st Gen iPod: iPod1,1
  • 2nd Gen iPod: iPod2,1
  • 3rd Gen iPod: iPod3,1
  • 4th Gen iPod: iPod4,1
  • 5th Gen iPod: iPod5,1
  • 1st Gen iPad (Wi-Fi): iPad1,1
  • 1st Gen iPad (AT&T): iPad1,2
  • 2nd Gen iPad (Wi-Fi): iPad2,1
  • 2nd Gen iPad (AT&T): iPad2,2
  • 2nd Gen iPad (Verizon): iPad2,3
  • 2nd Gen iPad (Wi-Fi): iPad2,4
  • 3rd Gen iPad (Wi-Fi): iPad3,1
  • 3rd Gen iPad (Verizon): iPad3,2
  • 3rd Gen iPad (AT&T): iPad3,3
  • 4th Gen iPad (Wi-Fi): iPad3,4
  • 4th Gen iPad (AT&T): iPad3,5
  • 4th Gen iPad (Verizon): iPad3,6
  • iPad Mini (Wi-Fi): iPad2,5
  • iPad Mini (AT&T-US; GSM & LTE 4, 17): iPad2,6
  • iPad Mini (Verizon-World; GSM, DMA & LTE 1,3,5,13,25): iPad2,7
  • iPad Mini Retina (Wi-Fi): iPad4,4
  • iPad Mini Retina (LTE): iPad4,5
  • iPad Air (Wi-Fi): iPad4,1
  • iPad Air (LTE): iPad4,2
u_w ad

optional Mobile device screen width, which overrides the automatic detection done by the ad server.

u_h ad

optional Mobile device screen height, which overrides the automatic detection done by the ad server.

id clk Required Ad ID id=12345
tile ad
Required if multiple ad tags use the same ad unit code on the same page

Specifies the position of an ad tag on a webpage. The value should be a unique integer. For an easier implementation, we recommend a value counting up. You shouldn't pass tile= within the &t= parameter as key-values.


<img src="">

<img src="">

mob ad

Indicates that this is a mobile ad request.

mob=js (This is the only accepted value.)


Custom environments for image and non-image ads

You can use the adx form of the simplified URL to request any ad from DFP. Environments that could request ads from DFP include the following:

  • Windows Phone 7 or BlackBerry applications where there is no DoubleClick SDK.
  • iOS and Android applications written in a non-native language such as C++.
  • Other custom environments such as Connected TVs or set-top boxes.

These environments should adhere to the following principles to request an ad from DFP:

Be sure to set a valid user agent (User-Agent) in the request header to ensure that targeting will work properly. In addition, we recommend performing a small load test (1-2% of anticipated volume) to validate the request before going live.
  • Ensure that the environment in question can handle Rich Media behaviors. Things to consider include running JavaScript, expansion, and so on.
  • Use one of the available libraries in this environment to make a HTTP request to DFP.

  • Inspect the response status to make sure that the request was well formed. DFP Mobile will return a HTTP 200/OK if the request is well formed.
  • If an ad is found, DFP returns the raw creative code associated to ad exactly as trafficked.
  • If an ad is not found, DFP returns a 200/OK with an empty response.

A call that uses adx could look like this:

A call that uses both jump and ad could look like this:

<a href="">
<img src=""></a>

Delayed impressions

DFP supports delayed impressions for use cases such as pre-caching ads. Contact your Technical Account Manager for more information.

Was this article helpful?