Difference between revisions of "Product Attributes"
(Description of Product Attributes) |
m (→Benefits) |
||
Line 21: | Line 21: | ||
* Apps don't have to add special code to process each type of requirements (e.g. looking at the array of ingredients and additives, the values of nutrients etc.) | * Apps don't have to add special code to process each type of requirements (e.g. looking at the array of ingredients and additives, the values of nutrients etc.) | ||
* Apps don't need to load and update taxonomies to interpret the returned data | * Apps don't need to load and update taxonomies to interpret the returned data | ||
− | * Translations are managed by the server, and we | + | * Translations are managed by the server, and we can use Crowdin to crowdsource them in many languages |
* If desired, apps can decide to use new product attributes added on the server without requiring app changes | * If desired, apps can decide to use new product attributes added on the server without requiring app changes | ||
Revision as of 16:47, 26 August 2020
Product Attributes
Introduction
Products Attributes is a new way to query the Open Food Facts API to make it easier for clients (like apps but also the OFF web site) to filter and rank search results according to the user preference, and to explain to users how well the products match their preferences.
We are introducing Product Attributes to support Project:Personalized Search, but it aims to enable many more uses.
What it is
Product Attributes is a standardized way to get information on how well a product matches a given requirement (e.g. the product has good nutritional quality, it is vegetarian, does not contain eggs, is organic etc.). The information is available as machine readable data (e.g. 100% match) and internationalized human friendly data ("This product has Nutri-Score E, it is recommended to reduce your consumption of products graded D and E"). For both the machine readable and the human friendly data, the format of the data is always the same, for all requirements.
The machine readable data makes it easy for apps to filter and rank search results in their own way, or according to the preferences of users.
The human friendly data makes it easy to present the information to users, with translations.
Benefits
Product Attributes greatly simplifies how apps can use and display product information, while at the same time offering more flexibility.
- Apps don't have to add special code to process each type of requirements (e.g. looking at the array of ingredients and additives, the values of nutrients etc.)
- Apps don't need to load and update taxonomies to interpret the returned data
- Translations are managed by the server, and we can use Crowdin to crowdsource them in many languages
- If desired, apps can decide to use new product attributes added on the server without requiring app changes
Examples of Product Attributes
Product Attributes are organized in sections:
- Nutritional quality
- Nutri-Score (A = 100%, E = 0%)
- Low salt / Low sugar / Low fat / Low saturated fat (based on the Nutrition Traffic Lights)
- Transformation
- No ultra-processed foods (NOVA 1 & 2 = 100%, 4 = 0%)
- Few additives (0 additives = 100%)
- Allergens
- for each allergen (not present = 100%, present = 0%, traces = 10% (low threshold that will exclude products if "No [allergen]" is marked as mandatory by the user)
- Ingredients
- Vegan
- Vegetarian
- Palm oil
- Labels
- Organic
- Fair trade
The list can be quite long and new Product Attributes can be added over time.
API
Request
Apps can request Product Attributes through API queries (/product or /search) by including "attributes_[language code]" (or "attributes_data" to get only the machine readable data) in the "fields" parameter.
Response
For each product returned, a new "attributes_[language code]" or "attributes_data" field is added, containing an array of sections (to regroupe attributes, like all allergens) that each contain an array of attributes.
Section format
- id - e.g. nutritional_quality
- name - Name of the group of attributes e.g. "Nutritional quality"
- attributes - Array of attributes
Attribute format
- id - e.g. nutriscore
- name - e.g. "Nutri-Score"
- status - known, unknown, not-applicable : indicate if we have enough data to decide if the requirement is met
- match - 0 to 100 - indicate how well the product matches the requirement (100 = 100% match)
- icon_url
- title - short title corresponding to the value of the attribute - e.g. "Nutri-Score D"
- description_short - very short description - e.g. "Bad nutritional quality"
- description_long - small text (1 or 2 paragraphs, possibly with bullet points introduced by dashes)
- recommendation_short - "Reduce"
- recommendation_long
- official_link_title - "Nutri-Score page on Santé publique France"
- official_link_url
- off_link_title
- off_link_url
Example uses
Personalized search
Users are being asked to enter preferences for each attribute (or a specific subset of attributes), for instance:
- The product is vegetarian - [ ] Not important, [ ] Important, [ ] Very important, [ ] Mandatory.
Based on the users preferences and the "match" key of the Product Attributes, apps can exclude some results (e.g. if a mandatory requirement is not fully met) and re-rank search results.
Information and recommendations
Apps can use the returned human friendly data of each attribute to show some explanations and/or recommendations to users.
As the data is always returned in the same format for each attribute, apps can also decide to display all product attributes returned by the API (even if the app is not aware of them).
Apps can also decide to display some attributes in their own way (using the more attribute specific data that is returned by other fields in the API).
Personalized information and recommendations
Based on users preferences, apps can filter and/or re-order the product attributes to first show the information that the user is the most interested in.