Project:Product versions and history

Product versions and history

This page is to discuss how to handle products that have different versions and/or that evolve over time.

Problems addressed

• Products with the same barcode that have different packaging and labels
  • Completely different products
    • Same barcode used by different products (e.g. conflicts with "internal" barcodes)
  • Products that have different versions being distributed simultaneously
    • Different versions for different markets
      • With or without product variations (packaging, ingredients, nutrition facts etc.)
    • Different flavors of the same product
    • Different marketing on the labels
  • Products that evolve over time
    • Versions can coexist for a while, but previous versions rapidly disappear

Problems not addressed

• Products that are the same product, or versions of another product but that have different barcodes
  • includes product packs that contain several instances of a product
• Multilingual products - addressed by Project:Multilingual products
• Adding the ability for the upload script to set an obsolete version (for the supermarket Dada pictures from the 1990s)

Current status

• We use the barcodes as product identifiers in the database
• For each barcode, only one product version exists in the database
  • In practice, there are some barcodes for which we have pictures corresponding to different products, different versions, or different evolutions.
• We store revisions of the product pages. Those revisions were intended for revisions of the product page itself (e.g. adding more data or fixing data corresponding to one set of product pictures), not for different versions or evolutions of the products.
  • In practice, revisions mix different versions, evolutions and revisions.

Typology

Not all versions are equal. In order to have a better understanding of the kind of versions that might occur, one can differentiate several type of versions:

• Views - product versions that are essentially the same, but have different packages. Each package is intended for a different locale (country and/or language). Sometimes, this can be just a sticker that has been added. Lidl-products are a good example of this;
• Marketing - The product (ingredients/nutritional values/etc) did not change. However the packaging evolved. Examples are Coca Cola, Perrier, etc;
• Evolutions - In this case the product has been changed and thus the package as well;
• Instances - the product as bought by a consumer with its own expiry date, purchase place and possibly producer-code;
• Re-usage - In this case only the barcode is the same. The product and package has been changed; Thus is barcode is only repurposed;

Solution

Introduce product versions and product evolutions

• Current identifier of a product page: barcode + revision id (1,2,..)
• Proposed identifier of a product page: barcode + version id (1,2..) + evolution id (1,2..) + revision id (1,2,..)

• Product versions correspond to versions of the same product that are being sold simultaneously
  • Product versions must have different pictures
  • Product versions can have completely different data
  • Products versions co-exist
    • Several product versions can be displayed on OFF
      • Some versions might be not shown for some queries (e.g. depending on the values of the "countries of distribution" field)
  • In practice, product versions can be abused to handle completely different products with the same barcode

• Product evolutions correspond to products that evolve over time
  • Only the latest evolution is shown on OFF in regular searches
  • We track all the changes and can display the evolutions: differences in ingredients, nutrition facts etc.
  • Product evolutions must have different pictures
  • Product evolutions can have completely different data
  • Product evolutions have a first seen and last seen field based on pictures showing the same information over time and input from users ("The packaging and data are still the same")

Allow to create new versions and evolutions

• Create new version or new evolution by moving pictures to it
  • Similar to the existing feature to move pictures from one barcode to another

Questions

Some Questions related to product versions.

• Purchase place - how does the purchase place fit into this?
• Expiration date - and the expiration date?
• Production place can be dependent on the expiration date imprint, thus two versions?

There should be a clear definition what a product is. The thing I buy in a shop is a product instance with unique packaging, purchase place, expiration date and packaging. Somebody else can buy another product instance in the same shop, same expiration date and packaging. Only the purchase time is different. Other product instance might be bought in the same shop, but with other expiration dates. Or in other shops, but with the same expiration date. All other aspects of the product instance are the same, defining what a product is. The system should allow the registration if these instances. It can be seen as an issue not related to product versions.