Recherche avancée

Sur d’autres sites (5414)

• How to use Behavioural Analytics to Improve Website Performance

  20 septembre 2021, par Ben Erskine — Analytics Tips, Plugins, Heatmap
  

  User behavioural analytics (UBA) give your business unique insights into your customers. 

  Where traditional website metrics track what actions are completed or how many visitors you have, user behaviour shows the driving factors behind those actions. UBA tools such as website heatmap software provide an easy-to-read visualisation of this data. 

  Ultimately, user behaviour analysis improves website performance and conversions by boosting customer engagement, optimising positive customer experiences, and focusing on the most important part of your sales : the people who are actually buying from you. 

  What is user behaviour analytics ?

  User behaviour analytics (UBA) is data that shows how customers and website visitors interact with your brand online. 

  UBA is tracked using tools such as heatmaps, session recordings and data visualisation software. 

  Where traditional web analytics track metrics such as page views and bounce rates, behavioural analytics provide an even more in-depth picture of your website or funnel success. 

  For example, UBA tracks actions like 

  • How far users are scrolling down the page 
  • Which CTA’s and copy they are focusing on (or not focusing on) 
  • Which design elements, links or buttons they are interacting with 
  • What is happening in between each action

  Tracking user behaviour metrics help keep visitors on your website longer because they analyse where customers may be confused or unclear so you can fix it. 

  What’s the difference between data and behavioural analytics ?

  There are a few key differences between data and behavioural analytics. While data analytics are beneficial to improving website performance, using UBA creates a more customer-centric approach to funnel building. 

  The biggest difference between data and behavioural analytics ? Metric data shows which actions are happening. Behavioural analytics show you WHY they are happening. 

  For example, data can show you that a customer bounced or clicked away. Behaviour analytics show you that a page took a long time to load, they tried to click a link several times and then maybe got frustrated and clicked away. 

  Key differences between data analytics and behavioural analytics : 

  • What is happening versus what is driving it 
  • Track an action (e.g. click-through) versus tracking inaction (e.g. hover without clicking) 
  • Measuring completion of an action versus the flow of actions to complete action 
  • Source of traffic versus individual actions 
  • What happens when someone takes an action versus what happens in between taking action 

  Matomo heatmaps offer both website analytics and user behaviour for a comprehensive analysis.

  Why do behavioural analytics help improve website performance ?

  User behaviour is important because it doesn’t matter how many website visitors you have if they don’t convert. 

  If you have a lot of traffic on mobile devices, but a low CTR, heatmaps show you what is causing the low conversions. Perhaps there is a button that isn’t optimised for mobile scrolling, or a pop up that covers important copy. 

  Analysing the driving factors behind each decision means that you can increase sign-ups and conversions without losing money on website traffic that never actually buys. 

  

  How do heatmap tools show website user behaviour analytics ? 

  Heatmap tools provide a visual representation of user behaviour. 

  There are several key ways that heatmap tracking can improve website performance and therefore your overall conversions.

  Firstly, heatmaps show where to optimise website structure. It uses real visitor experiences to indicate whether customers have to scroll to reach important content, whether important messages are being missed, and whether CTAs are clear. 

  Secondly, heatmaps provide always-on UX and useability testing for your website, identifying user frustrations and optimising their experience over time.

  They also show valuable user experience insights for A/B versions of a landing page. Not only will you see the raw conversion data, but you will also understand why one page converts more than another.

  Ultimately, heatmaps increase ROI on marketing by optimising the traffic that you are sending to your website.

  

  5 ways heatmaps and user behaviour analytics improve website performance and conversions

  #1. Improve customer experience

  One of the most important uses for UBA is to improve your customer experience. 

  Imagine you had a physical store. If there was something blocking customers from getting to the counter you could easily see and fix the problem. 

  It is just as important for an online store to find and fix these “roadblocks”. 

  Not only does it reduce friction in the sales funnel and make it easy for customers to buy from you, it improves their overall experience. And when 86% of buyers are willing to pay more for a great customer experience, UBA should be one of your number one priorities for growing your bottom line. 

  #2. Improve customer engagement

  Customer engagement is any interaction between a customer/product user and your business. 

  User behaviour analytics increase engagement at each customer journey touch point. 

  Using data from heatmaps will improve customer engagement because it gives you insights into how you can make your website more user friendly. This reduces friction and increases customer loyalty by making sure customers :

  • See important content 
  • Are not distracted by unnecessary elements 
  • Can easily access information or pages no matter what device they are using 
  • Are clicking on important page elements that take them further through the customer journey 

  For example, say a customer is on a sales page. A heatmap might show that pop ups or design elements like links to another page are pulling their attention away from the primary focus (i.e. the sales copy). 

  #3. Focus on customer-centric approach 

  A customer-centric approach means putting your customers at the centre of everything that you do. There is a lot of competition for your customers’ hard earned dollars, so you need to stand out. A good product or service is not enough on its own anymore. 

  User behaviour analytics are at the heart of customer-centric strategies. Instead of guessing how customers interact with your online presence, tools like heatmaps give insight into exactly what customers need. 

  This matched with an effective customer feedback strategy gives a holistic and effective approach to improving your customer experiences. 
  

  #4. Capture customer data across multiple channels

  Most customers won’t convert on their very first visit to a website. They might interact with your business across many channels and research your product multiple times before purchasing. 

  Multi Channel Conversion Attribution, also known as Cross Channel Attribution, lets you assign a value to each visit prior to a conversion or prior to a sale. By applying different attribution models, you get a better view on which channels actually lead to a conversion.

  User behaviour analytics like the multi channel conversion attribution that Matomo offers can show you exactly where you should focus your money to acquire new customers. 

  #5. Track and measure business objectives

  User behaviour analytics like heatmaps can show you whether you are actually hitting your targets. 

  Setting goals helps track your website performance against business objectives. 

  These include objectives such as lead generation, online sales and increased brand exposure. Matomo has a specific function for tracking goals and measuring analytics.

  Using a combination of UBA and data metrics will produce the most effective conversions. 

  For example, a customer reaching the payment confirmation page is a common objective to measure conversions. However, it is only tracked if they actually complete the action. Measuring on-page customer activity with heatmaps shows why they do or do not convert so you can fix issues. 

  Final thoughts on user behaviour analytics 

  User behavioural analytics (UBA) provide a unique and in-depth insight into your customers and their needs. Unlike traditional data metrics that track completed actions, UBA like heatmaps show you what happens in between each action and help fix any critical issues. 

  Heatmaps are your secret weapon to improving website performance while staying customer-centric ! 

  Want to know how heatmap analytics increase conversions and improve customer experience without spending more on traffic or marketing ? Check out some of the other in depth guides below. 

  The Ultimate Guide to Heatmap Software

  10 Proven Ways Heatmap Software Improves Website Conversions

  Heatmap Video

  Session Recording Video

