Sitecore’s Digital Marketing Suite is eye candy for many marketeers. Sad thing actually, because in many to-be-built online projects on Sitecore, the DMS part tends to get cast aside. ‘Yes, we acknowledge the power of the product, but let’s do that in phase 2’.
The reasons are understandable. Building a complex web platform with complicated HTML/CSS on itself can be a costly business, especially if you need to optimize that also for inline editing – Sitecore’s Page Editor mode. Having this Page Editor mode in place is mandatory for operating most of the DMS features and thus most often its priority gets lowered. A separate license fee for DMS that needs to be paid doesn’t help marketers as well: if we can postpone it anyway, than we can keep that money in the wallet as well.
The Federated Experience Manager let marketers tag along sooner
A new tool will be introduced in Sitecore 8 that might change this whole approach as it makes DMS much more accessible in early stages of upgrading your website to a new Sitecore platform. The Federated Experience Manager – from now abbreviated to FXM – lets you implement a very simple line of code in any external website, giving you access to its analytics and even add or replace content on it. Even personalized content. Let me abbreviate:
When Sitecore is installed, it is an empty working box of features that will kickstart you to create your website(s) within. Right at that beginning, you will have no website (yet), but the entire DMS is already active. Thus, it makes only sense that the entire team dives right in to concept, design and develop whatever you want to create. If marketers would be so kind to start waiting now for the website to be (partially) done, that would be great.
But why? You marketers – most likely – already have a generic idea of persona’s and user segments that you want to target your website on. This can be pretty generic or have detailed segments based on your experiences thus far. With an operating DMS in place, you could already start with setting those up. While you are at it, you can discuss these also with your concept team/agency.
In a similar way, working with the UX designers you can already set goals that can be achieved. Normally this is only for your new website, but for the sake of my argument let’s say you also add goals for your current – almost deprecated – website. You could do the same for page events, like adding a product to the user’s basket or call-to-action form. Even pages that need to be tracked if the referrer page is one of your marketing campaigns can be tracked, e.g. tweets, Facebook updates or external website. In any other project or CMS, this is what marketers could do until that point. Now, they will have to wait until that phase 2, where the website is finally fixed and these settings would apply and finally make sense. Unless, they could apply it already on the current website!
Why not? Although it needs an upgrade badly, it is still online waiting for its death sentence and is certainly not worthless. It can still tell you a lot about your users and their online behavior.
Back to the FXM and that one line of code: this one line of JavaScript code – which works just like all other 3rd party tooling like Google Analytics or Visual Website Optimizer – needs to be placed in your current website. With this little code, named a beacon, a connection is made between your current not-so Sitecore website and your brand new very-much-so Sitecore platform. It will actually utilize your goals, page events, campaigns and segments on your current site, based on your configurations in Sitecore what and how you want to track your pages. This makes that you are already harvesting a lot of useful analytics into your new platform, even while the new product is being developed. The main advantage: you will already have data in place when your new product goes live, instead of having blank slate and having to wait for useful analytics.
Agile development benefits as well
Many of the digital agencies nowadays work by agile development. As snippets of functionality become available one by one, you might consider if those functionalities couldn’t also be applied in your current website. The output of the first sprints can be used directly, even before the new project has enough ground to be released.
By inserting the code into your current website, you will give content editors control in Sitecore of actually adding and/or replacing content that is on that external website. That’s witchcraft! Not less true though. Sitecore will show you the external website within its own inline editor. This will let you add all page components that have been configured in Sitecore and disclose all corresponding content that you have in place.
I find this particularly useful if you are not developing just one new website, but when you are upgrading an entire platform that consists of multiple websites. Typically, the shared functionalities from all websites will be developed first after which each individual website will be rolled-out. To show any useful new feature on an old site would require a roll-out which is very time consuming. This would let you inject a simple piece of content directly in the old site. Nifty, eh?
I have 3rd party tools for that..
Of course you do. Who doesn’t have Google Analytics installed on their website or does not have worked even once with Visual Website Optimizer? This should not be a discussion if this performs better or not; I just think this addition to Sitecore is really powerful in a sense that you are utilizing the DMS and content in your CMS that you have in place anyway. Having new functionality added to both your current site as a new website simply implies twice the costs. Also twice the work on content management.
Disclaimer: the images shown in this article are taken from the Sitecore 8 Technical Preview that has been distributed to all registered attendees of the Sitecore Symposium 2014 in Barcelona. It is not released yet as a stable edition.
Reply