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:
- 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.
- 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.
- 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.
- 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.
|