Used to retrieve an ad specifically crafted for the target medium. Required for non-MMA banners. (see below). List of acceptable adunits are mma (default), banner, inter, tinter, splash (sdk only), vastlinear (only supported on the /vast endpoint), vastnonlinear (only supported on the /vast endpoint).
|size||Ad Size||Specifies the size of the ad you want returned. Required for non-MMA banners or where an explicit mma size is required. See below for list of acceptable sizes and the adunits.|
Latitude location of the user making the ad request. Note the "ll" parameter is the preferred method in which to supply geolocation information. Please pass the most accurate location known, which is generally GPS data pulled from the device.
Longitude location of the user making the ad request. Please pass the most accurate location known, which is generally GPS data pulled from the device.
Latitude and longitude of the user, encoded. The location of the user at the time of the advertising request. Availability of this parameter is, of course, platform- dependent and optional. It must be excluded if the user does not consent to provide location information in some manner. However, if location is available, it should be included. The parameter name is two lower-case Ls, and is encoded in a special format (described later in this document). The location's resolution does not have to be particularly precise, however a minimum target of 3km is recommended. Also, for a particular user session, it's sufficient to obtain the location only once. I.e., location does not need to be looked-up for every ad request during a session. Please pass the most accurate location known, which is generally GPS data pulled from the device.
|latlong||Lat/Long (Plain-text)||Latitude and longitude of the user, plain text. The value of this parameter should adhere to the format <latitude>,<longitude>. The data supplied here should adhere to the same rules as the above lat/long parameters, this is simply a convient method of providing location for those integrations where it is not possible to split the lat/long into separate parameters.|
|la||Location Age||Age of the supplied location (either lat/long or ll), in minutes. Please omit if the age is unknown.|
|lacc||Location Accuracy||Accuracy of the supplied location (either lat/long or ll), in meters. Please omit if the accuracy is unknown.|
Zip or Zip+4 postal code describing the location of the content being viewed (not necessarily the postal code of the user's location). The value should be a zero leading 5 digit postal code. Examples: 07048, 21228, 90210-1234,
|ip||Device's IP Address||IP address of the client/device on which the requested ad will be displayed. Mandatory for server-side requests; optional when requests come directly from a user's device.|
|age||Age||The user's age used for demographic targeting.|
|zip||Zip||The user's zip code.|
|gender||Gender||The user's gender used for demographic targeting. Acceptable values: "male", "female", "m", "f". If unknown, do not pass the key/value.|
The site on which the ad is presented. On mobile web, this would be the hostname of the mobile site; in the app world, it's a unique key that identifies the app (e.g., the iOS bundle ID).
position in which ad is to appear on page. Acceptable values are "top","inline", and "bottom"
semi-colon separated list of arbitrary key-value pairs. Example: color=blue;shape=square; (note, the value should be url encoded, as it is a query parameter value)
User Agent should be passed in the header. If that is not possible, pass an encoded user agent string here.
|model||Device Model||Model information for the requesting device when otherwise unavailable from the user agent (i.e., iOS, primarily). An iPhone 6 is referenced as "iPhone7,2" and an iPhone 6 Plus is"iPhone7,1". Use the identifier as prescribed in the following list: https://theiphonewiki.com/wiki/Models|
|hwmdl||Hardware Model||Manufacturer's designation for the device hardware model. At present, this should only be populated for iOS using the "hw.model" sysctl. For example, the GSM iPhone 4 would use the value "N90AP". Refer to the internal name designed in this list: https://theiphonewiki.com/wiki/Models On iOS, this parameter is preferred to the "model" parameter, but should be omitted if the information is unavailable.|
A Verve-assigned identifier assigned to the device type making the request. It is used to override the "User-Agent" HTTP request header. Note that this parameter is typically only used in conjunction with the Verve Registration API for mobile client applications. If blank, omitted, or an unknown value, the "User-Agent" HTTP request header is used to identify the device type. Ignore unless directed otherwise.
display block id
Ignore unless directed otherwise.
partner module id
Ignore unless directed otherwise.
disable iframe wrapping
If this parameter is set to false, responses from certain ad networks will not be wrapped within an iframe. This parameter should not be relied on to ensure that there is never or is always an iframe response. This is generally an internal Verve parameter for testing. Ignore unless directed otherwise.
Define the creative capability of your request.
"cc=1": for MRAID1 support
"cc=2": for MRAID2 support (From the client Apps this value will be just integer 2)
|nwk||Ad Network||char: The production ID of the ad network (ex: dfp even in staging would be '41'). Skips the chain resolution and directly calls the network.|
|flt||Flight||char: Unique flight identifier of some sort (passed through to ad network DSL) Requires nwk parameter is present. Identifies the flight id this call will use for creative tag retrieval.|
|ctg||Creative Tag||char: Unique creative identifier of some sort (passed through to ad network DSL) Requires nwk and flt parameters. Identifies the creative id this call will use for creative tag retrieval.|
s : requires secure creative
ns : requires insecure creative
x or n : secure creative agnostic (can handle both secure or unsecure)
|ou||Referer Override||The ou parameter should be used for mobile web requests, specifying the page url that the ad was requested on. Note: AdCel will use the referer header value for this, if this override is not specified.|
When using the Verve Registration API, typically the “b” (partner keyword), “p” (portal keyword), and “ua” or “dguid” parameters are pre-populated in the AdCel base URL value returned upon successful registration. Other values such as “pm” (partner module ID), “db” (display block ID), and “c” (content category ID) are available from the Content API in either the content hierarchy or listing.
Examples of headers that are meaningful for ad targeting include: "Accept", "Accept-Encoding", "Accept-Language", "msisdn", "ReferrerReferer", "User-Agent", and "x-up-subno".