#abtoanalytics

1. Analytics and BI standardization is waning. A decade ago, the BI market was consolidating as companies tried to standardize on fewer BI products that could be deployed throughout the organization. Times are changing. Cloud and mobile innovation and big-data exploration favor experimentation with a new generation of tools. Our 2015 survey reveals that only 28% of respondent firms now say they're standardizing, down from 35% in 2014. And 21% say their firms use "many analytics and BI products," up from 16% in 2014.

2. Cloud-based data warehousing is on the rise. Cloud-based data warehousing services show the biggest increase in adoption of any information-management category, jumping to 34% from just 24% in 2014. The poster child here is Amazon Redshift, the data warehousing service launched in 2013. Last year, Amazon Web Services CTO Werner Vogels described Redshift as the company's fastest-growing web service ever. IBM responded in 2014 with Netezza-based DashDB. Next up will be HP, which announced plans to launch an online version of its Vertica database early this year.

3. Real-time technology is seeing real gains. Providers of complex event processing (CEP) technology have predicted for more than a decade that the technology is going mainstream. We're still not there, with broad use of CEP still a rarity outside of financial services, security, telco, and intelligence agency circles. But adoption shows an eight-point lift to 35% of our 2015 respondents. Usage is "extensive" among 12% of respondents, while 23% say they use CEP "on a limited basis."

Amazon, once again, provides a mainstream proof point with its Kinesis CEP service, which is powering real-time bidding, buying, gaming, media streaming, and other services. Apache Spark, Apache Storm, Splunk, and other options are bringing real-time analysis to system, service, network, mobile, and application-monitoring scenarios. The cloud may be the enabler this once-exotic technology was waiting for.

4. Hadoop and NoSQL adoption are growing. No surprise here; NoSQL and Hadoop both show seven-point gains in adoption since our 2014 survey, used by 26% and 22% of our 2015 respondents, respectively. Factors driving interest in NoSQL databases include "faster, more flexible development than achievable with relational databases," cited by 24% of respondents, and "lower software and deployment cost," cited by 21%. Motivations to use Hadoop include the "ability to store and process semistructured, unstructured, and variable data," cited by 31% of respondents, and "lower hardware and storage scaling cost than commercial products," cited by 25% of respondents.

Reality check: Consistent with last year's results, about half of all respondents still say NoSQL and Hadoop are "not a priority for my organization" at this time.

5. Data quality concerns are easing. Data is messy -- always has been, always will be. Big-data platforms like Hadoop and NoSQL databases accommodate messiness because they don't force you to normalize everything into predefined data models with consistent dimensions of data. Techniques like machine learning and visualization let the data do the talking. Accuracy improves with scale, and trends and exceptions stand out more clearly. It's not that data quality is no longer important; indeed, it's still the No. 1 "barrier to success" cited by both BI and analytics types and information management professionals. But concern is diminishing -- at least where analysis is concerned -- with only 51% putting data quality on their "barriers" list, versus 59% in 2014.

One upshot of this year's report is that many companies are no longer counting on a few favored vendors to provide all the answers (along with hefty consulting bills). Organizations are experimenting. In some cases they're reacting to competitors that are innovating with new data sources and technologies.

The same old data and the same old tools can support the same old business, but how many CEOs are satisfied with the way things are? Not many. How many companies aren't confronting big challenges? Plenty. Don't embrace change for the sake of change, but don't be complacent in 2015.

Any broken promise, large or small, chips away at trust and credibility. A suitor asks you on a date but doesn’t show up. A parent says she’ll play a game but never does. A link on a website says Products & services but opens a registration page instead. These damaged promises make a person feel baited, annoyed, disrespected, disappointed, and duped. In short, nothing good. On the other hand, when a link does fulfill what it professes, people move through the site seamlessly and confidently.

Links Should Stand Alone

When conducting eyetracking research, I often observe how people attempt to scan the minimum amount of content that gets them enough information to proceed. Humans are programmed to seek efficiency and minimize the interaction cost: They economize on their fixations (how many things they look directly at). Often they scan first only the text and those UI elements that they believe will help them to quickly understand content and to progress in their task.

