Author / pizzathehut

by pizzathehut

3 Evil Opinions of Enterprise Architecture

I have long been an advocate of Enterprise Architecture as a concept, and have successfully helped roll out various forms of EA across different companies. However one constant has always been that EA needed to be redefined to address the widely varying views of what it was, and what benefits it could provide. In some cases this extended to changing or repairing some existing negative views. Those views could be because of one person (the architect that team or individual worked with), or as an opinion of the whole EA process.

This post shares some of those negative views, with the aim of helping architects understanding what stakeholders might think of EA and how to address them. It also allows me to be a bit negative towards EA, as I have certainly seen implementations of EA that are more a hindrance than help. As I’m currently helping roll out EA with a new company, I also want to make sure I don’t fall foul of the below perceptions.

The Government

One very common, and not entirely unjustified view, is that EA isthe remit of failed engineers or simply tech academia (e.g. those that can’t do, teach). It imposes frameworks and governance that only serve to centralise decision making and slow down the velocity of change and progress. This view can even sometimes come from architects themselves, especially Solutions Architects used to more agile processes, who would often be frustrated while waiting on their next ten minute opportunity within the bi-weekly Architecture Board to discuss their proposal for the replatforming of an entire system (or something like that). I see this view perpetrated by the more bureaucratic organisations where phrases like ‘we are not a tech company’ are prevalent (by the way, that’s probably the phrase I fear the most in any company I have worked for). In those types of companies, EA serves exactly that purpose, to slow things down, and provide assurances and accountability into any IT change. This in my opinion is the worst use of EA, and tarnishes it’s goals for others.

Rectifying this view comes down to collaboration with engineers, and building credibility with technical teams. This may also involve reviewing processes and relaxing the governance somewhat to ensure EA is guiding and not hindering development. From the business side it may also be necessary to begin demonstrating real business value quickly, and re-communicating the role of EA, along with any strategy or vision.

The Consultant

Another view of EA is the consultant view, in which architects only come into a project at certain times, spout advice and guidance, and then disappear until the end, or when something goes wrong. This view sees the architect as a bit of the ivory tower type, supercilious and not connected (or possibly experienced) with real projects. This view often stems from when actual consultants have been used to rollout EA, and their methods have been adopted by permanent replacements. This can also sometimes be the case when architects are simply stretched too thin, and can only spare time up front according to business priorities.

If you find this is the case in your practice, then consider who you have available to perform the role of Solutions s Architect within each team. this doesn’t always have to be a dedicated role, and often a lead engineer can perform this function well. Using these guys will help delegation, and also gains more buy in from engineering teams. Ultimately if you find you aren’t adding anything to a project, then simply refocus on priorities until you demonstrate the benefit that allows you the budget to get more architects.

The Thinker

Perhaps more of a character portrait, but this is certainly the view I have held myself of certain architects I’ve worked with (and unfortunately reported to). These architects tend to enjoy the blue sky thinking involved in architecture, and are typically the ones designing new processes, new templates, new acronyms, and have very little input into detail. Ideas coming from these guys tend to be quite ideological and seldom have any indication of how these visions and ideas might be achieved, at least not in any detail.

One simple solution to this one, start delivering real value. Architects need to resist the temptation to perfect everything they are doing upfront, and instead learn to be more agile and responsive. designs can change along the way, and often will. As George Patton once said;

“A good plan violently executed now is better than a perfect plan executed next week”

So how do I fix it?

All of these views derive from EA practices that have been poorly implemented, or have been implemented as top level governance frameworks with little connection to engineering and delivery. if you are in these positions, or perhaps are now implementing EA at your company, then keep these things in mind;

  • Although EA is about making IT align with business, the engineering teams are a critical part of this delivery, and their ability to deliver should be a key consideration.
  • As with all areas of business, EA needs to be seen to deliver value. In my opinion it is unacceptable for architects to spend a year in a dark room and then emerge with a radical framework designed for global dominance. Ensure you start delivering from day one, and resist overthinking or perfecting everything.
  • Although architects should be key resources and leaders of technical knowledge, don’t become the only guy with the knowledge. Ensure you have good knowledge management processes (thing Brown bag lunches , coding dojos etc), as it will upskill everyone and lighten your own workload.
  • Use diagrams as temporary tools to demonstrate thinking, and not as a governance tool to indicate an agreed design. Things change quickly in development, and adhering to thinking at the beginning of a project is dangerous. At minimum, you will find these diagrams become quickly out of date and will dilute your process. Diagrams can be given to agree an ‘approach’, and then architects should work closely engineering to ensure the final output is true to the ‘approach’, if not the actual design.
by pizzathehut

Why are you moving to the cloud?

It is becoming more and more normal for companies to consider the cloud for their hosting requirements, in particular where new builds are concerned. The advantages of cloud hosting are now well known, and it is no longer a bleeding edge technology, but something that is providing real value to business of all sizes.

