Recherche avancée

Sur d’autres sites (3320)

• On-premise analytics demand grows as Google Analytics GDPR uncertainties continue

  7 janvier 2020, par Jake Thornton — Privacy

  The Google Analytics GDPR relationship is a complicated one. Website owners in states like Berlin in Germany are now required to ask users for consent to collect their data. This doesn’t make for the friendliest user-experience and often the website visitor will simply click “no.”

  The problem Google Analytics now presents website owners in the EU is with more visitors clicking “no”, the less accurate your data will become.

  Why do you need to ask your visitors for consent ?

  At this stage it’s simply because Google Analytics collects data for its own purposes. An example of this is using your visitor’s personal data for retargeting purposes across their advertising platforms like Google Ads and YouTube. 

  Google’s Privacy & Terms states : “when you visit a website that uses advertising services like AdSense, including analytics tools like Google Analytics, or embeds video content from YouTube, your web browser automatically sends certain information to Google. This includes the URL of the page you’re visiting and your IP address. We may also set cookies on your browser or read cookies that are already there. Apps that use Google advertising services also share information with Google, such as the name of the app and a unique identifier for advertising.”

  

  The rise of hosting web analytics on-premise

  Managing Google Analytics and GDPR can quickly become complicated, so there’s been an increase in website owners switching from cloud-hosted web analytics platforms, like Google Analytics, to more GDPR compliant alternatives, where you can host web analytics software on your own servers. This is called hosting web analytics on-premise.

  Hosting web analytics on your own servers means :

  No third-parties are involved

  The visitor data your website collects is stored on your own internal infrastructure. This means no third-parties are involved and there’s no risk of personal data being used in the way Google Analytics uses it e.g. sending personal data to its advertising platforms. 

  When you sign up with Google Analytics you sign away control of your user’s personal data. With on-premise website analytics, you own your data and are in full control.

  NOTE : Though Google Analytics uses personal data for its own purposes, not all cloud hosted web analytics platforms do this. As an example, Matomo Analytics Cloud hosted solution states that all personal data collected is not used for its own purposes and that Matomo has no rights in accessing or using this personal data. 

  

  You control where in the world your personal data is stored

  Google Analytics servers are based out of USA, Europe and Asia, so where your personal data will end up is uncertain and you don’t have the option to choose which location it goes to when using free Google Analytics.

  Different countries have different laws when it comes to accessing personal data. When you choose to host your web analytics on-premise, you can choose the location of your servers and where the personal data is stored.

  More flexibility

  With self-hosted web analytics platforms like Matomo On-Premise, you can extend the platform to do anything you want without the restrictions that cloud hosted platforms impose.

  You can :

  • Get full access to the source code of open-source solutions, like Matomo
  • Extend the platform however you want for your business
  • Get access to APIs
  • Have no data limitations or restrictions
  • Get RAW data access
  • Have control over security

  >> Read more about on-premise flexibility for web analytics here

  

  So what does the future look like for Google Analytics and GDPR ?

  It’s difficult to assess this right now. How exactly GDPR is enforced is still quite unclear. 

  What is clear however, is now website owners in Berlin using Google Analytics are lawfully required to ask their visitors for consent to collect personal data. It has been reported that Google Analytics has already received 200,000 complaints in Germany alone and it appears this trend is likely to continue across much of the EU.

  When using Google Analytics in the EU you must also ensure your privacy policy is updated so website visitors are aware that data is being collected through Google Analytics for its own purposes.

  Moving to a web analytics on-premise platform

  Matomo Analytics is the #1 open-source web analytics platform in the world and has been rated as an exceptional alternative to Google Analytics. Check the reviews on Capterra.

  Choosing Matomo On-Premise means you can control exactly where your data is stored, you have full flexibility to customise the platform to do what you want and it’s FREE.

  Matomo’s mission is to give control back to website owners and the team has designed the platform so that moving away from Google Analytics is seamless. Matomo offers most of your favourite Google Analytics features, a leaner interface to navigate, and the option to add free and paid premium features that Google Analytics can’t even offer you.

  And now you can import your historical Google Analytics data directly into your Matomo with the Google Analytics Importer plugin.

  DOWNLOAD MATOMO (FREE)

  And if you can’t host web analytics on your own servers ...

  Hosting web analytics on-premise is not an option for all businesses as you do need the internal infrastructure and technical knowledge to host your own platform.

  If you can’t self-host, then Matomo has a Cloud hosted solution you can easily install and operate like Google Analytics, which is hosted on Matomo’s servers in the EU. 

  The GDPR advantages of choosing Matomo Cloud over Google Analytics are :

  • Servers are secure and based in the EU (strict laws forbid outside access)
  • 100% data ownership – we never use data for our own purposes
  • You can export your data anytime and switch to Matomo On-Premise whenever you like
  • User-privacy protection
  • Advanced GDPR Manager and data anonymisation features which GA doesn’t offer

  

  Interested to learn more ?

  If you are wanting to learn more about why users are making the move from Google Analytics to Matomo, check out our Matomo Analytics vs Google Analytics comparison page.

  >> Matomo Analytics vs Google Analytics

