MayGill home

Database Marketing
If you are a salesman, you know it is very important to know what your customers are buying, when they buy what, and with what time intervals they reorder. It is also very important to know what the customer is not buying.

A good salesman needs all this data, so he can contact his customer, before he needs to reorder, to make sure he'll get that new order. And by knowing which products that customer doesn't buy yet from him, he can also try to add new products.

The most expensive factor in business nowadays is time, so your salesmen are most likely very expensive. Knowing all this data when you are serving thousands of customers with thousands of products is almost impossible.

With BitsMarket, all this is completely automated. Of course, you need an order history to use this feature (an offline order history can also be converted of course, contact us for more information).

We'll try to give you an idea of how this is all done. But still, this information can be somewhat overwhelming. Please feel free to contact us for more information and/or questions.

As mentionned in Main Features, all products are tied together in product pages, which are tied together in rubrics, which are tied together in chapters. Now, when analysing all this data, we don't want to look per product, but we rather want to look at it per family of products ( i.e. when a client buys now this pencil, and then that pencil, it isn't really important: it's important to know he buys pencils). That's why every rubric points to a family.

When having a history and data about all families, BitsMarket calculates a usage percentage and a repeat percentage per family. So BitsMarket knows which families are needed by almost everyone, and also knows which families are reordered the most.

There is one more database: a machine conversion table. Here you can specify per product, which supplies this product needs, and which reference numbers to offer if needed. I.e. you need laminating pouches when you buy a laminating machine.

In the config files, you can activate or deactivate this tool. You can determine from which page count on offers can be made, how many offers per session, how many page counts between offers, and so on. You can also determine from which amount on to start with the offers. BitsMarket will calculate the prices on its own. Depending on your settings in the config files, this can be with very low margins (see below to know how they are determined). This is why we probably only want to start to make these offers when the customer already has some amount on his shoppingcart, so the basic costs like shipping, and so on, are already covered.

When the point to start the database marketing tool has come, BitsMarket will start a different process to analyse the history from this user, and to calculate one or more offers (depending on config, availability of offers, history of the user). Although all this is done in seconds, we start a different process because we want to keep BitsMarket fast and don't want a second of waiting for the user.

With the next click of the user, BitsMarket will know if there are offers, and if so, will start using these offers on specific pages. These specific pages are:
  • Going to the top of the index tree: because this most likely means the user has finished his previous action, and now starts something new.
  • When added a product to his cart. Same reason as above. One exception: if suggestions are made after adding a product to his cart, we don't make these offers, because then we want the user to see these suggestions, and act on it.
  • When looking at his cart.
The moment these offers (or other special offers) are available, there can be a special link on every page (depends on your templates), so the user can go back to all offers made for him personally.

