E-Commerce requires careful planning about how you structure your products and formulate your policies. The reason is simple, sustainable growth of your online portal as your business grows and changes. Unlike websites or traditional commerce, e-commerce sites need to react to business changes quickly. This demands good software supporting your business as well as a good data model process. Technology alone cannot solve everything and businesses need to realize that. At NeuroSystems we marry best of both worlds of tech and domain expertise to deliver the best e-commerce sites our clients can afford, and whats more is that the solutions are developed with a long term vision for your business. This goes beyond the software but requires the business to effectively team up with the technical people in makinng sure the business strategy is most accurately reflected in the end product. This requires a study and planning. The following touch on some of the most common points a business needs to get right, but is not limited to the following list:

Planning SKU codes

Before we take flight into core business concepts, one has to understand some basic rules of the Digital World. While this is true for the real world also, it becomes of particular importance in the digital world. An SKU is a word or sequence that uniquely identifies a product.

SKU codes need to be unique

By "unique" we mean, if the product exists in a different design, color or size then each variation is recommended to have a separate SKU. Infact anything being sold that can vary by the tiniest of intentions, must have a separate SKU code associated with it.

The reason for this is that while selling products online, unique identification is very important to ensure there is no confusion in the final goods being delivered to your customer. For example, if you were selling a SMALL size T-shirt and a Large size T-Shirt with the same SKU code, it is very probable that you would have a record that could allow you to ship the wrong product. There are other implications technically and business wise where you can have a disaster due to not tending diligence to this basic detail.

SKU codes need to be machine readable and usable

An SKU's closest analogy is a BAR CODE. Just as BAR CODE readers demand bar codes to be in a particular machine legible format, SKU codes should be structured such that the computer (machine) can read it easily. SKU codes *may* find their way on image names, links etc. This implies the following:

Avoid complicated schematics behind an SKU name

There is a temptation for some businesses to use SKU codes in a manner that by reading it tells the full nature and history of the product. Don't do thtat. An SKU code no matter how complex cannot tell the story of your product, and by that philosophy no matter what you do it will not be sufficient. There are other fields of data to represent characterizes of your data. Please do not use your SKU as some sort of summary. While some human legibility is nice, the primary importance is to keep it machine readable and usable.

The following example illustrates what should be avoided, is in the circle: Wrong way to think about SKUs

Model Codes

Products that share the same design/model will have the SAME model Code. For example, all products that are SIZE or COLOR variations, can share the same model code. This helps the system relate different products yet strongly related products.
Example: Lets assume there are 4 products. The 4 products have the following properties broken down. Of which we can see "B" has nothing in common:

The above example shows that if a user Looks at Product A2, then the computer can show products with Red and Size M as alternate option(s). Without the model code the computer would not know the relation between these products.

Summary: Simply, assign the same model code to products that are related by Size or Color


Categories are important for the following perspectives:

  1. Break down how your customer should view your products and for you to define a context around products
  2. Allow common visual and pricing, shipping strategies around a category : Products in the same category can share common properties like a common Tax% or common shipping or packaging cost.

Guidelines & indicators for Modelling Categories

Categories don't just impact visual but also business and operational aspects of your website. What's more is that categories once defined, can incur a significant overhead in data conversion if you decide to change it tomorrow. While the platform by NeuroSystems Technologies supports the ability to have your website facing categorization different from how you want to manage it at the backend, there are many arguments to consider while modelling your categories:

Example of what is a Category

The above is an interesting example on close inspection. One may feel this is an obvious example, but wait. One could have also modelled this as : SHIRT > MEN, SHIRT > WOMEN
So why is the previous a better model than the latter?
Apart from the intuitive bias, there is a deeper reason. We can see the sub-category SHIRT has a stronger association with the product than MEN or WOMEN.