• Marketing Cohort Analysis : How To Do It (With Examples)

  12 janvier 2024, par Erin

  The better you understand your customers, the more effective your marketing will become. 

  The good news is you don’t need to run expensive focus groups to learn much about how your customers behave. Instead, you can run a marketing cohort analysis using data from your website analytics.

  A marketing cohort groups your users by certain traits and allows you to drill down to discover why they take the actions on your website they do. 

  In this article, we’ll explain what a marketing cohort analysis is, show you what you can achieve with this analytical technique and provide a step-by-step guide to pulling it off. 

  What is cohort analysis in marketing ?

  A marketing cohort analysis is a form of behavioural analytics where you analyse the behavioural patterns of users who share a similar trait to better understand their actions. 

  These shared traits could be anything like the date they signed up for your product, users who bought your service through a paid ad or email subscribers from the United Kingdom.

  It’s a fantastic way to improve your marketing efforts, allowing you to better understand complex user behaviours, personalise campaigns accordingly and improve your ROI. 

  You can run marketing analysis using an analytics platform like Google Analytics or Matomo. With these platforms, you can measure how cohorts perform using traffic, engagement and conversion metrics.

  

  There are two types of cohort analysis : acquisition-based cohort analysis and behavioural-based cohort analysis.

  Acquisition-based cohort analysis

  An acquisition-based cohort divides users by the date they purchased your product or service and tracks their behaviour afterward. 

  For example, one cohort could be all the users who signed up for your product in November. Another could be the users who signed up for your product in October. 

  You could then run a cohort analysis to see how the behaviour of the two cohorts differed. 

  Did the November cohort show higher engagement rates, increased frequency of visits post-acquisition or quicker conversions compared to the October cohort ? Analysing these cohorts can help with refining marketing strategies, optimising user experiences and improving retention and conversion rates.

  As you can see from the example, acquisition-based cohorts are a great way to track the initial acquisition and how user behaviour evolves post-acquisition.

  Behavioural-based cohort analysis

  A behavioural-based cohort divides users by their actions on your site. That could be their bounce rate, the number of actions they took on your site, their average time on site and more.

  

  Behavioural cohort analysis gives you a much deeper understanding of user behaviour and how they interact with your website.

  What can you achieve with a marketing cohort analysis ?

  A marketing cohort analysis is a valuable tool that can help marketers and product teams achieve the following goals :

  

  Understand which customers churn and why

  Acquisition and behavioural cohort analyses help marketing teams understand when and why customers leave. This is one of the most common goals of a marketing cohort analysis. 

  Learn which customers are most valuable

  Want to find out which channels create the most valuable customers or what actions customers take that increase their loyalty ? You can use a cohort analysis to do just that. 

  For example, you may find out you retain users who signed up via direct traffic better than those that signed up from an ad campaign. 

  Discover how to improve your product

  You can even use cohort analysis to identify opportunities to improve your website and track the impact of your changes. For example, you could see how visitor behaviour changes after a website refresh or whether visitors who take a certain action make more purchases. 

  Find out how to improve your marketing campaign

  A marketing cohort analysis makes it easy to find out which campaigns generate the best and most profitable customers. For example, you can run a cohort analysis to determine which channel (PPC ads, organic search, social media, etc.) generates customers with the lowest churn rate. 

  If a certain ad campaign generates the low-churn customers, you can allocate a budget accordingly. Alternatively, if customers from another ad campaign churn quickly, you can look into why that may be the case and optimise your campaigns to improve them. 

  Measure the impact of changes

  You can use a behavioural cohort analysis to understand what impact changes to your website or product have on active users. 

  If you introduced a pricing page to your website, for instance, you could analyse the behaviour of visitors who interacted with that page compared to those who didn’t, using behavioural cohort analysis to gauge the impact of these website changes on engagemen or conversions.

  The problem with cohort analysis in Google Analytics

  Google Analytics is often the first platform marketers turn to when they want to run a cohort analysis. While it’s a free solution, it’s not the most accurate or easy to use and users often encounter various issues. 

  For starters, Google Analytics can’t process user visitor data if they reject cookies. This can lead to an inaccurate view of traffic and compromise the reliability of your insights.

  In addition, GA is also known for sampling data, meaning it provides a subset rather than the complete dataset. Without the complete view of your website’s performance, you might make the wrong decisions, leading to less effective campaigns, missed opportunities and difficulties in reaching marketing goals.

  How to analyse cohorts with Matomo

  Luckily, there is an alternative to Google Analytics. 

  As the leading open-source web analytics solution, Matomo offers a robust option for cohort analysis. With its 100% accurate data, thanks to the absence of sampling, and its privacy-friendly tracking, users can rely on the data without resorting to guesswork. It is a premium feature included with our Matomo Cloud or available to purchase on the Matomo Marketplace for Matomo On-Premise users.

  Below, we’ll show how you can run a marketing cohort analysis using Matomo.

  Set a goal

  Setting a goal is the first step in running a cohort analysis with any platform. Define what you want to achieve from your analysis and choose the metrics you want to measure. 

  For example, you may want to improve your customer retention rate over the first 90 days. 

  Define cohorts

  Next, create cohorts by defining segmentation criteria. As we’ve discussed above, this could be acquisition-based or behavioural. 

  Matomo makes it easy to define cohorts and create charts. 

  In the sidebar menu, click Visitors > Cohorts. You’ll immediately see Matomo’s standard cohort report (something like the one below).

  

  In the example above, we’ve created cohorts by bounce rate. 

  You can view cohorts by weekly, monthly or yearly periods using the date selector and change the metric using the dropdown. Other metrics you can analyse cohorts by include :

  • Unique visitors
  • Return visitors
  • Conversion rates
  • Revenue
  • Actions per visit

  Change the data selection to create your desired cohort, and Matomo will automatically generate the report. 

  Try Matomo for Free

  Get the web insights you need, without compromising data accuracy.

  Start for free

  No credit card required

  Analyse your cohort chart

  Cohort charts can be intimidating initially, but they are pretty easy to understand and packed with insights. 

  Here’s an example of an acquisition-based cohort chart from Matomo looking at the percentage of returning visitors :

  

  Cohorts run vertically. The oldest cohort (visitors between February 13 – 19) is at the top of the chart, with the newest cohort (April 17 – 23) at the bottom. 

  The period of time runs horizontally — daily in this case. The cells show the corresponding value for the metric we’re plotting (the percentage of returning visitors). 

  For example, 98.69% of visitors who landed on your site between February 13 – 19, returned two weeks later. 

  Usually, running one cohort analysis isn’t enough to identify a problem or find a solution. That’s why comparing several cohort analyses or digging deeper using segmentation is important.

  Segment your cohort chart

  Matomo lets you dig deeper by segmenting each cohort to examine their behaviour’s specifics. You can do this from the cohort report by clicking the segmented visitor log icon in the relevant row.

  

  

  Segmenting cohorts lets you understand why users behave the way they do. For example, suppose you find that users you purchased on Black Friday don’t return to your site often. In that case, you may want to rethink your offers for next year to target an audience with potentially better customer lifetime value. 

  Start using Matomo for marketing cohort analysis

  A marketing cohort analysis can teach you a lot about your customers and the health of your business. But you need the right tools to succeed. 

  Matomo provides an effective and privacy-first way to run your analysis. You can create custom customer segments based on almost anything, from demographics and geography to referral sources and user behaviour. 

  Our custom cohort analysis reports and colour-coded visualisations make it easy to analyse cohorts and spot patterns. Best of all, the data is 100% accurate. Unlike other web analytics solution or cohort analysis tools, we don’t sample data. 

  Find out how you can use Matomo to run marketing cohort analysis by trialling us free for 21 days. No credit card required.

  Try Matomo for Free

  21 day free trial. No credit card required.

  
  

  Your email address
  

  Your website address
  

  Your Analytics subdomain will be .matomo.cloud (change)

  Choose your analytics subdomain
  

  .matomo.cloud

  I accept the terms and conditions and data processing agreement (DPA)

  
  Your information will be used to create an account on our cloud service. For more information please consult our privacy policy.
  
  
  

  Start improving your websites now

  

