6 More Thorny Data Problems That Vex B-to-B Marketers, and How to Solve Them

B-to-B data continues to challenge marketers, who need to identify and communicate with customers and prospects, but who run into thorny issues every day. Problems range from duplicates, to key-entry errors, to missing data elements, and beyond. Recently, Bernice Grossman and I worked with a group of savvy B-to-B marketers at a DMA conference to compile a list of difficult data problems. Here are six that will bring tears to your eyes—but don’t worry, we also offer some solutions.

B-to-B data continues to challenge marketers, who need to identify and communicate with customers and prospects, but who run into thorny issues every day. Problems range from duplicates, to key-entry errors, to missing data elements, and beyond. Recently, Bernice Grossman and I worked with a group of savvy B-to-B marketers at a DMA conference to compile a list of difficult data problems. Here are six that will bring tears to your eyes—but don’t worry, we also offer some solutions.

  1. How do I find out the names of individuals who visit my website?
    There are two ways to de-anonymize the website visit. First, add a registration invitation to your site. This could be an email sign-up, or a piece of gated content, like a white paper or research report, in exchange for providing important data elements like name, title, company name, address, phone and email.
    Second, use the IP address to identify the company from which the visitor arrived. This can be done by hand, using Google Analytics, or more easily by using any number of services that enable IP address look-up. Marketing automation systems are increasingly baking this option into their tools.

    But the IP address method will still not get you the name of the visitor. You can infer the visitor’s interests and, possibly, role by looking at the time spent on various pages. And you can drop a cookie and retarget the visitor with text or banner ads later.

  2. Job titles are increasingly inconsistent-and proliferating. Categories like marketing manager and financial analyst don’t seem to work anymore.
    Several companies offer job title standardization services, called something like title mapping, title translation or title beautification. A resource like that is a good first step.

    Then, consider sending an outbound email, perhaps with a follow-up phone call, positioned as a “contact verification” message. Invite the target to indicate his or her functional job title, from a list.

    After that, you will be left with a relatively smaller list of remaining titles. At that point, you need to decide on a default for the rest of them. For example, anything that sounds like IT will go in an IT functional bucket. And, depending on how often you query your customers, you can always gather answers to this question over time.

    Then, you are faced with the remaining issue, which is far more difficult, namely the crazy new titles that some people are using these days. We’ve seen bizarre titles like Chief Instigating Officer and Marketing Diva. With these, you have two options.

    • Force aberrant titles into your standards, by hand, using your best guess. Use a default code for anything you can’t really figure out.
    • Leave them as they are, and link them to a table of standardized job functions. But maintain the self-reported wacky title, too, so you can still address the person the way he or she wants to be addressed.

    You might also consider using forced drop-down menus for job function and job title, at the point of key entry.

  3. How should I handle job changes? When an employee leaves and goes to another company, does his or her history with my company go along?
    We are going to assume—a big assumption—that you actually know the person has gone to a new company. It’s more likely that you will not know. This is why it’s a good idea to do periodic de-duplications by functional title to get a sense of new names that have popped up at the companies in your database.

    When you know that there is a job change and you have the new information, you must move the contact to the new company in your database. It’s a good idea to send along behavioral data like communications preferences. You might also add a LinkedIn profile URL to the record. If you believe the prior behavioral data is important, then take it as a duplicate, and put it in a separate field, not attributing it to the new company record.

    The purchase history belongs with the original company, and should stay there. Indicate in the company record that the individual has left.
    As a general rule, in marketing databases, never overwrite. Keep everything data stamped.

  4. We want our sales people to be selling, and keep administrative tasks to a minimum. But these people are also the closest resources to our customers. How can we motivate them to capture important data about the customers and prospects they are interacting with?
    Boil down the mission to just one or two key data points that reps are asked to collect and report. Job title, buying role and email address are among the most likely to change, and perhaps the most important to keep current. Train and reward the reps on consistent reporting on the selected elements.
  5. In an effort to improve web-form response rates, we are asking for only name and email address. What’s the best way to create a company record in this situation?
    We recommend that you consider hiring a service that will fill in the company record on the spot, as a start. Or send the file out to a third party compiler to append the records you need.

    Another way is to parse the email address. Take the letters after the @ and before the .com. For example, if the email is formatted as firstname.lastname@hp.com, the meaningful letters are hp. Search for other emails with these letters in this position in your file, and build a business rule that every email with these letters shall be assigned that company name. If you have a standard record on your file, import it.

    If the email address is a generic one, like gmail.com or yahoo.com, it’s more difficult. Email the prospect and ask for more data. You could also consider preventing email addresses other than those from company domains from being accepted on the web form. But keep in mind that there is some evidence that individuals filling out web forms with personal email addresses tend to be more responsive over time.

  6. We need to get our international customer data under control. Where should we start?
    First, add country name as a required field in your web forms and other response vehicles, so that future data collection will be set. Use a dropdown menu to improve capture of a standardized country name. Prevent the record from moving forward until the country is specified.

    Then, look at what parts of the world you do business in. Estimate how many countries, and how many customer records in each country, so you can see how big an issue this is.

    Then, figure out which records in the database are non-U.S. This will take some effort. Many databases don’t have a non-domestic indicator. There is no easy way around it.

    Country names are increasingly important as laws change. Consider Canada’s onerous new email law, which requires proven opt in before emailing. You can’t assume that those email addresses ending with .ca are the only Canadian emails on your file. One suggestion is to update your web forms with a message like “If you are in Canada, opt in here.”

You can find more thorny data issues and solutions in our new white paper, available for free download. Please submit any other issues you may be facing, using the comments section here, and we’ll be happy to suggest some solutions.

Updating Your Marketing Database

