Using Core-click event vs direct call of satellite

1. CSS implementation or DOM scraping is one of the most fragile tagging implementation. Depending on the CSS selector that you use, it is possible that your implementation simply stops working after a platform release on your website. It could be the css class has been renamed, the element has been changed from a button element to a link a element etc... 

Having said that it is the fastest and most flexible implementation. It removes the dependency from the development team. Your "tagging" team can do any changes at any point of time without any downtime.

2. DCR implementation has pros and cons. It is less fragile than CSS implementation. As long as your developer use the same DCR ids in their implementation then it will always trigger the rule. 

On top of that you can pass custom meta data to the rule and that can decrease the coding that is required on your side. If you have a good relationship with the development team then it becomes a successful implementation. You are not limited to the amount of meta data that you can pass, and it is in a JSON/JavaScript object type so it is easy to parse and access the data using "event.detail" in your code.

As mentioned there is cons. One of the limitation is that you will have direct dependency to your development team and their release lifecycle. If any issues are found thenit can be months away for a fix.

Also one of the main drawback for me is that it add dependency to the _satellite object in the source code of your website platform and I find it a deal breaker. Imagine the day you have to update from Adobe Launch to another tag management system, major refactoring task for your company. Lucky that adobe DTM and Adobe Launch use same object _satellite otherwise many companies would have found it challenging.

3.I would say the best approach is to use a data layer, where the data layer contain an array or is an array in itself, depending of which style you want for event notifications. 

Benefits of data layer:

• You can defined the structure of the data layer as you see fit for your company. Want to create an object page instead of pageDetails you can. Add a new property, you can.
• It will allow your developers to create a common MI library to reuse across platforms, especially nowadays where new implementation use SPA (React etc...) and it is common to create reusable libraries and components across multiple platforms.
• it is easier to maintain on your side and developers side.
• Not locked to a specific tagging providers
• Your tagging will be easier to maintain as the same data layer structure and how you access the data will be available.
• If you ask developers to also emit an event once data layer is updated that would be a must.

Cons:

• Requires a big investment initially in your company for defining a generic data layer reusable across all platforms. It will also come with some investment on development team side to implement it.
  • However once implemented less development team time is required and it is easier to maintain. No need to mess with CSS selectors anymore.

There is always a use case for any of the 3 solutions:

• it is unlikely you will be able to use #2 and #3 if your website is developed, hosted and managed by a third party. The codt would just be too much for the benefits. So #1 should always be the best solution.
• I would always choose #3 over #2, as it is a stronger solution long term and would allow you to reach "auto-tagging" implementation.

I will post article about auto-tagging that we have implemented on our side using #3, which I think is the best solution in terms future proofing your implementation.