Using Core-click event vs direct call of satellite

[jewilliams]

We have been implementing several rules using a direct call of satellites. Would it be better in launch to use the Core-click with a css identifier? Is there a key difference in performance of the two?

[Pablo_Childe]

I find its a balance of 2 development styles...

Direct call rules are better in the sense if its a web app the sat track is more likely to remain untouched/unmodified by accident.

The ccs selector has a greater likelihood of a developer modifying some css element and thus break your rule.

Direct call rules also I find seem to be better as a developer has more flexibility in moving them up or down in code to allow tagging optimization. 

regards

[VaniBhemarasetty]

@jewilliams Direct Call Approach creates Direct Call Rules or DCRs which are extremely powerful and give a lot of control over what data needs to be tracked and when to trigger the tracking.

We have found customers leaning towards Direct Call Approach in following scenarios:

1. DCRs are ideal for Single Page Applications or SPA. A SPA is an app that works inside a browser and does not require page reloading during use. Due to this, the Event Based Rules hit its limitations as the DOM constantly changes and creating EBRs gets really complicated to manage.

2. Direct call rules are also ideal for situations where you want to tell Launch exactly what is happening or in situations when Launch cannot detect an event in the DOM, such as with Adobe Flash or synchronous calls.

You can read about it more here over this article on Adobe Launch rule creation strategies 

https://medium.com/slalom-technology/adobe-launch-rule-creation-strategies-29e879af8dff

Hope this helps

[Alexis_Cazes_ · Accepted solution]

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.

[jewilliams]

Thank you, this is helpful. I look forward to reading:

"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."

[Alexis_Cazes_]

I have opted to use dev.to to create my post to the auto-tagging series. Check my dev.to profile for up coming articles.

https://dev.to/alcazes

https://dev.to/alcazes/adobe-launch-release-standards-2c9m

https://dev.to/alcazes/adobe-launch-coding-standards-e22

https://dev.to/alcazes/adobe-launch-tagging-standards-3aak