Home page of an online store

Option 1: we show the products we want to promote to the clients or new products that bring us the best proffits or products not sold or even products that belong to Supplier X (we just made a deal with that supplier).
This option starts with the idea that we push to the home page products that have a particular value to us.

Option 2: we put the most attractive products, products most viewed or most ordered.
This version is based on the idea of best sellers, we promote what we sell better / what people are viewing.

Option 3: we analyze which categories / products the user visited before or which products the client ordered in a prior visit to our shop and we make a selection of products based on these criteria.
In this option we take into account the interests of the user.

But the question remains: what do we put on the first page of an online store?

Wich solution is correct?

Unfortunately, none of the three options is correct, as neither of the three options is wrong. Options 1 and 2 are based on a classic sales model wish, in some cases, can give good results and option 3 goes on a behavioral shopping model that can work for a while.

I, personally, would go on a mix between those three plus a flavor of seasonality. How about you?

Related Posts

• Value of experiments in online commerce
• Social shopping evolves with Plurchase

If You Liked It Then Bookmark It

Hide Sites

Knowing that user experience can greatly influence purchasing decisions I think we should not ignore this.

This article tries to answer this question: how do we realize what the online stores customers need?

What should be improved?

User experience starts when a visitor reaches a page on your online store. This page is not always front page of the site. The first aspect to be improved is this page, which starts a user’s visit. Remember: this page is not necessarily the index page of your online store.

We are in the moment when a new visitor entered the online store. He now needs to go as fast and as easy as possible for products that interested him, those that are relevant to him. We must improve, then, the path from first page of his visit to the page he wants to see.

When the user has reached the product or products he’s interested in there are still two aspects that need to be improved:

• the path from initiating an order to ending the order
• the registration process of a new user

Generally, these are the directions where we need to look when we want to improve the user experience on an online store. How we do this is, however, another story.

How to find out what are the users desires?
There are several ways in which we can find out what they want.
We can do feedback forms, we can do surveys, we can do a contest to stimulate feedback but we can also do experiments with the online store.

I think that any way of collecting feedback we use, if we let the user decide what information he will provide, we can never be sure that we have real and relevant information available. Why do I believe this? Primarily because when a user sends us his feedback, being aware of that, he will provide us with subjective information. Second: this sort of collecting feedback generates reactions from extreme situations, the very happy and very unhappy people, but we are interested in an objective opinion of the majority of an average user.

We remain, however, with the experiments that we can run a tool that can help us find out what they want and we can be almost sure that the user provided objective and relevant information.

Note: a subjective opinion of a direct feedback from the user means that the information provided is different from the actual experience of that user.

What is an experiment with an online store?
An experiment on an online store is not an easy process but I think the results worth it.
A simplistic description of an experiment should be: modify sections of the store and study what happens, how users react and how the KPI (Key Performance Indicators) changes.

What are the steps necessary to make an experiment:

• identify the area where we want to do the experiment: it is better to choose one area at a time in which to do an experiment
• define what will be affected by the experiment: if we want to play with the product listing page and run some experiments on the product filters, change how it works and how it looks or their position then we write that down, change it and then look for the results.
• define a time and users interval when to run the experiment: the experiment can run several hours, several minutes or even several days, well, we can define and if it will run for all users or only for part of them.

Now you only have to implement your experiment and to measure the results.

Related Posts

• What we put on the first page of an online store?
• News from RunClassifieds.com
• Database sharding – when and how we implement
• Social shopping evolves with Plurchase

If You Liked It Then Bookmark It

Hide Sites

Solutions like should be planned before project starts in order to have an effortless scaling in time.

What is database sharding?
A decomposition of a database into multiple smaller units that can handle requests individually; A breaking into shards; A shard is a method of horizontal partitioning in a database or search engine.

What is database sharding beyond these definitions and how can it help us in real life when building online applications

When we plan an online application we have to think about it’s potential to grow. The growth translates, in general, into more requests to the application and huge resource consumption. From a certain point the resource consumption evolves exponentially, not linearly.
Even if today hardware is cheap and prices are going down in time there comes a time when investing in new, more powerful, hardware doesn’t bring too much performance and the cost per percent of performance increased is growing exponentially.

Where do problems appear more often?

