Making Your Site Vendor Agnostic via a Modern Data Layer
•Download as PPTX, PDF•
0 likes•832 views
(Presented by Matt Gallion, Implementation Engineer, Ensighten) Properly built and maintained data layers allow a company the freedom to swap vendors out as needed without having to completely restructure their page code. In this session we will discuss why they are useful, how to properly implement one and how to govern the data across web and mobile properties.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Making Your Site Vendor Agnostic via a Modern Data Layer
Similar to Making Your Site Vendor Agnostic via a Modern Data Layer (20)
More from Ensighten
More from Ensighten (19)
Recently uploaded
Recently uploaded (20)
Making Your Site Vendor Agnostic via a Modern Data Layer
- 2. #agility2016 Welcome to Agility New York 9:00 am 10:15 am 10:30 am 12:00 pm 1:00 pm 2:30 pm 2:50 pm 5:00 pm 2 WiFi Details Network Name Apella Password apella Making Your Site Vendor Agnostic (This Session) Break Personalize the Customer Experience Lunch & Scott Brinker Presentation Afternoon Sessions Break Afternoon Session Networking Reception
- 3. #agility2016 Making Your Site Vendor Agnostic via a Modern Data Layer Matt Gallion, Ensighten Implementation Engineer
- 4. #agility2016 Meet the Teacher Matt Gallion Implementation Engineer, Ensighten 4
- 5. #agility2016 Agenda • Data Layer Overview • Tool Swapping with Agnostic Data Layers • Best Practices • Tech Overview • Governance
- 6. #agility2016 What is a Data Layer? A centralized abstraction layer that sits between your website and your 3rd party marketing tools Data Tags Data Layer Data Tags
- 7. #agility2016 Why a Data Layer? 7 Styling (CSS) Marketing Data (Data Layer) Interactivity (JavaScript) Structure (HTML)
- 8. #agility2016 Vendor Locked or Vendor Agnostic? Vendor Lock In Vendor Agnostic
- 9. #agility2016 Ensighten Data Layer (EDL) Ensighten Data Layer Universal DOM Elements Scraped Page Values Ensighten Activate Vendor-Agnostic Data Layer
- 10. #agility2016 Example of data layer + drop downs in Manage
- 11. #agility2016 Data Layer Pro’s • Follows good design by separating form and function • Reduces “vendor lock-in” • IT can ignore vendor specific data formatting • Quicker implementation of marketing tools • Better data consistency and governance • Easier troubleshooting and QA • Data reuse > lighter page weight and improved performance
- 12. #agility2016 Data Layer Con’s • Initially adds additional effort (time/cost) to a project • Usually requires engaging IT/development resources to both create the data layer as well as to enhance and maintain it
- 13. #agility2016 To Scrape or to Build Explicitly exposing data • Pros: robust and reliable • Cons: less speed and agility Scraping the DOM • Pros: more speed and agility • Cons: fragile and likely to break • Cons: data availability in the DOM
- 14. #agility2016 Scraping the DOM var searchPhrase = jQuery("#page_title h1").text().substring(16); var searchNum = jQuery(".pagination-showing").first().text().match(/of (d+) items/)[1]; Explicitly Exposing the Data
- 15. #agility2016 Design Process Questions • List all needed dynamic data points • Consolidate and de-duplicate • Assign each element a place in the object structure • Assign each element a unique name • Specify acceptable values for each element • Specify the scope for each element • Communicate all this to IT in a data layer tech spec
- 16. #agility2016 Example Tool Swapping With an Agnostic Data Layer
- 17. #agility2016 Best Practices • Avoid including static data • Populate the object using server-side means • Keep it tag-agnostic and TMS vendor-agnostic • Keep it as "flat" as possible (but not totally flat) • Only include what's really needed • Avoid including things already easily, universally and immediately available in the DOM • Page URL, referrer, user agent, client-side date/time
- 18. #agility2016 Best Practices Continued • Best Case Scenario’s:
- 19. #agility2016 EDL Tech Overview • EDL utilizes JavaScript promises to resolve data • Deployments that rely on EDL elements are wrapped in promises that wait for data elements • Custom triggers are available to resolve data manually
- 20. #agility2016 Governance • Inform Page Tests & Critical Path • When does the Data Layer need to be updated? • How do you manage a data layer between a mobile and desktop site?
Editor's Notes
- I really like this simple visual because most technical folks are very familiar with the standard Structure, Interactivity and Styling (or HTML, JavaScript and CSS) layers of the browser stack If our dynamic marketing data is forced to live within one of these pre-existing layers – it will always be at-risk and will never be able to achieve it's needed potential What we're really trying to do here is add a 4th conceptual layer to the browser stack – one that can stand independent and not be impacted by changes to the other 3
- In the data layer fundamentals section of this training I think I was pretty clear that it's a best practice to have a vendor-agnostic data layer And now I'm about to tell you that you should have a vendor-specific data layer – namely an Ensighten Data Layer (or EDL for short) So what gives? Why am I going around contradicting myself? Well – it's because both are important – they play different roles - and the best practice is to have one of each So let's take a look at how these work together <<CLICK>> Your vendor-agnostic data layer is sucked into the EDL and becomes a sub-set of it <<CLICK>> Any universal DOM elements we need can be as well <<CLICK>> If we are doing any page scraping those values get pushed into the EDL as well <<CLICK>> And finally – Activate can bring in offline data, offsite data, and real-time modeling and decisioning data from all three sources: onsite, offsite and offline <<CLICK>> Then the "EDL superset of data" makes all its values available to your Manage deployments, the entire Ensighten product stack and anything else that might need to pull from it given that Ensighten's strategy is one of openness Some of our clients don't always have a vendor-agnostic data layer – but they all should have an Ensighten Data Layer – as it's the perfect final aggregated and abstraction layer for any dynamic data needed by your tags Here's an example – let's say you are using a single piece of dynamic data in 20 different places within Manage If the location of the source data changes – and you're using the EDL – then you only have to update that in 1 place – naming the EDL But if you're not using the EDL – and have direct-referenced the value within all your tags – then you'll have to update things in 20 places So in summary – the three main benefits of the EDL are: First making your dynamic data easily available throughout the entire Ensighten platform Second – it's rare for a client's vendor-agnostic data layer to have everything you need – so it gives you the ability to aggregate additional values as need And third – as the final abstraction layer – you only have to update things in one place when they need updates – instead of in lots of places
- Image of scaffolding… a data layer is like the scafolding that is key for good data capture by all marketing technologies on your site.
- So let's define this thing A JavaScript promise is a method that eventually produces a value – it's a proxy for a value not necessarily known when the promise was created Promises are asynchronous by nature and enable the quick, safe and efficient execution of complex dependency flows – in our case – data layer values and marketing tags Conceptually promises are sorta like asynchronous callbacks, but they provide several benefits over them such as better error handling and the avoidance of timing gaps that can occur between a callback event occurring and the associated listener being dispatched A promise allows you to associate different handlers to an asynchronous action's eventual success value – so in other words – when an action occurs successfully – fire a function JavaScript promises let asynchronous methods return values immediately like synchronous methods do But instead of the final value though - you get a promise of having a value at some point in the future Promises are initially created in a PENDING state – and once they've been fulfilled we consider the promise to be RESOLVED Once a promise has been resolved it's done - it can never transition to another state, and its value can never change Promises can be chained together – and in fact that is where they really shine In case you're super nerdy and like to know all the details – our promise architecture is based on the when.js library Let's talk about this from the perspective of a single tag deployment that uses three data layer elements <<CLICK>> Here's a timeline of a page loading within your browser <<CLICK>> And the 4 associated Ensighten timing events (note the second one is denoted in grey as it's kind of a secret-hidden timing that's not natively available in the UI) <<CLICK>> Let's also say that my three pieces of dynamic data become available at these times If we're not using promises – or in other words – we're using the traditional Ensighten browser-based timing hooks - what timing would I need to use to fire off my tag deployment code? <<CLICK>> We'll have to use "After Elements Exist" as it's the next available timing hook If we are using promises – or in other words – we're using the newer data-tab EDL – what timing would I need to use to fire off my tag deployment code? You don't actually need a traditional timing as the promise chain will resolve automatically as quickly as the data becomes available <<CLICK>> And it's this resolving process that automatically provides our needed timing hook – and fires our tag deployment right after it has all the needed data Let's get even more specific: each of the data layer elements is wrapped in its own promise – and the thing that causes them to resolve is something called their trigger which we'll discuss in a minute And the tag deployment is also wrapped in a promise – and the thing that causes it to resolve is simply it having all it's needed data layer elements And you can mess the whole thing up by manually assigning a traditional timing that is too late – so if all your dynamic data inputs are using the new EDL – then the associated deployments should all have a timing of IMMEDIATE – even if you know your data availability is not immediate So I'm hoping you can see the metaphor by now – but for those of you in Rio Linda – I'll give you the translation rundown The bus stop is the browser The espionage agent is the tag And the spy being allowed to leave represents the tag beacon leaving the browser and sending its data into its vendor The informant information drops represent the individual data layer elements becoming available The fixed-schedule bus is our standard browser based timing hooks – that were used with our legacy DMF EDL And the on-demand Uber is our new promised-based timings hooks – that are used with the new data-tab EDL So there you have it – you should all now be experts in how promises work within Manage And the big idea here - is that going forward we want on-demand Ubers - not fixed-schedule buses