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).

FXM works by having you adding a JavaScript reference to your pages:

This JavaScript, when run, instantiates a JavaScript Object (a Beacon) which makes a request of Sitecore:

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.

Precision

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.

Dynamic Sites

FXM doesn’t work well with dynamic sites, or sites using RequireJS, Much of this is mentioned in the Requirements and Limitations. Basically, if you’re using much JavaScript (and what site doesn’t these days?) then don’t go there.

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.

Placeholder Settings

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

This isn’t specifically an FXM problem – it’s a problem for JavaScript-based sites more widely – but FXM content might not be visible to search engines. Googlebot may index the content – but no guarantees. Bing, DuckDuckGo, and others will not. SEO recommendations are that content is rendered server-side.

 

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.