Another point is that SHOES may have shipping restrictions based onthe fact they may use Leather and may even have a different tax rate than shirts. T-Shirt inherits any Shirt properties like tax, shipping rates etc. The feature in inheritance of categories is a concept not many other e-commerce systems provide. While this is not the only way, we can define local shared attributes @ a category parent level that can be inherited by sub-categories. This proves useful in some category models.

All other forms of relating products, do not allow inheritance.

Example of what is NOT a Category

SALE is not a category. Products belonging to SHIRTs can also belong to a section called SALE. This does not make SALE a good category. SALE is simply the attribute of a product. So multiple rules are violated:

... So if SALE is not a category what is it? It is a section based on an ATTRIBUTE or a TAG. Just like NEW ARRIVALS. Or one could even make it a collection just like SUMMER 2015 COLLECTION (if your website has the need for collections).

Alternatives to a Default Category

Since there are some restrictions in concept on a Category, how would you get around representing your products to the end consumer is a natural question.
One can refer to the following types of relations for a complete guide. Here is a summary of options:

  1. Attribute : An attribute is any state or field in the product that allows you to control changes in a product. A great way to show a product on SALE is simply to have a Check Box ON / OFF for the product itself. This way ANY PRODUCT can be on SALE or off Sale.
  2. Tags : A tag is a word that associates a product with that word. The downside of tags is that they become unmanageable over time if the business keeps defining new words often.
  3. Collections : Read here all about collections

Product Photographs

This section communicates basic requirements on photo format for products in an e-commerce project. Different people have different methodologies. Our attempt is to only orient the photographer to what we find is common practice. If the photographser disagrees with anything in this section, we are open to communication. What is important at the end of the day is that all parties have an agreement on what is required to produce the final images.

Aspect Ratio

Ensure you design the website first and then share the Image Aspect Ratios' (sizes) with your photographer. What is of most importance is that photographer respects the aspect ratios shared in the design.
If the photograph does not match the aspect ratio then it may either have to be stretched or squeezed, or it will not look right on the website. This is the most critical aspect of shooting images for a website.

Sometimes the designs dont represent all products. Read the next section in that case.

Uniform Aspect Ratios across categories

Sometimes some categories demand different aspect ratios. This depends on the range of your products. For example, a garment would suit a POTRAIT style image while a Hand Bag may suit a LANDSCAPE type image. Shoes could be shot in POTRAIT or SQUARE images. Whatever the category needs, please ensure aspect ratios are consistent (same) across a category.
It is preferred your entire website follow the same aspect ratio's however if that is not possible it is important to convey this to the development & design team before you click or finalize all your photographs. Communication is essential on anything to do with changes of aspect ratio.

Image Resolution

The actual photograph can be in the highest resolution taken, and the e-commerce platform is capable of doing resizing (as long as the Aspect ratio is maintained). However it is also important for web display a standard 72 DPI be followed. This allows for optimized images for web.

Post Editing

Any post editing of the photograph, like cropping, lighting etc is usually the responsibility of the photographer. Ensure your photos are well processed to give them the edge.
The development team does not take on content work like cropping images or changing image formats etc. We can only automate re-scaling (resize with same aspect ratio) of images at best.
It is very important that post editing does not imply changing how the product looks. This can lead to misleading customers and returns on your product. So while some amount of editing is necessary, it should be within ethical limits not to mis lead anyone.

Image Format

For Product photographs, follow a JPEG format (.jpg). This ensures the quality can be WEB optimized. Also PNG-24 (.png) is another format, however this is less preferred as it supports transparency and cannot allow a lower resolution or compression.

Image Background

Typically we design the catalog section with a white background, and if the images do not have a transparent background (like in .jpg format), then it is important the image background colour matches the web page background colour. Typically this is white, but you can check with the design if there is any unlikely deviation.

Naming images

This section is intended for the team creating content and data, and may not concern the photographer hirectly

