Building a dynamic data layer is not easy, it has various complexities based on your websites design, back end frameworks and libraries and present difficulty in figuring out when and how to present it to the browser.

1. BestPractices
ForBuildingADynamicDataLayer
MikePlantSearch Discovery
Senior Implementation
Consultant
ObservePoint
Senior Analytics Data
Expert
JasonCall

2. WHAT IS A DATALAYER?
And why do I want one?
JASON will introduce - object - properties

4. Jason - what does the data layer do
Holds data in a non vendor specific way for use by all vendor tags

5. WHAT INFORMATION GOES IN
THE DATA LAYER?
• Page information
• Product Information
• Cart andTransaction Information
• Component Data
• User Information
• Access control for enforcing data security
thanks jason thats a good overview now lets get into what data goes into the data layer
complexity of commerce implementations always warrants the use of specific types of information
page information - common in all websites - page name, page type, and other meta information
commerce implementations have a growing need for information -
product detail pages - price, skus, ratings
cart and transaction data - trying to get this data to vendors is always cumbersome - products in the cart, coupon, totals and
shipping/tax costs
components - videos, banners,
user info - profile data, type of user and often geolocation
you can even think about data security and strive to enforce access control
why put all this in a datalayer when its already in the html. - in tag management systems dom scraping is clunky and often
actually counters against front end development standards and best practices by needing ID/classes that are tied to data type/

6. So who should be involved in data layer creation?
The people that need involved might never have heard of the data layer. You may be faced with confusion, bewilderment and
maybe even opposition - but I’d like to assure you that this is no longer just a buzzword - search discovery has adopted client
developed data layers as a best practice when implementing tag management systems to provide consistent data to analytics
and other vendors.
Depending on your requirements it will ultimately change who is responsible for what parts of your data layer but the reality is
almost everyone will and should be involved: Marketing professionals who often request vendor tags, Analytics experts and
business executives who rely on data collection, and the developers - who are already owners of the data production will
contribute to feasibility discussions and in the end will the one’s that ultimately produce the output of the data layer.

7. –Benjamin Franklin
“If you fail to plan, you are planning to fail.”
The key to any successful implementation is thorough planning

8. With the complexity of websites today and the multitude of data tracking requirements - thinking about what data to expose and
how to expose that data is the necessary first step.
To simplify this process, we have to find a meaningful and understandable way to create technical specifications and produce
deliverables that will govern data models and help maintain information accuracy.

9. One of best ways to start planning is to think about the data layer as it pertains to different page types.
In an commerce example different page types will contain different object properties and sub-objects to inform vendors of
varying requirements: landing pages, product listing pages(filters/sorting) and checkout flow - to re-engage users with
abandoned carts and tracking conversions - each page type will have unique data points it should offer.
page types division is a common principal used in various areas of a web properties project lifecycle, from discovery and
designing and beyond into development. your Stakeholders are likely already familiar with this concept and so that makes it an
ideal place to begin data organization - the stepping stones for further conversations into use cases and other business
requirements.

10. Future Requirements
As your website develops and changes so will your data layer - this is why we refer to it as a dynamic - agile data model. As
requirements are changed and developed over time - your data layer will be as well.
It is dynamic in the way that each page type will expose varying data points but each page will also carry different data based on
user journey and interactions.
As the demand for page-less and more seamless interactive web application grows, how and when you interact with your data
layer will as well.

11. STANDARDS
• Naming conventions
• Sub objects - arrays
• Logical structure
• Structured Models
Best practices start with well defined standards - following the W3C specification for data layers encourages a standard across
all web properties and encourages a more consistent approach to development. This structure will help guide the development
team during implementation and ensure a higher rate of success and continuity.
First and foremost we must adhere to strict naming conventions: ensure object properties do not contain spaces, start with
numbers or have specials characters. The use of camel casing is considered best practice and should be encourage to enhance
readability.
Sub objects and arrays are nested to encourage a logical structure of the data - arrays can hold lists of objects or string
depending on your data needs.
While the W3C spec gives a strong foundation, each web property is unique. Event the tag mangement systems being used are
each unique: Google Tag Manager has it’s own data layer development guide and principles, Tealium defines a more flattened
structure but also supports a W3C data layer to encourage standardization.
So i have touch a few times on data modeling, a large part of the planning process should be the development and design of

12. This simple example - came from the w3c spec and shows populated object properties and sub object properties. If this is your
first glance at a data layer let’s review some key terms we use when verbalizing the data layer.
The first line is the assignment of the data layer object, denoted by curly braces in Javascript to a global variables named
digitalData - you can call this anything you want but this has become a standard named used widely today. Clients may already
have global objects and it it also acceptable to use a subject if and when appropriate.
pageInstanceID is a simple object property - exposing a string value
The page and pageInfo, category, and attributes are examples of sub objects and each with it’s own properties
during the modeling exercises it will inevitably grow in size and complexity but it is important to follow the specification as it
pertains to overall structure. variance from this will cause confusion and often create errors

13. This is a portion of a more complex data model.
this sample has the same structural components reviews on the last slide but contains many more properties and sub objects -
and the introduction of arrays - square brackets denote an array and is commonly use for a list of items.
you can also notice the comments and that there are no sample values in the strings - notes can aid in development and define
expected values per line but you should also begin the process of defining a data layer specification guide with page types and
use cases and business requirements included