• How to write UI tests for your plugin – Introducing the Piwik Platform

  18 février 2015, par Thomas Steur — Development

  This is the next post of our blog series where we introduce the capabilities of the Piwik platform (our previous post was How to write unit tests for your plugin). This time you’ll learn how to write UI tests in Piwik. For this tutorial you will need to have basic knowledge of JavaScript and the Piwik platform.

  What is a UI test ?

  Some might know a UI test under the term ‘CSS test’ or ‘screenshot test’. When we speak of UI tests we mean automated tests that capture a screenshot of a URL and then compare the result with an expected image. If the images are not exactly the same the test will fail. For more information read our blog post about UI Testing.

  What is a UI test good for ?

  We use them to test our PHP Controllers, Twig templates, CSS, and indirectly test our JavaScript. We do usually not write Unit or Integration tests for our controllers. For example we use UI tests to ensure that the installation, the login and the update process works as expected. We also have tests for most pages, reports, settings, etc. This increases the quality of our product and saves us a lot of time as it is easy to write and maintain such tests. All UI tests are executed on Travis after each commit and compared with our expected screenshots.

  Getting started

  In this post, we assume that you have already installed Piwik 2.11.0 or later via git, set up your development environment and created a plugin. If not, visit the Piwik Developer Zone where you’ll find the tutorial Setting up Piwik and other Guides that help you to develop a plugin.

  Next you need to install the needed packages to execute UI tests.

  Let’s create a UI test

  We start by using the Piwik Console to create a new UI test :

  ./console generate:test --testtype ui

  The command will ask you to enter the name of the plugin the created test should belong to. I will use the plugin name “Widgetize”. Next it will ask you for the name of the test. Here you usually enter the name of the page or report you want to test. I will use the name “WidgetizePage” in this example. There should now be a file plugins/Widgetize/tests/UI/WidgetizePage_spec.js which contains already an example to get you started easily :

  describe("WidgetizePage", function () {
  
      var generalParams = 'idSite=1&period=day&date=2010-01-03';
  
  
  
      it('should load a simple page by its module and action', function (done) {
  
          var screenshotName = 'simplePage';
  
          // will save image in "processed-ui-screenshots/WidgetizePageTest_simplePage.png"
  
  
  
          expect.screenshot(screenshotName).to.be.capture(function (page) {
  
              var urlToTest = "?" + generalParams + "&module=Widgetize&action=index";
  
              page.load(urlToTest);
  
          }, done);
  
      });
  
  });

  What is happening here ?

  This example declares a new set of specs by calling the method describe(name, callback) and within that a new spec by calling the method it(description, func). Within the spec we load a URL and once loaded capture a screenshot of the whole page. The captured screenshot will be saved under the defined screenshotName. You might have noticed we write our UI tests in BDD style.

  Capturing only a part of the page

  It is good practice to not always capture the full page. For example many pages contain a menu and if you change that menu, all your screenshot tests would fail. To avoid this you would instead have a separate test for your menu. To capture only a part of the page simply specify a jQuery selector and call the method captureSelector instead of capture :

  var contentSelector = '#selector1, .selector2 .selector3';
  
  // Only the content of both selectors will be in visible in the captured screenshot
  
  expect.screenshot('page_partial').to.be.captureSelector(contentSelector, function (page) {
  
      page.load(urlToTest);
  
  }, done);

  Hiding content

  There is a known issue with sparklines that can fail tests randomly. Also version numbers or a date that changes from time to time can fail tests without actually having an error. To avoid this you can prevent elements from being visible in the captured screenshot via CSS as we add a CSS class called uiTest to the HTML element while tests are running.

  .uiTest .version { visibility:hidden }

  Running a test

  To run the previously generated tests we will use the command tests:run-ui :

  ./console tests:run-ui WidgetizePage

  After running the tests for the first time you will notice a new folder plugins/PLUGINNAME/tests/UI/processed-ui-screenshots in your plugin. If everything worked, there will be an image for every captured screenshot. If you’re happy with the result it is time to copy the file over to the expected-ui-screenshots folder, otherwise you have to adjust your test until you get the result you want. From now on, the newly captured screenshots will be compared with the expected images whenever you execute the tests.

  Fixing a test

  At some point your UI test will fail, for example due to expected CSS changes. To fix a test all you have to do is to copy the captured screenshot from the folder processed-ui-screenshots to the folder expected-ui-screenshots.

  Executing the UI tests on Travis

  In case you have not generated a .travis.yml file for your plugin yet you can do this by executing the following command :

  ./console generate:travis-yml --plugin PLUGINNAME

  Next you have to activate Travis for your repository.

  Advanced features

  Isn’t it easy to create a UI test ? We never even created a file ! Of course you can accomplish even more if you want. For example you can specify a fixture to be inserted before running the tests which is useful when your plugin requires custom data. You can also control the browser as it was a human by clicking, moving the mouse, typing text, etc. If you want to discover more features have a look at our existing test cases.

  If you have any feedback regarding our APIs or our guides in the Developer Zone feel free to send it to us.

