Marketers and Developers, Can We Understand Each Other?

Historically Sitecore developers have enjoyed a relative monopoly on understanding Sitecore terminology and practices. Through its history as a Content Management System, already well-known terms were used and developers and business users alike were able to easily understand their common meaning. Terms like ‘workflow’, ‘security roles’, ‘templates’ etc were typically the domain of developers and little to no communication was required to translate these terms into the business domain, and there is little room for ambiguity in these terms.

With Sitecore’s growth into a Customer Experience Platform, this has changed with its expansion into the world of marketing and its associated (and ever growing) terminology. Now developers are tasked with working with marketers to help create campaigns, track interactions and sessions, manage goals and outcomes, and all of the little bits in between. Marketers likewise need to be able to communicate their requirements to developers, without having to explain the intricacies of their day to day jobs. Perhaps an even larger issue is the coming together of these two different worlds, and a dependency between them to ensure business value is being delivered.

The Sitecore UK Marketing Team recently ran a survey to look at some of the communication challenges faced between Marketers and Developers, which attracted over 150 responses. As might be expected, the survey highlighted a huge gap between developers and marketers, with an overwhelming 95% of respondents stating that they are struggling to bridge these differences. Perhaps more surprisingly, 85% of Marketers, and 95% of developers expressed frustration in working with developers and marketers respectively. This indicates a huge issue that can be causing frustration in development, misinterpreted requirements, and ultimately a reduction in the business value being delivered by both groups. Indeed, the differences can descend into vitriol and cyniscm between the groups, with each of them viewing the other as supercilious or arrogant and detrimental to delivery.

What Marketers and Developers think of each other

What Marketers and Developers think of each other