In one frequently-observed page-scanning pattern, the Spotted Pattern, people scan in a seemingly random manner, that, when analyzed carefully, reveals that they look at items that seem to relate to what they want, or that are perceived as important or different than the bulk of the content. These items include:

Headings

Bullets

Content (words) that are shaped like what users are looking for

Digits when they are looking for a value that contains a number (such as a temperature or weight)

Capital letters when they are looking for items that often contain them (such as abbreviations for countries and states)

Buttons, when they have visible signifiers such as a rectangular frame and shadowing

Links, when they look different from normal text (for example when they have a different color, are underlined, or bolded)​

Thus when links and buttons are formatted differently than the surrounding text, they attract user attention. As a result, many users don’t actually read the adjacent content and treat links as standalone items. So the terms used in links should be understandable when taken out of context and read alone. (This practice will also benefit screen-reader users.) For example, trade words such as go, more, and read more, for descriptive phrases such as Chat with a specialist, Products and services, or Baby born on airplane.

The best links are salient and descriptive. People should be able to read an expressive link or button term, determine the strength of the information scent, decide if they want to click the link, click it, wait until the next page loads, scan the page when it does, and immediately confirm that they are in the right place. In many cases, websites confirm the user’s assumptions and the person confidently continues scanning or reading.

Confirm the Person's Assumption

Once users click a link, the onus is on the site to meet or break the link's promise. Ideally, the destination page should offer cues to tell the users that they have arrived in the right place, and how to move further ahead. Effective ways to confirm the users’ assumption include:

Positioning the expected content in the default viewable area, and not forcing users to scroll, click, or tap to display it

An understandable and visible page heading

If linking to an applet, displaying the applet, or at least the first step in the applet's workflow

If linking to a form, displaying some fields by default

An image that very much relates to the topic at hand

Incorrect Page with a Vague Description

Sometimes link and button text sets an expectation but instead links to a place other than what the user anticipated. Worse, it may not even be completely clear what the page is about. In these cases, users are forced to make assumptions and hunt for the right path. For example, the Canadian university McGill’s website provides a link to Programs, costs & more in the Graduate & postdoctoral studies section. People who are looking for tuition information and click the link will find a page that offers no tuition information, or even any hint of links to pages that have tuition information.

Programs costs & more leads to a page about McGill being one of the Top 25 universities. Users probably expected to see a table of tuition costs and other estimated costs, but instead are greeted with a dead end page with no links to tuition costs, and no suggestion in the IA.

In another example, consider an email from GoDaddy.com to a person who wants to buy a web domain. The call to action is a large green button named Click to Enter Min/Max. It strongly suggests that clicking it will lead to a form to enter a bid for the domain. However, clicking it opens a login page (which, although customary, it still does break the users’ train of thought and increases the chance of them leaving the site) and then leads to a page that includes a table with two domains, including one that the user owns. This page is not the place to enter the minimum or maximum bid for the domain. Rather, the person has to scan this page, see the Domain Buy title (which is not easy to see because it is positioned such that it seems like part of the promotional banner at the top of the page), read the Waiting for Customer Min/Max Offer message that appears with the second domain, and click the link that is the second domain name. Only then does the site open the Set up domain service for xxx.com lightbox where the user may enter the minimum and maximum bid.

The button text suggests it will link to a form with fields to enter the minimum and maximum bids, but it instead loads: a login page, the need to sign in, a table listing multiple domains, the need to locate a message and link to the domain, then finally a form to enter the minimum and maximum bids.

Expected Page with Evident Confirmations

Some link names clearly describe where they lead, and the page that follows makes it obvious to the users that they are where they expected. For example, a story title in the carousel on the US Food and Drug Administration’s website reads Three Encouraging Steps Toward New Antibiotics. When that story is clicked, there is no surprise. The page loads with the right article about antibiotics. The title appears at the top of the page and the article immediately follows.

The link text is the same as the title on the page it links to, which is a strong confirmation for the user.

In another example, on ISoldMyHouse.com, the user is viewing the property listing for the house she plans to sell and wants to schedule an open house. After clicking the blue Schedule Open Houses button, a form with several items appears that confirm to the user that she is on the right track, including:

a bold, orange title that includes the key words Open Houses for…

