JSON Fields

These fields should be used in preference to the other fields described in this document wherever possible. Through a more complex structure we are able to more accurately represent the industry's available deals and so better communicate them to customers, leading to improved conversion.

Note: The following standard fields should be downloaded alongside all the below fields as they aren't duplicated here:

Note: Majority of the JSON fields are not compatible with Landline, Broadband and TV deals except for [deal_type_json];[deal_extras_json]; [deal_costs_json] and [deal_retailer_json].

device_product_json (nvarchar) - non-null

The "product" sits at the highest level of our product tree, and describes a conceptual product like an "iPhone" or a "Galaxy" phone. It belongs to a manufacturer/brand, and has a product type.

Note: Using the [product_id] you can group all "Galaxy" products together or all "iPhone" products together (for example).

Note: The [product_name] can be appended to the [product_brand] to arrive at a more complete product name: [product_brand] + [product_name] = "Apple iPhone".

Example (Nokia Lumia 735 Black):

Nested fields

  • product_id - Unique ID.
  • product_name - Name of product.
  • product_brand - The primary product's branding.

    Note: this could be different from the manufacturer, so for instance a "Google Nexus 6" is branded "Google" but is manufactured by Motorola. Wherever possible we will specify the branding rather than the manufacturer. Similarly the "EE Kestrel" is manufactured by Huawei, but will be branded "EE" in our data.

  • product_brand_id - The brand ID is unique and will persist even if a brand name changes (for instance RIM changed to BlackBerry in the past).
  • product_type - A catergorised text-name for the product. See Product Type valid values for insight to what values you can expect.
  • product_type_id - These IDs are unique and persist even if a product type's name changes.

device_product_version_json (nvarchar) - non-null

The "product version" sits below the "product" in the product hierarchy and describes at a reasonably high level the product in the range. Examples would be (Apple iPhone) "5s" or (Samsung Galaxy) "S4". Using the [product_version_id], all the different colours and capacities of Samsung Galaxy S4 could be grouped together, or we can filter on just Apple iPhone 5C, and see all the colours and capacities that are available.

The [product_version_name] can be appended to [product_name] and [product_brand] to arrive at the complete product version name: [product_brand] + [product_name] + [product_version_name] = "Apple iPhone 5S".

Example (Nokia Lumia 735 Black):