Here are some of the more eye-opening comments from the respondents (the survey was anonymous for the safety of everyone involved 🙂 –

From Developers:

  • Self-importance, arrogant superiority
  • speak in riddles, have no clue or understand about web systems, technology

From Marketers:

  • Can be a sensitive bunch, easily misunderstood
  • The penny dropping takes too long – they are the experts – all hail developers 😉

What is causing the friction?

The clear message from the survey is that a lack of communication makes it difficult for both groups to understand the other. From a marketers perspective, developers can favour the application of technology over its actual use to the customer, and can be secretive and less communicative than the average marketer. On the other hand, developers often feel marketers lack the technical knowledge they should, and tend to view things as much simpler than they actually are. For instance, a common theme among developers was that marketers tend to request features present on sites like Google and Facebook, and expect these to be simple additions.

To add to the complexity, the terminology between the groups is very different, which leads to confusion and misinterpretation. This can lead to added effort within any development, and in some cases can lead to even worse.

Misunderstanding

How can this be improved?

This issue is not new within software development. Issues like this have existed for years between software teams and the business. The issue arises from a lack of communication between the teams, which leads to developers having to make assumptions and interpretations from a given set of requirements. Likewise, since the business does not communicate with development teams except through a given set of requirements, they have no understanding of what’s actually involved. Therefore, all they would see is a requirement taking longer than it should (or longer than they think it should). A lack of communication during this process inevitably leads to lots of finger pointing when things don’t go to plan.

Recently, this issue has been rectified through the introduction of new Agile methodologies, and the idea of multi-disciplined self-organised teams. Using this method, marketers and developers should ideally be within the same team, aligned to a particular business domain (such as product or sales). Agile development and project management methodologies advocate collaboration and communication over process and documentation. This seems to be the answer to ensuring that marketers and developers can actually sit and speak about requirements, and crucially things can be tested quickly to see if they work.

Of course this is a huge topic and a big organisational change if your company isn’t already doing it, and doing this with Sitecore also brings its own considerations. Look out for my forthcoming blog post about organisation structures to support development. In the meantime I would highly encourage anyone to look into agile processes if they aren’t being done already: http://www.agilealliance.org/the-alliance/the-agile-manifesto/

Improve the Little Things

There are many more things that can be done as quick wins to start to bridge the gap;

Developers

  • Ensure you speak to marketers for clarification of requirements where necessary
  • Take time to teach them the platform and it’s uses
  • Don’t assume knowledge
  • Lean on architects to translate concepts between domains, including creating a common ontology
  • Don’t try and contain knowledge, openly share knowledge and aim to educate others
  • Bury your ego

Marketers

  • Be aware of differing personalities and adapt your approach to suit (getting an organisation to use something like Myers-Briggs profiling really helps here)
  • Involve developers in your ideation process
  • Get developer feedback in your planning/scoping activities
  • Ask for explanation’s where necessary and ensure developers are made aware if you don’t understand something

Ultimately if communication is improved, then both groups will have a greater understanding of the others activities, and new developments will be quicker and less prone to bugs. Clear communication will also reveal that both groups are actually not as far apart as you think, as evidenced by the survey.

How Marketers and Developers Evaluate Tasks

How Marketers and Developers Evaluate Tasks

What can Sitecore do?

Sitecore as a platform needs to cater to both developers and marketers, with the intention that both groups will be working on the platform in collaboration. Of course depending on how you approach development this may not be the case, but there are some things that every Sitecore developmer should insist on to aid understanding between groups;

  • Ensure a common ontology for the core parts of your solution
  • Utilise the Sitecore 8 Marketing Taxonomies to categorise marketing activities
  • Use display names with associated validation to ensure friendly naming of items
  • Develop SPEAK applications to cater for common business processes, simplifying them to the essentials of the process

What do you think, and what challenges you are facing in your teams? I’m Especially interested in hearing how you may have overcome these issues as well.

Taxonomy

Sitecore 8 Marketing Taxonomies

The release of Sitecore 8 has seen a slurry of new features and capabilities added to the new platform, all of which shine for attention. Features like the Federated Experience Manager, new Analytics Suite, Test Everything approach, and test gamification all add to the marketers arsenal of tools.

However with all these new features, some of the more subtle important changes may have been overlooked. This post looks at one of those, namely the addition of new marketing taxonomies and the new ‘Outcomes’ feature.

Taxonomy (from Greek taxis meaning arrangement or division and nomos meaning law) is the science of classification according to a pre-determined system, with the resulting catalog used to provide a conceptual framework for discussion, analysis, or information retrieval

It’s easy for us developers to often think marketers only run one or two campaigns at a time, making them easy to manage. The reality though is that marketers are often running lots of campaigns, all spanning different channels and audiences, each needing to be reported on. Prior to Sitecore 8, marketers could include a ‘type’ whenadding new campaigns, however this was a free text field and wasn’t particularly useful in reality. Campaigns were also attributed a ‘Traffic Type’, which held the method by which a user visited the campaign (direct, via branded keyword etc). Again this was useful, but relatively limited.

Sitecore 8 introduces a slew of new taxonomy methods to help categorise and manage campaigns. These are found under the Marketing Control Panel (formerly Marketing Center).

Overall

Campaign Group

A Campaign Group provides the ability to group campaigns into relevant groups, which provides the ability to report on performance of a group of campaigns under a particular umbrella. For instance, if you are running multiple campaigns around a particular event, such as ‘Digital Trendspot’, then you can attribute all the relevant campaigns into a ‘Digital Trendspot’ Campaign Group.

Campaign Group

Warn

Channel

Channel is a direct replacement for the ‘Traffic Type’ attribute in previous Sitecore versions, however it adds more flexibility over Traffic Types.  Expanding the list of Channels will show you an exhaustive prepopulated list, covering both online, and crucially, offline channels as well.

Channels

As before, new campaigns can be attributed to a channel, which denotes the expected channel that the user will visit the campaign on. Of course, a campaign earmarked for a banner ad or ad network, could feasibly be tweeted and so also drive some traffic from Social networks. To capture this, Sitecore will capture both the intended channel (i.e. the channel attributed  to the campaign), and the actual channel for the user. Using these two fields, marketers can then see how campaigns are communicated through other channels than the originally intended channel.

Assets

A Marketing Asset is typically any marketing content that is used to educate and create interest for a company’s product or services (look out for my forthcoming blog post around terminology differences between marketers and developers). These usually take the form of white paper downloads or pdf’s, could be anything the marketer wishes to use.

Assets

Sitecore 8 now provides the ability to explicitly add marketing assets and attribute them to campaigns. The Asset taxonomy follows the Campaign Groups taxonomy, in that you can create an Asset Group containing many assets. For instance, and Asset Group might be FAQ’s around your products or services, which will then contain the actual FAQ assets.

Campaign, Asset, and Goal Facets

One of my very favourite things about Sitecore is it’s absolute extensibility and flexibility. No one platform can ever provide every feature requirement of a business, and Sitecore recognises this by providing all the mechanisms necessary to easily add your own features and content, all leveraging the underlying capabilities of the platform. Facets extend this idea into the marketing realm, and are essentially there to provide further means to categorise campaigns, Goals, and Assets by ways applicable to your business.

Facets

To use these, you simply rename the applicable facet to whatever you need, and then select it in the applicable field within your Campaign, Goal, or Asset. For instance, you might require Campaign Facets that denotes a Cost Centre. To do this, unprotect one of the ‘Campaing Facet’ items and rename to ‘EMEA’. Then select your campaign and under ‘Campaign Facet 1’ (or applicable number), choose your new Campaign Facet.

Outcomes

Lastly, Sitecore 8 has added a new way to group goals, or provide a hierarchy to user actions, through the ‘Outcomes’ feature. Outcomes are intended to specify a final outcome for the visitor, which may consist of many goals before achieving that outcome. For instance, a user purchase may be an outcome. To purchase a product, a user may trigger several goals along the path.

Outcomes

Using Outcomes will give more ways to analyse traffic (and/or base personalisation on) through tools such as the Path Analyzer and Experience Analytics.

Sitecore DMS: Recognising Users Across Devices

This post looks at how DMS stores visitor records, and this can be manipulated so that returning visitors across devices can reuse the same Visitor records.

When a user visits your site for the first time, the Sitecore DMS will create a brand new Visitor record in the analytics database, and link this to a new Visit record. This visit record will be updated for the duration of that session with relevant information, such as pages visited, profiles triggered etc. Sitecore will also place two cookies onto the clients computer, one for the session, and a global cookie that will help Sitecore identify the visitor between sessions. These cookies are called

SC_ANALYTICS_SESSION_COOKIE, and SC_ANALYTICS_GLOBAL_COOKIE respectively.

Once the first visit has been registered, your Visits Table will look like this (obviously ignoring any previous visits):

VisitFirst

The VisitorId matches the new Visitor record created in the Visitors table, which will look something like this:

VisitorFirst

Once that session ends, then the visit will be closed (this is all handled via the VisitEnd pipeline, which is invoked by the SessionEnd pipeline). If the user then returns to the site, Sitecore will check for the SC_ANALYTICS_GLOBAL_COOKIE  cookie, and if found, will use the existing Visitor record to attribute to a new Visit Record.  So to simulate this, delete the existingSC_ANALYTICS_SESSION_COOKIE (shown through Chrome below);

Remove Cookie

Now when you refresh the site, Sitecore will not find a session cookie, and so will create a new visit. However, as it can find a Global cookie, it can detect who you are, and so the same VisitorId will be used as the previous visit.

SecondVisit

So this is great, Sitecore can now continue attributing visits to the same user so long as it can find the Global cookie. The Global cookie is set to expire 10 years in the future, so as long as the user does not delete that cookie, and continues to browse from the same device, then Sitecore will continue to recognise them.

However, if the user browses to the site from another device (mobile, different browser etc), then obviously the cookie won’t be there and Sitecore will create a new Visitor record. Assuming that the user hasn’t authenticated against the site (and so no Sitecore User exists for them) then there is unfortunately no way to detect that user on another device. What about when the user does log in or becomes known in some other way? Unfortunately Sitecore still does not recognise this as the same visitor, and so the new Visitor record will endure.

If you do want to use the same Visitor record however, then this is possible, so long as the user has registered (or in some way has a corresponding Sitecore User profile). When the user registers with the site a Sitecore User profile is created. Of course at this point you should also be using the ‘ExternalUser’ field to set the user name (or other identifiable attributes), which would allow you to query for the user across different visitor records as well.

Tracker.Visitor.ExternalUser = Sitecore.Context.GetUserName();

So once the user registers, the Visitor record will be updated as such:

Register

To allow Sitecore to recognise a returning authenticated user, and set the Visitor record appropriately, you simply need to recognise the visitor first, and then replace the automatically generated Session cookie with a new Session cookie containing the previous visitor details. To do this, within the Log In method for example, you can see if the user has an existing profile (using the user name), and if so set the cookie;

var visitor = VisitorManager.GetVisitorByExternalUser(domainUser);

if (visitor == null)

{

    Log.Info("First visit of " + domainUser, this);

}

else

{

    Log.Info("Returning visit of " + domainUser, this);

    if(visitor.VisitorId != Guid.Empty)

    {

        new VisitorKeyCookie().Create(visitor.VisitorId);

        new VisitCookie().Invalidate();

    }

}

With this method in place, when the user firsts visits your site from a different device, a new visitor record will be created to match their anonymous status (as they are not known at this point).

ReturnAnon

Once they log in however, a new Visit record will be created with the previous Visitor details set. This does mean that everything for the user post log in will be treated as a new visit, but using the previous VistorId.

Recognise