the same title also confirms the specific number associated with the listing. (Note: For people listing multiple properties, it would help to display the property address here too so they don’t need to recall the number associated with each property.)

the form with fields such as date and time for the open house plus a button to submit the form labeled Add Open House, which also confirms the specific action associated with this 

Summary

Whether it’s a date not kept, a ball never tossed, or a product page not loading when requested on a website, bailing out on your promises is impolite, bad practice and will hurt your organization in the long run. So think twice before you make a promise that you don’t plan to keep. Instead follow this simple, two-step plan:

write descriptive, true link text, and

immediately display what the user expects to see — right on the link’s destination page.

So, Your Site is Ready for a Redesign

Where should you start? There are many UX activities that can help your project start off on the right foot. One of them is competitive usability testing. That is, usability studies of the existing design along with several competitor websites. Resist the urge to jump on your computer and start designing right away.

Even if a redesign (or refresh) is required, don’t be so quick to throw away the existing design. You can learn from it. Use it as a starting point for your new project by gathering user feedback and feeding it into your new design. Before you begin, know how aggressive a change you need. For Agile teams, competitive testing is a worthwhile activity to perform during sprint zero.

Your old site is the best prototype of your new site: it’s already fully implemented and it solves exactly the design problem you’re targeting: a website for your business.  For sure, the old site doesn’t solve the design problem perfectly, but it’s not enough to say that it’s bad. You need to know in which specific ways it’s bad. And you also need to find out what aspects of the old design are loved by users. The short history of the Internet is rife with examples of major web properties that redesigned only to be met by a storm of user requests for great features that had been inadvertently removed.

Competitive usability studies provide a way for you to assess different design patterns and user flows, and determine which concepts might work and not work for your audience. They allow you to test ideas without having to build the designs yourself and to discover new interactions for your site and avoid mistakes made by others. Usability studies lay the groundwork for the redesign process and keep you and your team focused on the right issues. You feel more confident about your decisions because you’ve witnessed people interacting with websites in similar situations.

We’ve all wondered about our competition — How well are they presenting information? How are they better than us? It is good to browse websites for inspiration. However, don’t stop there. Test them. If you find concepts and ideas you like, don’t rush to copy them. The design might look good but might not be usable. Minimize risk by testing designs and know for certain whether or not they work before it’s too late. Resist the temptation to emulate without proper knowledge. This is why we often find bad design replicated across many different websites.

Learn From Competitive Usability Tests

Teams waste much time debating over design solutions and making decisions based on personal preference or bias. Rather than continue the debate, competitive testing allows teams to get feedback from target users early, so they can make informed decisions. It’s much easier to argue over opinions than user data.

Competitors’ sites are the second-best prototypes of your new site: they solve almost the same design problem as you have, and they are fully implemented instances of designs that these other companies have invested major resources in polishing.

Competitive tests can help you with the following:

Evaluate future features. Before you offer or build a new feature, learn whether customers consider it valuable or how it could be designed better. Seeing how customers react to features on the competitor’s site can help you determine whether they’re worth the effort.

Examine similar features. Your site may offer features similar to those on competitor sites, but one process might work better than the other. By examining varying designs of similar features, you can quickly identify the elements that work and make your design better while avoiding mistakes made on other websites.

Discover better ways to doing things. Your site might test well, but testing other sites might reveal features and interactions that you haven’t thought of. Having people react to different designs gives them an opportunity to compare and contrast. Participants are often better at articulating their thoughts and retrieving memories when they have several examples to which they can refer.

Conducting Competitive Usability Tests

Competitive studies don’t need to take long; usually 2 days are sufficient. Spend a few days studying your website along with 1-2 competitive websites and the study will yield fruitful findings that answer complex UX questions and provide inspiration for new ideas. 2 days is quick—a small price to pay in the context of a project timeline.

We run most competitive usability tests based on the thinking-aloud methodology. In this type of study, each participant performs the same tasks on every website (e.g., Site A, Site B, and Site C) while thinking out loud. We observe how people interact with each website and note verbal feedback. At the end of each session, we may ask users which version they prefer and why. The key is to understand the rationale behind people’s behavior.

