Digital Marketing

Growing your Technical Marketing Organisation and Roles

The last week I have again been reading through the Connect book by Lars Birkholm Petersen et al. which covers the marketing maturity model exercised by the Sitecore SBOS team. Although it is a very good read it does have one very big gap: The lack of focus and attention on the technology powering the modern marketing organisation.

Sitecore Maturity Model

The back cover reads: “Marketing must be faster and more agile than in the past, ready to move rapidly to leverage new technology and stay connected and available to customers”.

In other words: As the marketing operations become more mature the need for quick optimisations and deployment of initiatives, new features, channel support etc. becomes imperative. Marketing technology – if implemented correctly – is sophisticated enough to allow marketers and marketing technologists to adapt and optimise somewhat without the intervention of development or IT. But as the organisation matures and marketing initiatives cover more business critical parts of the customer journeys, the technology touchpoints and requirements will inevitably become more advanced and start spanning more business critical systems and more of integrations. This will require a greater focus on traditional development and IT disciplines – and if these disciplines are not a part of the marketing organisation agility will suffer,

The IT/Marketing Gap is a Maturity Blocker

I have been building marketing solutions for the last 10 to 15 years and have encountered organisations in every end of the maturity scale and ranging from the smallest to the largest organisations in the world.

Over the years, I have experienced that one of the biggest blockers for marketing to realise the full potential of their marketing technology investment – and therefore ultimately a blocker for maturing more rapidly – is the lack of coherence between marketing and technology. The realisation that the IT/Marketing relationship has to be strong and respectful is more and more essential when moving up the maturity scale.

In essence: in a modern and mature marketing organisation, technology is not covered by external roles or organisations but needs to be a part of the marketing team and built into the daily marketing operations.

Growing your Marketing Organisation and Roles

Chapter 12 of the Connect book is titled “Growing Your Organization and Roles” and covers the marketing roles which needs focus in a maturing marketing organisation. The roles covered in the book are:

  • Marketers
  • Digital Analysts
  • Acquisition Marketer
  • Channel Expert
  • Data Analyst or Data Scientist
  • Chief Marketing Technologist
  • Experience Architect

As mentioned, none of these roles are actual technical roles, developing or extending the marketing solution. The following lists the technology roles needed for a modern mature marketing organisation, written in the same format as in the book:

Solution Architect

The Solution Architect is your key to getting off on the right foot and leveraging whatever technology or technologies you choose the right way for the business. This role also makes sure that your governance process and solution is architected in a way which assures the flexibility and agility you need to mature and optimise.

A good solution architect is not only a technologist, understanding the chosen technologies and surrounding systems, but also a person who understands the business and marketing. This is the person which translates your business goals into technology and makes sure that the technology adapts continually.

You need this guy on your team if you want to be successful in the long run.

Skills and Competencies

  • Understands the technology and how to apply it in the business
  • Understands digital marketing and the goals
  • Works in an agile manner and understands the need for flexibility in the technology
  • Strong in communication
  • Practical
  • Quality driven

User Experience Architect

The most flexible part of any marketing solution is customer facing user interface and even if you are dealing with campaign landing pages, email, personalisation, or testing and optimisation, the user experience of your marketing solution will have to be continually changed and adapted.

A User Experience Architect knows the underlying marketing technology and how you will get the most value without rebuilding again and again and again.

Skills and Competencies

  • Strong on digital marketing and information architecture
  • Focus on solving real-world business problems with technology as an enabler
  • Understands the entire technology stack and how it all applies to the user experience
  • Works in an agile manner
  • Quality driven

Content Architect

With the increase of maturity in the marketing organisation and rise of the importance the digital channels it is vital that your valuable content – whether information, merchandising or other – is reusable across digital channels and that the task of creating and maintaining the content is as optimised as possible.

The Content Architect will assure that your organisation has a strong focus on content architecture and organisational processes, including content before presentation.

Skills and Competencies

  • Strong organisational understanding
  • Focus on workflows and business processes
  • Prioritises content over presentation
  • Quality driven


In a technology stack as deep as in marketing technology ranging all the way from user interface (HTML, Javascript and CSS) and server technology (Java, .NET, PHP, Ruby) down to the service layer and database technologies the developer role can be quite broad and it can be quite a task for a marketing organisation to team up with developers in the entire stack – and in truth, in many scenarios this is not even a viable solution.

This said, all marketing organisations need to comprehend that developers are essential for the long running success of the marketing effort. No marketing solution will run itself after installation so respect the developers and make sure you comprehend what they are doing and understand what they are saying. Your success relies on them doing their best.

Embrace the Technology