• How to write UI tests for your plugin – Introducing the Piwik Platform

  18 février 2015, par Thomas Steur — Development

  This is the next post of our blog series where we introduce the capabilities of the Piwik platform (our previous post was How to write unit tests for your plugin). This time you’ll learn how to write UI tests in Piwik. For this tutorial you will need to have basic knowledge of JavaScript and the Piwik platform.

  What is a UI test ?

  Some might know a UI test under the term ‘CSS test’ or ‘screenshot test’. When we speak of UI tests we mean automated tests that capture a screenshot of a URL and then compare the result with an expected image. If the images are not exactly the same the test will fail. For more information read our blog post about UI Testing.

  What is a UI test good for ?

  We use them to test our PHP Controllers, Twig templates, CSS, and indirectly test our JavaScript. We do usually not write Unit or Integration tests for our controllers. For example we use UI tests to ensure that the installation, the login and the update process works as expected. We also have tests for most pages, reports, settings, etc. This increases the quality of our product and saves us a lot of time as it is easy to write and maintain such tests. All UI tests are executed on Travis after each commit and compared with our expected screenshots.

  Getting started

  In this post, we assume that you have already installed Piwik 2.11.0 or later via git, set up your development environment and created a plugin. If not, visit the Piwik Developer Zone where you’ll find the tutorial Setting up Piwik and other Guides that help you to develop a plugin.

  Next you need to install the needed packages to execute UI tests.

  Let’s create a UI test

  We start by using the Piwik Console to create a new UI test :

  ./console generate:test --testtype ui

  The command will ask you to enter the name of the plugin the created test should belong to. I will use the plugin name “Widgetize”. Next it will ask you for the name of the test. Here you usually enter the name of the page or report you want to test. I will use the name “WidgetizePage” in this example. There should now be a file plugins/Widgetize/tests/UI/WidgetizePage_spec.js which contains already an example to get you started easily :

  describe("WidgetizePage", function () {
  
      var generalParams = 'idSite=1&period=day&date=2010-01-03';
  
  
  
      it('should load a simple page by its module and action', function (done) {
  
          var screenshotName = 'simplePage';
  
          // will save image in "processed-ui-screenshots/WidgetizePageTest_simplePage.png"
  
  
  
          expect.screenshot(screenshotName).to.be.capture(function (page) {
  
              var urlToTest = "?" + generalParams + "&module=Widgetize&action=index";
  
              page.load(urlToTest);
  
          }, done);
  
      });
  
  });

  What is happening here ?

  This example declares a new set of specs by calling the method describe(name, callback) and within that a new spec by calling the method it(description, func). Within the spec we load a URL and once loaded capture a screenshot of the whole page. The captured screenshot will be saved under the defined screenshotName. You might have noticed we write our UI tests in BDD style.

  Capturing only a part of the page

  It is good practice to not always capture the full page. For example many pages contain a menu and if you change that menu, all your screenshot tests would fail. To avoid this you would instead have a separate test for your menu. To capture only a part of the page simply specify a jQuery selector and call the method captureSelector instead of capture :

  var contentSelector = '#selector1, .selector2 .selector3';
  
  // Only the content of both selectors will be in visible in the captured screenshot
  
  expect.screenshot('page_partial').to.be.captureSelector(contentSelector, function (page) {
  
      page.load(urlToTest);
  
  }, done);

  Hiding content

  There is a known issue with sparklines that can fail tests randomly. Also version numbers or a date that changes from time to time can fail tests without actually having an error. To avoid this you can prevent elements from being visible in the captured screenshot via CSS as we add a CSS class called uiTest to the HTML element while tests are running.

  .uiTest .version { visibility:hidden }

  Running a test

  To run the previously generated tests we will use the command tests:run-ui :

  ./console tests:run-ui WidgetizePage

  After running the tests for the first time you will notice a new folder plugins/PLUGINNAME/tests/UI/processed-ui-screenshots in your plugin. If everything worked, there will be an image for every captured screenshot. If you’re happy with the result it is time to copy the file over to the expected-ui-screenshots folder, otherwise you have to adjust your test until you get the result you want. From now on, the newly captured screenshots will be compared with the expected images whenever you execute the tests.

  Fixing a test

  At some point your UI test will fail, for example due to expected CSS changes. To fix a test all you have to do is to copy the captured screenshot from the folder processed-ui-screenshots to the folder expected-ui-screenshots.

  Executing the UI tests on Travis

  In case you have not generated a .travis.yml file for your plugin yet you can do this by executing the following command :

  ./console generate:travis-yml --plugin PLUGINNAME

  Next you have to activate Travis for your repository.

  Advanced features

  Isn’t it easy to create a UI test ? We never even created a file ! Of course you can accomplish even more if you want. For example you can specify a fixture to be inserted before running the tests which is useful when your plugin requires custom data. You can also control the browser as it was a human by clicking, moving the mouse, typing text, etc. If you want to discover more features have a look at our existing test cases.

  If you have any feedback regarding our APIs or our guides in the Developer Zone feel free to send it to us.