To combat order effects, alternate the sequence of the websites that participants evaluate. For each participant, keep the number of websites they evaluate at 3 or less. When evaluating too many sites, tasks become monotonous and difficult to track for participants.

Select sites with interesting features. The sites you select do not need to be direct competitors. It’s best to aim for diversity by comparing sites that have features and designs distinctly different than yours. Don’t waste your time testing sites that you know are bad. The study will generate more valuable ideas when you include sites that might outperform your site. It’s OK to lose now you will win later.

Conclusion

Before you redesign your site, make sure that you understand the strengths and weaknesses of your current design. Garner design ideas and alternatives by studying your competitors. The focus of competitive tests is not to crown a winner, but to gain deeper insight into why design elements work or fail so we can make informed decisions moving forward.

  User Behavior Trends

Patterns can tell us a lot about data, they are intuitive and show us a lot of information at a glance. With that in mind, we produced the charts below to show how people behave around Christmas and New Year’s Eve. We wanted to understand the differences between cultures, so we focused on the trends from three large economies: US, UK and France. All the charts show data from December 11 to January 14 for the last three years and the two vertical grey areas represent Christmas Day and New Year’s Eve.

United States: the transactions trend clearly shows that users purchase mostly up to a week before Christmas Day and no improvement is seen in early January, although sessions do return to normal quickly after New Year’s Eve. Publishers should take advantage of this rebound in sessions, while retailers may want to wait on providing deals until sales bounce back fully.

United Kingdom: transactions decline sharply until Christmas and then start rising sharply from December 26, and about a week after New Year’s Eve it raises to levels about the same or higher than pre-holiday, so you might consider creating marketing campaigns and promotions to take advantage of January’s rise. Sessions follow a similar pattern.

France: transactions and sessions follow a similar pattern as in the UK, but with a significant decline during New Year’s Eve. As you can see, there is a major spike in the second Wednesday of January every year, that’s the day Winter sales begin in France! Unlike in the US, January is an important month for French retailers, should we say the French Cyber Wednesday?

Get a head start on 2015

So how can you take advantage of those trends to be more successful during the coming year? Here are some ideas for you to act upon right now:

Look at your own data for previous years to understand the patterns for your existing and previous customers.

Check your reports to learn more about how other websites of your size and in your vertical performed.

Use Google Trends to check trends from previous years related to your vertical and country.

Make sure you match your marketing efforts to your local post-holiday trend.

Sometimes we use the terms visitors instead of users and visits instead of sessions – they’re analogous. The onset of mobile devices (and other devices, like set top boxes) have prompted us to introduce new terms into our vocabulary.

It’s important to understand each piece of the hierarchy and how it builds on the other to create a view of our customers and potential customers. Because, at the end of the day, we need to use this data to evaluate our decisions and look for new business opportunities.

Let’s start at the bottom, with hits, and work our way up to users.

Hits

A hit is the most granular piece of data in an analytics tool. It’s how most analytics tools send data to a collection server. In reality, a hit is a request for a small image file. This image request is how the data is transmitted from a website or app to the data collection server.

All data is sent using a hit. Most hits are actually the request for an invisible image file.

There are many different kinds of hits depending on your analytics tool. Here are some of the most common hits in Google Analytics:

Pageviews/Screenviews: A pageview (for web, or screenview for mobile) is usually automatically generated and measures a user viewing a piece of content. A pageview is one of the fundamental metrics in digital analytics. It is used to calculate many other metrics, like Pageviews per Visit and Avg. Time on Page.

Events: An event is like a counter. It’s used to measure how often a user takes action on a piece of content. Unlike a pageview which is automatically generated, an event must be manually implemented. You usually trigger an event when the user takes some kind of action. The action may be clicking on a button, clicking on a link, swiping a screen, etc. The key is that the user is interacting with content that is on a page or a screen.

Transactions: A transaction is sent when a user completes an ecommerce transaction. You must manually implement ecommerce tracking to collect transactions. You can send all sorts of data related to the transaction including product information (ID, color, sku, etc.) and transactional information (shipping, tax, payment type, etc.)

Social interaction hit: A social interaction is whenever a user clicks on a ReTweet button, +1 button, or Like button. If you want to know if people are clicking on social buttons then use this feature! Social interaction tracking must be manually implemented.

