flat vs nested data layer? | Community
Skip to main content
A
akilg_honda
Level 2
November 30, 2018

flat vs nested data layer?

  • November 30, 2018
  • 1 reply
  • 7132 views

I would like to know pros and cons of nested and flat data layer to implement on a web property? Also, would like to understand if there any concerns related with implementing anyone of the data layer method with respect to Adobe Launch (TMS)?

    This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

    1 reply

    Stewart_Schilling
    Community Advisor
    Stewart_SchillingCommunity Advisor
    Community Advisor
    December 1, 2018

    We at Search Discovery have put a ton of thought into this topic - so much, in fact, that we've created an extension for Launch called the "Data Layer Manager".   I'll get to that later, but for now, let's talk flat versus hierarchical...

    I am not a fan of flattened data layers an I'll show you why.

    Consider this hierarchical JSON object representing an Order Placed event on an e-commerce website :

    Now, let's flatten it.

    Although the flattened version might seem more easily created and understood than the hierarchical one there is a big problem.

    When we try to represent Arrays of Objects in a flattened manner, we become reliant on the perfect alignment of multiple Arrays.

    Consider the scenario where something breaks in the generation of these arrays (and yes, things WILL break. they always do. and they break in strange ways).  Below is one scenario where we ended up with 3 items in all arrays except the sku array which only has two.

    The question here is, "How should you align the sku array with the others?" The answer is, "You can't".

    In practice, you would probably get the 2nd sku aligned with the 2nd productID, sellingPrice, and quantity which would lead to strange reports that leave analysts scratching their heads.  The 3rd productID would go without a sku which again, would lead to compromised reporting.  Now consider large orders and the possibilities for misalignment there...

    Here's one more example to make my case against flat data layers.

    Consider this scenario where we want to represent the contents of a product bundle along with the inventory status of the various skus for each product in the bundle. The hierarchical approach can easily handle this with arrays of objects within arrays of objects.

    Let's put that object through Tealium's flattener... 

    We end up with two productIDs, five skus, and five inventory states.  We cannot realign these arrays in any meaningful way. 

    Stewart_Schilling
    Community Advisor
    Stewart_SchillingCommunity Advisor
    Community Advisor
    December 1, 2018

    Now a bit about the Data Layer Manager extension.

    What value do you get from using it?

    1. Better outcomes in implementation. This extension was built to address the challenges that we have seen in hundreds of TMS implementations spanning architectures from tradition HTML multi-page sites to full SPA (and everywhere in between (i.e. HTML/SPA hybrids, and "islands of richness" multi-SPA sites)).   During these implementations, we found that one of the biggest risk factors impacting the success of implementation was the ability of the IS/IT department to correctly implement event-driven data layers. With Launch, we have the ability (via extensions) to reduce this risk by providing a standard interface for communication from the application to the TMS.  Instead of having six things that could go astray, now we have only a couple. 
    2. Built for today, but ready for tomorrow.  The standard payload for communication is a JSON object with an event envelope. The standard scope of messaging is from application to other client-side consumers (like Launch).  In the near future, the very same extension could be sending messages to cloud-based consumers such as the Adobe Experience Platform in XDM format or others in CloudEvents format.
    3. Improved end-user performance (quicker time to paint) via asynchronous embed of Launch. This extension provides a way to implement an asynchronous, event-driven data layer which works perfectly for async Launch implementations.
    4. Provides a standard communication mechanism between Applications and Launch implementations via an extended push method.  Payloads pushed prior to Launch initialization are handled seamlessly in a first-in-first-out manner. 
    5. Automatically creates and dispatches a Custom Event for each Application event pushed.
    6. Provides a computed state for each dispatched event. This computed state is a snapshot that gives the context when the event was fired. For example, if there was page info and user info provided prior to an event that provides product info, the combination of page, user, and product info is provided when the product event is dispatched.

    Below is a diagram showing the interaction between the Application (your website), the data layer (labeled window.AppEventData), the Data Layer Manager extension and Launch in time sequence from top to bottom. (Click the image for an expanded view).

    A
    akilg_hondaAuthor
    Level 2
    December 4, 2018

    Thank you Stewart for your reply.

      Terms & ConditionsAccessibility statement

      Loading footer...