Collection of behavioral analytics event data technically increasingly complex
If the number of data sources for event data wasn’t enough, especially browsers and mobile apps make it more difficult to collect data. Furthermore, non-traditional touch points, primarily non-digital ones, require proper planning and special techniques to derive data.
Lack of coordination and/or collaboration between the departments involved: IT, marketing, data
Analytics implementation usually span multiple departments: Event data is often owned by the marketing department, which takes requests from data teams and their own to the IT department. Recently, the legal department gets involved more often. This process is as complex as it sounds and needs to be actively managed.
A lot of additional downstream work due to source data not being modeled versatile enough
Often times, data is collected for one specific use case and then reused for additional use cases. The burden is then on data engineers, analytics engineers, and data scientists to adjust the existing data to their needs. This work is usually time-consuming and prone to error, sometimes resulting in huge hidden opportunity costs with a noticeable effect on the data initiative’s ROI.
Lack of focus: Similar data is often collected multiple times instead of once in high quality
The bigger the business the more likely that multiple departments or groups are collecting the same or very similar data multiple times. Because developer resources are limited, such implementations usually lack quality. This is not only a waste of resources but usually also results in competing data sets because of errors and different data models. Not having a single source of truth often leads to even more friction on the business side.
Implementation prone to break when developers add new features: Missing data, schema changes, etc.
Most analytics implementations are adding a layer on top of existing applications instead of integrating with the application. An added layer can work in the beginning but eventually the underlying application will change without the layer being adjusted accordingly. Furthermore, an analytics layer is always more prone to error than analytics integrated into the application. But in either cases developers can change data schemas resulting in issues downstream.
Developers usually overwhelmed by amount of requested event data, competing for limited resources
The business side usually needs the help of the IT department to collect data. But they are not the only ones trying to access these often times very limited resources. That’s why it is important to make it as easy as possible for developers to collect data. Due to a lack of understanding, many non-developers go to developers with confusing requirements, so speaking the same or a similar language always works better.
Moral hazard when service providers charge by the hour and not for high-quality data
Theoretically (and, unfortunately, we have seen this many times), when charging by the hour, it can be beneficial for service providers to cause as much chaos and overhead as possible to maximize their own profits at the expense of their customers that trust them. This issue can only really be solved by aligning the service provider’s goals with the goals of the customer. Generally speaking, there should not be an incentive for the service provider to increase the number of people and/or billable hours.
Increasingly strict privacy laws and more scrutiny from the legal department
Business in Europe had strict privacy laws for many years now, but more and more US states are creating similar privacy laws, sometimes even taking European laws as blueprints. Through there is nothing similar on the federal level yet, businesses that operate US-wide have should align their data strategy with the strictest privacy regulation. Contrary to popular belief, compliance often times doesn’t is possible without negative effects on the data use case, if things like partial anonymization, pseudonymization or cohorts are used, for example.
Jeopardizing long-term data stability and ROI with short-term fixes and “quick wins”
One of the recurring theme with businesses of all sizes is a focus on short-term wins over long-term value, although most data initiatives are rather strategic and data professionals usually stick with the company longer than coworkers from other disciplines. This kind of prioritization doesn’t make sense on the level of individual contributors, but it doesn’t even make sense at the management level, because they are usually around for a bit longer, too.