Sur d’autres sites (4992)

• 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.

• Evolution #4749 (Nouveau) : [UX] Comportement des labels : quoi par défaut, quoi ponctuel ?

  27 avril 2021, par RastaPopoulos ♥

  Ce ticket sert à réfléchir et possiblement reconcevoir les choix par défaut pour les labels des formulaires.

  État des lieux¶

  On le sait, l’ergo c’est normalement beaucoup d’objectif : certains placements, certaines tailles, épaisseurs, etc fonctionnent mieux que d’autres, et ceci est prouvable par tests utilisateurs.

  Or cela fait des années que les tests par eye-tracking montrent que les formulaires sont
  1) lu plus rapidement
  2) avec une meilleure compréhension
  lorsque les labels sont au-dessus des champs.

  Ça ne veut pas dire qu’il faut totalement interdire autrement mais : ça veut clairement dire que ça devrait être le comportement par défaut. Et seulement ponctuellement, par choix explicite, pouvoir mettre les labels sur le côté.

  Par ailleurs les pros de l’ergo (sur base des mêmes tests) préconisent tou⋅tes : dans les rares cas où on met les labels sur le côté, ça devrait être calé à droite sur le champ, pour les mêmes raisons de compréhension.

  Les avantages des labels au-dessus :
  - prouvé que c’est bien mieux compris par tout le monde
  - lecture plus rapide
  - fonctionne de base sur tous les écrans, pas d’adaptation à faire
  - polyvalent et générique sur le contenu des labels : marche mieux quelque soit la longueur, et donc à prioriser dans un contexte multilingue
  => cela correspond bien au maximum de notre utilisation : un CMS multi-lingue, allant enfin vers le responsive, se souciant d’accessibilité.

  Le seul désavantage : allonge la hauteur des formulaires, mais ça n’a un impact surtout que pour les formulaires ayant vraiment vraiment beaucoup de champs, ce qui est rare !
  Quand un formulaire est extrêmement long, il y a même plusieurs méthodes qui peuvent être utilisées sans pour autant passer les labels sur le côté :
  1) placer certains champs sur le même ligne (prénom + nom, etc)
  2) découper le formulaire en plusieurs étapes.

  Proposition pour le futur¶

  - tous les labels doivent être au-dessus comme comportement par défaut
  - pour certains cas, une classe permet de mettre sur le côté : valable uniquement en grand écran, ça reste au-dessus en mobile first
  - si sur le côté : c’est mieux si aligné sur le champ (donc à droite en LTR)
  - ex de rare formulaire candidat : changement des dates

  Quelques sources¶

  Tests utilisateurs
  https://www.uxmatters.com/mt/archives/2006/07/label-placement-in-forms.php

  Placing a label above an input field works better in most cases
  Placing labels above input fields is preferable
  In most cases, when placing labels to the left of input fields, using left-aligned labels imposes a heavy cognitive workload on users
  if you choose to place them to the left of input fields, at least make them right aligned

  Chez le très connu cabinet d’ergo Nielsen Group
  https://www.nngroup.com/articles/form-design-white-space/

  We recommend placing field labels above the corresponding text fields [en gras chez eux !]
  it makes the form easier to scan, because users can see the text field in the same fixation as the label. Top placement also allows for longer field labels
  If the labels are too far to the left, it can be difficult to associate the correct label with its corresponding field

  Chez Adobe, ils préconisent de suivre les recommandations de la première source
  https://xd.adobe.com/ideas/principles/web-design/best-practices-form-design/

  Matteo Penzo’s 2006 article on label placement suggests that forms are completed faster if labels are on top of the fields. Top-aligned labels are good if you want users to scan the form as quickly as possible.
  The biggest advantage of top-aligned labels is that different-sized labels and localized versions can more easily fit the UI.
  Takeaway : If you want users to scan a form quickly, put labels above the fields. The layout will be easier to scan because the eye will move straight down the page. However, if you want users to read carefully, put labels to the left of the fields. This layout will slow down the reader and make them scan in a Z-shaped motion.

  Chez une appli de conception d’interface
  https://phase.com/magazine/usability-of-forms/

  from a cognitive point of view, the association is powerful
  Also, the eyes move only in one direction since the scanning is top down as compared to Z shape (left-right and top-bottom) for inline labels
  Design is space efficient and hence adaptable to all resolutions ; in short, responsive in nature
  We also get flexibility regarding the length of labels. This proves useful while working with variable label lengths like multilingual support for applications
  One drawback of this approach is the increased height of the form. However, it can be solved with alternate designs like a grouping of fields or stepper forms