• web server: problems with accessing files or too many concurrent requests; you can deal with this kind of problems by using a CDN for file storage and by using balancers for web servers; there are a lot of solutions for this issue, both hardware and software, both cheap and expensive
• database server: problems arise both at writing to database and reading from it; at a certain point even a replication model (few write servers and more read servers in replication, or whatever model suits you best) can be inefficient when problems are generated by huge tables and indexes.

How can database sharding help us in this case?

When using sharding as a solution for database horizontal partitioning we have to think about logical distribution of the database on multiple servers.
The structure of the database will be the same as for a normal architecture in most cases but on each server we will have smaller databases with fewer records.

Now let’s give an example to translate all that I wrote until now

Let’s consider we have an application that manages users and the messages exchanged between those users.

At start let’s consider we will only need 2 database servers.
The structure for the tables in the 2 databases will be the same, the only difference is that on server Alpha we will put the users that have and id that is even and on server Beta we will put the users that have an odd id.
On the Alpha server we will store also all the messages related to the Alpha users, both sent and received and on Beta we will do the same for Beta users.
If we do it this way we will double the number of messages in the entire system but we gain performance when doing readings from the database.

This is a simple solution for a simple problem. For more complex problems there are other solutions and I will write about those in the following lines.

One more thing about this example: how do we work with this database setup from the point of view of the developer?
Simple: all the requests to the database layer will have to contain the user id too and the database layer will decide, based on the user id, to which server it will send the request.

Moving on: types of database sharding implementations

There are many ways to implement database sharding for the application we want to develop.
Each one has its own advantages and disadvantages and it’s our mission to decide which one fits our project best.
Some ways of database sharding implementations can do us a lot of good but some can destroy our application so always plan smart.

1. Vertical partitioning
   We split the database into logical entities that can live independently from others. Some entities will go on shard while others on different shards. We can also have a dedicated shard for one entity.
   Example: we have one shard for user profiles, one shard for messages and one shard for image gallery.
   In this way, when we want to show images we will send requests to the image shard. All we have to do is to maintain in all shards a reference to a central entity, in this case the user.
   This set-up works well in certain cases and it’s easy to implement but can’t handle individual growth of entities.
2. Interval partitioning
   This set-up is best suited for financial applications and means that we choose the shard we write to/read from by checking in which interval a certain value fits.
   Example: all financial data for year 2008 is saved in shardX and for year 2009 in shardY.
3. ID based partitioning
   In this case we copy the same database structure on all shards and we define the main entity of the application, for example the user.
   Considering we have n shards available we will have the following rule of writing / reading: for user id 1 we use shard 1, for user id 2 we use shard 2, for user id n we use shard n, for user id n+1 we use again shard 1 and so on.
   Such a solution is a good option when we can estimate the growth of the database.
   The good: all shards will be evenly loaded.
   The bad: is hard to increase the number of shards used and re-balance the shards.
4. Directory based partitioning
   Think of a system where for each database request we also send to the database layer the entity identifier and the id (for example: entity – users, id – 567 or entity – images, id – 23).
   We also build a directory that relates entity + id to shard.
   Choosing such a system is the best solution when not knowing how your application will grow and when. It’s also the hardest to implement because for all database operations you have to update information’s in the directory.

When not to use database sharding

There are still a lot of situations when we are not forced to use database sharding, there a lot of other solutions we can use until we really need database sharding.
We can use sql cache, sql proxy, storing entire record sets with memory with memcache. Or we can use better hardware.

Such an example comes from the 37signals team, read here.

Before the end

Here is a nice presentation from NETLOG about database sharding, enjoy!

Related Posts

• News from RunClassifieds.com
• Value of experiments in online commerce

If You Liked It Then Bookmark It

Hide Sites

I started writing on this blog because I have the feeling that there is a lot of information and advices that I could share with you and it would be a waste to keep it only for the Romanian market.

I’ve been writing until now about various subjects, covering from concept development for online projects to managing an existing project.

Here I will write about the four stages of an online project: concept development, planning, implementation and management.

I hope you’ll enjoy the articles you’ll find here and I promise I’ll always keep a high quality standard with what I write.

Random Posts

• RunClassifieds.com has a new owner
• How to promote your business through classifieds
• News from RunClassifieds.com
• RunClassifieds.com reviewed by KillerStartups.com
• Value of experiments in online commerce

If You Liked It Then Bookmark It

Hide Sites