Sitecore’s Federated Experience Manager (FXM) allows non-Sitecore sites to record analytics data into Sitecore. It’s both quite neat, and has a number of problems. I’m going to assume you’ve done a little reading about FXM already, but here’s how it works (in Sitecore 9.0.x).
And the response to that sets up a Sitecore Session ID, Contact ID, and returns element matches, which are stored in Cookies:
The element matches use HTML Element IDs to identify content to a) attach click handlers too, or b) elements to insert content around or in place of.
This is where we hit the first of my problems with FXM…
Scalability (and lack of caching)
That response contains all event trackers and all content replacements for the entire site, even ones that don’t relate to the page you are on. The content replacements in particular are large, so the whole response can become very, very large.
Worse, as this response includes the Session ID, Contact ID and so on, this response cannot be cached. Add a large file download to each and every page? Not Good.
This problem could be mitigated by having the element matches be downloaded as a separate response to the Session/Contact details. Even better, have replacement content only downloaded when a page needs it. And both those types of response could be cached by the browser.
Next problem is the lack of precision about element matches. Elements matches just use the DOM element’s ID to match on:
- This could be an advantage – configure once, affect many pages…
- … or it could be a problem – Configure once, affect too many pages.
And sometimes you might need conditional matches (like the site I was working with). For example, on click fire this event if that checkbox is checked. However, therein lies madness – easier to re-engineer the site you’re using FXM on.
It’s not clear to me that this could be ‘fixed’ one-way or the other. Depending on situation, this could be a good feature, or a major problem.
Flash of Original Content
If doing content replacement, your content isn’t replaced immediately. The user can possibly see the content before your replacement happens. This problem gets worse at scale (see above).
This is a tricky one – it’s probably inescapable if you’re not rendering the replacement content server-side for the target site.
FXM placeholders are named using the GUID that is generated to Identify the FXM Placeholder in Sitecore. Therefore, placeholder restrictions would have to be configured individually for each placeholder…
… which isn’t dreadfully practical. It would be nice to be able to set some sort of Placeholder Restrictions. You’ll probably need to train your Editors about how to deal with the choice of what renderings to use.
Site Datasources not supported
Okay, so this isn’t part of core Sitecore – but if you’re using the per-site datasources functionality that’s built into the Habitat project, then those won’t work in FXM. This is a shame, because that functionality is excellent in a multi-site system.
SEO Visibility of Replaced Content
All of this means that I think that the range of situations where it’s appropriate to use FXM (particularly for content replacement) is quite limited. I think, on balance, I would have preferred if it didn’t focus on the content replacement side of things as much; if you excluded that, a number of the above issues would go away. Also, separate the requests, so it can use a little caching.
There are also issues that I doubt have an easy technical solution for the product as designed. For example, “flash of original content” is hardly a problem unique to FXM, and short of server-side rendering (which I presume Sitecore were trying to avoid) there is no easy answer.
But there are a few elements that could be built better. My advice would be to:
- Thoroughly check requirements and limitations (and believe them).
- Use FXM sparingly, particularly content insertion/replacement.
- Don’t oversell FXM until you’ve checked out that it can do what you need it to.