It’s amazing how quickly things go obsolete these days. For those of us in the business of customer data, times and technologies have changed along with the times. Some has to do with the advent of new technologies; some of it has to do with changing expectations. Let’s take a look at how the landscape has changed and what it means for marketers.

It’s amazing how quickly things go obsolete these days. For those of us in the business of customer data, times and technologies have changed along with the times. Some has to do with the advent of new technologies; some of it has to do with changing expectations. Let’s take a look at how the landscape has changed and what it means for marketers.

For marketing departments, maintaining updating customer data has always been a major headache. One way to update data is by relying on sales team members to make the updates themselves as they go about their jobs. For lack of a better term, let’s call this method internal crowd-sourcing, and there are two reasons why it has its limitations.

The first reason is technology. Typically, customer data is stored in a data hub or data warehouse, which is usually a home-grown and oftentimes proprietary database built using one of many popular database architectures. Customer databases tend to be proprietary because each organization sells different products and services, to different types of firms, and consequently collects different data points. Additionally, customer databases are usually grown organically over many years, and as a result tend to contain disparate information, often collected from different sources during different timeframes, of varying degrees of accuracy.

It’s one thing having data stored in a data warehouse somewhere. It’s quite another altogether to give salespeople access to a portal where the edits can be made—that’s been the real challenge. The database essentially needs to be integrated with or housed in some kind of tool, such as an enterprise resource planning (ERP) software or customer relationship management (CRM) software that gives sales teams some capability to update customer records on the fly with front-end read/write/edit capabilities.

Cloud-based CRM technology (such as SalesForce.com) has grown by leaps and bounds in recent years to fill this gap. Unlike purpose-built customer databases, however, out-of-the-box cloud-based CRM tools are developed for a mass market, and without customizations contain only a limited set of standard data fields plus a finite set of “custom fields.” Without heavy customizations, in other words, data stored in a cloud-based CRM solution only contains a subset of a company’s customer data file, and is typically only used by salespeople and customer service reps. Moreover, data in the CRM is usually not connected to that of other business units like marketing or finance divisions who require a more complete data set to do their job.

The second challenge to internal crowd-sourcing has more to do with the very nature of salespeople themselves. Anyone who has worked in marketing knows firsthand that it’s a monumental challenge to get salespeople to update contact records on a regular basis—or do anything else, for that matter, that doesn’t involve generating revenue or commissions.

Not surprisingly, this gives marketers fits. Good luck sending our effective (and hopefully highly personalized) CRM campaigns if customer records are either out of date or flat out wrong. Anyone who has used Salesforce.com has seen that “Stay in Touch” function, which gives salespeople an easy and relatively painless method for scrubbing contact data by sending out an email to contacts in the database inviting them to “update” their contact details. The main problem with this tool is that it necessitates a correct email address in the first place.

Assuming your salespeople are diligently updating data in the CRM, another issue with this approach is it essentially limits your data updates to whatever the sales team happens to know or glean from each customer. It assumes, in other words, that your people are asking the right questions in the first place. If your salesperson does not ask a customer how many employees they have globally or at a particular location, it won’t get entered into the CRM. Nor, for that matter, will data on recent mergers and acquisitions or financial statements—unless your sales team is extremely inquisitive and is speaking with the right people in your customers’ organizations.

The other way to update customer data is to rely on a third-party data provider to do it for you—to cleanse, correct, append and replace the data on a regular basis. This process usually involves taking the entire database, uploading it to an FTP site somewhere. The database is then grabbed by the third party, who then works their magic on the file—comparing it against a central database that is presumably updated quite regularly—and then returning the file so it can be resubmitted and merged back into the database on the data hub or residing in the CRM.

Because this process involves technology, has a lot of moving parts and involves several steps, it’s generally set up as an automated process and allowed to run on a schedule. Moreover, because the process involves overwriting an entire database (even though it is automated) it requires having IT staff around to supervise the process in a best-case scenario, or jump in if something goes wrong and it blows up completely. Not surprisingly, because we’re dealing with large files, multiple stakeholders and room for technology meltdowns, most marketers tend to shy away from running a batch update more than once per month. Some even run them quarterly. Needless to say, given the current pace of change many feel that’s not frequent enough.

It’s interesting to note that not very long ago, sending database updates quarterly via FTP file dump was seen as state-of-the-art. Not any longer, you see, FTP is soooo 2005. What’s replaced FTP is what we call a “transactional” database update system. Unlike an FTP set-up, which requires physically transferring a file from one server and onto another, transactional data updates rely on an Application Programming Interface, or API, to get the data from one system to another.

For those of you unfamiliar with the term, an API is a pre-established set of rules that different software programs can use to communicate with each other. An apt analogy might be the way a User Interface (UI) facilitates interaction between humans and computers. Using an API, data can be updated in real time, either on a record-by-record basis or in bulk. If a Company A wants to update a record in their CRM with fresh data from Company B, for instance, all they need to do is transmit a unique identifier for the record in question over to Company B, who will then return the updated information to Company A using the API.

Perhaps the best part of the transactional update architecture is that it can be set up to connect with the data pretty much anywhere it resides—in a cloud-based CRM solution or on a purpose built data warehouse sitting in your data center. For those using a cloud-based solution, a huge advantage of this architecture is that once a data provider builds hooks into popular CRM solutions, there are usually no additional costs for integration and transactional updates can be initiated in bulk by the CRM administrator, or on a transaction-by-transaction basis by salespeople themselves. It’s quite literally plug and play.

For those with an on-site data hub, integrating with the transactional data provider is usually pretty straightforward as well, because most APIs not only rely on standard Web technology, but also come equipped with easy-to-follow API keys and instructions. Setting the integration, in other words, can usually be implemented by a small team in a short timeframe and for a surprisingly small budget. And once it’s set up, it will pretty much run on its own. Problem solved.