Independent of the technology you choose to power your digital business, you will inevitably need to take more and more ownership as your maturity grows. Just like you need more and more focus on growing your marketing team and filling the marketing roles, you will need to embrace the technical roles as part of your team – and unless you embrace this early in the process, technology and the processes around it will only slow you down.On the other hand: if you embrace the technical roles as your own, technology can be the driver to speed your maturity.

Recommended Practises, Search

Why does my Sitecore website perform so badly?

After many years of doing a lot of reviews on Sitecore I would conclude that it more or less always comes down to one single thing when pages perform badly: bad code. And when I mean bad code, I mean code iterating an excessive amount of items.

Iterating A LOT of items

Previously we used to see a lot of calls to descendants when solutions were using axis, xpath or Sitecore Query, but luckily this is a disappearing trend with the introduction of Sitecore Search in Sitecore 7. This does not mean that there are less bad code – maybe even on the contrary. The use of ORM and abstractions in many solutions means that layers of code can easily hide item iterations. Neither of the two patterns or technologies are inherently bad, but they do provide means to hide “bad code”.

The ARGH! Example

The example in the diagram below is from a customer here in Australia which had a problem with a very slow running product search. The diagram breaks down the different parts of the search page and describes the functionality and number of items hit by each part. It was part of the presentation to the client to highlight where the performance bottleneck was (and that Sitecore itself was not cause of the problem).

After looking through layers and layers of code (3000+ lines to be more specific), we discovered that the code in the different layers were searching Lucene and iterating search results, loading the items individually and recursively running business logic.

A simple search resulting in a page of 50 links would easily take up to 5 minutes, simply because the code was iterating in excess of 1.7 mio items from the Sitecore database –  which would take time in any solution🙂

Excessive Item Iterations

To cut the very long story short: always keep an eye on number of items being iterated – and never rely on caching to do the trick.

Introduction, New releases

Extending the Reach of your Sitecore Platform using the Federated Experience Manager.

The Customer Experience Management system landscape is incredible fragmented, covering amongst others content management, online customer service, e-commerce, campaign management, analytics and tracking, personalization, automation, social media, ad management, retargeting and many more, and most organisation have multiple systems in place – not only to handle different parts of the process, but often identical systems – like multiple CMS’s – to cover the same processes.

This scenario is not likely to change in the near future.

One of the newest features of the Sitecore Platform is the Federated Experience Manager, which can help connect a fragmented digital platform and make it possible to track and reach out to all visitors across all the owned channels in an organization.

Disconnected Platforms

Before joining Sitecore in 2014, I worked the last 14 years in a company called Pentia, based in Copenhagen, Denmark and since Pentia was the company from which Sitecore originally sprung in 2001, we were almost exclusively building Sitecore solutions for Danish and international customers.

Through the years, most of the clients I worked on aquired Sitecore as a major technological investment and as a new platform for driving their marketing efforts. So building or rebuilding their brand website, customer service website or e-commerce solution – and configuring the marketing tools – was almost always a major project for them.

When this is said, almost without exception, all would be stuck with one or more legacy websites or CMS systems following the migration or implementation project. This was not because the marketing division necessarily wanted it, but typically because the technical migration of their entire web platform would be too costly – or simply because Sitecore did not feel like the a good fit for a remaining systems.

So even though a lot of hours and smart people worked on implementing Sitecore and making the marketing platform better and giving the customers a better experience, it would often feel like we were working on a part that mattered very little.

Disconnected Experiences

We often saw that the legacy websites which were not converted to Sitecore was the e-commerce platforms, the direct customer service websites or the transaction websites. In other words, the websites actually giving the most value to the visitors – and often the organisation – and where the customer experience and visitor journey tracking was most vital to the success of the whole online platform, was being kept on legacy systems and technologies that were not allowing Sitecore to help marketing and customer service.

So the result was often a bad and very disconnected customer experience.

Seemingly simple things, like the visual design changing slightly from website to website, the overall flow or information architecture being bad or simply the content being wrong, not updated or just not assisting the customer towards the goal and the conversion. Furthermore the tracking and profiling capabilities of Sitecore was severely crippled, making the investment in personalization and optimization at best poor but often simply not worthwhile.

One platform, One Experience

Personally this was why I was rather excited when I first heard about the Federated Experience Manager a while ago.

By allowing Sitecore to reach out to non-Sitecore websites and applications and track visitor behaviour across these, we can start to see the entire visitor journey on the owned platforms and profile the users accordingly. But more importantly, we can start incorporating the legacy websites into the optimization effort, assisting the visitors on making those vital transactions, or start marketing our products or services on the websites where the visitor actually is, and not just where we would like them to be.

This will allow the marketing people to get even more control over all the digital channels – and ultimately make the investment in Sitecore and their new marketing platform much more valuable.

The Sitecore Federated Experience Manager