• Long Overdue MediaWiki Upgrade

  5 février 2014, par Multimedia Mike — General

  What do I do ? What I do ? This library book is 42 years overdue !
  I admit that it’s mine, yet I can’t pay the fine,
  Should I turn it in or should I hide it again ?
  What do I do ? What do I do ?

  I internalized the forgoing paean to the perils of procrastination by Shel Silverstein in my formative years. It’s probably why I’ve never paid a single cent in late fees in my entire life.

  However, I have been woefully negligent as the steward of the MediaWiki software that drives the world famous MultimediaWiki, the internet’s central repository of obscure technical knowledge related to multimedia. It is currently running of version 1.6 software. The latest version is 1.22.

  The Story So Far
  According to my records, I first set up the wiki late in 2005. I don’t know which MediaWiki release I was using at the time. I probably conducted a few upgrades in the early days, but that went by the wayside perhaps in 2007. My web host stopped allowing shell access and the MediaWiki upgrade process pretty much requires running a PHP script from a command line. Upgrade time came around and I put off the project. Weeks turned into months turned into years until, according to some notes, the wiki abruptly stopped working in July, 2011. Suddenly, there were PHP errors about “Namespace” being a reserved word.

  While I finally laid out a plan to upgrade the wiki after all these years, I eventually found that the problem had been caused when my webhost upgraded from PHP 5.2 -> 5.3. I also learned of a small number of code changes that caused the problem to go away, thus kicking the can down the road once more.

  Then a new problem showed up last week. I think it might be related to a new version of PHP again. This time, a few other things on my site broke, and I learned that my webhost now allows me to select a PHP version to use (with the version then set to “auto”, which didn’t yield much information). Rolling back to an earlier version of PHP might have solved the problem easily.

  But NO ! I made the determination that this goes no further. I want this wiki upgraded.

  The Arduous Upgrade Path
  There are 2 general upgrade paths I can think of :
  

  1. Upgrade in place on the server
  2. Upgrade offline and put the site back on the server

  Approach #1 is problematic since I don’t have direct shell access, though I considered using something like PHP Shell. Approach #2 involves getting the entire set of wiki files and a backup of the MySQL tables. This is workable since I keep automated backups of these items anyway.

  In fairly short order, I was able to set up a working copy of the MultimediaWiki hosted on a local Linux machine. Now what’s the move ? The MediaWiki software I’m running is 1.6.10. The very latest, as of this upgrade project is 1.22.2. I suppose it’s way too much to hope that the software will upgrade cleanly from 1.6.x straight to 1.22.x, but I guess it’s worth a shot…

  HA ! No chance. Okay, next idea is to march through the various versions and upgrade each in turn. MediaWiki has all their historic releases online, all the way back to the 1.3 lineage. I decided that the latest of each lineage should upgrade cleanly from anything in the previous version of lineage. E.g., 1.6.10 should upgrade cleanly to 1.7.3 (last in the 1.7 series). This seemed to be a workable strategy. So I downloaded the latest of each series, unpacked, and copied all the wiki files over the working installation and ran ‘php update.php’ in the maintenance/ directory.

  The process is tedious and not without its obstacles. I consider this penance for my years of wiki neglect. First, I run into the “PHP Parse error : syntax error, unexpected T_NAMESPACE, expecting T_STRING” issue, the same that I saw years ago after the webhost transitioned from PHP 5.2 -> 5.3. I could solve this by editing assorted files and changing “Namespace” -> “MWNamespace” (which is what MediaWiki did by version 1.13). But I would prefer not to.

  Instead, I downloaded the source for PHP 5.2 and compiled it in a separate directory, then called ‘/path/to/php/5.2/bin/php update.php’. Problem solved.

  The next problem is that a bunch of the database update scripts are specifying “Type=InnoDB”. This isn’t supported by modern MySQL databases. Now, it’s “Engine=InnoDB”. A quick search & replace at the command line fixes this for 1.6.x… and 1.7.x… and 1.8 through 1.12. Finally, at 1.13, it was no longer necessary. As a bonus, at 1.13, I was able to test the installation since Namespace had been renamed to MWNamespace. I would later learn that the table type modifications probably could have been simplified in by changing “$wgDBmysql4 = true ;” to “$wgDBmysql5 = true ;” somewhere in LocalSettings.php.

  Command line upgrading worked smoothly up through 1.18 series when I got a new syntax error :

  <br />