• Layout Video Recording Like Instgram/ Ticktok Feature

  21 mars 2023, par Amarchand K

  I'm try to do record video inn different layouts like Instagram in Flutter. For this feature I used ffmpeg_kit_flutter package. I refers this solution to do this. but output video is blank, any one helps me to solve this.
the video input and output path is valid, also show the bellow error while printing,

  


  `ffmpeg version n5.1.2 Copyright (c) 2000-2022 the FFmpeg developers
    built with Android (7155654, based on r399163b1) clang version 11.0.5 (https://android.googlesource.com/toolchain/llvm-project 87f1315dfbea7c137aa2e6d362dbb457e388158d)
    configuration: --cross-prefix=aarch64-linux-android- --sysroot=/files/android-sdk/ndk/22.1.7171670/toolchains/llvm/prebuilt/linux-x86_64/sysroot --prefix=/home/taner/Projects/ffmpeg-kit/prebuilt/android-arm64/ffmpeg --pkg-config=/usr/bin/pkg-config --enable-version3 --arch=aarch64 --cpu=armv8-a --target-os=android --enable-neon --enable-asm --enable-inline-asm --ar=aarch64-linux-android-ar --cc=aarch64-linux-android24-clang --cxx=aarch64-linux-android24-clang++ --ranlib=aarch64-linux-android-ranlib --strip=aarch64-linux-android-strip --nm=aarch64-linux-android-nm --extra-libs='-L/home/taner/Projects/ffmpeg-kit/prebuilt/android-arm64/cpu-features/lib -lndk_compat' --disable-autodetect --enable-cross-compile --enable-pic --enable-jni --enable-optimizations --enable-swscale --disable-static --enable-shared --enable-pthreads --enable-v4l2-m2m --disable-outdev=fbdev --disable-indev=fbdev --enable-small --disable-xmm-clobber-test --disable-debug --enable-lto --disable-neon-clobber-test --disable-programs --disable-postproc --disable-doc --disable-htmlpages --disable-manpages --disable-podpages --disable-txtpages --disable-sndio --disable-schannel --disable-securetransport --disable-xlib --disable-cuda --disable-cuvid --disable-nvenc --disable-vaapi --disable-vdpau --disable-videotoolbox --disable-audiotoolbox --disable-appkit --disable-alsa --disable-cuda --disable-cuvid --disable-nvenc --disable-vaapi --disable-vdpau --enable-gmp --enable-gnutls --enable-iconv --disable-sdl2 --disable-openssl --enable-zlib --enable-mediacodec
    libavutil      57. 28.100 / 57. 28.100
    libavcodec     59. 37.100 / 59. 37.100
    libavformat    59. 27.100 / 59. 27.100
    libavdevice    59.  7.100 / 59.  7.100
    libavfilter     8. 44.100 /  8. 44.100
    libswscale      6.  7.100 /  6.  7.100
    libswresample   4.  7.100 /  4.  7.100
  -vsync is deprecated. Use -fps_mode
  Passing a number to -vsync is deprecated, use a string argument as described in the manual.
  Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/data/user/0/com.example.tuki_taki/cache/REC1453994379216336834.mp4':
    Metadata:
      major_brand     : mp42
      minor_version   : 0
      compatible_brands: isommp42
      creation_time   : 2023-03-21T07:15:58.000000Z
      com.android.version: 12
    Duration: 00:00:03.77, start: 0.000000, bitrate: 2204 kb/s
    Stream #0:0[0x1](eng): Video: h264, 1 reference frame (avc1 / 0x31637661), yuv420p(tv, bt470bg/smpte170m/bt709, progressive, left), 640x480, 2199 kb/s, 29.61 fps, 29.58 tbr, 90k tbn (default)
      Metadata:
        creation_time   : 2023-03-21T07:15:58.000000Z
        handler_name    : VideoHandle
        vendor_id       : [0][0][0][0]
      Side data:
        displaymatrix: rotation of -90.00 degrees
    Stream #0:1[0x2](eng): Audio: aac (mp4a / 0x6134706D), 48000 Hz, mono, fltp, 128 kb/s (default)
      Metadata:
        creation_time   : 2023-03-21T07:15:58.000000Z
        handler_name    : SoundHandle
        vendor_id       : [0][0][0][0]
  Input #1, mov,mp4,m4a,3gp,3g2,mj2, from '/data/user/0/com.example.tuki_taki/cache/REC5972384708251368209.mp4':
    Metadata:
      major_brand     : mp42
      minor_version   : 0
      compatible_brands: isommp42
      creation_time   : 2023-03-21T07:16:05.000000Z
      com.android.version: 12
    Duration: 00:00:02.84, start: 0.000000, bitrate: 2703 kb/s
    Stream #1:0[0x1](eng): Video: h264, 1 reference frame (avc1 / 0x31637661), yuv420p(tv, bt470bg/smpte170m/bt709, progressive, left), 640x480, 2801 kb/s, 29.61 fps, 29.58 tbr, 90k tbn (default)
      Metadata:
        creation_time   : 2023-03-21T07:16:05.000000Z
        handler_name    : VideoHandle
        vendor_id       : [0][0][0][0]
      Side data:
        displaymatrix: rotation of -90.00 degrees
    Stream #1:1[0x2](eng): Audio: aac (mp4a / 0x6134706D), 48000 Hz, mono, fltp, 128 kb/s (default)
      Metadata:
        creation_time   : 2023-03-21T07:16:05.000000Z
        handler_name    : SoundHandle
        vendor_id       : [0][0][0][0]
  Stream mapping:
    Stream #0:0 (h264) -> scale:default
    Stream #0:1 (aac) -> amix
    Stream #1:0 (h264) -> scale:default
    Stream #1:1 (aac) -> amix
    hstack:default -> Stream #0:0 (mpeg4)
    amix:default -> Stream #0:1 (aac)
  Press [q] to stop, [?] for help
  Output #0, mp4, to '/data/user/0/com.example.tuki_taki/cache/output.mp4':
    Metadata:
      major_brand     : mp42
      minor_version   : 0
      compatible_brands: isommp42
      com.android.version: 12
      encoder         : Lavf59.27.100
    Stream #0:0: Video: mpeg4, 1 reference frame (mp4v / 0x7634706D), yuv420p(progressive), 960x640 (0x0) [SAR 1:1 DAR 3:2], q=2-31, 200 kb/s, 29.58 fps, 11360 tbn
      Metadata:
        encoder         : Lavc59.37.100 mpeg4
      Side data:
        cpb: bitrate max/min/avg: 0/0/200000 buffer size: 0 vbv_delay: N/A
    Stream #0:1: Audio: aac (mp4a / 0x6134706D), 48000 Hz, mono, fltp, delay 1024, 69 kb/s
      Metadata:
        encoder         : Lavc59.37.100 aac
  frame=    1 fps=0.0 q=4.3 size=       0kB time=00:00:00.23 bitrate=   1.5kbits/s speed=3.49x    


  


  [mpeg4 @ 0xb400007122ebac50] Invalid pts (8) <= last (8)&#xA;Error submitting video frame to the encoder&#xA;[aac @ 0xb4000071232208c0] Qavg : 9911.349&#xA;[aac @ 0xb4000071232208c0] 2 frames left in the queue on closing&#xA;Conversion failed`

  &#xA;

  I'm tried

  &#xA;

    `Future<void> onLayoutDone() async {&#xA;try {&#xA;  final String outputPath = await _getTempPath();   &#xA;  const String filter =&#xA;      "[0:v]scale=480:640,setsar=1[l];[1:v]scale=480:640,setsar=1[r];[l][r]hstack;[0][1]amix -vsync 0 ";    &#xA;  log("left path: ${layoutVideoPathList[0]} right : ${layoutVideoPathList[1]} $outputPath");     &#xA;  final String command =" -y -i ${layoutVideoPathList[0]} -i ${layoutVideoPathList[1]} -filter_complex$filter$outputPath -loglevel verbose"; `these paths are valid`    &#xA;     &#xA;  await FFmpegKit.execute(command).then((value) async {      &#xA;    String? error = await value.getAllLogsAsString();    &#xA;    log(error!);    &#xA;    final ReturnCode? returnCode = await value.getReturnCode();    &#xA;    if (returnCode != null) {&#xA;      setVideo(videoPath: outputPath);    &#xA;      layoutVideoPathList.clear();    &#xA;    }&#xA;  });&#xA;} catch (e) {&#xA;  log("error while  combine -========-=-=-=-=-=-=-=-=- $e");    &#xA;}`&#xA;</void>

  &#xA;