Enhanced e-commerce using GTM but no in-page dataLayer

Question

I am working on a project where I do not have access to page source nor can I ask client's IT team to create in-page/onload dataLayer e.g. having dataLayer before the tag. Is the idea of implementing enhanced e-commerce tracking remotely possible via dataLayer.push e.g. build dataLayer as you go?I have a very little knowledge of dataLayer.push (which I am starting to read up). Question is :

• Is dataLayer.push the correct way move forward? Have anyone done this before?
• what issue I might face e.g. "add to cart" event, remove cart or category page any working example? I still don't have a clear view of the workflow here.
• What are the downside of doing it this way beside "style/css" based trigger might fall off during future site design update.

Thanks.

Answer 1

I think it's important to acknowledge here that the Data Layer is just one way of storing this information, and is used solely because it's possible to push data to it from the page.

If you can't write the code into the site itself, don't push information to the data layer. Just keep that information for yourself, in GTM's variables. You'll save yourself a huge headache, and a bit of computation too.

DOM scraping is a perfectly reasonable way to get hold of information, but you will run into some barriers.

• You're going to have to write a lot of JavaScript to get the data you need.
• Some buttons may turn out to be composed of several elements that you'll have to cover with your triggers etc.
• Any changes to the site will potentially ruin your code.
• Not everything is available to you, especially verification of data (checking if a purchase went through is probably no longer possible before reporting the transaction).

Answer 2

Your main problem is that you need to get the data from somewhere. Usually without a dataLayer this means DOM scraping and then assembling the scraped data into a dataLayer in a custom javascript function. Drawbacks are the same as with your stle/css based triggers:

• Implementation is strongly coupled to the page layout
• data might be missing, or require cleaning (if mixed with html or unrelated text)
• potentially expensive in clients CPU time
• custom javascript introduces new points of failure (i.e. can you test rigorously enough to guarantee that there are no side effects)

If you do workarounds around your client's ITs shortcomings remember that you own them - you will be responsible if the workarounds break, or have side effects, or need to be amended to account for new features. Make sure that you are very well compensated for that risk (and personally with the experience I have now I would not do this at all).