Product View Script

A number of features require knowledge of the Products that you sell. Product and Purchase Data is used to drive the built in Enrichments as well as used to feed data into third-party platforms to enable the creation of personalised Customer experiences.

Because Product data can be used in Customer communications we ask for display attributes, such such as the Product name, Image URL, Shop URL, Price and Availability. An example of use of these is merging into an email template. Who wants to receive a message about a great deal on a product ID 1726?  

The Product and Purchase History used to drive Enrichments such as the Product Recommendation Engine creates a unique set of Product Recommendations per Customer, and the Spend Bracket Enrichment classifies Customers’ spend per Product category. 

So both Product and Purchase History are useful datasets to bring into


When planning for the creation of the Product database View it is important to think of the end use cases for Product data. As described above Product data is used for communication with Customers via a third-party platform, likely one that does email.

The Product data definition includes the most common attributes. Bringing these in via your View should cover most scenarios, at least initially. However if your Products have additional attributes that are vital to communicate to your Customers it is worth including these as well. 

As per the Customer dataset, if you are not the person who will be writing the SQL to create these Views it is worth doing the attribute defining legwork prior to handing over to the View creation, then working closely with the nominated SQL guru to refine the dataset. It is likely that they will be able to surface more useful data as well. 

If you would like some guidance during this process, please see our Supported Onboarding process. We have our own SQL gurus that can help should you need it.

Creating the Views

View Rules

  • Each record in the View should represent one Product.
  • Each Product should only be represented by one record in each Product View.
  • It is important that the available attribute should be populated with True/False
  • Each Row must have a Text column called ID that contains a unique identifier. This could be your internal ID or if you don’t easily have those used across multiple systems you can prefix the ID with a code representing the source system.

    For instance if you have two Products with the ID 100 in different systems, prefix one with “sys1-100” and “sys2-100” to make them unique across both.

Core Attributes

A full description of the Product dataset and its Attributes can be found in the Product data Definition.

You can bring as many attributes as you wish into your Product dataset and of course it is likely that you will have a set of attributes that are highly bespoke to your Organisation.

There are however a set of Common Product Attributes that uses for specific purposes. These include things like Product Name, Thumbnail URL, Available, Price, etc.

Custom Attributes

A key use for Product data is forwarding into third-party tools to be merged into Customer Communications (i.e. to be used in Email Template mail-merges). You may wish to include additional attributes to those listed in the core set described in Product data definition.

As with Customers when you are naming your attributes case is not important, however will attempt to form a Friendly Name from the raw attribute name. To make best use of this use an underscore “_” to separate out the words in the Attribute.

For example tickets_left will become a friendly name of “Tickets Left”. 

View Naming Convention

As with Customer data, once you have connected your database will interrogate the schema and look for Product datasets. 

For a Table or View to be identified as containing Product data it must contain the words “Distil” and “Product”, in that order. 

Some suggestions are:

  • distilProducts
  • distil-products
  • distil_products
  • v_distil_products
  • v_distil_product