Do products need a SKU?
Alrighty, I'm trying to summarize a discussion that occurred in IRC today surrounding the need / name for the SKU on products. We talked about this in our San Francisco sprint last October, but I didn't recall reaching a conclusion away from SKUs. In fact, our white board picture and various blog posts and threads on the product specification presume a SKU field as an essential part of the product entity. This hasn't been challenged thus far, and I still want to contend for its inclusion and acceptance based on some observations below. That said, these issues bear further consideration and will serve to more clearly define what a product will be.
First, let me say that I accept that SKU is a bit of a misnomer. Technically it stands for "Stock Keeping Unit", but not everything people have sold with Ubercart or will sell with Drupal Commerce has a stock value in the traditional sense. In those cases, it's more like a sales tracking value than a stock keeping unit, but I'm comfortable with this "outside the box" use for the SKU for reasons outlined below.
Ok, so the basics. What is a SKU? It is a unique, alphanumeric, merchant-defined identifier for the product. Its primary purpose is as a human readable product identifier that's at the same time concise and meaningful. It will be used for product searching / entry, displayed on product pages and order displays if desired, used in reports, and used for various stock tracking and picking applications. I'm guessing this value will be used in other ways, too.
One question is why not just use the $product->product_id? We do in fact have a serial numeric ID for products in addition to the unique SKU. Do we need this? I think so, and that's because a numeric value isn't very meaningful. Someone may in fact have a small number of products for sale and just end up using this numeric value, but it's insufficient for sites with a large number of products. It also doesn't convey any sort of relation between products, like SKUs with minor adjustments for various attributes (the regular example being TSHIRT-S, TSHIRT-M, TSHIRT-L).
Ok, so why not use the product title for differentiation? Here I believe this fails to be concise and will not communicate differentiation. When selling the same product with 5 different size values, the title will be the same with the size field having different values. But lest I be seen as exaggerating this point, it still could work, but whatever solution we cook up wouldn't be concise and could be liable to multilingual confusion.
Now, here's the kicker, and it's inspired by the fact that Magento uses the SKU field explicitly as "as a unique identifier for this product, across all stores and websites." I want to assume people will have multi-site stores, and the SKU will be constant for the merchant across all web properties as in Magento. What might not be constant is the title (multilingual, marketing segmentation, etc.) or the internal $product->product_id. Having a short alias for the specific product will be very beneficial here, but making SKUs optional and trying to support things like multi-site based on product_ids will lead to difficulty.
So, why not keep the SKU but name it something else? We may in fact be able to find something that more closely captures the meaning of the field... like "Product ID Alias" or "Short Product Name". But those have their own confusion level and aren't readily familiar to anyone. Furthermore, for situations where this field functions as a SKU, it won't be intuitive that this is indeed the stock keeping unit.
I understand that there are concerns with how well SKU will be understood internationally, but as I pointed out in IRC, the GoodRelations RDF Ontology for e-commerce is comfortable specifying SKUs and is itself an international document. My hunch is that we could try to find a term that is more "translatable," but in so doing we'll have to completely invest the new term with meaning as opposed to giving millions of people a head start in understanding what we're referring to.
So... to summarize:
- I think keeping the SKU as an essential part of the product as discussed before is a good thing.
- I think defining it for everyone is essential: The SKU is a unique, alphanumeric, merchant-defined value assigned to a product that is concise and meaningful. [This definition should itself become more concise if possible.]
- I think it's worth having this as an assumed part of the product for a variety of reasons related to usability and "codeability."
- I think it's worth maintaining alongside the site specific numeric product_id, but we should implement Tokens and SKU patterns so sites that don't want to bother setting SKUs can default them to some pattern based on the product_id. [Note: this effectively makes SKUs "optional," and a contrib module can easily disable the form element from the product form, or we can introduce a "force pattern" checkbox on product types that doesn't allow individual product SKU overriding.]
- I think it's better to use a term that's used in other systems than to create an original term for this value that we would then have to teach to everyone.
In other words, I don't think there will be a viable alternative to SKUs as currently implemented, but I don't want to dismiss anyone's concerns... I'd rather just define the term and implement it in such a way that concerns are validated and addressed. After screwing this up once ("Model" in Ubercart, later changed to SKU externally while still $product->model internally), I really think sticking with SKU will pay off, especially in relation to other e-commerce systems.