Sur d’autres sites (8832)

• Ogg objections

  3 mars 2010, par Mans — Multimedia

  The Ogg container format is being promoted by the Xiph Foundation for use with its Vorbis and Theora codecs. Unfortunately, a number of technical shortcomings in the format render it ill-suited to most, if not all, use cases. This article examines the most severe of these flaws.
  

  Overview of Ogg

  The basic unit in an Ogg stream is the page consisting of a header followed by one or more packets from a single elementary stream. A page can contain up to 255 packets, and a packet can span any number of pages. The following table describes the page header.

  Field	Size (bits)	Description
  capture_pattern	32	magic number “OggS”
  version	8	always zero
  flags	8
  granule_position	64	abstract timestamp
  bitstream_serial_number	32	elementary stream number
  page_sequence_number	32	incremented by 1 each page
  checksum	32	CRC of entire page
  page_segments	8	length of segment_table
  segment_table	variable	list of packet sizes

  Elementary stream types are identified by looking at the payload of the first few pages, which contain any setup data required by the decoders. For full details, see the official format specification.

  Generality

  Ogg, legend tells, was designed to be a general-purpose container format. To most multimedia developers, a general-purpose format is one in which encoded data of any type can be encapsulated with a minimum of effort.

  The Ogg format defined by the specification does not fit this description. For every format one wishes to use with Ogg, a complex mapping must first be defined. This mapping defines how to identify a codec, how to extract setup data, and even how timestamps are to be interpreted. All this is done differently for every codec. To correctly parse an Ogg stream, every such mapping ever defined must be known.

  Under this premise, a centralised repository of codec mappings would seem like a sensible idea, but alas, no such thing exists. It is simply impossible to obtain a exhaustive list of defined mappings, which makes the task of creating a complete implementation somewhat daunting.

  One brave soul, Tobias Waldvogel, created a mapping, OGM, capable of storing any Microsoft AVI compatible codec data in Ogg files. This format saw some use in the wild, but was frowned upon by Xiph, and it was eventually displaced by other formats.

  True generality is evidently not to be found with the Ogg format.

  A good example of a general-purpose format is Matroska. This container can trivially accommodate any codec, all it requires is a unique string to identify the codec. For codecs requiring setup data, a standard location for this is provided in the container. Furthermore, an official list of codec identifiers is maintained, meaning all information required to fully support Matroska files is available from one place.

  Matroska also has probably the greatest advantage of all : it is in active, wide-spread use. Historically, standards derived from existing practice have proven more successful than those created by a design committee.

  Overhead

  When designing a container format, one important consideration is that of overhead, i.e. the extra space required in addition to the elementary stream data being combined. For any given container, the overhead can be divided into a fixed part, independent of the total file size, and a variable part growing with increasing file size. The fixed overhead is not of much concern, its relative contribution being negligible for typical file sizes.

  The variable overhead in the Ogg format comes from the page headers, mostly from the segment_table field. This field uses a most peculiar encoding, somewhat reminiscent of Roman numerals. In Roman times, numbers were written as a sequence of symbols, each representing a value, the combined value being the sum of the constituent values.

  The segment_table field lists the sizes of all packets in the page. Each value in the list is coded as a number of bytes equal to 255 followed by a final byte with a smaller value. The packet size is simply the sum of all these bytes. Any strictly additive encoding, such as this, has the distinct drawback of coded length being linearly proportional to the encoded value. A value of 5000, a reasonable packet size for video of moderate bitrate, requires no less than 20 bytes to encode.

  On top of this we have the 27-byte page header which, although paling in comparison to the packet size encoding, is still much larger than necessary. Starting at the top of the list :

  • The version field could be disposed of, a single-bit marker being adequate to separate this first version from hypothetical future versions. One of the unused positions in the flags field could be used for this purpose
  • A 64-bit granule_position is completely overkill. 32 bits would be more than enough for the vast majority of use cases. In extreme cases, a one-bit flag could be used to signal an extended timestamp field.
  • 32-bit elementary stream number ? Are they anticipating files with four billion elementary streams ? An eight-bit field, if not smaller, would seem more appropriate here.
  • The 32-bit page_sequence_number is inexplicable. The intent is to allow detection of page loss due to transmission errors. ISO MPEG-TS uses a 4-bit counter per 188-byte packet for this purpose, and that format is used where packet loss actually happens, unlike any use of Ogg to date.
  • A mandatory 32-bit checksum is nothing but a waste of space when using a reliable storage/transmission medium. Again, a flag could be used to signal the presence of an optional checksum field.

  With the changes suggested above, the page header would shrink from 27 bytes to 12 bytes in size.

  We thus see that in an Ogg file, the packet size fields alone contribute an overhead of 1/255 or approximately 0.4%. This is a hard lower bound on the overhead, not attainable even in theory. In reality the overhead tends to be closer to 1%.

  Contrast this with the ISO MP4 file format, which can easily achieve an overhead of less than 0.05% with a 1 Mbps elementary stream.

  Latency

  In many applications end-to-end latency is an important factor. Examples include video conferencing, telephony, live sports events, interactive gaming, etc. With the codec layer contributing as little as 10 milliseconds of latency, the amount imposed by the container becomes an important factor.

  Latency in an Ogg-based system is introduced at both the sender and the receiver. Since the page header depends on the entire contents of the page (packet sizes and checksum), a full page of packets must be buffered by the sender before a single bit can be transmitted. This sets a lower bound for the sending latency at the duration of a page.

  On the receiving side, playback cannot commence until packets from all elementary streams are available. Hence, with two streams (audio and video) interleaved at the page level, playback is delayed by at least one page duration (two if checksums are verified).

  Taking both send and receive latencies into account, the minimum end-to-end latency for Ogg is thus twice the duration of a page, triple if strict checksum verification is required. If page durations are variable, the maximum value must be used in order to avoid buffer underflows.

  Minimum latency is clearly achieved by minimising the page duration, which in turn implies sending only one packet per page. This is where the size of the page header becomes important. The header for a single-packet page is 27 + packet_size/255 bytes in size. For a 1 Mbps video stream at 25 fps this gives an overhead of approximately 1%. With a typical audio packet size of 400 bytes, the overhead becomes a staggering 7%. The average overhead for a multiplex of these two streams is 1.4%.

  As it stands, the Ogg format is clearly not a good choice for a low-latency application. The key to low latency is small packets and fine-grained interleaving of streams, and although Ogg can provide both of these, by sending a single packet per page, the price in overhead is simply too high.

  ISO MPEG-PS has an overhead of 9 bytes on most packets (a 5-byte timestamp is added a few times per second), and Microsoft’s ASF has a 12-byte packet header. My suggestions for compacting the Ogg page header would bring it in line with these formats.

  Random access

  Any general-purpose container format needs to allow random access for direct seeking to any given position in the file. Despite this goal being explicitly mentioned in the Ogg specification, the format only allows the most crude of random access methods.

  While many container formats include an index allowing a time to be directly translated into an offset into the file, Ogg has nothing of this kind, the stated rationale for the omission being that this would require a two-pass multiplexing, the second pass creating the index. This is obviously not true ; the index could simply be written at the end of the file. Those objecting that this index would be unavailable in a streaming scenario are forgetting that seeking is impossible there regardless.

  The method for seeking suggested by the Ogg documentation is to perform a binary search on the file, after each file-level seek operation scanning for a page header, extracting the timestamp, and comparing it to the desired position. When the elementary stream encoding allows only certain packets as random access points (video key frames), a second search will have to be performed to locate the entry point closest to the desired time. In a large file (sizes upwards of 10 GB are common), 50 seeks might be required to find the correct position.

  A typical hard drive has an average seek time of roughly 10 ms, giving a total time for the seek operation of around 500 ms, an annoyingly long time. On a slow medium, such as an optical disc or files served over a network, the times are orders of magnitude longer.

  A factor further complicating the seeking process is the possibility of header emulation within the elementary stream data. To safeguard against this, one has to read the entire page and verify the checksum. If the storage medium cannot provide data much faster than during normal playback, this provides yet another substantial delay towards finishing the seeking operation. This too applies to both network delivery and optical discs.

  Although optical disc usage is perhaps in decline today, one should bear in mind that the Ogg format was designed at a time when CDs and DVDs were rapidly gaining ground, and network-based storage is most certainly on the rise.

  The final nail in the coffin of seeking is the codec-dependent timestamp format. At each step in the seeking process, the timestamp parsing specified by the codec mapping corresponding the current page must be invoked. If the mapping is not known, the best one can do is skip pages until one with a known mapping is found. This delays the seeking and complicates the implementation, both bad things.

  Timestamps

  A problem old as multimedia itself is that of synchronising multiple elementary streams (e.g. audio and video) during playback ; badly synchronised A/V is highly unpleasant to view. By the time Ogg was invented, solutions to this problem were long since explored and well-understood. The key to proper synchronisation lies in tagging elementary stream packets with timestamps, packets carrying the same timestamp intended for simultaneous presentation. The concept is as simple as it seems, so it is astonishing to see the amount of complexity with which the Ogg designers managed to imbue it. So bizarre is it, that I have devoted an entire article to the topic, and will not cover it further here.

  Complexity

  Video and audio decoding are time-consuming tasks, so containers should be designed to minimise extra processing required. With the data volumes involved, even an act as simple as copying a packet of compressed data can have a significant impact. Once again, however, Ogg lets us down. Despite the brevity of the specification, the format is remarkably complicated to parse properly.

  The unusual and inefficient encoding of the packet sizes limits the page size to somewhat less than 64 kB. To still allow individual packets larger than this limit, it was decided to allow packets spanning multiple pages, a decision with unfortunate implications. A page-spanning packet as it arrives in the Ogg stream will be discontiguous in memory, a situation most decoders are unable to handle, and reassembly, i.e. copying, is required.

  The knowledgeable reader may at this point remark that the MPEG-TS format also splits packets into pieces requiring reassembly before decoding. There is, however, a significant difference there. MPEG-TS was designed for hardware demultiplexing feeding directly into hardware decoders. In such an implementation the fragmentation is not a problem. Rather, the fine-grained interleaving is a feature allowing smaller on-chip buffers.

  Buffering is also an area in which Ogg suffers. To keep the overhead down, pages must be made as large as practically possible, and page size translates directly into demultiplexer buffer size. Playback of a file with two elementary streams thus requires 128 kB of buffer space. On a modern PC this is perhaps nothing to be concerned about, but in a small embedded system, e.g. a portable media player, it can be relevant.

  In addition to the above, a number of other issues, some of them minor, others more severe, make Ogg processing a painful experience. A selection follows :

  • 32-bit random elementary stream identifiers mean a simple table-lookup cannot be used. Instead the list of streams must be searched for a match. While trivial to do in software, it is still annoying, and a hardware demultiplexer would be significantly more complicated than with a smaller identifier.
  • Semantically ambiguous streams are possible. For example, the continuation flag (bit 1) may conflict with continuation (or lack thereof) implied by the segment table on the preceding page. Such invalid files have been spotted in the wild.
  • Concatenating independent Ogg streams forms a valid stream. While finding a use case for this strange feature is difficult, an implementation must of course be prepared to encounter such streams. Detecting and dealing with these adds pointless complexity.
  • Unusual terminology : inventing new terms for well-known concepts is confusing for the developer trying to understand the format in relation to others. A few examples :
    

    Ogg name	Usual name
    logical bitstream	elementary stream
    grouping	multiplexing
    lacing value	packet size (approximately)
    segment	imaginary element serving no real purpose
    granule position	timestamp

  Final words

  We have found the Ogg format to be a dubious choice in just about every situation. Why then do certain organisations and individuals persist in promoting it with such ferocity ?

  When challenged, three types of reaction are characteristic of the Ogg campaigners.

  On occasion, these people will assume an apologetic tone, explaining how Ogg was only ever designed for simple audio-only streams (ignoring it is as bad for these as for anything), and this is no doubt true. Why then, I ask again, do they continue to tout Ogg as the one-size-fits-all solution they already admitted it is not ?

  More commonly, the Ogg proponents will respond with hand-waving arguments best summarised as Ogg isn’t bad, it’s just different. My reply to this assertion is twofold :

  • Being too different is bad. We live in a world where multimedia files come in many varieties, and a decent media player will need to handle the majority of them. Fortunately, most multimedia file formats share some basic traits, and they can easily be processed in the same general framework, the specifics being taken care of at the input stage. A format deviating too far from the standard model becomes problematic.
  • Ogg is bad. When every angle of examination reveals serious flaws, bad is the only fitting description.

  The third reaction bypasses all technical analysis : Ogg is patent-free, a claim I am not qualified to directly discuss. Assuming it is true, it still does not alter the fact that Ogg is a bad format. Being free from patents does not magically make Ogg a good choice as file format. If all the standard formats are indeed covered by patents, the only proper solution is to design a new, good format which is not, this time hopefully avoiding the old mistakes.

