What Can Go Wrong With Data Management?

Luna ShirleyGeneral

What Can Go Wrong With Data Management?

Data management is one of the pillars of e-commerce marketing automation and this is the angle which we’ll be discussing in this article. Being able to trust the data that you have at your disposal to run marketing automation campaigns is as crucial as is their accuracy.

The key to building that trust is recognizing what could go wrong and mitigate its probability. Here are several of the most common issues with data management in regards to e-commerce marketing automation, which can go wrong.

Integration Issues

Severity: High

You should be cautious with 3rd party integrations. The more you have them, the higher the probability that something can go wrong may occur. You risk losing a portion of your data, its delay or in the worst case scenario, it may pollute your database by erroneous values.

What to do about it?

Make sure that you setup monitoring on any foreign 3rd party datastream and ensure you get alerts when your monitoring system detects an anomaly. If you are dealing with huge databases, automated early detection could save you from a disaster, which you, yourself wouldn’t detect otherwise.

The other possibility to mitigate integration issues and ensure that your data management is in order would be to collect the data from 3rd party integrations inside your data warehouse before you pass them in a single stream to your marketing automation database. This solution is viable, if you don’t need the data in near real-time (which you often don’t) and can detect issues before they pollute your marketing automation database.

Multiple Tracking Snippets

Severity: High

Sometimes, if there isn’t a single point of contact between marketing and IT departments, an implementation of multiple front-end tracking snippets can sometimes occur, which most of the times tracks double values into your database, completely polluting the data.

How to treat it?

Make sure that you have a single point of contact in your IT team who takes care of data management or approves any new tracking implementations on your site.

Also, every time after the new tracking implementation on site, verify whether the tracking snippets are implemented in your website’s code correctly and if possible, verify whether tracking values fit, at least within a certain tolerance, if you already have similar tracking in place.

Poorly Designed Data Structure

Severity: Medium

The data structure is the backbone of data management and governs how various data points are stored and manages the relationships with them. A poorly designed data structure could lead to data being stored inefficiently, reducing the performance of the database and that’s not even the worst.

Poorly designed data structures often lack critical data which weren’t specified when it was created due to underestimating the analysis of use cases which will be utilizing the database.

Furthermore, such poorly designed data structures are often hard or outright impossible to sensibly expand.

What to do about it?

Before you design any new data structure, be thorough with the identification of various campaigns and analyses which you would like to perform and try to map the new database structure in such a way that it will contain all the necessary data points and relationships between them.

Duplicate Data

Severity: Low to high

Duplicate data can occur with an increasing frequency the older and larger your database is and the cause is commonly the lack of transparency of the database structure.

In reality, it means that before checking whether the required data are already in the database, someone again requests its addition.

The issue that duplicate data causes tend to vary from low impact, where it’s being tracked as separate values, just increasing the size and complexity of the database, to highly impactful where for example customer purchases could be calculated multiple times completely wrecking your analyses.

What to do about it?

Make sure that you have an easily searchable database structure with descriptions of data points along with their sources and use cases which rely on them. Before implementing each new tracking request, make sure to review if the data already exists there.

An ideal option would be to have a single responsible person for the database, who would ensure that these duplicities won’t occur.

Saved Values As Different Type

Severity: Low

Sometimes when importing data or creating a new database structure, you can mistakenly define a new datapoint as a different type. For example text instead of integer to store numeric values. Such mistakes could impact your reporting or even completely disable some of your marketing automation scenarios.

How to treat it?

Fortunately, this data management threat is easy to solve. Changing the data type is rather easy and could be often done in your database administration.

Reliance On Front-End Tracking

Severity: Low to Medium

Front-end tracking, which often means triggering JavaScript to send customer behavior events to your database (think Google Analytics) is fragile and can break very easily with either any changes on your website’s front-end or even by customers who would be using ad blocking plugins.

The impact could vary from a simple case of missing a few data points during a single customer’s session to completely polluting your database with nonsensical values leading you to wrong business conclusions.

How to treat it?

Try to minimize the need to rely on your front-end tracking as much as possible to mitigate its volatility.

A common example could be tracking customer purchases using your CRM rather than logging purchases on your “thank you for purchase” page.

Missing Common Identifiers

Severity: Low

Marketing automation use cases tend to rely on the ability to match user behavior data with the product database. Ensuring that you keep the same identifiers across these databases is paramount if you want to utilize marketing automation.

Discrepancy often happens between product names within your product catalog which contains a plethora of metadata and product page visits with just a product name in a slightly different format than in your product catalog.

How to treat it?

After you implement the behavior tracking, make sure that these identifiers which enable you to connect the data across databases match.