Nested Fields

  • product_version_id - Unique ID.
  • product_version_name - text name, for example "S4". This can be empty in cases where the [device_product_json] - product_name field sufficiently describes the product (so, there probably aren't multiple versions of this product as is the case with iPhones).

device_product_edition_json (nvarchar) - non-null

The "product edition" is the lowest level of the product hierarchy and describes a specific product being sold. Examples would be (Apple iPhone 5S) "16GB White" or (Samsung Galaxy S4) "32GB Blue".

Note: in practice, the capacity and colour will act as the defining features of this edition (separating it from other editions under the same [product_version]), but in future other defining features could emerge.

Note: the capacity and colour are described in a structured way in the [device_features_json] field so there is no need to parse the [product_edition_name] field.

The full product name can be derived by using the [product_brand], [product_name], [product_version_name] and [product_edition_name] together: e.g. "Apple iPhone 5S 16GB White".

Example (Nokia Lumia 735 Black):

Nested Fields

  • product_edition_id - Unique product edition ID.
  • product_edition_name - Product edition name, for example "16GB White". This can be empty in cases where the [device_product_json] - product_name and/or [device_product_version_json] - product_version_name fields adequately describe the product (so there probably aren't multiple editions (colours, capacities, etc.) of this product, as there are with iPhones).
  • reseller_product_edition_id - Unique identifier that defines the product at a reseller level (for instance there might be one reseller_product_edition_id for a New product, and another for Refurbished models). No two resellers will ever share [reseller_product_edition_ids], but they will share [product_id], [product_version_id], and [product_edition_ids].

device_images_json (nvarchar) - non-null

More image types could be added in future. A note about images.

Example

Nested Fields

  • primary_thumb - Thumbnail image URL.
  • primary_large - Large image URL.

device_features_json (nvarchar) - null

This field contains product attributes that can be used for filtering and grouping of products.

Note: the values can be empty for product types where the feature does not apply (for instance Televisions don't have a SIM Card Type), and as a result the key may not appear. See Specifications and Features availability for more information.

Example

Nested Fields

  • colour - This is the device's 'marketing colour'. It is unlikely to be generic enough to use for filtering or grouping but could be used as a secondary filter if needed.
  • colour_group - Used for filtering/grouping. The list of acceptable values here has been reduced to a sensible minimum. You won't find any "ruby red" or "sunset orange" style values here, just "red" and orange". See Colour Group valid values for insight to what values you can expect.
  • max_data_standard - The device's maximum available data standard. Valid values are "2G", "3G", "4G" and "5G".

    Note: this does not relate to the Network or tariff being purchased (as in, it's entirely possible to buy a 3G contract for a 4G device). The contract's data standard is described in [tariff_allowances_json] - cellular speed.

  • condition - Is either "New" or "Refurbished" and should be used for grouping/filtering.
  • condition_grade - Is either blank (the product is either "New" or "Refurbished") "Grade A" (excellent condition), "Grade B" (could have some light scratches and marks), and "Grade C" (more visible marking / visibly used).
  • condition_friendly - This should be displayed on your page in place of "New" or "Refurbished" if available and represents the merchant or Network's preferred wording (for instance EE prefer "Good As New" instead of "Refurbished"). In some cases there could be legal implications, so [condition_friendly] should be displayed in place of [condition] wherever possible.

    Note: where there is no 'friendly' description is available, the standard description is passed through in its place.

  • sim_type - Valid values for this are currently limited to: "Combi SIM" (used for SIM cards only), "Standard SIM", "Nano SIM", "Micro SIM". Note that "Micro SIM" and "Standard SIM" devices can be used with "Combi SIM" SIM Cards.
  • capacity - The device's internal storage rounded up or down to the nearest GB (in line with the product's marketing, where possible).
  • os - The device's operating system, where known. Valid values are currently: "Android", "Apple iOS", "Badu", "BlackBerry", "N/A", "Proprietary", "Tizen", "Windows".
  • megapixels - Text describing the number of megapixels the device's camera has available.

    Note: older cameras can show as having a decimal value of less than 1 megapixel ("0.3" is VGA, for example), but all newer cameras will be rounded to the nearest megapixel. If no camera is available, this field will contain the text 'None'.

device_specifications_json (nvarchar) - non-null

It is expected that specifications will not be used for filtering or grouping because many of the specifications are free text fields.

Example

Nested Fields

Note: that many of the fields below have already been described in Standard Fields - specifications. Those fields that are unique to the JSON representation have been described below.

Note: sub-fields could still be empty if the relevant device does not have a certain specification. Where this is the case, the key will not be included. This is because not all specification types apply to all products. See Specifications and Features availability for more information.

  • display_resolution - This field could be used for filtering/grouping devices if required as the number of different resolutions on the market is relatively small.
  • display_size - The values here are always consistent (as in, we don't mix 2.1" and 2.1 inches).
  • display_type - A text description of the type of display (like "Super AMOLED", etc.).
  • primary_camera_flash - Could be used for grouping as the number of available values is limited.
  • primary_camera_resolution - The device's primary camera resolution in W x H pixels. This field could be used for grouping if required, but the megapixels value in [device_features_json] is probably more useful.
  • internal_memory - The amount of internal storage the device ships with. This value can be quite specific, and will end with either "MB" or "GB".
  • memory_card_slot - The type of memory card slot, and the maximum card capacity (if known.
  • processor - Details of the device's processor (where known).
  • 2g - A list of 2G frequency bands on which this device can operate
  • 3g - A list of 3G frequency bands on which this device can operate
  • 4g - A list of 4G/LTE frequency bands on which this device can operate
  • bluetooth - The bluetooth version number will always be at the beginning of the string and will be a decimal like "2.0", "2.1", "4.2". This will be followed by any text describing the additional/supported Bluetooth features of the device as advertised by the manufacturer.
  • gps - The supported GPS standards of the device.
  • wifi - The supported WIFI standards of the device.
  • talk_time - Will contain text in the format "Up to x hours". Talk time is always rounded up to the nearest hour for simplicity and to allow for easier filtering/grouping.
  • secondary_camera - Details of the device's secondary or rear-facing camera if available.
  • weight_grams - This can be used for grouping/filtering in a range, as the value is just a simple integer.
  • dimensions - Always in the format "H x W x D mm".
  • chipset - Details of the device's chipset (where known).
  • battery_type - States whether the battery is removable or not, and the primary battery technology used (like "Li-Ion", for example)
  • ip_rating - Describes the device's weatherproofing capabilities along with its IP rating where known.

network_details_json (nvarchar) - null

General details of the Mobile Network Operator with whom the customer will have a contract.

Example

Nested Fields

Note: In cases where the product does not belong to a Network (i.e. is SIM-Free or not a cellular device), the [name] and [company_id] values will be populated consistently as "No Network" and "76" respectively, but the other values can be blank. See also Skipping fields based on [network_details_json].

  • name - Name of the Network
  • company_id - The unique ID of this company. This could be the same as the retailer ID where the Network and the Reseller are the same (for instance O2 direct).
  • logo_url - The URL containing the Network's logo for use in comparison lists or outbound links
  • coverage_url - The Network's coverage checker URL.

    Note: that this is not always available for MVNOs.

  • terms_url - The Network's general terms and conditions URL. Note that this could be different from the retailer's own terms and conditions URL (see [deal_retailer_json] for this). Where a customer is buying a Network's products from a Retailer, the Retailer's terms are more likely to be of use to the customer.
  • description - A short description of the network and its primary benefits.

tariff_group_details_json (nvarchar) - non-null

Tariffs are often grouped by the networks. The tariff group allows for filtering/grouping of tariffs. Similar tariffs often have the same benefits, call charges etc. See also Displaying tariff information.

Example

Nested Fields

Note: In cases where the product is sold without a contract (as in the case of SIM-Free phones, or some wearable devices), the [tariff_group_description] field can be empty. In all other cases it should be populated. See also Skipping fields based on network_details_json.

  • tariff_group_id - simple integer, can be used to group similar tariffs together.
  • tariff_group_description - a description of the tariff and its benefits.
  • tariff_group_promo_info - should there be any promotional information to display, it will be contained here.

    Note: it is important to display promotional information when it is available as it could materially affect the product the customer is purchasing. This field can (and often will) be empty.

tariff_details_json (nvarchar) - null

Contains details of the specific tariff being purchased. See also Displaying tariff information.

Example

Nested Fields

Note: To determine whether or not the device comes with a contract you can check for the value of "11" in [tariff_details_json] - tariff_type_id or "76" in [network_details_json] - company_id. See also Skipping fields based on network_details_json.

Note: The tariff_type_id gives no indication of whether the deal is a "SIM Only" type deal (i.e. without a device included). In order to determine whether the deal comes with or without a device, check the [device_product_json] - product_type_id field for a value of 2 (SIM Card).

  • tariff_id - can be used to link the same tariff across multiple handsets or even retailers (An O2 Big Bundle sold by O2 will have the same ID as an O2 Big Bundle sold by mobiles.co.uk)
  • tariff_name - describes the tariff being sold
  • tariff_type_id - See Tariff Types for valid values.
  • tariff_type - This contains the type of contract being sold to the customer (also repeated in custom3).
  • tariff_term - integer - the number of months the customer is tied into a contract with the network.
  • tariff_term_friendly - the network's preferred wording for the contract length. In some cases Networks will legally have to refer to 1 month contracts as "30 day" (since not all months have the same number of days). Wherever a 'friendly' contract length is provided, this should be displayed on-site, with the [tariff_term] field used only for filtering/sorting/grouping. Where this field is empty, you should use the [tariff_term] field instead.
  • tariff_promo_info - should there be any promotional information to display, it will be contained here.

    Note: it is important to display promotional information when it is available as it could materially affect the product the customer is purchasing. This field can (and often will) be empty.

tariff_allowances_json (nvarchar) - non-null

Contains details of all the allowances that come with this tariff. See also Displaying tariff information.

Example

Nested Fields

Note: All these fields are optional, and depend on the type of contract tied to the deal (if any). To determine whether or not it's worth your code checking through this field, you can look for the presence of "11" in [tariff_details_json] - tariff_type_id or "76" in [network_details_json] - company_id. See also Skipping fields based on network_details_json.

Note: Wherever the product does come with a contract, you should find data in these fields, though exactly which ones are populated will depend on the type of contract (for instance Mobile Broadband deals don't come with minutes and texts). In most cases, it is best for your page to 'fail gracefully' - i.e. intelligently show or hide fields based on the presence of a value.

Note: In many cases Pay-as-you-go tariffs can have inclusive minutes/texts/data/etc. when purchased with an appropriate topup, so it's best not to rely on assumptions about contract types (related to the above point).

mins_details
  • cross_net_anytime (integer) - number of Cross-Network Anytime minutes
  • cross_net_anytime_qualifier - "UK" or "Roaming See Terms". Clarifies whether any international minutes are included.
  • same_net_anytime (integer) number of Same-Network minutes (if any)
  • special_numbers_see_terms (integer) number of special number minutes included in the allowance (like access to 0800 or 0808 numbers).
  • landline (integer) number of landline minutes included
texts_details
  • cross_net_anytime (integer) number of Cross-Network Anytime texts included
  • same_net_anytime (integer) number of Same-Network Anytime texts included
data_details
  • wifi_mb - Amount of wifi data included in the plan in MB.

    Note: sometimes unlimited wifi is included as a benefit of being on the network or under certain circumstances like on the london underground. This won't be represented here, but instead will be shown in [deal_extras_json].

  • cellular_mb - amount of data allowance included in MB
  • cellular_speed - the speed at which the contract can operate.

tariff_out_of_plan_charges_json (nvarchar) - non-null

Contains details of pence-per-minute or pence-per-MB style charges when the customer uses up all their inclusive allowances (or where there's no inclusive allowance). See also Displaying tariff information.

Example

Nested Fields

Note: All these fields are optional, and depend on the type of contract tied to the deal (if any). To determine whether or not it's worth your code checking through this field, you can look for the presence of 11 in [tariff_details_json] - [tariff_type_id] or 76 in [network_details_json] - company_id. See also Skipping fields based on network_details_json.

Note: Wherever the product does come with a contract, you should find data in these fields, though exactly which ones are populated will depend on the type of contract (for instance Mobile Broadband deals don't come with minutes and texts). In most cases, it is best for your page to 'fail gracefully' - i.e. intelligently show or hide fields based on the presence of a value.

  • pence_per_cross_net_min - integer
  • pence_per_cross_net_text - integer
  • pence_per_mb - integer
  • data_charge_text - string - occasionally networks don't charge per MB (sometimes a flat rate per day, for instance). Where that's the case this field will be populated and the pence_per_mb field will likely be empty.
  • pence_per_voicemail_min - integer

deal_type_json (nvarchar) - non-null

Describes the type of sale to allow appropriate filtering. Valid values are currently limited to:

Example

Nested Fields

  • deal_type_id - The ID of the deal type. This won't change so can be relied upon for filtering/grouping over time.
  • deal_type_name - The name of the deal type.

deal_extras_json (nvarchar) - null

Extras are split into high-level Groups (like "Free Gifts", or "Discounts & Loyalty", for instance), and within those groups Extras are further sub-categorised into Source Types. Everything is given a consistent ID and so Groups and Types can be grouped/filtered as required within your code. See also Displaying tariff information.

Example

Nested Fields

Note: Additional Group Types may be added in future. When they are, they will be documented here.

Note: The list of Source Types will grow and change over time as new services and types of service are brought to market. It's therefore best to build your list of Source Types based on the contents of the data feed rather than the extract above, which is provided as an example only.

  • groups (Top Level) - beneath this is an array of Extra Groups Types and their details.

    Note: Each Extra Group is contextually different, and their purposes are discussed below, though their structure is consistent.

    • id - The Extra Group type ID. This is consistent and can be used for grouping in your code.
    • text - The Group's text description acts as a key.
  • extra source type (Second Level) - beneath this is an array of Extra Source Types and their details.

    Note: Source Types allow us to subcategorise Extras. The Source Type can appear under more than one Group (for instance, allowances could be part of an inclusive service and/or a loyalty reward.)

    • id - The Extra's Source Type ID. This is consistent and can be used for grouping in your code.
    • text - The Source Type's text description acts as a key.
  • extra (Third Level) - beneath this is an array of extras and each extra's details.

    • id - The Extra's unique ID. This will never change, and if you're storing it, you could avoid re-absorbing the details of the extra next time you pull in the feed.
    • groupingId - This ID allows you to group similar Extras. In the example above, both "O2 Priority" and "O2 Tracks" have a groupingId of "M4", as they're both part of the "Entertainment freebies and discounts" Source Type. See "Interpretting the Grouping ID" for more information
    • title - a short title for the service/product being included
    • suffix - In some cases, an Extra will be time limited or there may be other exclusions that clarify important details. These will often be included in the suffix field.
    • desc - A short paragraph describing the product or service being included. We recommend having this available as a popup/mouseover or expander where it's populated (it should be in the majority of cases). The field could have escaped line breaks, so you should check for these and handle them appropriately.
    • cost - the cost of the item, if chargeable. This field will only appear where a cost exists.
    • cost_type - can be "Fixed" (a one-off payment) or "Monthly". This field will only appear where a cost exists.
    • img_url - an image URL, where available. This is currently only implemented where the source type ID is 2 ("Product"). A note about images.
Interpreting the Grouping ID:
  • Where the Source Type ID is 2 ("Product"), the groupingId will begin with a "P" followed by an integer (e.g. "P1234"). The integer refers to a [device_product_edition] - [product_edition_id], and will therefore be consistent across deals and resellers. It can be used to safely group all deals across all resellers who include (for instance) a Playstation 4 Pro.
  • Where the Source Type ID is 1 ("Allowance"), the groupingId will begin with an "A" followed by an integer (e.g. "A1234"). The integer refers to an allowance type ID. This allows you to group or filter on all deals that come with additional Text allowances or Data allowances (for instance).
  • Where the Source Type ID begins 255, the groupingId will begin with an "M" followed by an integer (e.g. "M43"). This allows you to group or filter on all deals that come with (for instance) "Trade-in Discounts", "Enhanced customer service" or "Entertainment Freebies and Discounts". In the case of Source Types beginning 255, the Source Type ID is as useful for grouping as the groupingId.

deal_retailer_json (nvarchar) - null

Contains details of the merchant (retailer) selling the deal. Note that this can be different from the Network the deal is being sold on.

Example

Nested Fields

  • name - The Retailer's trading name
  • company_id - The company's unique ID.
  • logo_url - The URL for the Retailer's logo to be used in comparison lists and outbound links
  • terms_url - The URL for the Retailers terms and conditions of sale.

deal_cost_json (nvarchar) - non-null

Contains details of the deal's pricing both including and excluding VAT. Including VAT prices should be shown for consumer deals, whereas convention dictates that business-only deals be sold at exc. VAT prices. We have included both in case you need to mix and match business and consumer deals in the same list.

See Understanding Pricing for more information.

Example

Nested Fields

Note: Where the product is not being sold with a contract (check for "76" in [network_details_json] - company_id), any monthly fields should be ignored. See also Skipping fields based on network_details_json.

Note: Any _previous fields can be empty where no previous price exists.monthly_contract_ and monthly_device_ fields will be empty where the contract isn't a split-price deal.

  • upfront_inc_vat - The deal's total upfront cost including VAT
  • upfront_exc_vat - The deal's total upfront cost excluding VAT (for business-customer deals)
  • upfront_previous_inc_vat - Where this deal has previously been sold at another price, that price will be listed here.
  • upfront_previous_exc_vat - As above but excluding VAT (for business-customer deals)
  • monthly_total_inc_vat - The deal's monthly total cost (note this field will contain the sum of the phone monthly cost and contract monthly cost where these are expressed separately, as is the case with O2 Refresh products.)
  • monthly_total_exc_vat - As above, but excluding VAT (for business-customer deals)
  • monthly_total_previous_inc_vat - Where this deal has previously been sold at another monthly price, that price will be listed here.
  • monthly_total_previous_exc_vat - As above, but excluding VAT (for business-customer deals)
  • monthly_device_inc_vat - the monthly price of the device portion of the monthly cost. This will be populated only where the device is being sold separately from the tariff (e.g. Giffgaff handsets, Tesco Mobile, O2 Refresh).
  • monthly_device_exc_vat - As above, but excluding VAT (for business-customer deals)
  • monthly_device_term_months - in most cases the contract term for the device will be the same as for the contract, but not in all cases. In the case of giffgaff it is possible to purchase the handset over a different term from the contract (all giffgaff deals are in fact Pay-as-you-go). In all cases, this field should be checked to ensure the customer is given the correct information.
  • monthly_device_final_term_inc_vat - the monthly price of the final term of the device finance contract. Currently only used by Sky Mobile, and tends to be a reduced line rental for the final few months of the device contract.
  • monthly_device_final_term_exc_vat - As above, but excluding VAT (for business-customer deals)
  • monthly_device_final_term_months - this is the number of months that the 'final term' lasts. If populated, this 'final term' will often feature a reduced line rental or some other changes to the way the device is financed.
  • monthly_contract_inc_vat - the monthly price of the tariff portion of the monthly cost. This will be populated only where the device is being sold separately from the tariff.
  • monthly_contract_exc_vat - As above, but excluding VAT (for business-customer deals)
  • monthly_contract_term_months - the contract term for the tariff.
  • ecpm_inc_vat - effective cost per month - the effective total monthly cost after taking into account all payments over the course of the contract and any upfront cost. Note that discounts and free gifts are not included in this calculation.
  • ecpm_exc_vat - As above, but excluding VAT (for business-customer deals)
  • tco_inc_vat - total cost of ownership - the total cost over the course of the contract including any upfront cost. Note that discounts and free gifts are not included in this calculation.
  • tco_exc_vat - As above, but excluding VAT (for business-customer deals)

deal_discounts_json (nvarchar) - non-null

Details the discounts available with this deal, split into network and retailer discounts (the two can co-exist). A retailer discount is often supplied on a redemption (customer must claim) or automatic (sent in the post after x days) basis, and payment will usually arrive by cheque or bank transfer. By contrast a network discount is usually discounted at source, and so the customer will see the discount applied to their monthly bill.

See Grouping and Filtering Cashbacks.

Example

Nested Fields

Note: Where a promotion code is required to support any given discount, this will be described in the fields: [tariff_group_details_json] - tariff_group_promo_info, [tariff_details_json] - tariff_promo_info or [deal_promo_info]. It is important therefore that all these fields can be passed through unaltered and presented on-site in order to support merchant promotional activity. Whether the promo info is stored at the tariff group, tariff, or deal level depends on to what extent this promotion is shared among other deals offered by the merchant.

Note: Empty entries will be excluded, so if there are no discounts of any sort, this field could be empty.

network_discount
  • nd_reduction_type_id - The type of discount being described
  • nd_payment_type_id - whether the discount is applied automatically or has to be claimed by redemption
  • nd_requires_promo_code (boolean) - whether this discount requires a promo code to be entered in the basket by the customer in order to be activated.
  • nd_value - The value of the promotion (whether a percentage or pence value). This field can only be interpreted in the context of the reduction_type_id.
  • nd_duration_in_months - the number of months that the promotional price applies
  • nd_description - a description for the discount, like "Pay only 50% for 3 months (automatic)"
retailer_discount
  • rd_reduction_type_id - the type of discount being described
  • rd_payment_type_id - whether the discount is applied automatically or has to be claimed by redemption
  • rd_requires_promo_code (boolean) whether this discount requires a promo code to be entered in the basket by the customer in order to be activated (this is very rare for retailer discounts).
  • rd_value - The value of the promotion (whether a fixed price or discount). This field can only be interpreted in the context of the reduction_type_id.
  • rd_duration_in_months - the number of months that the promotional price applies
  • rd_description - a description for the discount, like "Pay only £8.50 for 22 months (by redemption)"

deal_cashback_json (nvarchar) - null

See Grouping and Filtering Cashbacks.

Example

Nested Fields

Note: This field will be empty where no cashbacks are available for this deal.

  • id - the unique ID for this cashback (combines type and value)
  • type_id - the unique ID for the type of cashback. Valid values are 1 (redemption) and 2 (automatic)
  • type_name - the text description for the above ID.
  • value - the amount of cashback being offered, like "200.00"

deal_tags_json

This field is currently not being used.