PHP Fatal error:  Call to a member function addMessages() on a non-object in /mnt/sdb1/archive/wiki/extensions/Cite.php on line 68<br />

  Best I could do was comment out that line. I hope that doesn’t break anything important.

  In the home stretch, the very last transition (1.21 -> 1.22) failed :

  PHP Fatal error :  Cannot redeclare wfProfileIn() (previously declared in 
  /mnt/sdb1/archive/wiki/includes/profiler/Profiler.php:33) in 
  /mnt/sdb1/archive/wiki/includes/ProfilerStub.php on line 25
  

  Apparently, this problem arises occasionally since 1.18. I found a way around it thanks to this page : Deleted the file StartProfiler.php. Who am I to argue ?

  Upon completing the transition to 1.22, the wiki doesn’t look correct– the pictures aren’t showing up. The solution was to fix the temporary directory via LocalSettings.php.

  Back To Production
  Okay, it all works again ! Locally, that is. How to get it back to the server ? My first idea was that, knowing that this upgrade process can succeed, try stepping through the upgrade process again, but tell the update.php scripts to access the database tables on multimedia.cx. This seemed to be working for awhile, even though the database update phase often took 4-5 minutes. However, the transition from 1.8.5 -> 1.9.6 took 75 minutes and then timed out. According to my notes, “This isn’t going to work.”

  The new process :

  1. Dump the database tables from the local database.
  2. Create a new database remotely (melanson_wiki_ng).
  3. Dump the database table into melanson_wiki_ng.
  4. Move the index.php file out of the wiki files directory temporarily (or rename).
  5. Modify the LocalSettings.php to talk to the new database.
  6. Perform a lftp mirror operation in order to send all the files up to the server.
  7. Send the index.php file and hope beyond hope that everything magically works.

  And that’s the story of how the updated MultimediaWiki came back online. Despite the database dump file being over 110 MB, it only tool MySQL 1m45s to transmit it all to the remote server (let’s hear it for the ‘–compress’ option). For comparison, inserting the tables back into a fresh local database took 1m07s.

  When the MultimediaWiki was first live again, it loaded, but ever so slowly. This is when I finally looked into optimization and found that I was lacking any caching. So as a bonus, the MultimediaWiki should be much faster now.

  Going Forward
  For all I know, I did everything described here in the hardest way possible. But at least I got it done. Unless I learn of a better process, future upgrades will probably look similar to this.

  Additionally, I should probably take some time to figure out what new features are part of the standard MediaWiki distribution nowadays.