Some of the inertia behind the cloud seems to be driven from a perspective of cost, in particular there is a perception that running in the cloud is cheaper than on premise. I have been involved with many architectures (both new and old) that have moved to the cloud, and a good majority of these have been driven from a cost perspective. This idea, coupled with a lack of knowledge of how to manage a cloud infrastructure and to utilise its benefits, is actually driving cost of hosting up, as well as affecting performance and stability. I have long been preaching the necessity to understand exactly how the cloud works, and some of the recommended practices or culture changes required when moving to the cloud, and I thought it was about time I put these out to the wider world.

Time to Scale

Most cloud providers offer auto-scaling functionality to allow you to deal with peaks in demand. This is a critical factor for ensuring performance, and one of the best parts about cloud hosting. The other often missed part, is scaling down. This is also crucial, as it optimises the cost of your hosting and ensures you really do only pay for what you need. You should think out clearly your scaling strategy alongside your architecture to ensure you have every part of your architecture ready. Scaling should cover both vertical and horizontal scaling as well, not just horizontal. This is particularly applicable for Platform as a Service (PaaS) services, which offer differing tiers, and tend to hold you ransom for higher performance tiers.

Ideally you should have a view of your traffic profiles over time and adjust your auto scaling factors to account for these. For instance, on weekdays you might scale between x and y for web servers, but on the weekends, you might scale between y and z. Likewise for your horizontal scaling. Scaling is not a golden bullet either, and you should consider the following when planning your scaling strategy;

  • Scaling isn’t ‘instant’ in most cases, and can sometimes take minutes to hours. If you know you have spikes at certain times, then scale beforehand
  • Scaling any 3rd party software may have licensing impacts, so beware
  • Consider all elements of your architecture when setting scaling parameters. There is no point in scaling out to 30 web servers if you will just create a bottleneck on one database server
  • Consider Infrastructure Automation tools like Salt and Chef to help create advanced scaling rules, as well as managing the auxiliary services impacted by scaling
  • Scaling should not replace capacity planning. Scaling is to optimise cost and cope with spikes in demand, and should be built on top of a well-planned architecture

Stability

When moving to the cloud, I often see companies with a perception of outsourcing networking and infrastructure knowledge. It’s true that the benefit of cloud hosting is that you no longer have to worry about infrastructure and networking, but you need to understand this, and in particular understand how your cloud hosting provider deals with it, in order to design stable systems. Graceful degredation, dependency failures etc don’t disappear in the cloud, but they can be abstracted if you don’t fully understand how your hosting provider presents these issues. This can lead to architectures that don’t take into account failure scenarios that they perhaps would have in on premise architectures. Stability is a huge issue in the cloud, and one that you should be thinking about from day one. If you are migrating an existing on premise architecture, then this is doubly important as you should not be expecting the same levels of stability, and should be planning how your architecture will cope with multiple service failures (which is a fact of cloud life).

I often see the clouds inherent instability as an advantage, as it forces you to think about resiliency and failover from day one, which only serves to increase overall stability in the application. However I often see people disregarding this aspect, instead relying on underlying cloud provider SLA’s and good old backups. Stability in the cloud basically means ‘anything can happen’, and it usually does. Services will frequently fail, contention on resources will affect performance, servers are self-healed, demand spikes add resource contention etc etc. This requires you to really consider this when deploying, and try to eliminate all single points of failure and have failover plans in place for all parts of the architecture.

Testing is a critical part of deploying to cloud, and should involve some level of failure testing. This would typically involve testing how your architecture handles under load when certain services fail. If you are on AWS, then Netflix’s Chaos Monkey (part of the Simian Army toolset) will help you introduce this type of testing, as well as giving you the rare privilege of yelling ‘Release the Monkeys!’ every time you deploy.

Culture, DevOps, and Tooling

Taking full advantage of the cloud will almost certainly require a change in culture, as well as the addition of new tooling into your architecture and deployment processes. Your culture should acknowledge and embrace the instability in cloud, through the following (as a minimum);

  • Developers should be ‘coding defensively’
  • Architects should be architecting for new failure scenarios
  • Load testing should be the norm
  • Monitoring and Alerting tools should be implemented from day one
  • Self-healing infrastructure should become the norm
  • Infrastructure automation should be utilised
  • Service failure testing (testing failure of different elements within the architecture)

Without adopting these practices then the potential for falling foul to the traps of cloud will become more likely, and frankly the benefits of moving to the cloud will be lost.

Developers and DevOps should also be utilising the on-demand nature of cloud to provide instant test servers, trying out new products and services, and continually improving all aspects of infrastructure. One common example is UI testing, which historically can prove to be a bit flaky. When running something like Selenium on your build server, there is a potential for lots of hanging browsers, which over time will impact the build server. To rectify this, you can instead put up an on-demand server specifically to run UI tests, and then shut it down once complete. While this might affect build time, it does increase stability of the overall process. This method can be expanded to add new build agents as desired to cope with load testing etc. The underlying message is that the culture of the team should adapt to take advantage of what becomes available through cloud hosting.

Performance

