Clear search
Close search
Google apps
Main menu

Simplified URL tags

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 have some limitations:
  • They don't work with AdSense, Ad Exchange, or AdMob dynamic allocation.
  • Dynamically serving creatives into HTML email or newsletters is not supported.
  • You may not be able to use cookies from apps for tracking or other purposes.
  • They are not eligible for Active View reporting.

We recommend using the DFP Tags Generator to generate simplified URL tags.

Simplified URLs follow this format:

  • For non-SSL:
  • For SSL:

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. Note that DFP assumes that the /jump request came from the same browser and cookie as the /ad request, and that the value of the "c" parameter was the same in the /ad request. This is because at click time, this information is used to match the click request with the ad request in order to process the click.

Example tag:

<a href="">

<img src="">

Returns the raw code of the creative trafficked in DFP.

If you're loading the adx request type on the web, you must load it in an <iframe> so it can then execute the raw code that is returned.

If the request URL contains /adx, the ad server 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>

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.




Each key within a set of key-values must be unique; if you provide the same key more than once, only one of the associated values is taken into account.

c ad

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.

Note that for the /jump request to properly redirect to the correct landing page, the value of the parameter has to be the same as the one used in the /ad request.


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
  • iPhone 6 : iPhone7,2
  • iPhone 6 Plus: iPhone7,1
  • iPhone 6s: iPhone8,1
  • iPhone 6s Plus: iPhone8,2
  • iPhone SE: iPhone8,4
  • iPhone 7: iPhone9,1
  • iPhone 7 Plus: iPhone9,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. 

To use delayed impressions with simplified URLs, add the parameters d_imp=1 and d_imp_hdr=1 to the ad request. The view URL is returned in the Google-Delayed-Impression header and the third-party impression URL (if present in the creative) is returned in the Google-3rdParty-Delayed-Impression header. You can explicitly disable delayed impressions using d_imp=0.

When using third-party creatives, custom creatives, and creative templates, be careful not to report an impression twice. If the view URL macro is used in the creative, then it should not be used separately from the header; and vice versa.

Was this article helpful?
How can we improve it?