Sitecore Federated Experience Manager, FXM, will in short allow you to track the individual visitors across Sitecore and non-Sitecore websites using javascript tags – just like you know it from other analytics tools. This will allow you to use the standard Sitecore tools for goal tracking and visitor profiling. This mechanism is pretty much independent of technology, and FXM can even be used to track non-websites such as mobile apps.

But FXM will also allow you to push content from Sitecore to non-Sitecore websites and applications. This of course means that content can be maintained in one location within Sitecore and pushed across to other platforms. But potentially this can also be used to push theming and visual elements, to assure a unified user experience across all systems.

And since all content is managed and shared though the standard Sitecore mechanisms, we can leverage all Sitecores tools including personalization and A/B testing.

Finally FXM can be used to push data back to Sitecore too. This means that events and data from the external system can be sent across to Sitecore, and by leveraging Sitecores rules engine, we can trigger marketing events in Sitecore, for example engagement automation.

FXM is available for Sitecore 7.1 and forward on SDN.

New releases, Sitecore, xDB

Merging Visitor cookies in Sitecore CMS 7.5 and the Experience Database

Sitecore 7.5 hasn’t hit the streets yet, but as rumour has it, it will soon.

One of the highly anticipates features of Sitecore 7.5 is the ability to merge visitors across devices or cookies. This was something which had to be implemented specifically in the past, but will now be part of the platform.

How do I merge two visitors?

First of all, visitors in Sitecore 7.5 are no longer called visitors, but contacts. This is a part of a larger renaming scheme where e.g. visits (sessions) now are interactions and visitors are contacts. The renaming has consequences in the API, in that the DMS (which is now the Experience Database, xDB) API has had a major rework. Therefore expect a slightly harder upgrade path for those heavy DMS customized websites.

The key to merging contacts lies in identification. Two interactions on two different devices cannot be associated unless something common identifies them. This could be a login, an entered email address or something similar. It’s basically up to you to determine what and how to uniquely identify two contacts on two different interactions as being the same.

Sitecore.Analytics.Tracker.Current.Session.Identify(string key)

After you have determined the appropriate key to uniquely
identify a user, it’s as simple as calling the Identify method on the current interaction, ehh session? (Oops, apparently the rename hasn’t been done all consistently)

How does it work?

Using the new session handling mechanisms in Sitecore 7.5, Sitecore loads the contact associated with the current interactions cookie into session. The contact is then locked in shared session, making sure that two separate interactions will change the contact simultaneously.

  1. When calling Identify on the contact in the current interaction, any other contact identified with the same key is loaded using the LoadContactReadOnly in the ContactRepository class.
  2. The newly loaded contact is locked, making sure other interactions are not changing it.
  3. The current interaction is transferred onto the new contact, running the TransferSession pipeline
  4. MergeContacts is called, passing the current contact as “dying” and and the loaded as the “surviving”
  5. The MergeContacts pipeline is triggered, which in turn merges tags, counters, automation states, attributes and facets on the contacts.
  6. The new merged contact is now the active contact in the interaction and tracking will continue on this across multiple devices.

Things to keep in mind:

  • Sitecore 7.5 introduces new terms for the Analytics API
  • Expect a development effort when upgrading – dependant on the level of analytics use
  • In Sitecore 7.5, the platform will be able to merge visitors automatically
  • Nothing comes for free – you will have to determine how to uniquely identify contacts, and call the appropriate method
  • All steps of the actual merge is configurable using pipelines

See Nicks posts on 7.5 for a more in-depth walk through:


Getting your Sitecore project right

Still a very relevant blogpost – from 2011


This post is for you clients who have already selected Sitecore as your new website platform and is starting up a new Sitecore project.
Here are a couple of my thoughts on how you can get your Sitecore project on the right track from the beginning, by setting the stage for a good collaboration with your implementation partner.

The website you a building today should also be the website for tomorrow and hence the website you are building should be extendable, flexible and scalable. It is absolutely possible to build a Sitecore web platform which will last many iterations – considering that you take this into account early in the process.

Select your implementation partner carefully

Your implementation partner is the single most important collaboration partner in your project. They bind everything together; requirement specifications, user experience design, hardware, software, domain knowledge and more, and is therefore crucial for the

View original post 778 more words

Recommended Practises, Sitecore

How do I get the Publishing date for a page in Sitecore CMS?

During the last week I’ve stumbled upon this question multiple times (strangely enough when dealing with many Sitecore solutions I find myself stumble upon the same issues – and oddly enough, the same issue often arises on different solutions at the same time) and the answer is: “You need to determine what you mean by Publishing Date”.

Getting the date the item was published.

So you mean the date and time the page was transferred from the master database to the web database? Would this be the very first time the page item is transferred to the web database? Or maybe the first time the latest version of the page is transferred? Or maybe the last time the version was transferred?

The answer to all the above would be: There is no such date available in the Sitecore CMS API!