If any has ever told you that the cloud is fast, then you have every justification to strap them to a chair and force them to endure endless reruns of Frozen – Singalong edition while eating Rum and Raisin ice cream, a fate worse than enduring any Vogon poetry for sure. Of course the cloud can be fast if architected correctly, but compared to physical dedicated hardware….not likely.  So If you are thinking of a ‘lift and shift’ approach to your infrastructure to migrate to the cloud, this should be an immediate red flag to you and any architect involved. Hosting on-premise with dedicated hardware is an entirely different beast to hosting in the cloud. Where you might think it is a simple matter of having the same number of VM’s, this really isn’t the case, and will certainly cost you more as well as be unlikely to offer the same level of performance.

Performance from the cloud comes with the use of the available services, as well as the aforementioned scaling ability. Things like Content Delivery Networks, SSD storage etc are all likely part of your cloud provider, and so should be utilised to enhance performance.

These are some of the things that I have often seen forgotten when thinking of cloud hosting, and it’s always to the detriment of the solution.

Let me know your experiences of moving to the cloud, and in particular which things are often overlooked.

by pizzathehut

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
by pizzathehut

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.

by pizzathehut

Sitecore DMS: Register a Goal Against Any Page

This is a quick tip for allowing a single service (Web Api Controller, MVC Route etc) to programmatically register goals against any page.

Typically when using the Sitecore DMS to register goals through code, the most common approach is to use the Tracker class to register a goal on the current page, as such;

        //Create the record that needs to be stored (the goal)
        VisitorDataSet.PageEventsRow pageEventsRow = Tracker.CurrentPage.Register(goal);

        //Add any data you like, which will be stored with the PageEvent
        pageEventsRow.Data = eventMessage;
        pageEventsRow.ItemId = goalItem.ID.ToGuid();

        //Submit the goal
        Tracker.Submit();

The issue with this is that it registers a goal against the current page only.

In some scenarios you may wish to register goals against other pages. For instance if you would like to set up a generic MVC/Web API route to register a goal from client side, accepting any page.

To do this, you can use the PagesRow class (the class type for the Tracker.CurrentPage object) from the VisitorDataSet to register the goal.

       //Getting the current page into PagesRow 
        VisitorDataSet.PagesRow page = Tracker.Visitor.CurrentVisit.CurrentPage;

        //Override items as required
        page.ItemId = tmpItemId.ToGuid();
        page.PageId = tmpItemId.ToGuid();
        page.Url = "/Articles/Custom-Field-for-Task-Schedule";

        var pageEventData = new PageEventData(goalName)
        {

               ItemId = tmpItemId.ToGuid(),
               DataKey = goalName,
               Data = "/Articles/Custom-Field-for-Task-Schedule",
               Text = targetItem.Name
        };

        //Register via page
        page.Register(pageEventData);

This example uses the CurrentPage object to instantiate a PagesRow object, which is then overridden with the required values. I then create a standard MVC route to this method. My example looks like this;

     routes.MapRoute(
            "RecordGoal", // Route name
            "rest/goal/{goalName}/{itemId}", // URL with parameters
            new
            {
                action = "RecordGoal",
                controller = "MarkettingService",
            });

I can now call this route from any page client side, and simply pass the goal name and the page I wish to register it against. Now in the Latest Visits report, I can see my goal recorded against the correct page:

Analytics Report

by pizzathehut

Sitecore: Grouping Publishing Targets

This post is to provide a simple tool to cover an admittedly rare scenario, or at least currently rare. This scenario came about after working with a global Sitecore customer to design an architecture that covered the customers global footprint. The architecture allowed for multiple Content Delivery (CD) servers within each region for availability/redundancy purposes.

World Architecture

When designing this architecture, it became evident that there would be lots of different publishing targets created, which would become an annoyance to Content Editors, and also bring about the possibility of publishing targets being left unchecked. Editors in Asia however still needed to be able to publish to the Asian CD’s and not necessarily to other CD servers. With the above, the publishing dialog looked something like this;

Publish Dialog Before

The simple solution to this is to allow grouping of the publishing targets into logical groups, such as Asia; Europe; US etc. To achieve this is easy, and involved the following steps;

  1. Create a new template type to represent Publishing Groups. This contains a single multi-list for selecting publishing targets that it will represent.
  2. Create a folder to contain your publishing groups.
  3. Create the groups that you want to use, and add the relevant publishing targets into each.
  4. Override the ‘Publish.xml’ dialog to add in a new frame for publish groups
  5. Create your own class to sit behind the dialog form;
  6. Where publishing groups exist, then use those in place of publishing targets, else use Publishing Targets in the normal way

In the infamous words of Blue Peter, here is one I have made earlier: https://marketplace.sitecore.net/Modules/Sitecore_Publishing_Target_Groups.aspx

You can also find the source here: https://github.com/brooksyd2/sitecorepublishgroups

Once installed, this module will allow you to set up publishing groups to represent many publishing targets;

Add Group

This will then feed into the publishing dialog as below;

Dialog

This can be further refined through default publishing groups, settable in the same way as default publishing targets.

As stated in the beginning, a simple solution to a rare problem, but one I hope will help someone else in future.

Related Module: https://marketplace.sitecore.net/Modules/Sitecore_Publishing_Target_Groups.aspx

Related Source: https://github.com/brooksyd2/sitecorepublishgroups

by pizzathehut

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