Adobe Launch: Managing Launch Series (Part 03) – Managing Extensions and Rules

Adobe Summit 2020 was a great start to the financial year. Because Covid-19 made it digital this year, I am glad I participated. There are more than 100+ breakouts and many on Data & Insights. I’d suggest you if you’re not aware of or did not experience the breakouts, please go through. Okay, let’s get to the subject.

Extensions

An extension is a packaged set of code that determine the available elements when building properties, rules, and data elements. So, ideally it is a library functionality in Launch Interface that will help us to ease our implementation and integration. Modern architects who never worked on Page Level implementations and integrations using JavaScript bundles would not know the timing issues, dependencies and timeline extensions we have faced earlier. Thanks to the Extensions which took away all the hurdles from us by just one click installation.

While we install and configure the extensions, we should be aware of the below.

1. Adobe Launch by default has an extension called Core and will be installed in your property by default.

2. The Data Elements created using an extension bundle can be used in other extensions i.e. Extensions are used in conjunction with each other.

3. You cannot control an extension loading time so we should be careful while mapping the scrapped JavaScript elements directly in the extensions because unlike Data Elements, Scrapped JavaScript elements will not work on JavaScript Promises. Chances are high that unset values of the elements are captured.

4. There are customized extensions available in the catalog and proper use of those extensions can ease your implementation and integration. Few I can suggest are Accessible Site Speed Metrics, Adobe Analytics Product String, Lookup Table Utility, Time and Scroll Event etc., other than popular and known extensions such as Google Analytics, Google Ads, Facebook Pixels etc.

5. You can develop your own extension! Yes, absolutely possible. There are plenty of materials and communities, checkout to start your contribution.

So managing extensions should never be the problem if we are aware of the above #s, but not the same prototype for Rules.

Rules

Launch is a rule-based system. The rules are the bins that place and execute your codes on the basis of events and conditions, so nothing will happen without rules.

There are three main elements in the Rules.

1. Events (IF) : Events correspond to the time/occurrence the action takes place such as Library Load, DOM ready, On Click, Data Element change etc. Events are the mandatory artefacts that must occur before a rule is triggered and can be combined together using ‘OR’.
2. Conditions (IF) : Conditions are the extra filters added to the events to narrow down the trigger of the rule. Multiple conditions can be combined together using ‘AND’ with both inclusion and exclusion filters.
3. Action (THEN) : Actions are the things you want Launch to do after the rule event has occurred and conditions have been met. Multiple actions can be combined together inside a rule one after another.

Since rules are the mandatory containers, dealing with them is important but tricky. Below are few important checklists to ensure the correct administration of Rules.

1. Proper Naming Convention : I was talking about the naming convention 2nd time in the series after Data Element, but what to do. One of the break-out session in Adobe Summit had this and showed that below is how the best rule should look like.

Since we cannot look up codes in the launch interface unlike few other tag managers like Ensighten, I still won’t agree with the Awful Name Convention List shared above but it is my statement.

1. Suppose you want to search where is your Google Analytics Code resides in the rules list, how do you search?
2. Or assume, in the list of actions within a rule you want to edit a single action, what do you do?

#1 is impossible at all except when the rule is explicitly stated by an appropriate naming convention and #2 is risky because your one edition can accidentally modifies the other action, so after each edition you are supposed to re-validate the entire rule. I won’t go for it and thus my suggestion is the below.

Both are methods are fine and thus it is an architect’s call.

2. Proper Rule Order / Priority : Rule order determines which rule runs first when an event is triggered. If two rules have the same event type, the one with the lowest number runs first. So if dependencies exist, I would suggest using the ruling order instead of grouping all the actions into a single rule one after another.

3. Proper Name for Events, Conditions and Actions : Yes, it helps to make our debugging easier with the proper name to events, conditions and actions. If you look at my first screen shot, numbers 2, 3 and 4 will also have proper naming convention like the rule by itself. Condition Path Equals ‘Home’ is better than Path Without Query String – Core right? Applicable to others as well.

4. Proper Notes : Same as Data Elements, proper descriptions and notes to be added to the rules for easy understanding.

5. Don’t try to create Custom Code every time : Create Custom Code only if you don’t have an Extension for your requirement. A custom code for Analytics or Google Conversion is not necessary since it is already available in Extensions and easy to implement with just one click.

Other pointers like copying resources, comparing the revisions, deleting resources are already available in the internet and thus we can use the same for reference.

Bonus : If you are looking for Adobe Launch Document or need to see how it will look like, you can download the document here – Download Adobe Launch Document. Specially for you, enjoy.

Thus ending this managing Adobe Launch series. If you missed to read out the first 2 part of the series, please click on the links to proceed : Managing Launch Series (Part 01) – Managing Properties & Managing Launch Series (Part 02) – Managing Data Elements.

Kindly ‘SUBSCRIBE’ and stay tuned for the future updates.