To be able to make these offers, BitsMarket has first to analyse the history of this user. This is done in 4 steps:
  1. Using the machine conversion table (written about above):
    • BitsMarket will search in the order statistics for products bought for which supplies are needed.
    • Per supply needed, we'll look at when, how much and how regularly these are ordered.
    • If the supplies are never ordered, we know something is wrong, and that we have to try to change this.
    • If the supplies are ordered, we calculate an average usage per day. And with this data we can determine when the user needs to reorder, or when he had to reorder.
    • With this and with the age of the machine bought, and with offers made already, ordered or not ordered on offer makes a difference, we calculate a probability ratio
    • All results from this step, are ordered by probability ratio. Because offers made without success are calculated within this probability ratio, we are not going to make the same offers each time.
  2. Family statistics 1 (references to offer per family must be specified by the shop owner):
    • BitsMarket will create statistics for every family that a user looks at.
    • Because of this, we can easily extract the families the user has looked at, but until now never has ordered.
    • This data is sorted on the number of times he looked at that family, the number of offers made, the number of orders following a database marketing offer, and the usage and repeat values of this family (explained above).
    • So again, BitsMarket knows what to offer. If more than one offer is available for this family and no offers are made yet, it will be determined at random. If an offer already has been made without success, the other product will be offered.
    • An offer made without success, has a negative impact on the sorting, so we don't make the same offer all the time.
  3. Family statistics 2 (references to offer per family must be specified by the shop owner):
    • This is very similar to Family Statistics 1, except that the user never looked at these families.
    • The sorting depends more on the usage and repeat values per family, and of course again on the fact of offers are already made, and if so, were they ordered or not.
  4. Family order statistics:
    • We look at the complete order statistics for this user, grouped per family. At this stage it is not important to know exactly which references the customer buys.
    • Within each family, the quantities per order are calculated, and the time between orders. With this data (if enough orders concerning this family are available), we can calculate an average usage per day, and can estimate when to expect a new order for this family.
    • With the data acquired until now, and in the case a reorder should already have taken place, we calculate a probability ratio (again also with using the usage and repeat values of this family as explained above, i.e. agendas: you need this only once a year, so it could be misleading, but by using the usage and repeat values this problem is eliminated).
    • This data is again ordered by probability ratio.
    • Then for the families where it would be appropriate to make an offer following the probability ratio, we search for the references that this customer already ordered within this family, count the orders per reference and look if database marketing offers were already made, and if orders were received from these offers.
    • These references are then ordered by number of orders and grouped together as they are on the same product-page.
    • When BitsMarket is going to try to make an offer (when, how and why is explained below), BitsMarket will look at the available products for this family grouped per product page. It has again a negative impact, if offers were already made, but no orders came out of it.
    • We then look at the other products on the same product-page, and if the costprices of these other products are within a specific range and not too long ago updated, then those other references will also be offered.
How many offers, which type of offers (from the above 4 steps), and so on, can all be specified in the config files.
  • If enough data is available, BitsMarket will try to make offers. If not enough data is available for one or more of the above steps, the other above steps will be used if allowed in the config file.
  • If a product is already added to the users cart, which is on the same product page, as the products we are going to offer, then this group is skipped. First it isn't necessary, because the user already has chosen to order. Secondly it would not be nice to make an offer for a comparable product, but not for the one he already chose.
  • If products to offer are on different product pages (this can be for the above first 3 steps), we'll take one product page out of it.
  • If all products to offer for this product page have a costprice within a range of 5% we will handle them all as should they have the same costprice. We then take the highest costprice, and the lowest selling price, to make our calculations. Otherwhise all products are calculated separately.
  • If BitsMarket is not able to calculate more than half of the products selected to offer, this product page will be skipped.
Then finally the calculation of the offers.
  • We first look for this product(-range) which offers were already made (globally, so also for other customers) sorted on margin. And for which offers (in other words, with which margins) did we receive an offer.
  • If no history is available, we calculate by using values that can be set in your config file, as mininum and maximum discount percentages, minimum margin and so on.
  • The moment we have history, we look at the results of previous offers.
  • If the proportion between offers made and orders from these offers received, isn't good enough, we lower the margin following the offers already made (not necessarely lower than the lowest margin already used).
  • In the other case that the proportion of orders received against offers made, is positive, we try to increase the margin a little.
  • This algorithm searches the right margin to get success ! If you never receive orders following these offers, the price will go down. The moment you receive regularely orders, the price can be increased. This is based on a sort of averages, so an order or one offer without an order can't really influence the system.
  • The flexibility of the system depends on the margin to start with, which depends on the lowest normal price for the active pricelevel, and the minimum margin you have set in the config files.
  • The reason that you can also set in the config files the amount that has to be on the users cart, before starting to make these offers, is so you can go very low with your minimum margin. The idea behind it is that you can use the order amount already on the cart for your general costs. And see the extras as extras, i.e. new products that the customers tries, possibly winning back products that the customer in the meanwhile has bought somewhere else, and so on.
  • All this also means that a user with a lower price level can have a little influence on the margins, although this impact isn't big, again because of the kind of averages we work with.
The actual offers are in real text, using templates. You can provide as many templates as you want, the template to use will be chosen at random per offer. Within the templates, it's possible to include the users name (speak to him, make these offers personal !). At some time you can also analyse the offers made, offers clicked on, and offers for which orders were received. And possibly conclude which templates work the best for you (or in fact for your customers).

More information on request.