Adobe Launch — Rule creation strategies
Adobe Launch is the next generation Tag Management System from Adobe. Launch gives customers a simple way to deploy and manage all the analytics, marketing, and advertising tags necessary to power relevant customer experiences.
One of the key features of Adobe Launch is its robust “Rule Builder” which can combine multiple events, sequenced in the way that you determine using if/then logic with conditions and exceptions.
Rules are the heart and soul of any Adobe Launch implementation. One of most common challenges that marketing teams face with their Adobe Launch is choosing the right implementation:
- Marketing teams have to work with complex CSS.
- Longer wait times before they can have a new interaction active on their website.
In order to find the right balance, it is extremely important to decide the strategy for Rule creations at the beginning of your implementation. Without the proper strategy in place, creation, maintenance, and debugging of Rules will get complicated down the line.
As you consider your overall Adobe Launch implementation and more specifically your Launch Rule creation strategy, you have 3 approaches:
- Event Based Approach
- Direct Call Approach
- Hybrid Approach
Event Based Approach
Event Based Approach creates “Event Based Rules” (EBRs) in Adobe Launch interface. Creation of EBRs require configuration to be done only within the Adobe Launch interface. They can be configured to trigger depending on the different interactions on the page such as Click, Mouse Over, Form submission, etc. For complete list of event types supported, refer to Adobe’s documentation.
We have found customers leaning towards the Event Based Approach in following scenarios:
1. Their website is a traditional website or a multiple-page application where every change, whether it is the display of data or submitting data back are requests to the server that will render a new page in the web browser. This approach can be helpful as marketers can track a good chunk of data when the page loads by fetching values from the data layer and only the interactions then need to be configured separately.
2. Marketers want more control over the user interactions getting tracked on the website and do not want to rely or wait for the website team to implement the changes.
3. Marketers want to capture interactions (example — how many users clicked on a promo code?) only for a specific time range, like a few days and this approach can be helpful as changes to Event Based Rules are only on the Adobe Launch interface, so they have relatively quicker time to market.
Direct Call Approach
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.
Configuring these rules is a 2-part process. Marketers will have to create a new rule within Adobe Launch interface and select “Direct Call Rule” as its event type and provide a unique identifier for that rule. Once the identifier is set, web pages will need to run the JavaScript code like below to trigger as per the tracking needs:
_satellite.track(“<DCR Identifier configured in Launch >”,{name:”wug”,price:”12.99",color:”red”})One of the best features about DCRs is, it doesn’t rely on the CSS selectors.
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.
Hybrid Approach
Hybrid approach uses the mix of Event Based Rules and Direct Call Rules. This approach provides the best of both worlds.
When going with Hybrid approach, one of the key things is to establish a proper governance model around the Rule types (EBR or DCR) and have that tracked in the Solution Design Reference (SDR) or Tagging Plan document for the ease of work distribution.
Consider below points when deciding whether to configure a rule as an EBR or DCR:
1. Whether the event or interaction to track is available in the list of supported events?
2. Whether the data to be tracked is available at the time of interaction?
3. How quickly do you want the Rule to be active in production and want to have the ability to disable it?
We have found customers lean towards this approach in below scenarios:
1. Marketers have requirements to be able to track certain interactions for their A/B testing for a short span of time and then remove it. They want to conduct the entire process without the involvement of Development team.
2. Marketers don’t want full control of all the events and interactions getting tracked on the website as they could grow over a period of time and become overwhelming to manage.
3. Marketers have requirements to pull data from multiple elements on the web site but don’t have that advanced CSS selectors knowledge within their team and want web developers to manage that.
So, when should I use which approach?
As we saw above, each of the approaches have their own pros and cons, it really depends on your requirements.
Consider the following questions to help guide your decision.
1. Do you want to give more power to the marketers to create, update, and delete rules and data that is getting sent to Analytics?
2. Is your website or application a Single Page Application, Multi-Page Application, or uses both?
3. Does your website frequently change layout, structure, or visual components?
4. Does the marketing team have a basic understanding of CSS selectors? If not, are they willing to be trained?
5. Can your marketing team wait?
6. Is housekeeping and archival of rules required?
7. What type of interactions and data do you primarily want to track from the website? Simple interaction (such as click events) or complex events such as result of an asynchronous call made from the web page?
We at Slalom have helped various clients define their measurement KPI, define and implement the data layer for data collection, configure analytics reports and help optimize their user experience and improve engagement.
Follow Slalom Technology and read more articles on thought leadership in Technology.