Customized user timings:User timings provide a simple way to measure the actual time between two activities. For example, you can measure the time between when a page loads and when the user clicks a button. Custom timings must be implemented with additional code.

That’s a lot of hit types!

All hit types are sent to Google Analytics via a tracking code. The tracking code variation depends on what you are tracking. If you are tracing a website then JavaScript code, named analytics.js, generates the hits. If you are tracking a mobile app then an SDK (either Android oriOS) generates the hits. If you are tracking a kiosk, then YOU generate the hits with themeasurement protocol.

Regardless of the hit type, the hits are all formatted in a similar manner. They are a request for an invisible image and contain data in query string parameters.

http://www.google-analytics.com/collect?v=1&_v=j16&a=164718749&t=pageview&_s=1&dl=http%3A%2F%2Fcutroni.com%2F&ul=en-us&de=UTF-8&dt=Analytics%20Talk%20-%20Digital%20Analytics%20for%20Business&sd=24-bit&sr=1920x1080&vp=1308x417&je=1&fl=12.0%20r0& _utma=32856364.1751219558.1391525474.1391525475.1391525475.1& _utmz=32856364.1391525475.1.1.utmcsr%3D(direct) %7Cutmccn%3D(direct)%7Cutmcmd%3D(none)&_utmht=1391525534970& _u=cACC~&cid=1751219558.1391525474&tid=UA-91817-11&z=378275262

For all the nerds out there, the data hits can be sent via a GET request or a POST request. This is really important to know, because the amount of data can change. With a GET request you can only send 2048 characters of data. Technically a post can be any length (it’s a setting on most servers), but it’s around 8000 characters when sending data to Google Analytics.

The information in a hit is transformed into dimensions during processing. Every report is just a single dimension, and the corresponding metrics for each value. that you see in your reports.

Each report in Google Analytics shows all of the values for a single dimension, and the corresponding metrics for each value.

A quick note on mobile…

The mobile SDKs do not send data in real time. They actually store the hits locally and them send them in bursts. This is called dispatching and it’s used for a couple of reasons. First, mobile devices are not always connected to a network. So analytics must store the hits until it detects a connection and then it sends the hits. Second, sending hits in a bunches can help conserve battery life. Don’t worry, dispatching does not impact session calculations – which we’ll talk about right now :)

Session

A session is simply a collection of hits, from the same user, grouped together. By default, most analytics tools, including Google Analytics, will group hits together based on activity. When the analytics tool detects that the user is no longer active it will terminate the session and start a new one when the user becomes active.

Most analytics tools use 30 minutes of inactivity to separate sessions. This 30-minute period is called the timeout.

A session is a collection of hits. It ends when there has been 30 minutes of inactivity.

Google Analytics, and most tools, use the time between the first hit and the last hit to calculate the time on site. The time between hits is also used to calculate other metrics, like time on page. You can read more in my overview of how Google Analytics performs time calculations.

Most tools let you change the default timeout to better suit your needs. For example, if you have a lot of video on your site you might want to change the timeout – especially if your video last more than 30 minutes.

Why?

If a user is watching a 60 minute video (and by watching I mean that no other hits are sent to analytics) their session will end 30 minutes after the first hit. To insure that the session lasts until the end of the video you could change the timeout to match the longest video length.

OR, a better way to extend the session, would be to send additional hits while the user is watching the video. Think about it – more hits create more data points that can be used to calculate time. Trust me, take 12 minutes to read more about how Google Analytics performs time calculations.

Now that we know that hits are grouped together into sessions, let’s look at how sessions are grouped based on users.

Users

Here’s where things start to get interesting. A user is the tools best-guess of an anonymous person. Users are identified using an anonymous number or a string of characters. The analytics tool normally creates the identifier the first time a user is detected. Then that identifier persists until it expires or is deleted.

The identifier is sent to the analytics tool with every hit of data. Then the analytics tools can group hits (and thus sessions) together using the identifier in the hits.

Make sense?

Sessions from the same user can be grouped together as long as each hit has the same user ID.

Here’s how users are detected on some of today’s most common digital platforms.

Website Users

