Sur d’autres sites (8691)

• Date and segment comparison feature

  31 octobre 2019, par Matomo Core Team — Analytics Tips, Development

  Get a clearer picture with the date and segment comparison feature

  What can you do with it ? What are the benefits ?

  Make informed decisions faster by easily comparing different segments and dates with each other.

  Compare report data for multiple segments next to each other

  

  Directly compare the behaviour of visitors from different segments e.g. customers with accounts vs. customers without accounts. Segment comparisons are a powerful way to compare different audience ; learn which ones perform better ; and in what way their actions differ. 

  Compare report data for two time periods next to each other

  

  See how your website performs compared to the previous month/week/year. Including seeing trends over those periods. Say, your business always picks up at the same times within a year, or there’s a sag in business for every user segment over this year and the last except one.

  By being able to compare date ranges you are able to get a quick overview of trends and period to period performance. Has a campaign worked better in September than in October ? Get an instant look by having the side-by-side comparison in Matomo.

  What is it capable of ?

  It lets you ask the question, “What is different ?”

  If you look at reports you’ll only see how people behave overall and if you look at specific segments you’ll see how they behave at face value, however, if you compare data together you’ll be quickly informed on what makes them unique. This data is still there when you don’t use the comparison feature, it’s just buried. Comparing data highlights discrepancies and leads to important questions and answers.

  For example, perhaps some class of users have very low engagement on a specific day compared to the rest of your visitors, and perhaps those users are responsible for an outsized proportion of churn. 

  Who could benefit from it, and why ?

  Everyone can benefit from using it (and probably should use it). It’s yours to experiment with ! You shouldn’t feel restricted to only comparing between the current and last period, or having questions before you start comparing. Follow your instincts and see what pops out when data from different segments is laid out next to each other.

  Where can you find it in Matomo ?

  • Segment comparison is activated by the new icon in the segment selector

  

  • Date comparison can be found in the calendar section of Matomo

  

  • The list of active comparisons is visible at the top of the page for all pages that support comparison
  • Comparisons are visible in every report that supports comparing data, and reports that do not support it will display a message saying so

  How do you use it ?

  • To compare segments, click the icon in the segment selector
  • To compare periods, click the ‘compare’ checkbox in the period selector, then select what period you want to compare it against in the dropdown (previous period, previous year, or a custom range)
  • When comparisons are active, view your reports as normal

  Take it away !

  The comparison feature is a new tool from Matomo 3.12.0 that highlights discrepancies and differences in data that can lead to more clarity and understanding, so we’d encourage everyone to use it. 

  Try it out today in your Matomo and see the power behind this new data comparison mode !

• Anomalie #3772 : Filtrage automatique par statut actif sur une boucle spip_articles depuis SPIP 3.x

  8 mai 2016, par jluc -

  Comme écrit sur la page liée, un critère optionnel est actif "uniquement si l’environnement contient la balise demandée". Dans l’environnement des boucles imbriquées, la balise est bien définie, et ce serait donc normal que le critère soit activé.

  Dans les exemples cités, le traitement ne semble pas malin car dans l’environnement de la boucle interne, cette balise est un champ de la table englobante, qui n’est pas l’une des tables sur lesquelles boucle la boucle interne, comme c’est souvent le cas pour les critères raccourcis.

  Les critères optionnels et raccourcis ont été mis en place pour les arguments d’url ou les arguments des appels d’INCLURE ou de modèles, et rien n’est pas prévu de désambiguiser les homonymes : quand il y a statut dans une url, ce n’est ni spécialement un statut de rubrique, ni spécialement un statut d’article. Donc par conception,

  statut, statut ?, id_rubrique

  n’en tiennent pas compte.

  On ne peut pas changer ça pour les critères raccourcis, sinon la transmission des #ID_RUBRIQUE ne pourrait pas se faire d’une boucle rubrique à une boucle article et les critères raccourcis n’auraient quasiment plus raison d’être.

  A priori je trouve assez sain (car simple) que les critères optionnels fonctionnent pareil que les critères raccourcis. Donc il faudrait une raison sérieuse pour que ça soit différent. Quelle serait elle ?

• nvenc : De-compensate aspect ratio compensation of DVD-like content.

  28 janvier 2015, par Philip Langdale

  nvenc : De-compensate aspect ratio compensation of DVD-like content.
  For reasons we are not privy to, nvidia decided that the nvenc encoder
  
  should apply aspect ratio compensation to ’DVD like’ content, assuming that
  
  the content is not BT.601 compliant, but needs to be BT.601 compliant. In
  
  this context, that means that they make the following, questionable,
  
  assumptions :
  1) If the input dimensions are 720x480 or 720x576, assume the content has
  
  an active area of 704x480 or 704x576.
  2) Assume that whatever the input sample aspect ratio is, it does not account
  
  for the difference between ’physical’ and ’active’ dimensions.
  From these assumptions, they then conclude that they can ’help’, by adjusting
  
  the sample aspect ratio by a factor of 45/44. And indeed, if you wanted to
  
  display only the 704 wide active area with the same aspect ratio as the full
  
  720 wide image - this would be the correct adjustment factor, but what if you
  
  don’t ? And more importantly, what if you’re used to lavc not making this kind
  
  of adjustment at encode time - because none of the other encoders do this !
  And, what if you had already accounted for BT.601 and your input had the
  
  correct attributes ? Well, it’s going to apply the compensation anyway !
  
  So, if you take some content, and feed it through nvenc repeatedly, it
  
  will keep scaling the aspect ratio every time, stretching your video out
  
  more and more and more.
  So, clearly, regardless of whether you want to apply bt.601 aspect ratio
  
  adjustments or not, this is not the way to do it. With any other lavc
  
  encoder, you would do it as part of defining your input parameters or do
  
  the adjustment at playback time, and there’s no reason by nvenc should
  
  be any different.
  This change adds some logic to undo the compensation that nvenc would
  
  otherwise do.
  nvidia engineers have told us that they will work to make this
  
  compensation mechanism optional in a future release of the nvenc
  
  SDK. At that point, we can adapt accordingly.
  Signed-off-by : Philip Langdale <philipl@overt.org>
  
  Reviewed-by : Timo Rothenpieler <timo@rothenpieler.org>
  
  Signed-off-by : Anton Khirnov <anton@khirnov.net>
  

  • [DBH] libavcodec/nvenc.c