If you’ve done much research about data layers, you’ve probably noted that naming conventions and data layer structure vary from data layer to data layer.
For example, you could see differences in:
- data_layer vs. dataLayer vs. digitalData vs. utag_data
Variable naming conventions of sub-objects
- pageTitle vs. pageName vs. pageID
- pageID vs. pageId vs. page_id
- Flat vs. multi-level
- One data object with sub-objects vs. multiple data objects inside an array
All this variation in naming, formatting and structure should show you one thing: there are lots of ways to implement this critical code.
So what conventions and structure should you use?
The Data Layer Structure Discussion
Here are a couple questions to help you prepare for this discussion with other stakeholders:
1. What tag management solution are you using?
That being said, most tag management solutions allow you to customize variable names and structures. Ali Benham, co-founder of Tealium, said concerning the relationship between a TMS and a data layer, “We strongly feel that the TMS product should be able to accommodate customer preference, and not vice-versa” (Source).
If for some reason the format of your TMS’s default data layer does not match your business rules, you should be able to make the necessary customizations.
If you don’t have a TMS or aren’t planning on implementing one, but still want a data layer, the Customer Experience Digital Data Layer (CEDDL) specification is a great place to start.
2. What do your internal resources look like?
There will be two parties that will be the principal stakeholders responsible for creating and applying the data layer—developers and digital marketers/analysts.
Because the developers are responsible for the initial implementation, they may have more say as to what naming conventions are used—lowercase vs. camelCase, underscore vs. no underscore, etc.—as well as structural preferences.
But since marketers and analysts will be the end users linking their third-party vendor applications back to the data layer, it’s important to involve them in the conversation to see what will be the most intuitive for them.
For example, using all lowercase with underscores (e.g. page_id) instead of camelCasing (e.g. pageID) might be easier for non-developers to read and work with, mitigating the risk of error.
As to structure, you should take into account the complexity of your technologies. A flat structure works well if you don’t have a large amount of data points, and can be easier to read. On the other hand, a multi-level, nested or hierarchical data layer structure allows developers to sort data into different buckets with consistent categories. This structure works well if you have a lot of different data points that can nest within each other.
Trustworthy data is a consequence of proper data governance and the bedrock of effective decision-making. Establishing best practices for maintaining the data layer will further enhance your confidence in your data. As you consider implementing or updating your data layer, consider implementing a data layer auditing tool that can validate the functionality of your data layer.
Because if it’s worth implementing, it’s worth maintaining.
About the AuthorLinkedIn More Content by Jason Call