To measure a user on a website almost all analytics tools use a cookie. A cookie is a small text file. The cookie contains the anonymous identifier. Every time a hit is sent from the browser back to the analytics server identifier stored in the cookie is sent along with the data.

When measuring a website, the analytics tool usually uses a first party cookie to store an anonymous ID.

Now let’s have the cookie talk.

Google Analytics uses a first party cookie. A first party cookie is connected to the domain that creates it. A first-party can only be used by the domain that sets it. So on this site, the cookie has a domain of cutroni.com and can only be used by this website.

In Universal Analytics the cookie is named _ga and lasts for two years. In the previous version of Google Analytics the cookie was named __utma.

The good thing about a first party cookie is that almost all browsers will allow a first party cookie. It’s a very reliable piece of technology.

First party cookies are challenging when your site spans multiple domains. When a user leaves your site, and traverses to another site that you own, they do not take their first party cookies. In most situations, unless you configure analytics correctly, analytics will set another cookie when the user lands on the second domain.

Analytics uses a first party cookie to maintain a user identifier.

Now you have one user with two cookies. That could lead to double counting of users. Plus, if we want to create really cool metrics, like Revenue per user, it becomes very, very hard because we don’t know the true number of users.

The other type of cookie, a third-party cookie, can be set and accessed by domains other than the domain that creates it. Some analytics tools will let you use a third party cookie.

The value of a third party cookie is that the analytics tool can use a third party cookie to identify a user as they move from one domain to another.

A third party cookie can be used by multiple domains.

However, third-party cookies are not permitted by most browsers – that means no data.

Google Analytics does not use a third party cookie. You can read all about the Google Analytics cookies in the developer documentation.

So what’s the solution here? How do you correctly identify a user if your website spans multiple domains? In the Google Analytics world we use a feature called Cross Domain Tracking. I’m not going to talk about it in this post, but you can read about it in our support documentation.

Mobile Users

Now let’s move on to mobile platforms – something that is very popular :)

Mobile tracking is similar to web tracking. There is an anonymous identifier stored on the device. The identifier is generated every time the app is installed. So if a user deletes the app the identifier will also be deleted. But if a user updates the app the identifier will not change.

The big difference between mobile and web is that the identifier is not stored in a cookie. It’s stored in a database on the mobile device – but it basically functions the same way as a cookie. The identifier is sent on every hit back to the analytics server. The analytics server then uses the identifier to create metrics like unique users.

Here’s one challenge with user measurement on an app. Many apps are not just an app. They’re a hybrid app/website. They use a browser within the app to “frame” content from a website. This can mess up the data collection.

In this situation we have two technologies with two different user identifiers. The app will measure a user based on the ID stored on the device and the website will use a cookie when a page loads in the app.

Mobile apps that “frame in” content from a website, might be sending duplicate hits to the analytics tool.

There are some ways around this, but it’s a long solution that need it’s own blog post. But just be aware of this potential data issue.

Ok, so now we know about website users and mobile users. But what about other digital touch-points, like a kiosk?

Other Digital Touch-points

In today’s world a user can interact with your digital content on lots of different devices (computers, mobile, kiosks, set top boxes, etc.). And that can cause a lot of issues as tools try to de-duplicate users and get an accurate count of users.

One of the key features of Universal Analytics is the ability to track users on devices other than websites and mobile devices, things like a point-of-sale system or a kiosk. It does this using a technology called the measurement protocol.

But how does it actually work?

The measurement protocol works by – wait for it – collecting hits :) These are the same hits that I described above. The big difference is that you must manually build the hits. So if you want to implement analytics on a kiosk, you must create MORE code to build the hits that are sent to Google Analytics.

But what about measuring users when you use the measurement protocol?

When you create the hit you must insert a user identifier into the hit. Google Analytics will then use this identifier as the unique identifier when it processes the data.

To measure users when tracking other devices, like a kiosk, you must insert your own identifier and generate your own data hits.

Unlike websites and mobile apps, there is no cookie or database to store the identifier. So the ID does not persist from one hit to another, or from one session to another. You must manually insert the identifier into every hit in every session.

Your code must control the generation of the identifier and the storage of the identifier.

Let’s end it there. That’s a pretty good overview of digital analytics data.