Implementation Tips

These implementation tips can be used in conjunction with wireframes (PAYG and PAYM) that demonstrate the relative importance of various data elements through the use of colour and positioning.

Grouping and Filtering Devices

Should you wish to focus purely on the hardware, the merchant_category (standard) or device_product_json (JSON) fields provide basic product type categorisation, with the JSON fields in general providing a more reliable ID-based approach.

In many cases however, it's likely that you will want to also filter based on the type of contract (pay as you go, mobile broadband, sim only, etc.), as well as deal type (consumer, existing customer, upgrade, business, etc.) linked to the device in order to ensure the customer doesn't end up looking at a device only available on a type of contract they aren't interested in.

For deal type, check out the product_type or deal_type_json fields, and details of the contract type are available in custom3 and tariff_details_json.

Sorting and Filtering Discounts

Discounts (whether network or retailer discounts) are represented identically aside from field naming. This means that both types of discount can be stored internally in the same table, with just a marker denoting whether the discount is a retailer or network discount. This should make filtering far easier.

The nd_reduction_type_id and rd_reduction_type_id fields can be used to group deals by the type of discount being offered, or perhaps more usefully, the fields can be used in combination with the *_value and *_duration_in_months fields to calculate the total discount available and use this derived value as a means of sorting the results (or comparing against Cashbacks - see "Filtering and Grouping Cashbacks" below).

Using the *_payment_type_id field, developers can group deals according to whether or not the customer is required to redeem the discount, or whether it is automatically applied. In many cases customers will prefer to opt for an automatically applied discount.

Grouping and Filtering Cashbacks

Cashbacks are really just a simpler type of discount where the amount of discount is expressed as a total discount available. This means Cashbacks can be compared directly against Discounts in two ways:

  • Compare Cashback value with the derived total Discount mentioned in "Sorting and Filtering Discounts" above.
  • Compare claim method (automatic / redemption) in the Cashback type_id field against the claim method stored in a Discount's *_payment_type_id field.

Understanding Pricing

Many will be used to the idea of pricing in the Telco vertical being split into an upfront cost (a deposit of sorts on the hardware, assuming we aren't dealing with a SIM-only deal) and a monthly cost that covers the service/allowances being purchased but also subsidises the cost of the device.

While the above approach still exists, there are now more complex pricing structures being adopted that not only have a bearing on the data now made available via datafeeds but also on how pricing is displayed on the web. In many cases there can be legal requirements that have to be met (such as displaying information about RPI-linked price increases or credit agreements) and pricing is now increasingly represented as one price for the service, and another for the handset or device. Additionally the contract term for the device and service can be different (so for instance Giffgaff offer 30 day topups, and hire purchase agreements for the device of up to 24 months)

When should I use ex. VAT pricing?

If the deal is a Business deal (product_type or deal_type_json fields), then you should use ex. VAT pricing wherever possible. It is acceptable to use inc. VAT pricing in circumstances where Consumer and Business deals are being compared but you should indicate clearly that the customer will be charged Ex. VAT when it comes to payment.

How will I know when to show separate monthly prices for devices and tariff?

For comparison / sorting / filtering purposes you can safely just use the upfront_inc_vat / upfront_exc_vat and monthly_total_inc_vat / monthly_total_exc_vat fields. It's only when it comes to displaying pricing for the deals in question that you need to worry about any split.

Identifying a deal where the price has been split is straightforward - if monthly_device_inc_vat / monthly_device_exc_vat is populated, then we're dealing with a split-pricing deal. Remember that the contract length for the device (monthly_device_term_months) can be different from the contract length for the service/tariff (monthly_contract_term_months), so you'll need to ensure these are properly represented on the page along with the legal text if populated.

I'm not using the JSON fields. How can I implement split-pricing?

This is currently unsupported. Split pricing information is only available here. Even if you aren't able to use JSON natively in your code, it may be possible to extract the required values using some simple regular expressions, though the exact method will depend on your programming language of choice.

Displaying Tariff Information

Note that this section assumes the use of JSON fields. When displaying a deal, the following should be considered:

About Images

We attempt to ensure that images are provided in all cases however there are some situations beyond our control (for instance early product pre-orders) that mean images won't always be available. Where that's the case we will always provide a placeholder image so your import code won't throw errors and your web page won't contain any broken image links. As soon as we are able to get hold of the relevant image, the feed will be updated to include it.

In total there are six styles of image available, listed below:

Note: The large_image and alternate_image data is repeated in the device_images_json field.

Handling Feed Updates efficiently (JSON Only)

Since the JSON fields are structured and include IDs wherever possible, we can rely on them to efficiently update the feed whenever it is imported. Rather than overwriting everything in your local database each time you import a row of the CSV you can check each ID just once, and then ignore any further occurrences of it in the feed.

For a super-quick import you can even just check *some* of the fields as described below, though you risk not picking up on corrections to previously faulty data (human errors will always happen). If you do want to use this approach we recommend that you perform a more complete update once every couple of days or so.

Bare minimum field value updates

During each feed import run, assuming the IDs (and previously imported data) for the below already exist in your database:

Skipping fields based on network_details_json

Where the network_details_json - company_id is "76", we're dealing with a product that comes without a contract. Therefore we can skip the following fields, which will be unused in this context:

Specifications And Features Availability

In all cases where the product is a "Mobile Phone" (device_product_json - product_type_id = "1"), all of the fields mentioned below should be populated.

Where the product type is not a Mobile Phone, you should check each field carefully for a value without assuming they will always be available.