Original article
Feature Flags or Feature Toggle is a common practice used by developers. It allows to deploy specific functionalities in an incremental manner and only enable them when needed.
In the tagging world feature flags is a little-known concept. Most of the time a standard tagging release will consist of creating the tag, testing it with the tag management system dev endpoint then publishing it to production. This means that sometimes the release timing is crucial as it needs literally to be done at the same time as the new platform feature has been released to production so it does not impact user experience.
Feature flags are a development concept that allows to wrap a functionality inside an if
condition that checks a specific variable value. This variable is usually a Boolean, so the possible values are either true
for enable my feature or false
for disable my feature. This allows the development team to deploy part or a full feature in an incremental manner. By doing so you can then enable/disable a feature during runtime without a code release.
if (featureFlags.feature1 === true) {
executeCode();
}
By doing so you can allow the development team to deploy a feature to production and complete the QA process before making the feature available to your users.
If the feature relies on multiple teams to complete their work, this allows your tagging and development team to work in parallel without having to wait on each other.
One might think that tagging is as simple as deploying a script tag on a platform, however it does require some planning and orchestration to make sure the tags fire in the correct order, at the right time and with the right configuration. Tags configuration can become really complex based on the business needs and the layout of the website.
If you look at how tag management systems work you will find that feature flags are being used in tags configuration without the tagging team realising it.
TMSs, like Adobe Launch, are usually structured around these 3 main sections:
In a sense, the conditions section can be considered as the feature flag section. But unlike traditional feature flags they are only usable by the TMS during its runtime. These conditions are most of the time scoped to the TMS object and cannot be evaluated by the platform scripts.
Now that we have understood that the feature flags concept is being used for tag configuration, the next step will be to figure out how to expose the feature flag functionality to be used outside of the TMS runtime. Our goal is for the feature flag to be set and ingested during runtime by our TMS, our platform scripts and any third party vendor scripts that we deploy on the platform via the TMS.
To achieve this, we will need to have one common location where these feature flags can be set and accessed. Luckily for us we have defined a generic data layer which is the ideal candidate to host our feature flags.
In the next section I will describe how we can extend our generic data layer to support the featureFlags
property.
Luckily for us the generic data layer is a nested type data layer with a root of an object that can be easily extended.
This is an example of how our feature flags will be defined:
var digitalData = {
"featureFlags": {
"featureName1": true,
"featureName2": false,
"overWrite": {
"featureName1": false,
"featureName3": true
}
}
}
We can clearly see that we want to extend the root object to contain a new featureFlags
property. This property will be an object.
To support future use cases, we will have 2 feature flag levels:
overWrite
object will be used primarily by the tagging team. This will allow the business to be in charge to enable or disable specific features as required in the least amount of time. This level will prevail over the first level. For example when the business wants to deploy a chat functionality on your platform, they might want to first test that the chat functionality has a positive impact on the conversion rate. Before fully committing a lot of resources for the chat functionality we want to confirm that by having it on our checkout funnel it will increase the conversion rate. This use case is best answered by an A/B test. In this use case we will deploy the core functionality of the chat via a tag from our TMS. We will add a condition that will depend on our feature flag for the tag to be executed during runtime. Now in the A/B test instead of having the chat code we just need to have 2 experiences, one for chat enabled which will set digitalData.overWrite.chatEnabled
to true and one for chat disabled which will set digitalData.overWrite.chatEnabled
to false. As you can see the A/B test is now simpler to compose.Now as our generic data layer is defined using the JSON schema definition, we will extend our definition by adding the featureFlags
property definition inside the top level properties
property:
{
"properties": {
"featureFlags": {
"type": "object",
"properties": {
"overWrite": {
"type": "object",
"additionalProperties": {
"type": "boolean"
}
}
},
"additionalProperties": {
"type": "boolean"
}
}
}
}
Notice that the only item you will need to add to your generic data layer definition will be the
featureFlags
object inside your top level "properties" property.
Now you might be wondering why we will spend time and effort to create a feature flag functionality that is already covered by the conditions section of our TMS.
One of the main limitations of the conditions section of your TMS is that the conditions can only be evaluated by your TMS. This means that your platform has no indication if a specific feature is enabled or not.
Some personalization products deployed on your platform will sometime require the development team to deploy custom components to create an optimal user experience. In order for the platform to know at runtime which component to display in the journey, they will need a feature flag. However, as the conditions section of your TMS is not globally accessible and we do not want to create technical debt by adding code from the TMS object into our platform code then the feature flag functionality is the best option.
Here are some other benefits when using globally scoped feature flags with your tagging implementation:
Using a feature flag approach will allow your business to run campaigns in an agile way where you can stop/start any functionalities without waiting on your development team to do a release. Your tagging build can be pushed to production before the platform release date.
It also provides a new type of collaboration between your development and tagging team where specific components can be created for specific use case. These components can then be displayed based on values of specific feature flags at runtime.
A good example would be the surveys displayed on your website.
Traditionally you will use your TMS to inject your survey script code when the customer reaches a specific milestone like a page in your application. This will result in the survey being displayed on the page before your customer can see the content of the page which results in a bad user experience.
An easy fix for this issue would be to provide a button when the customer completes/close the application which will give an option to take the survey. To do so your development team will need to display this new component whenever and wherever the business wants the survey.
As the content of the survey can change at any time due to regulations, we will need to rely on something other than the development release cycle to switch on/off the survey.
The best option would be for:
In order for us to be able to test specific product/feature behaviours, we need to be able to switch a feature flag on/off without having to do a release. This means that we want to overwrite the feature flag value after the tagging library is loaded and application library is loaded.
To overwrite the values set we can use 2 routes:
featureFlags
object.By doing so this will allow us to test both the scenarios with the feature on and off without having to a tagging or development release each time. This is particularly useful for your QA engineers to validate their tests.
We have seen that in its core tagging revolves around TMS based feature flags (conditions). While it is a viable approach and is mainly used, there is additional benefits to adopt a more traditional approach around globally scoped featured flags. These feature flags allow additional A/B test capabilities, tailored custom implementation to improve customer experience and a better QA process.
Very comprehensive and helpful article.
Thanks a ton, @Alexis_Cazes_
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies
Views
Like
Replies
Views
Like
Replies