I’m seeing challenges and confusion with BluePrinting and Targeting in BluePrint workshops and in discussions about profiling and personalization. Don’t let the rise of “Customer Experience Management” (CXM or CEM for TLA fans) adversely affect your SDL Tridion BluePrint. Localization != Personalization (!= is code, literally, for “not equals”).

BluePrinting Observations and Recommendations

• Localization is best for content that is logically the same, is possibly used in the same page, and has the same relationship to other content.
• Mobile doesn’t automatically mean personalization or “customer experience,” but it’s a good candidate for it.
• Localization might be appropriate for a mobile publication. But only if it’s really a near “clone” of all or part of your desktop website. It might be a short-sighted solution, though (explained below).
• BluePrint designs typically separate definitions, content, design, translations, structure, and pages into their own publications. Most BluePrint designs I’ve seen do this following the classic “diamond” approach. I’ve also seen scenarios that put Design publications below Content. Regardless of approach, you typically put templates in separate publications.
• Channels represent the ways you present content and may include your desktop website, a mobile-specific website, an app, or even print. Though you may have some channel-specific publications, you might want to avoid channel-specific BluePrint layers. Consider placing channel-specific content in the Content publication and adding “publishable” channel publications as needed.
• Profiles represent target audiences you may want to personalize content or an experience for. Though you may have profile-specific pages and content, you probably want to avoid profile-specific Tridion publications.

Channels != Language

I’ll sometimes see a BluePrint that replaces “language” with “channels.” I’d argue it’s better to avoid mobile, tablet, or other channels as publications all-together (except maybe for publishable publications), but you may want to segregate functionality into (ideally) one “application” Publication(s) if the following apply:

1. Your Templates and the developers that work on them are different than your “www” (dub dub dub) team
2. You foresee a future with lots and lots of channels that may include browsers or content on kitchen appliances, internet-enabled clothes, and wall-sized interactive displays (kiosks or giant touch screens).
3. Your strategy includes a single format (XML, JSON, or the next machine-and-human readable format) or a web service layer to handle these scenarios.
4. You need to assemble content into Tridion Pages that render this single format your developers can then use across channels. In this case, the content lives in your Global Content Publication and the shared pages may come from an Application Publication in the “Site Master” or Structure Group/Pages layer.

In the same way Manuel “Tridion Strategist” Garrido recommends minimizing localization, I advocate avoiding localization for personalization and profiling. Publications shouldn’t be a go to answer for “experience management.”

Localizing www into mobile works… for now.

Creating a BluePrint requires a series of decisions, but is a relatively straightforward process. Just know that Profiles != Publications. Let’s see where simply inheriting a mobile publication from www can go wrong.

• It’s just mobile and tablets and maybe apps for you now. But the internet of things is likely coming (check out some smart clothes). Not all will have content, but are you going to make a publication for each new channel? Fridge and Car Browser Publications anyone?
• Your business may demand finer-tuned profiling. A typical requirement is for US State-specific content. I hope you’re not considering fifty publications (plus Washington DC) for this.*
• Take any profiled information and multiple it out by the number of variations. It’s N-factorial (N!). Ian Trustcott refers to this as the content explosion. Fifty states for two types of users quickly becomes 100 variations. Then add cities and Visio won’t have a font small enough for your one-page BluePrint.

So sure, consider different publications for differences in high-level architecture, functionality, or distinct sets of internal users/development teams. But avoid confusing localization with personalization.

*There is a scenario I could imagine where it might be okay to multiply out child publications. If you could present a parent item and all of its localized child variations in a single UI, then authors wouldn’t have to struggle jumping between publications. But your IT operations team might not appreciate managing N! publications.

How CXM Impacts Your BluePrint

Authentication. The public and authenticated parts of a site are probably be part of the same publication, especially if they’re currently managed in the same application or website.

Internal Vs. External Content. You might have external and internal content publications, but not because of personalization. Your intranet might have its own content publication, not because the audience is different, but because you don’t want internal, sensitive material easily published or shared to the internet. I’ve heard of SDL Tridion-using organizations with hundreds of publications, but it’s mainly to handle distinct websites, and definitely not for personalization.

Mobile Experience. You could localize for mobile devices, meaning Mobile-as-a-child publication, if the following apply:

• Your desktop website has mostly informational content
• You have nearly the same structure, pages, and experience between desktop and mobile.

But if you’re taking this strategy, instead consider responsive design (article by Frank van Puffelen. Yes, that’s the same “Mr. P” that gives you a hard time on StackOverflow).

If your mobile channel (app or website) has its own set of authors and developers, a different rendered output, and/or screens/pages/steps that differ from desktop, then feel free to create a Publication for it. Be careful if you want to localize components for this channel, especially if you’re not sure on your strategy for future channels. You may opt to create the variations in your highest Content publication instead.

Forget the Fancy Acronyms. You’ve Done This Before.

Sometimes we joke about the acronym soup our industry generates–CMS, WCM, WEM, CEM, and now Global CXM. The way forward is with the same tools and techniques we’ve had in Tridion forever–components, templates, metadata, and the relationship between them. We can create appropriately “tagged” content and dynamically present the right content to the right audience (up to you if that’s SmartTarget, the Content Delivery (CD) API, the CD Web Service, or your proprietary rendering framework). Regardless of the architecture (or even CMS software), authors will manage “personalization” in one of roughly four ways:

1. Select metadata.Then publish components. I prefer dynamic delivery, but Event System automation also works. Personalization engines such as SmartTarget changes everything though.
2. Merge Fields. Content is mostly the same, but author adds placeholders in text that change via templating.
3. Links. Author selects related components and publishes the “index” or containing component. You might consider a custom resolver to handle link propagation (items linked to your items get re-published by default), especially if you use parts of this content in others ways (e.g. static on a page or multiple pages).
4. Lots of Pages. Boo! Except for the occasional two-or-three variation setup, this is the lazy-in-a-bad-way approach and makes IT, consultants, and the software look bad. Seriously. This breaks the “Content forward. Not page backwards.” phrase coined by David Adams (SDL PS).

Authors could potentially “profile” something via template selection, but you introduce the same problem with publications-for-personalization. Templates should offer a few variations that change presentation, shown fields, or possibly functionality. But fifty templates for fifty states should set off alarms in your head.

For the not-in-the-CMS information, we “connect” via templating, “proxy components” (where some component acts as a “widget” representing some code or functionality), imports, or (new in 2013, maybe!) External Content Libraries.

Everyone must deal with what a personalized user experience means to content strategy, but it’s important we don’t confuse personalization with localization along the way. I’m tempted to also say don’t localize for code branching, but that’s another post altogether.

I’m interested in what has worked for you and if you’re seeing the same fuziness, muddiness, and confusion between personalization and localization. Let us know if and where “publication-per-profile” has worked for you (or failed) in the comments.