Lately we've been getting a bit of pressure from the business to use Target as a CMS to deploy new features to 100% of the traffic. Some requests are especially complex in terms of development effort. The reason for this is the IT department isn't as quick as us Target Team are in developing, and naturally it requires a big investment from the business. We are pushing back strongly saying this is not what Target is designed for, but I was wondering if you could share with me exactly what the risks and limitations are of using Target as a CMS, or point me to resources that can help? Thanks in advance for the help!
First a shout-out for having the correct frame of mind: "We are pushing back strongly saying this is not what Target is designed for" Another caveat I see is over-time and many changes performance impact. Take the following. We want to modify content on URL1 to change the header from saying Hi to saying Hello.
Option1: Edit the site code and make the change.
Benefits: This is the right way to make this change.
Disadvantages: You need to wait for the right peopel to make the change.
Option2: Create a new activity and make the change in one of the activity experiences then direct everybody to that activity experience.
Benefits: This is the fast way to make this change.
Disadvantages: Probably against your internal security rules. Puts undue burden on the Adobe Target platform and it not being used to serve legitimate targeting content. Data is being collected in reporting for no real reason and adds overhead to your website load time as you are now involving a third party in the content deliver side. Requires that the activity continues to run for ever. If anybody ever de-activates the activity or if anything happens on Target site your changes are no longer there. So many disadvantages.
Those are some things that stand out to me that I would recommend to keep in mind.
I wanted to summarise some points that will form part of the argument, in case they are useful to somebody else.
Target relies on Adobe Cloud platform, which can undergo maintenance and downtime, which means no Target content will be shown if down
If something is live to 100% of traffic and we run more activities on that page / funnel, the 100% activity has to be replicated on any new activity, increasing implementation effort, possibility of human error and data cross-pollination
The practice of using Target to deliver projects quickly as a CMS is not recommended by Adobe
Due to current implementation of Adobe Tag Manager, the content might not be delivered as seamlessly as it would if it was hardcoded on the website (eg. Users might see a slight flicker)
Some browsers are not supported by the platform and are regularly excluded from activities (eg IE)
Often not possible to delivery dynamic content or communicate with API unless IT Team release a change
Not scalable; not possible to replicate across different domains or pages with different structure
Not possible to make any changes to a Target experience once it’s gone live, unless prepared to deactivate it
Furthermore, to also kill the counter-argument "But can't we treat it like a personalisation and push to 100% of the traffic?, we have also defined personalisation as an activity that delivers bespoke content to an audience using an existing component (as opposed to a new one created via Target).
this is a common usecase for any testing tool, at least to my experience.
It becomes risky when you have to many "content-elements" that are managed by Target on the site and forget about them. The effort to maintain everything within Target can be substantial. And of course from a performance perspective, Target as a client-side technology is not as fast or reliable as a normal CMS would be.
That sad, as you mentioned, the speed and flexibility that a testing tool is providing, is usually unmatched so go ahead and make the most out of it 🙂