Sur d’autres sites (10985)

• tests : Rename vsynth2 to vsynth_lena

  30 novembre 2014, par Michael Niedermayer

  tests : Rename vsynth2 to vsynth_lena
  This avoids confusion with a growing number of vsynth tests
  Signed-off-by : Michael Niedermayer <michaelni@gmx.at>
  

  • [DH] tests/Makefile
  • [DH] tests/fate/ffmpeg.mak
  • [DH] tests/fate/seek.mak
  • [DH] tests/fate/vcodec.mak
  • [DH] tests/ref/seek/vsynth_lena-asv1
  • [DH] tests/ref/seek/vsynth_lena-asv2
  • [DH] tests/ref/seek/vsynth_lena-dnxhd-1080i
  • [DH] tests/ref/seek/vsynth_lena-dnxhd-720p
  • [DH] tests/ref/seek/vsynth_lena-dnxhd-720p-rd
  • [DH] tests/ref/seek/vsynth_lena-dv
  • [DH] tests/ref/seek/vsynth_lena-dv-411
  • [DH] tests/ref/seek/vsynth_lena-dv-50
  • [DH] tests/ref/seek/vsynth_lena-ffv1
  • [DH] tests/ref/seek/vsynth_lena-flashsv
  • [DH] tests/ref/seek/vsynth_lena-flv
  • [DH] tests/ref/seek/vsynth_lena-h261
  • [DH] tests/ref/seek/vsynth_lena-h263
  • [DH] tests/ref/seek/vsynth_lena-h263p
  • [DH] tests/ref/seek/vsynth_lena-huffyuv
  • [DH] tests/ref/seek/vsynth_lena-jpegls
  • [DH] tests/ref/seek/vsynth_lena-ljpeg
  • [DH] tests/ref/seek/vsynth_lena-mjpeg
  • [DH] tests/ref/seek/vsynth_lena-mpeg1
  • [DH] tests/ref/seek/vsynth_lena-mpeg1b
  • [DH] tests/ref/seek/vsynth_lena-mpeg2-422
  • [DH] tests/ref/seek/vsynth_lena-mpeg2-idct-int
  • [DH] tests/ref/seek/vsynth_lena-mpeg2-ilace
  • [DH] tests/ref/seek/vsynth_lena-mpeg2-ivlc-qprd
  • [DH] tests/ref/seek/vsynth_lena-mpeg2-thread
  • [DH] tests/ref/seek/vsynth_lena-mpeg2-thread-ivlc
  • [DH] tests/ref/seek/vsynth_lena-mpeg4
  • [DH] tests/ref/seek/vsynth_lena-mpeg4-adap
  • [DH] tests/ref/seek/vsynth_lena-mpeg4-adv
  • [DH] tests/ref/seek/vsynth_lena-mpeg4-error
  • [DH] tests/ref/seek/vsynth_lena-mpeg4-nr
  • [DH] tests/ref/seek/vsynth_lena-mpeg4-nsse
  • [DH] tests/ref/seek/vsynth_lena-mpeg4-qpel
  • [DH] tests/ref/seek/vsynth_lena-mpeg4-qprd
  • [DH] tests/ref/seek/vsynth_lena-mpeg4-rc
  • [DH] tests/ref/seek/vsynth_lena-mpeg4-thread
  • [DH] tests/ref/seek/vsynth_lena-msmpeg4
  • [DH] tests/ref/seek/vsynth_lena-msmpeg4v2
  • [DH] tests/ref/seek/vsynth_lena-rgb
  • [DH] tests/ref/seek/vsynth_lena-roqvideo
  • [DH] tests/ref/seek/vsynth_lena-rv10
  • [DH] tests/ref/seek/vsynth_lena-rv20
  • [DH] tests/ref/seek/vsynth_lena-snow
  • [DH] tests/ref/seek/vsynth_lena-snow-ll
  • [DH] tests/ref/seek/vsynth_lena-svq1
  • [DH] tests/ref/seek/vsynth_lena-wmv1
  • [DH] tests/ref/seek/vsynth_lena-wmv2
  • [DH] tests/ref/seek/vsynth_lena-yuv
  • [DH] tests/ref/vsynth/vsynth2-amv
  • [DH] tests/ref/vsynth/vsynth2-asv1
  • [DH] tests/ref/vsynth/vsynth2-asv2
  • [DH] tests/ref/vsynth/vsynth2-avui
  • [DH] tests/ref/vsynth/vsynth2-cljr
  • [DH] tests/ref/vsynth/vsynth2-dnxhd-1080i
  • [DH] tests/ref/vsynth/vsynth2-dnxhd-720p
  • [DH] tests/ref/vsynth/vsynth2-dnxhd-720p-10bit
  • [DH] tests/ref/vsynth/vsynth2-dnxhd-720p-rd
  • [DH] tests/ref/vsynth/vsynth2-dnxhd_1080i
  • [DH] tests/ref/vsynth/vsynth2-dv
  • [DH] tests/ref/vsynth/vsynth2-dv-411
  • [DH] tests/ref/vsynth/vsynth2-dv-50
  • [DH] tests/ref/vsynth/vsynth2-dv_411
  • [DH] tests/ref/vsynth/vsynth2-ffv1
  • [DH] tests/ref/vsynth/vsynth2-ffv1.0
  • [DH] tests/ref/vsynth/vsynth2-ffvhuff
  • [DH] tests/ref/vsynth/vsynth2-ffvhuff420p12
  • [DH] tests/ref/vsynth/vsynth2-ffvhuff422p10left
  • [DH] tests/ref/vsynth/vsynth2-ffvhuff444
  • [DH] tests/ref/vsynth/vsynth2-ffvhuff444p16
  • [DH] tests/ref/vsynth/vsynth2-flashsv
  • [DH] tests/ref/vsynth/vsynth2-flashsv2
  • [DH] tests/ref/vsynth/vsynth2-flv
  • [DH] tests/ref/vsynth/vsynth2-h261
  • [DH] tests/ref/vsynth/vsynth2-h261-trellis
  • [DH] tests/ref/vsynth/vsynth2-h263
  • [DH] tests/ref/vsynth/vsynth2-h263-obmc
  • [DH] tests/ref/vsynth/vsynth2-h263p
  • [DH] tests/ref/vsynth/vsynth2-huffyuv
  • [DH] tests/ref/vsynth/vsynth2-huffyuvbgr24
  • [DH] tests/ref/vsynth/vsynth2-huffyuvbgra
  • [DH] tests/ref/vsynth/vsynth2-jpeg2000
  • [DH] tests/ref/vsynth/vsynth2-jpeg2000-97
  • [DH] tests/ref/vsynth/vsynth2-jpegls
  • [DH] tests/ref/vsynth/vsynth2-ljpeg
  • [DH] tests/ref/vsynth/vsynth2-mjpeg
  • [DH] tests/ref/vsynth/vsynth2-mjpeg-422
  • [DH] tests/ref/vsynth/vsynth2-mjpeg-444
  • [DH] tests/ref/vsynth/vsynth2-mpeg1
  • [DH] tests/ref/vsynth/vsynth2-mpeg1b
  • [DH] tests/ref/vsynth/vsynth2-mpeg2
  • [DH] tests/ref/vsynth/vsynth2-mpeg2-422
  • [DH] tests/ref/vsynth/vsynth2-mpeg2-idct-int
  • [DH] tests/ref/vsynth/vsynth2-mpeg2-ilace
  • [DH] tests/ref/vsynth/vsynth2-mpeg2-ivlc-qprd
  • [DH] tests/ref/vsynth/vsynth2-mpeg2-thread
  • [DH] tests/ref/vsynth/vsynth2-mpeg2-thread-ivlc
  • [DH] tests/ref/vsynth/vsynth2-mpeg4
  • [DH] tests/ref/vsynth/vsynth2-mpeg4-adap
  • [DH] tests/ref/vsynth/vsynth2-mpeg4-adv
  • [DH] tests/ref/vsynth/vsynth2-mpeg4-error
  • [DH] tests/ref/vsynth/vsynth2-mpeg4-nr
  • [DH] tests/ref/vsynth/vsynth2-mpeg4-nsse
  • [DH] tests/ref/vsynth/vsynth2-mpeg4-qpel
  • [DH] tests/ref/vsynth/vsynth2-mpeg4-qprd
  • [DH] tests/ref/vsynth/vsynth2-mpeg4-rc
  • [DH] tests/ref/vsynth/vsynth2-mpeg4-thread
  • [DH] tests/ref/vsynth/vsynth2-mpng
  • [DH] tests/ref/vsynth/vsynth2-msmpeg4
  • [DH] tests/ref/vsynth/vsynth2-msmpeg4v2
  • [DH] tests/ref/vsynth/vsynth2-msvideo1
  • [DH] tests/ref/vsynth/vsynth2-prores
  • [DH] tests/ref/vsynth/vsynth2-prores_ks
  • [DH] tests/ref/vsynth/vsynth2-qtrle
  • [DH] tests/ref/vsynth/vsynth2-qtrlegray
  • [DH] tests/ref/vsynth/vsynth2-r210
  • [DH] tests/ref/vsynth/vsynth2-rgb
  • [DH] tests/ref/vsynth/vsynth2-roqvideo
  • [DH] tests/ref/vsynth/vsynth2-rv10
  • [DH] tests/ref/vsynth/vsynth2-rv20
  • [D

• Processing Big Data Problems

  8 janvier 2011, par Multimedia Mike — Big Data

  I’m becoming more interested in big data problems, i.e., extracting useful information out of absurdly sized sets of input data. I know it’s a growing field and there is a lot to read on the subject. But you know how I roll— just think of a problem to solve and dive right in.

  Here’s how my adventure unfolded.

  The Corpus
  I need to run a command line program on a set of files I have collected. This corpus is on the order of 350,000 files. The files range from 7 bytes to 175 MB. Combined, they occupy around 164 GB of storage space.

  Oh, and said storage space resides on an external, USB 2.0-connected hard drive. Stop laughing.

  A file is named according to the SHA-1 hash of its data. The files are organized in a directory hierarchy according to the first 6 hex digits of the SHA-1 hash (e.g., a file named a4d5832f... is stored in a4/d5/83/a4d5832f...). All of this file hash, path, and size information is stored in an SQLite database.

  First Pass
  I wrote a Python script that read all the filenames from the database, fed them into a pool of worker processes using Python’s multiprocessing module, and wrote some resulting data for each file back to the SQLite database. My Eee PC has a single-core, hyperthreaded Atom which presents 2 CPUs to the system. Thus, 2 worker threads crunched the corpus. It took awhile. It took somewhere on the order of 9 or 10 or maybe even 12 hours. It took long enough that I’m in no hurry to re-run the test and get more precise numbers.

  At least I extracted my initial set of data from the corpus. Or did I ?

  Think About The Future
  
  A few days later, I went back to revisit the data only to notice that the SQLite database was corrupted. To add insult to that bit of injury, the script I had written to process the data was also completely corrupted (overwritten with something unrelated to Python code). BTW, this is was on a RAID brick configured for redundancy. So that’s strike 3 in my personal dealings with RAID technology.

  I moved the corpus to a different external drive and also verified the files after writing (easy to do since I already had the SHA-1 hashes on record).

  The corrupted script was pretty simple to rewrite, even a little better than before. Then I got to re-run it. However, this run was on a faster machine, a hyperthreaded, quad-core beast that exposes 8 CPUs to the system. The reason I wasn’t too concerned about the poor performance with my Eee PC is that I knew I was going to be able to run in on this monster later.

  So I let the rewritten script rip. The script gave me little updates regarding its progress. As it did so, I ran some rough calculations and realized that it wasn’t predicted to finish much sooner than it would have if I were running it on the Eee PC.

  Limiting Factors
  It had been suggested to me that I/O bandwidth of the external USB drive might be a limiting factor. This is when I started to take that idea very seriously.

  The first idea I had was to move the SQLite database to a different drive. The script records data to the database for every file processed, though it only commits once every 100 UPDATEs, so at least it’s not constantly syncing the disc. I ran before and after tests with a small subset of the corpus and noticed a substantial speedup thanks to this policy chance.

  Then I remembered hearing something about "atime" which is access time. Linux filesystems, per default, record the time that a file was last accessed. You can watch this in action by running 'stat <file> ; cat <file> > /dev/null ; stat <file>' and observe that the "Access" field has been updated to NOW(). This also means that every single file that gets read from the external drive still causes an additional write. To avoid this, I started mounting the external drive with '-o noatime' which instructs Linux not to record "last accessed" time for files.

  On the limited subset test, this more than doubled script performance. I then wondered about mounting the external drive as read-only. This had the same performance as noatime. I thought about using both options together but verified that access times are not updated for a read-only filesystem.

  A Note On Profiling
  Once you start accessing files in Linux, those files start getting cached in RAM. Thus, if you profile, say, reading a gigabyte file from a disk and get 31 MB/sec, and then repeat the same test, you’re likely to see the test complete instantaneously. That’s because the file is already sitting in memory, cached. This is useful in general application use, but not if you’re trying to profile disk performance.

  Thus, in between runs, do (as root) 'sync; echo 3 > /proc/sys/vm/drop_caches' in order to wipe caches (explained here).

  Even Better ?
  I re-ran the test using these little improvements. Now it takes somewhere around 5 or 6 hours to run.

  I contrived an artificially large file on the external drive and did some 'dd' tests to measure what the drive could really do. The drive consistently measured a bit over 31 MB/sec. If I could read and process the data at 30 MB/sec, the script would be done in about 95 minutes.

  But it’s probably rather unreasonable to expect that kind of transfer rate for lots of smaller files scattered around a filesystem. However, it can’t be that helpful to have 8 different processes constantly asking the HD for 8 different files at any one time.

  So I wrote a script called stream-corpus.py which simply fetched all the filenames from the database and loaded the contents of each in turn, leaving the data to be garbage-collected at Python’s leisure. This test completed in 174 minutes, just shy of 3 hours. I computed an average read speed of around 17 MB/sec.

  Single-Reader Script
  I began to theorize that if I only have one thread reading, performance should improve greatly. To test this hypothesis without having to do a lot of extra work, I cleared the caches and ran stream-corpus.py until 'top' reported that about half of the real memory had been filled with data. Then I let the main processing script loose on the data. As both scripts were using sorted lists of files, they iterated over the filenames in the same order.

  Result : The processing script tore through the files that had obviously been cached thanks to stream-corpus.py, degrading drastically once it had caught up to the streaming script.

  Thus, I was incented to reorganize the processing script just slightly. Now, there is a reader thread which reads each file and stuffs the name of the file into an IPC queue that one of the worker threads can pick up and process. Note that no file data is exchanged between threads. No need— the operating system is already implicitly holding onto the file data, waiting in case someone asks for it again before something needs that bit of RAM. Technically, this approach accesses each file multiple times. But it makes little practical difference thanks to caching.

  Result : About 183 minutes to process the complete corpus (which works out to a little over 16 MB/sec).

  Why Multiprocess
  Is it even worthwhile to bother multithreading this operation ? Monitoring the whole operation via 'top', most instances of the processing script are barely using any CPU time. Indeed, it’s likely that only one of the worker threads is doing any work most of the time, pulling a file out of the IPC queue as soon the reader thread triggers its load into cache. Right now, the processing is usually pretty quick. There are cases where the processing (external program) might hang (one of the reasons I’m running this project is to find those cases) ; the multiprocessing architecture at least allows other processes to take over until a hanging process is timed out and killed by its monitoring process.

  Further, the processing is pretty simple now but is likely to get more intensive in future iterations. Plus, there’s the possibility that I might move everything onto a more appropriately-connected storage medium which should help alleviate the bottleneck bravely battled in this post.

  There’s also the theoretical possibility that the reader thread could read too far ahead of the processing threads. Obviously, that’s not too much of an issue in the current setup. But to guard against it, the processes could share a variable that tracks the total number of bytes that have been processed. The reader thread adds filesizes to the count while the processing threads subtract file sizes. The reader thread would delay reading more if the number got above a certain threshold.

  Leftovers
  I wondered if the order of accessing the files mattered. I didn’t write them to the drive in any special order. The drive is formatted with Linux ext3. I ran stream-corpus.py on all the filenames sorted by filename (remember the SHA-1 naming convention described above) and also by sorting them randomly.

  Result : It helps immensely for the filenames to be sorted. The sorted variant was a little more than twice as fast as the random variant. Maybe it has to do with accessing all the files in a single directory before moving onto another directory.

  Further, I have long been under the impression that the best read speed you can expect from USB 2.0 was 27 Mbytes/sec (even though 480 Mbit/sec is bandied about in relation to the spec). This comes from profiling I performed with an external enclosure that supports both USB 2.0 and FireWire-400 (and eSata). FW-400 was able to read the same file at nearly 40 Mbytes/sec that USB 2.0 could only read at 27 Mbytes/sec. Other sources I have read corroborate this number. But this test (using different hardware), achieved over 31 Mbytes/sec.

• Server-side tracking vs client-side tracking : What you need to know

  3 juillet, par Joe

  Server-side tracking vs client-side tracking : What you need to know

  Today, consumers are more aware of their online privacy rights, leading to an extensive use of ad blockers and stricter cookie policies. Organisations are facing some noteworthy challenges with this trend, including :

  • Limited data collection, which makes it harder to understand user behaviour and deliver personalised ads that resonate with customers
  • Rising compliance costs as businesses adapt to new regulations, straining resources and budgets.
  • Growing customer scepticism in data practices, affecting brand reputation.
  • Maintaining transparency and fostering trust with customers through clear communication about data practices.

  Server-side tracking can help resolve these problems. This article will cover server-side tracking, how it works, implementation methods and its benefits.

  What is server-side tracking ? 

  Server-side tracking refers to a method where user data is collected directly by a server rather than through a user’s browser.

  The key advantage of server-side tracking is that data collection, processing, and storage occur directly on the website’s server.

  For example, when a visitor interacts with any website, the server captures that activity through the backend system, allowing for greater data control and security. 

  Client-side tracking vs. server-side tracking 

  There are two methods to collect user data : client-side and server-side. 

  Let’s understand their differences. 

  Client-side tracking : Convenience with caveats

  Client-side tracking embeds JavaScript tags, pixels or other scripts directly into a website’s code. When a user interacts with the site, these tags fire, collecting data from their browser. This information might include page views, button clicks, form submissions and other user actions. 

  The collected data is then sent directly to third-party analytics platforms like Google Analytics or Adobe Analytics, or internal teams can also analyse it.

  This method is relatively easy to implement. That’s because marketers can often deploy these tags without needing extensive developer support, enabling quick adjustments and A/B testing. 

  However, there are some challenges. 

  Ad blockers and browser privacy settings, such as Intelligent Tracking Prevention (ITP), restrict the ability of third-party tags to collect data. 

  This results in data gaps and inaccuracies skewing analytics reports and potentially leading to misguided business decisions. 

  Reliance on numerous JavaScript tags can also negatively impact website performance, slowing down page load times and affecting user experience. This is especially true on mobile devices where processing power and network speeds are often limited.

  

  Now, let’s see how server-side tracking changes this.

  Server-side tracking : Control and reliability

  Server-side tracking shifts the burden of data collection from the user’s browser to a server controlled by the business. 

  Instead of relying on JavaScript tags firing directly from the user’s device, user interactions are first sent to the business’s own server. Here, the data can be processed, enriched, and analysed. 

  This method provides numerous advantages, including enhanced control over data integrity, improved privacy, and more, which we discuss in the next section.

  Benefits of server-side tracking 

  Server-side tracking offers a compelling alternative to traditional client-side methods, providing numerous business advantages. Let’s take a look at them.

  Improved data accuracy

  This method reduces inaccuracies caused by ad blockers or cookie restrictions by bypassing browser limitations. As a result, the data collected is more reliable, leading to better analytics and marketing attribution.

  Data minimisation

  Data minimisation is a fundamental principle in data protection. It emphasises that organisations should collect only data that is strictly needed for a specific purpose. 

  In server-side tracking, this translates into collecting just the essential data points and discarding anything extra before the data is sent to analytics platforms. It helps organisations avoid accumulating excessive personal information, reducing the risk of data breaches and misuse.

  For example, consider a scenario where a user purchases a product on an e-commerce website. 

  With client-side tracking scripts, the system might inadvertently collect a range of data, including the user’s IP address, browser type, operating system and even details about other websites they have visited. 

  However, for conversions, the organisation only needs to know the purchase amount, product IDs, user IDS, and timestamps. 

  Server-side tracking filters unnecessary information. This reduces the privacy impact and simplifies data analysis and storage.

  Cross-device tracking capabilities

  Server-side tracking provides a unified view of customer behaviour regardless of the device they use, allowing for more personalised and targeted marketing campaigns. 

  In-depth event tracking

  Server-side tracking helps businesses track events that occur outside their websites, such as payment confirmations. Companies gain insights into the entire customer journey, from initial interaction to final purchase, optimising every touchpoint. 

  Enhanced privacy compliance

  With increasing regulations like GDPR and CCPA, businesses can better manage user consent and data handling practices through server-side solutions. 

  Server-side setups make honouring user consent easier. If a user opts out, server-side logic can exclude their data from all outgoing analytics calls in one central place. 

  

  Server-side methods reassure users and regulators that data is collected and secured with minimal risk. 

  In sectors like government and banking, this level of control is often a non-negotiable part of their duty of care. 

  Extended cookie lifetime

  Traditional website tracking faces growing obstacles as modern browsers prioritise user privacy. Initiatives like Safari’s ITP block third-party cookies and also constrain the use of first-party cookies. 

  Other browsers, such as Firefox and Brave, are implementing similar methods, while Chrome is beginning to phase out third-party cookies. Retargeting and cross-site analytics, which rely on these cookies, encounter significant challenges.

  Server-side tracking overcomes this by allowing businesses to collect data over a longer duration. 

  When a website’s server directly sets a cookie, that cookie often lasts longer than cookies created by JavaScript code running inside the browser. This lets websites get around some of the limits browsers put on tracking and allows them to remember a visitor when they return to the site later, which gives better customer insights. Plus, server-side tracking typically classifies cookies as first-party data, which is less susceptible to blocking by browsers and ad blockers.

  Server-side tracking : Responsibilities and considerations

  While server-side tracking delivers powerful capabilities, remember that it also brings increased responsibility. Companies must remain vigilant in upholding privacy regulations and user consent. It’s up to the organisation to make sure the server follows user consent, for example, not sending data if someone has opted out.

  Server-side setups introduce technical complexity, which can potentially lead to data errors that are more difficult to identify and resolve. Therefore, monitoring processes and quality assurance practices are essential for data integrity. 

  How does server-side tracking work ? 

  When a user interacts with a website (e.g., clicking a button), this action triggers an event. The event could be anything from a page view to a form submission.

  The backend system captures relevant details such as the event type, user ID and timestamp. This information helps in understanding user behaviour and creating meaningful analytics.

  The captured data is processed directly on the organisation’s server, allowing for immediate validation. For example, organisations can add additional context or filter out irrelevant information.

  Instead of sending data to third-party endpoints, the organisation stores everything in its own database or data warehouse. This ensures full control over data privacy and security.

  Organisations can perform their own analysis using tools like SQL or Python. To visualise data, custom dashboards and reports can be created using self-hosted analytics tools. This way, businesses can present complex data in a clear and actionable manner.

  How to implement server-side tracking ?

  Server-side tracking can work in four common ways, each offering a different blend of control, flexibility and complexity.

  1. Server-side tag management

  In this method, organisations use platforms like Google Tag Manager Server-Side to manage tracking tags on the server, often using containers to isolate and manage different tagging environments. 

  

  (Image Source) 

  This approach offers a balance between control and ease of use. It allows for the deployment and management of tags without modifying the application code, which is particularly useful for marketers who want to adjust tracking configurations quickly.

  2. Direct server-to-server tracking via APIs

  This method involves sharing information between two servers without affecting the user’s browser or device. 

  A unique identifier is generated and stored on a server when a user interacts with an ad or webpage. 

  If a user takes some action, like making a purchase, the unique identifier is sent from the advertiser’s server directly to the platform’s server (Google or Facebook) via an API. 

  It requires more development effort but is ideal for organisations needing fine-grained data control.

  3. Using analytics platforms with built-in server SDKs

  Another way is to employ analytics platforms like Matomo that provide SDKs for various programming languages to instrument the server-side code. 

  This eases integration with the platform’s analytics features and is a good choice for organisations primarily using a single analytics platform and want to use its server-side capabilities.

  4. Hybrid approaches

  Finally, organisations can also combine client- and server-side tracking to capture different data types and maximise accuracy. 

  This method involves client-side scripts for specific interactions (like UI events) and server-side tracking for more sensitive or critical data (like transactions). 

  While these are general approaches, dedicated analytics platforms can also be helpful. Matomo, for example, facilitates server-side tracking through two specific methods.

  Using server logs

  Matomo can import existing web server logs, such as Apache or Nginx, that capture each request. Every page view or resource load becomes a data point. 

  Matomo’s log processing script reads log files, importing millions of hits. This removes the need to add code to the site, making it suitable for basic page analytics (like the URL) without client-side scripts, particularly on security-sensitive sites.

  Using the Matomo tracking API (Server-side SDKs)

  This method integrates application code with calls to Matomo’s API. For example, when a user performs a specific action, the server sends a request to Matomo.php, the tracking endpoint, which includes details like the user ID and action. 

  Matomo offers SDKs in PHP, Java C#, and community SDKs to simplify these calls. These allow tracking of not just page views but custom events such as downloads and transactions from the backend, functioning similarly to Google’s Measurement Protocol but sending data to the Matomo instance. 

  Data privacy, regulations and Matomo

  As privacy concerns grow and regulations like GDPR and CCPA become more stringent, businesses must adopt data collection methods that respect user consent and data protection rights. 

  Server-side tracking allows organisations to collect first-party data directly from their servers, which is generally considered more compliant with privacy regulations.

  Matomo is a popular open-source web analytics platform that is committed to privacy. It gives organisations 100% data ownership and control, and no data is sent to third parties by default.

  

  (Image Source) 

  Matomo is a full-featured analytics platform with dashboards and segmentation comparable to Google Analytics. It can self-host and provides DoNotTrack settings and the ability to anonymise IP addresses.

  Governments and organisations requiring data sovereignty, such as the EU Commission and the Swiss government, choose Matomo for web analytics due to its strong compliance posture.

  Balancing data collection and user privacy

  Ad blockers and other restrictions prevent data from being accurate. Server-side tracking helps get data on the server and makes it more reliable while respecting user privacy. Matomo supports server-side tracking, and over one million websites use Matomo to optimise their data strategies. 

  Get started today by trying Matomo for free for 21 days, no credit card required.