• Playing MP3 with FFMPEG Library

  13 février 2017, par Keith Chambers

  I am attempting to make a C program that will play an MP3 file (Using FFMPEG & SDL).

  Here’s the general gist of what I’m try to do, based on my understanding thus far.

  1. Open the file + load ’container’ level data into a AVFormatContext
  2. Find the stream inside the container that you want to work with. In my case I believe there is only a single audio steam so format_context->streams[0] references this.
  3. Fetch a decoder(Stored in AVcodec), by the Codec ID found in the stream and populate AVCodecContext
  4. Set up your desired SDL_AudioSpec struct. Notably here you pass it a callback function for filling up an audio buffer provided by SDL itself and your AVCodecContext which is passed to the callback.
  5. Open an SDL audio device using your wanted spec and call SDL_PauseAudioDevice() which creates a new thread to continually call the callback function (start the audio playback).
  6. The main thread continues and continually reads encoded packets/frames and puts them on a global queue until the stream data has been completely processed.
  7. The callback function dequeues the encoded packets, decodes them and writes them to the buffer passed by SDL audio as a parameter.

  Questions :

  1. What exactly is the difference between a frame and a packet in the context of audio ?

     My understanding is that frames are encapsulated packets that are easier to feed as raw data since they are more uniform in size. A frame may require multiple packets to fill it but multiple frames cannot be made from a single packet(I could have mixed that up, as I don’t remember where I read that). Are packets always decoded into frames or are the terms somewhat interchangeable ?

  2. Where is the encoded stream of packets stored ? In my code I’m using av_read_frame(AVFormatContext*, AVPacket) to somehow fetch a packet from somewhere so I can put the packet on my queue.

  3. Lots of things about the callback function..

     `void audio_callback(void *userdata, Uint8 *stream, int len)`

     1. Just to confirm, stream and len are decided by SDL audio ? The programmer has no way of passing values for these arguments ?
     2. Len is the size, in bytes of decoded audio data that SDL Audio is requesting ?
     3. How do I know how many frames is enough to write len data to the buffer ? To my knowledge a frame is an encapsulation of a FIXED amount of decoded audio data, so how do I know how much data each frame contains ?
     4. avcodec_send_packet(AVCodecContext *, AVPacket *) and avcodec_receive_frame(AVCodecContext *, AVFrame *) are the new ways to decode data, how exactly do they work ?

  So it seems like you pass in a valid packet to avcodec_send_packet(), it decodes it and then to get the corresponding frame you call the avcodec_receive_frame().

  Issues that I can see with this is that size-wise a packet mightn’t correspond to a frame, a number of packets might make up a single frame.

  OK here’s the stripped down version of my code, I can link to the full thing if required.

  I omitted all error checking, clean up and the implementation of the PacketQueue structure since it’s pretty intuitive. I haven’t tested this specifically but my original program is segfaulting when it gets to avcodec_send_packet()

  // Includes etc ommited
  
  
  
  // My own type, just assume it works and was allocated in main
  
  PacketQueue *audioq;
  
  
  
  void audio_callback(void *userdata, Uint8 *stream, int requestedLen)
  
  {
  
      AVCodecContext *codec_context = (AVCodecContext *)userdata;
  
      AVPacket * nextPacket;
  
      AVFrame outputFrame;
  
  
  
      // Take packet off of audioq Queue and store in nextPacket
  
      deQueue(audioq, nextPacket);
  
      avcodec_send_packet(codec_context, nextPacket);
  
      avcodec_receive_frame(codec_context, &outputFrame);
  
  
  
      memcpy(stream, (uint8_t *)outputFrame.data, outputFrame.sample_rate);
  
  }
  
  
  
  int main(int argc, char *argv[])
  
  {
  
  
  
      AVCodec * audio_codec;
  
      AVCodecContext *codec_context;
  
      AVFormatContext *format_context = NULL;
  
      SDL_AudioSpec want;
  
      SDL_AudioSpec have;
  
      SDL_AudioDeviceID audio_device_id;
  
      const char* audio_device_name = NULL;
  
  
  
      SDL_Init(SDL_INIT_AUDIO | SDL_INIT_TIMER);
  
      av_register_all();
  
  
  
      format_context = avformat_alloc_context();
  
      avformat_open_input(&format_context, *(argv + 1), NULL, NULL);
  
      avformat_find_stream_info(format_context, NULL);
  
  
  
      audio_codec = avcodec_find_decoder(format_context->streams[0]->codecpar->codec_id);
  
      codec_context = avcodec_alloc_context3(audio_codec);
  
  
  
      avcodec_open2(codec_context, audio_codec, NULL);
  
  
  
      want.freq = codec_context->sample_rate;
  
      want.format = AUDIO_S16SYS;
  
      want.channels = 2;
  
      want.samples = SDL_AUDIO_BUFFER_SIZE;
  
      want.callback = audio_callback;
  
      want.userdata = codec_context;
  
      want.silence = 0;
  
  
  
      audio_device_id = SDL_OpenAudioDevice(NULL, 0, &want, &have, SDL_AUDIO_ALLOW_FORMAT_CHANGE);
  
      audio_device_name = SDL_GetAudioDeviceName(0, 0);
  
  
  
      SDL_PauseAudioDevice(audio_device_id, 0);
  
  
  
      while(quit == 0)
  
      {
  
          AVPacket* packet = malloc(sizeof(AVPacket));
  
          av_read_frame(format_context, packet);
  
          // Put packet onto audioq Queue
  
          enQueue(audioq, packet);
  
  
  
          if(packet)
  
              free(packet);
  
      }
  
      // Cleanup
  
  
  
      return 0;
  
  }

  I’m sure my callback function is highly simplistic and somewhat naive but after I replaced the old avcodec_decode_audio4() much of the code I had seem irrelevant(Don’t worry the program wasn’t working at that point either..)