If you still want to pursue this path, John West has a brilliant post apparently solving this:

But you have to keep a couple of things in mind:

  1. Perhaps most important – does this date really make sense? Remember that this is not the date the page item was last changed, but merely the time of the transfer to the web database.
  2. This date would be the publish of the latest version to the web database.
  3. A full publish of an item would update this date – even if the item already exists in the web database. A full publish removes the items from the web database before a new publish commences.
  4. I am always most reluctant to make changes directly in the web database (as suggested by John West). There are generally many components of Sitecore (indexing, publishing etc.) which are based on items being transferred as-is from master to web. You might get it to work – but will every feature of Sitecore keep working? Correctly?

Getting the date the page was last changed.

Well this one is easy: Item.Statistics.Updated will give you just this, the date/time for the last change – any change – on the version of the item. By setting up workflows and a scheduled publishing strategy (which I would recommend on any solution) will transfer the page changes automatically to the web database, thereby getting an updated item published as soon as possible.

But! If you determine to use this field, keep in mind:

  1. The Updated date/time field will be updated by any change, e.g. both major revisions and just smaller changes. Even fields which are not shown on the page or not edited manually by users will trigger a change. For example: If an editor makes a revision to the text on a page on July 1., but an approver waits two months before approving the change (without content changes), the Updated date will be September 1. (because the item workflow state was changed on this date).
  2. There is no way for the editor to control this field (unless you start meddling with the inner working of Sitecore, which is never recommended). The field is controlled by Sitecore.

Using your own date/time field

Most likely, when thinking this issue through, you will arrive at the conclusion that the editors – or at least the administrators – needs to have total control over the Published Date shown on the page. This of course means that the field will have to be a custom field added to all page items – and the most straight forward solution is to just make the editors set the value when they make a change.

But if you need to automate the date/time value, there are a number of options which springs to mind:

  1. First option is to set the field value when the item is created. This can be done by setting the standard values on the template:
  2. You could change the date/time if some predetermined fields changes (e.g. the content fields shown on the page). This would be done in an event handler for the item saved event:
  3. You could update the field in a workflow action, e.g. approval. This would be require a custom workflow action. See more here:

Things to keep in mind

  • Think carefully what you mean by “Published Date”
  • There are no “Publishing Date” concept in Sitecore.
  • Use the Updated date with care – it will get changed by Sitecore at every change to the item
  • Consider using a custom field for this. There are ways of automating the value in the field without meddling with the inner workings of Sitecore.
Search, Sitecore

Avoiding downtime while rebuilding your Lucene search indexes in Sitecore ASP.NET CMS

This is the first blog post I’ve written since my arrival in Sydney and my new job within Sitecore. It will be about a simple yet strong feature often overlooked in the Lucene indexing capabilities of Sitecore 7: how to avoid downtime on your Lucene indexes.
One of the problems I run into occasionally is that a rebuild of an index, e.g. the web database index, will cause features of the site to not work properly. This is due to the fact that the index is taken offline while rebuilding.

But what causes a rebuild?

A rebuild may be triggered manually through the control panel in Sitecore, or by an indexing strategy such as RemoteRebuild (see more here). But full rebuilds might also be triggered by simply publishing too many items from master to web. This is due to the Threshold setting in e.g. the PublishEndStrategy, which will transform many single item indexes to simply one full rebuild if the given threshold is reached (See more here).

How do I avoid downtime then?

Well the solution to the above problem is relatively simple, yet often overlooked: Changing the standard Lucene index handler (the class which actually handles reading and writing to the Lucene index files) from LuceneIndex to SwitchOnRebuildLuceneIndex will remove this problem.

<configuration xmlns:patch="">
        <configuration type="Sitecore.ContentSearch.LuceneProvider.LuceneSearchConfiguration, Sitecore.ContentSearch.LuceneProvider">
          <indexes hint="list:AddIndex">
            <index id="sitecore_web_index" type="Sitecore.ContentSearch.LuceneProvider.SwitchOnRebuildLuceneIndex, Sitecore.ContentSearch.LuceneProvider">
              <param desc="name">$(id)</param>
              <param desc="folder">$(id)</param>
<!-- ... -->

The SwitchOnRebuildLuceneIndex maintains two separate indexes on disk, one active and one passive. As a rebuild occurs, it is executed on the passive index and when the rebuild completes, the passive becomes active and the active becomes passive. Thereby, there will be no downtime of the index.

Things to keep in mind

Therefore, a couple of things to keep in mind:

  • Switch to SwitchOnRebuildLuceneIndex if you want to make sure that you have no downtime on your Sitecore search indexes.
  • Make room on disk for maintaining duplicate disks.
  • Always choose your Index update strategies carefully.
  • Different server roles might require different index update strategies.