14. So how do we do this - technically speaking? The answer is actually seemingly simple - keep doing what you do best or if your
not a developer - let your developers keep doing what they do best!
As we know all web sites are construction with HTML, CSS and Javascript and more than likely you are already manipulating
your data into this html markup and I imagine using objects to do so.
While the website you see is the same not all server languages are the same and that is where your developers should
encouraged to continue using the object oriented programming languages they know and love. They should develop the data
layer object on the backend.
Whatever language your server is using, build your data layer in the language you work in every day, create your objects,
properties and sub objects - fill them up with your data. This will avoid errors further down the line as they will be exposed during
the backend development phase.
Most of you are already printing vendor tags today, so all the data you need is readily available to you in your current templates.
The difference a data layer imposes is that instead of trying to cobble together a bunch of different front end scripts( uses strings

15. Using PHP as a basic example this code shows the construction of a data object in the backend using server side coding - in
this case a basic associative array is built out
this code shows how to set properties - sub objects - mixing and matching the data needed to the appropriate fields by using
the data models defined earlier.
then in one step a function named json_encode(in php) is called to convert the digitalData object created in PHP and transform it
into a JSON string - that when assigned to a variable in a javascript tag - becomes the global data layer object.
now there are complexities(character encoding issues, and formatting) so lets not over simplify - but in the end this is relatively
similar in most server side code - C#( can use JavaScriptSerializer ) and JAVA has similar libraries GSON among many others to
name a couple server languages.

16. InitialRequest
Response
BROWSER
SERVER
HTML Page
Datalayer
At this point you have used your data models to build objects in the backend and now output that data layer to the front end and
it is really just part of the document object now. On page load the data object is embedded in the html without being visible to
the user but tag management systems and other vendors tags can begin to utilize this data.
Most of this so far focused on page type - page load data layer properties - but there is something else that we have to also
begin to consider. And this goes all the way back to the planning and business requirements as well.
Events - what we consider a data layer event is when an interaction that requires a server side response takes place - ajax form
submissions, filtering/updating listing pages.

17. InitialRequest
Response
BROWSER
SERVER
HTML Page
Datalayer AJAX Event
Request
Response
Events - what we consider a data layer event is when an interaction that requires a server side response takes place - ajax form
submissions, filtering/updating listing pages and other real time server interactions that do not always warrant a separate page
load.
The timing of these types of events can create complexities with vendors and therefore require additional efforts to update and
manipulate the data layer after the page has loaded. These events are handled in a similar way and most of the time you may
already be working with JSON and need to add Javascript code to push this event information into the events array and update
the data layer.

18. Page load timing is also important.
The question you need to answer is how early in the page load do I need this data?
With certain tools like A/B testing or audience manager you might need it right away in the head of the document, for other tools
like adobe analytics and other vendors may not fire until the bottom of the document object.
Often we see data that is not even available until after page load occurs. All of items these must be considered when planning
and also building the data layer.
Where you output the object is very important.
As a javascript object simply embedding it in the page you are not adding any extra requests or much overhead to the overall
size of your web page.

19. InitialRequest
Response
BROWSER
SERVER
CACHE
Datalayer
Another sometimes overlooked scenario is web page caching, as traffic grows and the load on your server increases many
implementers will utilize caching.
How do we accommodate a datalayer that is going to be statically retrieved? what about user information, segmentation and the
events we just mentioned?

20. InitialRequest
Response
BROWSER
SERVER
CACHE
Datalayer Datalayer
Request
Response
The answer is to separate your data layer into chunks, the static portion is tied to the page type can be static and embedded in
the markup on the page. The dynamic data that may be tied to the user or other constantly updating data would come in
separately - typically we handle this using an event type scenario.

21. The answer is to separate your data layer into chunks, the static portion is tied to the page type can be static and embedded in
the markup on the page. The dynamic data that may be tied to the user or other constantly updating data would come in
separately - typically we handle this using an event type scenario.

22. with proper planning, structured data models and backend implementation you hopefully can avoid most of the common errors
we see during implementation.
Typically these problems come from
not following naming conventions - spaces or unenclosed values
not adhering to the standards - missing commas or objects are formatting incorrectly (stemming from trying to build strings
instead of outputting objects as described earlier)
and finally values are important - the type of value expected - string, sub object vs array and so on are all common problems
compare against your data models

23. use the console - comparing to data model

24. json validators
it’s just javascript object notation

25. governance is important
you planned it - organized your data - built out models to validate against and now you have to think about maintaining that
data, improving it and tracking it over time

26. FUTURE
things will change

27. FUTURE
they always do
keep your code modular and think about this as you develop
accept that the data layer is a living breathing data object and use tools to help you monitor, maintain and improve it

28. document requirements, use cases and provide complete data models - this will keep the stakeholders involved and responsible
and will help maintain governance over the data layer as it changes.
Provide insight into complex use cases and business requirements and explain in detail the data and it’s needs and current state
at different times during the user journey

29. REQUIREMENTS
• Data inventory
• Stakeholder objectives
• Events and Use Cases
• Feasibility Review
IMPLEMENTATION
• Standards
• Data models
• Development
• Validation
GOVERNANCE
• Documentation
• Modification
• Maintenance
• Monitoring
DATA
LAYER
following these guidelines will ensure you succeed - review slide content above
soon we will be providing more thorough guidelines that dig deeper into each of the topics covered today
monitoring

30. Question
&Answer

31. FreeWebsiteAuditwith
LearnMorewith
Identify holes in web tag deployment
Make sure your big data is telling the truth
Increase the ROI of your MarTech stack
Better understand customer behavior
Drive better traffic to your site
Execute cross channel media campaigns
www.observepoint.com www.searchdiscovery.com
Contact Us | 404.898.0430Contact Us | 855.878.8466