Some manufacturers release different product versions under new SKUs.  As these new products are released, it is important for MetaLocator to properly identify and update the product under its new identity.  

The new SKU should also appear under Interface and button integrations that reference the old SKU. This allows data managers to introduce new SKUs without involving the Web team to change the SKU.

This procedure assumes the following product lifecycle:

  1. SKU A is active and integrated on a product page with a Where to Buy button that references SKU A.
  2. SKU B is released on the Client Web site as a replacement for SKU A.  This may be released under a different URL than SKU A.  It may also appear under the same URL as SKU A.

Product Data Configuration

To ensure the SKU B is recognized, SKU B should be added to the product record for SKU A as a secondary SKU as shown below:

The secondary SKU must added as a product key that begins with SKU, e.g. SKU1, SKU2 etc. so that it can be optionally referenced in the button configuration.  

Results that correspond to SKU B can be preferred in the Where to Buy display by adjusting the rank of SKU A down to 2 as shown above.  However, if the ranks are the same, the system will prefer the newer SKU, which would typically correspond to SKU B since it was released and likely added to MetaLocator after SKU A.

Button & Interface Configuration

The SKU field, as distinguished from the product keys, is a unique key the list of products.  The product SKU field is managed as shown below.  It appears in the product data import spreadsheet in the SKU column.

The SKU is typically used to reference the product in the button configuration.  E.g. 

data-metalocator-sku="SKU A" 

This filters the display to show only products where the SKU field is exactly "SKU A".  This will also display when "SKU A" is listed as a secondary SKU key as shown above.  This allows button configurations to be created with the primary SKU field and also with the secondary SKU.

Analytics Implications

Product Impressions, eCommerce Product Views and click actions will be attributed to the SKU that is actually displayed.  Page-level actions that include a SKU segment will be segmented according the SKU referenced in the Button configuration.  

Product Key Overlap

SKUs, and product keys in general, should not be duplicated across products in the same locale.  For example, primary SKUs should not be added as secondary SKUs to other products.  Similarly, EANs for one product should not be found on another product record in the same locale.

Product Discovery

When a new key is added to an existing product, the Product Onboarding system will automatically search the relevant retailers for the product under the new key.  As the crawler does its work to find the new product, the results will automatically appear under Retailers > Offers.  Similarly, the new product will be automatically matched to the correct product.  

Product Onboarding does not normally affect products that are already matched.  However, the system will look for products with keys that were not configured when the product was matched.  They can be identified by the empty crawl date as shown below:

Since TESTSKU has no Crawled date above, it is considered new and will be included in onboarding.  To prompt the system to re-crawl for an existing key that was already present in the context of a match, remove the date from the Crawled field and save the record.  This will move the product to the top of the onboarding queue.

Did this answer your question?