Adobe Launch: Managing Launch Series (Part 01) – Managing Properties

It’s harder for me at all times to be a developer. I know that managing codes are not easy but for a Tag Management Solution it is obligatory. I have had difficult days when I migrated Adobe Analytics and related codes from Dynamic Tag Management to Launch. But it provided me with a clear idea on how to manage a tag management system effectively, so I want to share it with all of you. Trust me, it will work!

I have worked on Google Tag Manager, Ensighten, Tealium (Not extensive) and Launch. Certainly, there are differences between these tag managers but managing the core components such as Properties, Extensions, Data Elements, Rules and Conditions are identical. For other tag managers I won’t go into the details, but only Adobe Launch and therefore it is necessary to understand the core concept of Adobe Launch before reading the post.

Managing Properties

Definition: A property is basically a container that you fill with extensions, rules, data elements, and libraries as you deploy tags to your site.

Oh great! Clearly understood, isn’t it. Many of us don’t know the core idea of why a tag manager own properties. You can add me into the list as I will share my ideas rather than the idea of the world.

When do we need to create a property and Why?

Don’ts
Let’s see the don’ts before do’s.

1. Don’t create multiple properties simply because you have different domains i.e. Property creation is not based on the domains. It is not mandatory neither best practice to create 10 different properties just to segregate 10 different domains.
2. Don’t create multiple properties when you have a single content platform serving a single business purpose. A blog that was hosted through single content platform WordPress should not have multiple properties.
3. Don’t create multiple properties since because you have different Report Suites in Adobe Analytics i.e. Property creation is not based on the Adobe Analytics Report Suite IDs.

Do’s.

1. Create multiple properties if you are subjected to multiple business needs. Reliance retail market and telecommunications are entirely different businesses and thus we should create two properties.
2. Create multiple properties when you have multiple content platforms even if it serves single business purpose. A business group hosted through HTML Platform and another group hosted through SPA (Single Page Application) should have different properties. This is because the content structure for these platforms is different and it is better to keep it separate.
3. Create multiple properties if you have multiple Mobile Application i.e. Property creation is also based on Mobile SDKs.

I know that examples are much easier to understand rather than a definition or explanation. So, let’s see.

Take a BFSI industry with branches worldwide. Assume that the industry has Pre-Login and Post-Login business groups hosted through HTML and SPA (Single Page Application) respectively but having multiple domains; also having individual Mobile Applications for locales. So, the Adobe Launch wire frame will look like below.

Three properties for a country are more than enough i.e. Country * 3. Thus, we will not disturb the Pre-Login or Mobile Application when there are any changes / emergency updates in Post-Login and vice versa.

Why? I have seen few architects create a property for each line of business within single business unit. For our example on BFSI sector, consider there are different properties for Savings/Current Account, Credit Card, Insurance etc. Might be an architect call, but I wonder! Managing multiple properties are not easy though it serves only one business purpose. Since each property we create will have different embed codes, imagine dealing with different deployments, different configurations, different validations for a single business unit, tougher for everyone and thus i wonder, wont recommend.

However, this is a beginning in Adobe Launch, we still need to formulate a plan to manage Extensions, Data Elements, Rules and Conditions. To continue to the Part 02 of the series on how to manage Data Elements, please click here.