For ETL to process the images automatically and associate them to the products, a consistent naming convention needs to be defined. The format can be flexible and different for each proejct, however the following guidelines should be followed:

  1. Each image needs to correspond to a Product, a product may have multiple images
  2. To implement the above point, a convention such as <SKU or Product or Model code>-<Sequence#> , can be used. Example: PTS84F28_L_ML-1.JPG
  3. If Any delimiters are used in the Product Code (like SKU, product Code) then that delimiter should not be used again. For example PTS84F28-L-ML-1.JPG is less desirable as compared to PTS84F28_L_ML-1.JPG
  4. Avoid spaces in names, they cause confusion and problems to the human eye and machine.
  5. Its advisable to have a unique image file mapped to each product with a different SKU / product code. This is true even if some images end up being repeats. There are exceptions to this rule, whoch can be discussed with the developer.
  6. The <Sequence#> is a pure number and ideally prefixed with a hyphen (-), and please do not pad it with "0"s etc. It is to denite the numerical sequence of the image for the product.
  7. Even if there is only 1 image for a product, use a Sequence code.( i.e -1)

Update Process

Admin User Interface Forms

You can update content or product information like inventory, price, and all other attributes using the admin interface. See Catalog for details.

ETL Process

A more efficient process for updating data in bulk is using NeuroSystems Technologies ETL Process.
The ETL process allows your to import and export data and other sophisticated processes. Exports are done by the reporting sections of various modules across admin. The way it works is that the Excel export format is designed by default to match the input Excel format. This means that what you can import, you can export and a cycle that can be purely managed by Excel for the most.

Strategies: Sale, Shipping, Discount, Tax

Strategies and policies relate to how you plan to sell your products on line and the terms you set for the customer to accept your product.
Strategies can be of various kinds, and it is important you think through these with your developer.

How your products are priced domestically and if you have international shipping then internationally. For example, will you include tax, shipping costs in the displayed product cost itself or keep either separate. For selling internationally this gets more complex. For example, will you keep multiple currencies and how will you manage shipping and duties. There are many solutions to these problems but each with their related complexity and costs. At NeuroSystems we can guide you on whats most suited for your business.

The difference between a Strategy Vs Policy is that, a strategy results in some calculation that impacts the sale of the product and its cost. Example Tax, discount, Shipping. A policy is just a written statement that legally binds you to your customer. The policy should be clear and you must ensure on any action before purchase, the customer always agrees to your polciy. Any change in policy should ideally be communicated to your customer. Again based on budget for your solution we can make these processes efficient and automate them in some cases.

Testing Strategy

It is the unwritten rule (and now written), of the software world. TEST TEST TEST. When you take an estimate of time, please factor time for testing at various levels.

Why is testing important?

Customers are very unforgiving. If they dislike the experience or there is a critical issue on your website there is a very good chance they will never come back. An issue can happen at any level, some namely:

As you can see there is a breadth of things to test and the actual subject of testing is vast. However as a business user it is important to understand the importance of testing on your front with a small group of people you trust and then only letting it out to the public. Being in a hurry can punish you, unless your business strategy demands a specific time to market.

Typically business users tend to procrastinate their own activities and at the end put pressure on development to deliver. This is the worst case scenario, as backend development is actually the most complex of all phases in the project. To rush the most complex phase without adequate testing for a complex site is for sure spelling disaster. Try to avoid that.

How long does it take to test?

Ideally the business should be involved all throughout to validate and test the process of the development team. Post development the development team itself needs about a month, along and post which the business can perform something called UAT (User Acceptance Testing).

Managing changes

Changes happen, however managing them is extremely important or else it can result in a domino effect and un tested changes being released in a hurry.
Every change should be scoped, documented, approved by the client, developed, communicated and finally tested.
Sometimes changes can result in issues in existing functionality. This is known as Regression, as it causes the system to regress rather than progress.
Unless you have an in house team, managing this is crucial. NeuroSystems technologies is experienced in all facets including e-commerce project management and we can use our experience of many projects and past enterprises worked with to ensure change management is smooth.

Refer to the following for a full flow of how NeuroSystems technologies executes an e-commerce project:
E-Commerce process flow

Back to Top