Deciding on Data Layer Design, Structure, and Variable Naming Conventions

Deciding on Data Layer Design, Structure, and Variable Naming Conventions

 

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:

  • Variable naming conventions of the main JavaScript object: A data layer object could be called anything like data_layer, dataLayer, digitalData, or really anything at all.
  • Variable naming conventions of the object’s keys: pageTitle vs. pageName vs. pageID.
  • Formatting conventions: pageID vs. pageId vs. page_id.
  • JavaScript Object structure: e.g. flat vs. multi-level, one data object with sub-objects vs. multiple data objects inside an array.

Even the term “data layer” is not always the preferred term—alternate names include the Universal Variable and Universal Data Object, or just the generic JavaScript Object (JSO).

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?

If you utilize a tag management system (like Google Tag Manager or Adobe Launch), your TMS should already have default data layer conventions. This includes variable/key names, structure and even the name of your JavaScript object itself. If you choose to go with your TMS’s default data layer style, this can help simplify the process of pre-implementation planning.

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.

The Importance of Testing Your Data Layer

Because the data layer does not exist in a vacuum, errors in the data layer can occur that impact the quality of the data. Despite your best efforts to define a clear structure and naming conventions, having different teams all working together on a single analytics and marketing implementation will result in inconsistencies.

As such, regularly testing your data layer against your standards of naming and structure will help you ensure the integrity of your data layer and the data it distributes.

If a data layer is worth implementing, then it’s worth maintaining.

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 tool that can validate the functionality of your data layer.

See how ObservePoint can run a site-wide audit of your data layer against your defined standards.

Related Posts

ObservePoint Makes UV50 List for the 4th year

SILICON SLOPES, Utah – October 6, 2022 – Utah Valley BusinessQ Magazine has announced that ObservePoint has been honored for the fourth year in a row as one of the fastest-growing companies in Utah Valley. ObservePoint is ranked #29 on their UV50 2022 Fastest-Growing Companies list. The UV50 Fastest-Growing Companies list awards companies based on…
Read More

ObservePoint to Sponsor & Attend #RISK

SILICON SLOPES, Utah – (October 19, 2022) – ObservePoint is proud to be a sponsor and to join a panel discussing Privacy Litigations at #Risk in London on November 16-17, 2022. ObservePoint will be sponsoring and participating in the GRC World Forum #RISK. Stop by our booth for a game of cornhole and to receive a free…
Read More

Website Privacy (6/6): Are requests coming from unauthorized countries, regions, or domains?

If you’ve followed along with our privacy validation series, you know that we’ve discussed auditing privacy policy link presence, “do not sell/share” link coverage, cookie consent banner tag presence, whether or not the consent management platform (CMP) is respecting user preferences, and where new or unapproved cookies are showing up on your site. The final question we address in this series is, “Are there network…
Read More

ObservePoint Named on MWCN’s 2022 Utah 100

SILICON SLOPES, Utah – October 17, 2022 – ObservePoint has been named on the 2022 Utah 100, MountainWest Capital Network (MWCN)’s annual list of the fastest-growing companies in Utah. ObservePoint ranked #81 on the list and was honored at the 28th annual Utah 100 Awards program, held at the Grand America Hotel in Salt Lake City.…
Read More

ObservePoint Makes UV50 List for the 4th year

SILICON SLOPES, Utah – October 6, 2022 – Utah Valley BusinessQ Magazine has announced that ObservePoint has been honored for the fourth year in a row as one of the fastest-growing companies in Utah Valley. ObservePoint is ranked #29 on their UV50 2022 Fastest-Growing Companies list. The UV50 Fastest-Growing Companies list awards companies based on…
Read More

ObservePoint to Sponsor & Attend #RISK

SILICON SLOPES, Utah – (October 19, 2022) – ObservePoint is proud to be a sponsor and to join a panel discussing Privacy Litigations at #Risk in London on November 16-17, 2022. ObservePoint will be sponsoring and participating in the GRC World Forum #RISK. Stop by our booth for a game of cornhole and to receive a free…
Read More

Website Privacy (6/6): Are requests coming from unauthorized countries, regions, or domains?

If you’ve followed along with our privacy validation series, you know that we’ve discussed auditing privacy policy link presence, “do not sell/share” link coverage, cookie consent banner tag presence, whether or not the consent management platform (CMP) is respecting user preferences, and where new or unapproved cookies are showing up on your site. The final question we address in this series is, “Are there network…
Read More

ObservePoint Named on MWCN’s 2022 Utah 100

SILICON SLOPES, Utah – October 17, 2022 – ObservePoint has been named on the 2022 Utah 100, MountainWest Capital Network (MWCN)’s annual list of the fastest-growing companies in Utah. ObservePoint ranked #81 on the list and was honored at the 28th annual Utah 100 Awards program, held at the Grand America Hotel in Salt Lake City.…
Read More