• How to Use Analytics & Reports for Marketing, Sales & More

  28 septembre 2023, par Erin — Analytics Tips

  By now, most professionals know they should be using analytics and reports to make better business decisions. Blogs and thought leaders talk about it all the time. But most sources don’t tell you how to use analytics and reports. So marketers, salespeople and others either skim whatever reports they come across or give up on making data-driven decisions entirely. 

  But it doesn’t have to be this way.

  In this article, we’ll cover what analytics and reports are, how they differ and give you examples of each. Then, we’ll explain how clean data comes into play and how marketing, sales, and user experience teams can use reports and analytics to uncover actionable insights.

  What’s the difference between analytics & reports ? 

  Many people speak of reports and analytics as if the terms are interchangeable, but they have two distinct meanings.

  A report is a collection of data presented in one place. By tracking key metrics and providing numbers, reports tell you what is happening in your business. Analytics is the study of data and the process of generating insights from data. Both rely on data and are essential for understanding and improving your business results.

  

  A science experiment is a helpful analogy for how reporting and analytics work together. To conduct an experiment, scientists collect data and results and compile a report of what happened. But the process doesn’t stop there. After generating a data report, scientists analyse the data and try to understand the why behind the results.

  In a business context, you collect and organise data in reports. With analytics, you then use those reports and their data to draw conclusions about what works and what doesn’t.

  Reports examples 

  Reports are a valuable tool for just about any part of your business, from sales to finance to human resources. For example, your finance team might collect data about spending and use it to create a report. It might show how much you spend on employee compensation, real estate, raw materials and shipping.

  On the other hand, your marketing team might benefit from a report on lead sources. This would mean collecting data on where your sales leads come from (social media, email, organic search, etc.). You could collect and present lead source data over time for a more in-depth report. This shows which sources are becoming more effective over time. With advanced tools, you can create detailed, custom reports that include multiple factors, such as time, geographical location and device type.

  

  Analytics examples 

  Because analytics requires looking at and drawing insights from data and reports to collect and present data, analytics often begins by studying reports. 

  In our example of a report on lead sources, an analytics professional might study the report and notice that webinars are an important source of leads. To better understand this, they might look closely at the number of leads acquired compared to how often webinars occur. If they notice that the number of webinar leads has been growing, they might conclude that the business should invest in more webinars to generate more leads. This is just one kind of insight analytics can provide.

  For another example, your human resources team might study a report on employee retention. After analysing the data, they could discover valuable insights, such as which teams have the highest turnover rate. Further analysis might help them uncover why certain teams fail to keep employees and what they can do to solve the problem.

  The importance of clean data 

  Both analytics and reporting rely on data, so it’s essential your data is clean. Clean data means you’ve audited your data, removed inaccuracies and duplicate entries, and corrected mislabelled data or errors. Basically, you want to ensure that each piece of information you’re using for reports and analytics is accurate and organised correctly.

  If your data isn’t clean and accurate, neither will your reports be. And making business decisions based on bad data can come at a considerable cost. Inaccurate data might lead you to invest in a channel that appears more valuable than it actually is. Or it could cause you to overlook opportunities for growth. Moreover, poor data maintenance and the poor insight it provides will lead your team to have less trust in your reports and analytics team.

  The simplest way to maintain clean data is to be meticulous when inputting or transferring data. This can be as simple as ensuring that your sales team fills in every field of an account record. When you need to import or transfer data from other sources, you need to perform quality assurance (QA) checks to make sure data is appropriately labelled and organised. 

  Another way to maintain clean data is by avoiding cookies. Most web visitors reject cookie consent banners. When this happens, analysts and marketers don’t get data on these visitors and only see the percentage of users who accept tracking. This means they decide on a smaller sample size, leading to poor or inaccurate data. These banners also create a poor user experience and annoy web visitors.

  Matomo can be configured to run cookieless — which, in most countries, means you don’t need to have an annoying cookie consent screen on your site. This way, you can get more accurate data and create a better user experience.

  Marketing analytics and reports 

  Analytics and reporting help you measure and improve the effectiveness of your marketing efforts. They help you learn what’s working and what you should invest more time and money into. And bolstering the effectiveness of your marketing will create more opportunities for sales.

  

  One common area where marketing teams use analytics and reports is to understand and improve their keyword rankings and search engine optimization. They use web analytics platforms like Matomo to report on how their website performs for specific keywords. Insights from these reports are then used to inform changes to the website and the development of new content.

  As we mentioned above, marketing teams often use reports on lead sources to understand how their prospects and customers are learning about the brand. They might analyse their lead sources to better understand their audience. 

  For example, if your company finds that you receive a lot of leads from LinkedIn, you might decide to study the content you post there and how it differs from other platforms. You could apply a similar content approach to other channels to see if it increases lead generation. You can then study reporting on how lead source data changes after you change content strategies. This is one example of how analysing a report can lead to marketing experimentation. 

  Email and paid advertising are also marketing channels that can be optimised with reports and analysis. By studying the data around what emails and ads your audience clicks on, you can draw insights into what topics and messaging resonate with your customers.

  

  Marketing teams often use A/B testing to learn about audience preferences. In an A/B test, you can test two landing page versions, such as two different types of call-to-action (CTA) buttons. Matomo will generate a report showing how many people clicked each version. From those results, you may draw an insight into the design your audience prefers.

  Sales analytics and reports 

  Sales analytics and reports are used to help teams close more deals and sell more efficiently. They also help businesses understand their revenue, set goals, and optimise sales processes. And understanding your sales and revenue allows you to plan for the future.

  One of the keys to building a successful sales strategy and team is understanding your sales cycle. That’s why it’s so important for companies to analyse their lead and sales data. For business-to-business (B2B) companies in particular, the sales cycle can be a long process. But you can use reporting and analytics to learn about the stages of the buying cycle, including how long they take and how many leads proceed to the next step.

  Analysing lead and customer data also allows you to gain insights into who your customers are. With detailed account records, you can track where your customers are, what industries they come from, what their role is and how much they spend. While you can use reports to gather customer data, you also have to use analysis and qualitative information in order to build buyer personas. 

  

  Many sales teams use past individual and business performance to understand revenue trends. For instance, you might study historical data reports to learn how seasonality affects your revenue. If you dive deeper, you might find that seasonal trends may depend on the country where your customers live. 

  

  Conversely, it’s also important to analyse what internal variables are affecting revenue. You can use revenue reports to identify your top-performing sales associates. You can then try to expand and replicate that success. While sales is a field often driven by personal relationships and conversations, many types of reports allow you to learn about and improve the process.

  Website and user behaviour analytics and reports 

  More and more, businesses view their websites as an experience and user behaviour as an important part of their business. And just like sales and marketing, reporting and analytics help you better understand and optimise your web experience. 

  Many web and user behaviour metrics, like traffic source, have important implications for marketing. For example, page traffic and user flows can provide valuable insights into what your customers are interested in. This can then drive future content development and marketing campaigns.

  

  You can also learn about how your users navigate and use your website. A robust web analytics tool, like Matomo, can supply user session recordings and visitor tracking. For example, you could study which pages a particular user visits. But Matomo also has a feature called Transitions that provides visual reports showing where a particular page’s traffic comes from and where visitors tend to go afterward. 

  

  As you consider why people might be leaving your website, site performance is another important area for reporting. Most users are accustomed to near-instantaneous web experiences, so it’s worth monitoring your page load time and looking out for backend delays. In today’s world, your website experience is part of what you’re selling to customers. Don’t miss out on opportunities to impress and delight them.

  Dive into your data

  Reporting and analytics can seem like mysterious buzzwords we’re all supposed to understand already. But, like anything else, they require definitions and meaningful examples. When you dig into the topic, though, the applications for reporting and analytics are endless.

  Use these examples to identify how you can use analytics and reports in your role and department to achieve better results, whether that means higher quality leads, bigger deal size or a better user experience.

  To see how Matomo can collect accurate and reliable data and turn it into in-depth analytics and reports, start a free 21-day trial. No credit card required.