Mobile navigation

FEATURE 

One big honeypot

Your data assets are spread here, there and everywhere:- circulation system, ad manager’s PC, web server, box of cards under your desk, Janet’s bottom drawer. Bring them altogether and you have a valuable asset. James Evelegh looks at some of the dos and don’ts of setting up a marketing database.

By James Evelegh

Marketing databases are sexy and glamorous – relatively speaking. Everyone wants one and everyone should have one – shouldn’t they?

Well yes and no. Yes if you plan to do it properly, but no if there is a good chance of you messing it up. Peter Kempsey, md of Adare Intellidata says "a well designed and managed database is an essential tool in the modern business world, enabling organisations to derive real value from their data assets." However he says, the flip side is that "poorly designed and managed, a database can be a burden, sapping resources and stifling effective marketing communications."

There are two types of database: operational and marketing. The operational ones are the mainstay of the company and are the ones that actually do things; process orders, produce mailing labels, churn out renewals. According to Charles Ping, head of customer relationship management at The Guardian, the marketing database is "a database to hold all information and correspondence about an individual in an easy-to-manage system – usually a single database". Typically a marketing database will sit on top of all the operational databases and be updated by a series of data feeds from them.

Should every company have a marketing database? No. Single title publishers with no ancillary products as well as multiple title publishers whose titles do not overlap would certainly not benefit from one. A marketing database works best where there are multiple related products handled by the publisher or as Ping puts it "where there is the same audience coming to you through different channels". A publisher with a number of related titles, an exhibition and an awards night would be "absolutely daft" not to have a marketing database.

So the first question you should ask yourself is: do I have multiple related products? If the answer is no, then you can stop reading now. If the answer is yes then the next key question is, according to Ping, "do you want to make more money out of your existing customers – do you want to increase your share of their wallet?" I’ll take that as a yes.

One myth to dispel is the notion that marketing databases are only within the reach of the really big publishers. Figures, taken out of context are meaningless, but Charles Ping says that it is "not a hugely expensive game". Garry Olive of Qbase Data Services maintains that "any publisher, irrespective of size, can take advantage of the benefits of a marketing database."

According to Kempsey, marketing databases give publishers a "better understanding of customer buying behaviour, leading to increased sales, through accurately targeted up sell and cross sell activities, longer retention and better RoI from the customer base." The cross selling / upselling benefit is echoed by Olive who also thinks that they "can guide the development of the product offering, by shaping content through knowledge and provide valuable support to editorial". Another very obvious benefit is the increased potential for list rental achieved by having all your customers in one pot and therefore more easily accessible.

In addition to the greater revenue opportunities there will be considerable cost savings through increased marketing efficiencies. Furthermore a better awareness of the worth of a customer enables you to quantify the cost of losing a customer and allow resources to be allocated to prevent this.

According to Ping, the Nirvana moment for marketing databases is the single view of the customer. Not many publishers have got there yet, but if achieved it allows for fantastic levels of customer service. One of the complexities of using the marketing database for customer service is that it blurs the distinction between operational and marketing databases, with the marketing database taking on some operational functions. Where this becomes problematic is that this model of customer service necessitates a two way flow of data; hitherto all the dataflows have been from the operational databases into the marketing. If you are to start capturing information on the marketing database (for instance gone aways, mailing suppression preferences etc) then that information will have to feed back to the operational database otherwise the recently deceased will continue to get their early bird reminders.

Three routes to success

Broadly speaking there are three options when it comes to setting up a marketing database. Firstly you can buy the technology and run it inhouse, secondly you can buy the technology but have it managed by a third party (like Qbase, Adare Intellidata or Coad, Cole & Burey) or thirdly you can build it from scratch yourself. Some people think that there is a fourth option: and that is adapting one of your existing operational databases. Whilst not impossible Charles Ping says that it is "inordinately difficult to turn an operational database into a marketing database – especially in the area of complex analyticals".

The Guardian went down the self build route. Whilst happy with his decision Charles Ping urges caution. To build a marketing database from scratch a publisher needs to be extremely confident of their project management skills, have an excellent understanding of marketing databases and lastly the company must have a very robust IT department and infrastructure. At the very least a publisher would need an expert consultant onboard.

The Guardian put together a project team headed by Ping and which included a freelance Oracle contractor and an in-house team. One critical aspect was the design of a good robust database model and for that Ping advises publishers to buy in specialist skills and resources. The kind of person who has handled such projects before and is well schooled in Oracle implementations is unlikely to be already on your books.

Two critical factors in the Guardian’s success were the buying in of specialist skills and giving this team the time and space to do the job. Typically the problems associated with in-house implementations are a lack of specialist skills and relevant experience of major database build projects and project teams not being able to extricate themselves from their operational tasks.

The Guardian went for an Oracle database and bought in a small number of third party products such as Capscan for address reformatting and Viper as a reporting and extractions tool. Read-only access has been given to a large number of marketing staff, although data loads and extracts are closely controlled by the CRM team.

As with any large capital expenditure the start point will be to quantify benefits – including a financial justification. If the likely increase in revenue and / or reduction in costs do not considerably outweigh the costs then the project should be aborted. Once the project has been justified then you will need to decide whether to outsource the project or to build it in-house. This is the crunch question; remember that you shouldn’t even consider the in-house route unless you really do have an all-singing, all-dancing IT department. There are two other major implementation steps, one technical, one attitudinal. The technical one is identifying the various operational databases used by your organisation and making sure that they can produce data feeds at regular intervals into the marketing database. The attitudinal one involves "buy in". A marketing database is only as good as the marketers who use it, and if they don’t use it then you will end up with one big white elephant on your hands. What is more a marketing database can only thrive if it has the full-hearted backing of senior directors. Garry Olive advises "securing the buy-in from the end users and involve them throughout the process", whilst Peter Kempsey advises that the internal project management team should include all stakeholders as well as a senior director.

Database development never stops

So move yourself forward 12 months; you have successfully installed a gleaming new marketing database, the world is your oyster, what could possible go wrong? Well a number of things actually – and they frequently do!

One of the main causes of these projects turning sour is the belief that the hard work stops at go-live. This often manifests itself in a sharp reduction in the amount of resource dedicated to the marketing database and a dropping off in the areas of training and team motivation. Kempsey says that problems often arise "from failure to train and motivate their users". This "leads to ineffectual use of the resource and ultimately the systems will fail to deliver the anticipated business benefits."

Too often companies fail to feed their investment. Gary Olive says that "the development of a database is only the starting point, once you’ve got it, you need to use it to drive your activity". The database requires ongoing management time and must be encouraged to evolve to prevent it becoming obsolete. This same dropping off can also be seen in data maintenance. Prior to completion of the project great efforts are put in to validate the data sources to ensure that on go-live the data is in top condition. Unfortunately too often that care is not carried through into the future. Again, too often as a result of skimping, companies fail to maintain their data properly leading to data degradation and declining effectiveness. Kempsey has a nice take on the "rubbish in / rubbish out" mantra: "its no good having an F1 car and running it on 2 star fuel!"

To summarise: if you have lots of data sources from related product areas then you probably would benefit from a marketing database. Unless you have an extremely strong internal IT resource don’t even consider building one yourself – go to the experts. Make sure senior directors and data users buy into the project from the start. Be honest about your forecasting – any budget that does not contain sufficient resource to ensure ongoing development and maintenance of the database should be chucked out. Lastly – never think the job is done.

For some companies not to have a marketing database would be a disaster, but so too would be having a bad one. This leaves just one option: a well designed, lovingly maintained and continually evolving marketing database. The potential benefits from getting it right are enormous, but be prepared for the long haul.