Recherche avancée

Sur d’autres sites (11116)

• First-party data explained : Benefits, use cases and best practices

  25 juillet, par Joe

  Third-party cookies are being phased out, and marketers who still depend on them for user insights need to find alternatives.

  Google delayed the complete deprecation of third-party cookies until early 2025, but many other browsers, such as Mozilla, Brave, and Safari, have already put a stop to them. Plus, looking at the number of data leak incidents, like the one where Twitter leaked 200 million user emails, collecting and using first-party data is a great alternative. 

  In this post, we explore the ins and outs of first-party data and examine how to collect it. We’ll also look at various use cases and best practices to implement first-party data collection.

  What is first-party data ?

  First-party data is information organisations collect directly from customers through their owned channels. 

  Organisations can capture data without intermediaries when people interact with their website, mobile app, social media accounts or other customer-facing systems.

  For example, businesses can track visitor behaviour, such as bounce rates and time spent browsing particular pages. This activity is considered first-party data when it occurs on the brand’s digital property.

  Some examples include :

  • Demographics : Age, gender, location, income level
  • Contact information : Email addresses, phone numbers
  • Behavioural insights : Topics of interest, content engagement, browsing history
  • Transactional data : Purchase history, shopping preferences

  A defining characteristic is that this information comes straight from the source, with the customer’s willingness and consent. This direct collection method is why first-party data is widely regarded as more reliable and accurate than second or third-party data. With browsers like Chrome fully phasing out third-party cookies by the end of 2025, the urgency for adopting more first-party data strategies is accelerating across industries.

  How to collect first-party data 

  Organisations can collect first-party data in various ways. 

  Website pixels

  In this method, organisations place small pieces of code that track visitor actions like page views, clicks and conversions. When visitors land on the page, the pixel activates and collects data about their behaviour without interrupting the user experience. 

  Website analytics tools

  With major browsers like Safari and Firefox already blocking third-party cookies (and Chrome is phasing them out soon, there’s even more pressure on organisations to adopt first-party data strategies.

  Website analytics tools like Matomo help organisations collect first-party data with features like visitor tracking and acquisition analysis to analyse the best channels to attract more users. 

  Multi-attribution modelling that helps businesses understand how different touchpoints (social media channels or landing pages) persuade visitors to take a desired action (like making a purchase). 

  

  (Image Source)

  Other activities include :

  • Cohort analysis 
  • Heatmaps and session recordings 
  • SEO keyword tracking
  • A/B testing 
  • Paid ads performance tracking

  

  Heatmap feature in Matomo

  Account creation on websites

  When visitors register on websites, they provide information like names, email addresses and often demographic details or preferences.

  Newsletters and subscriptions 

  With email subscriptions and membership programs, businesses can collect explicit data (preferences selected during signup) and implicit data (engagement metrics like open rates and click patterns).

  Gated content

  Whitepapers, webinars or exclusive articles often ask for contact information when users want access. This approach targets specific audience segments interested in particular topics.

  Customer Relationship Management (CRM) systems

  CRM platforms collect information from various touchpoints and centralise it to create unified customer profiles. These profiles include detailed user information, like interaction history, purchase records, service inquiries and communication preferences.

  Mobile app activity

  Mobile in-app behaviours can assist businesses in gathering data such as :

  • Precise location information (indicating where customers interact with the app)
  • Which features they use most often
  • How long they stay on different screens
  • Navigation patterns

  This mobile-specific data helps organisations understand how their customers behave on smaller screens and while on the move, insights that website data alone cannot provide.

  Point of Sale (PoS) systems

  Modern checkout systems don’t just process payments. PepsiCo proved this by growing its first-party data stores by more than 50% through integrated PoS systems. 

  Today’s PoS technology captures detailed information about each transaction :

  • Item(s) sold
  • Price (discounts, taxes, tip)
  • Payment type (card, cash, digital wallet)
  • Time and date
  • Loyalty/rewards number
  • Store/location

  Plus, when connected with loyalty programs where customers identify themselves (by scanning a card or entering a phone number), these systems link purchase information to individuals. 

  This creates valuable historical records showing how customer preferences evolve and offering insight into :

  • Which products are frequently purchased together
  • The time of the day, week, month, or year when items sell best
  • Which promotions or special offers are most effective

  Server-side tracking 

  Most websites track user behaviour through code that runs in the visitor’s web browser (client-side tracking). 

  Server-side tracking takes a different approach by collecting data directly on the company’s own servers. 

  Because the tracking happens on company servers rather than browsers, ad-blocking software doesn’t block it. 

  Organisations gain more consistent data collection and greater control over their customer information. This privacy-friendly approach lets companies get the data they need without relying on third-party tracking scripts.

  Now that we understand how organisations can gather first-party data, let us explore its use cases. 

  Use cases of first-party data 

  Businesses can use first-party data in many ways, from creating customer profiles to personalising user experiences.

  Developing comprehensive customer profiles

  First-party data can help create detailed customer profiles. 

  Here are some examples :

  • Demographic profiles : Age, gender, location, job role and other personal characteristics.
  • Behavioural profiles : Website activity, purchase history and engagement with marketing campaigns that focus on how users interact with businesses and their offerings. 
  • Psychographic profiles : Customer’s interests, values and lifestyle preferences.
  • Transactional profiles : Purchase patterns, including the types of products they buy, how often they purchase and their total spending.

  The benefit of developing these profiles is that businesses can then create specific campaigns for each profile, instead of running random campaigns. 

  For example, a subscription service business may have a behavioural profile of ‘inactive users’. To reignite interest, they can offer discounts or limited-time freebies to these users.

  Crafting relevant content

  First-party data shows what types of content customers engage with most. 

  If customers love watching videos, businesses can create more video content. If a blog gets more readership for its tech articles, it can focus on tech-related content to adjust to readers’ preferences. 

  Uncovering new marketing opportunities

  First-party data lets businesses analyse customer interactions in a way that can reveal untapped markets. 

  For example, if a company sees that many website visitors are from a particular region, it might consider launching campaigns in that area to boost sales. 

  Personalising experiences

  89% of decision-makers believe personalisation is key to business success in the next three years. 

  First-party data helps organisations to tailor experiences based on individual preferences. 

  

  For example, an e-commerce site can recommend products based on previous purchases or browsing history. Shoppers with abandoned carts can get reminders. 

  It’s also helpful to see how customers respond to different types of communication. Certain groups may prefer emails, and some may prefer text messages. Similarly, some users spend more time on quizzes and interactive content like wizards or calculators. 

  By analysing this, businesses can adjust their strategies so that users get a personal experience when they visit a website.

  Optimising operations

  The use cases of first-party data don’t just apply to the marketing domain. They’re also valuable for operations. When businesses analyse customer order patterns, they can spot the best locations for fulfilment centres that reduce shipping time and costs.

  For example, an online retailer might discover that most customers are concentrated in urban areas and decide to open fulfilment centres closer to those locations.

  Or, in the public sector, transport companies can use first-party data to optimise routes and fine-tune fare simulation tools. By analysing rider queries, travel preferences and interaction data, they can :

  • Prioritise high-demand routes during peak hours 
  • Adjust fare structures to reflect common trip or rider patterns
  • Make personalised travel suggestions based on individual user history.

  Benefits of first-party data 

  First-party data offers two significant benefits : accuracy and compliance. It comes directly from the customers and can be considered more accurate and reliable. But that’s not it. 

  First-party data aligns with many data privacy regulations, like the GDPR and CCPA. That’s because first-party data collection requires explicit consent, which means the data remains confidential. This builds compliance, and customers develop more trust in the business.

  Best practices to collect and manage first-party data 

  Though first-party data comes with many benefits, how should organisations collect and manage it ? What are the best practices ? Let’s take a look. 

  Define clear goals

  Though defining clear goals seems like overused advice, it’s one of the most important. If a business doesn’t know why it’s collecting first-party data, all the information gathering becomes purposeless. 

  Businesses can think of different goals to achieve from first-party data collection : improving customer relationships, enhancing personalisation or increasing ROI. 

  Once these goals are concrete, they can guide data collection strategies and help understand whether they’re working.

  Establish a privacy policy

  A privacy policy is a document that explains why a business is collecting a user’s data and what it will do with it. By being open and honest, this policy builds trust with customers, so customers feel safe sharing their information. 

  For example, an e-commerce privacy policy may read like : 

  “At (Business name), your privacy is important to us. We collect your information when you create an account or buy something. This information includes your name, email and purchase history. We use this data to give you a better shopping experience and suggest products that you’ll find useful. We follow all data privacy laws like GDPR to keep your personal information safe.” 

  For organisations that use Matomo, we suggest updating the privacy policy to explain how Matomo is used and what data it collects. Here’s a privacy policy template for Matomo users that can be easily copied and pasted. 

  For a GDPR compatible privacy policy, read How to complete your privacy policy with Matomo analytics under GDPR.

  Simplify consent processes

  Businesses should obtain explicit user consent before collecting their data, as shown in the image below. 

  

  (Image Source) 

  To do this, integrate user-friendly consent management platforms that let customers easily access, view, opt out of, or delete their information.

  To ensure consent practices align with GDPR standards, follow these key steps :
  

  GDPR-compliant consent checklist
  ✅ State the purpose clearly	Describe data usage in plain terms.
  ✅ Use granular opt-ins	Separate consents by purpose.
  ✅ Avoid pre-ticked boxes	Active choices only.
  ✅ Enable easy opt-out	Simple and accessible withdrawal.
  ✅ Log consent	Timestamp and record every opt-in.
  ✅ Review periodically	Audit for accuracy and relevance.

  Comply with platform-specific restrictions

  In addition to general consent practices, businesses must comply with platform-specific restrictions. This includes obtaining explicit permissions for :

  • Location services : Users must consent to sharing their location data.
  • Contact lists : Businesses need permission to access and use contact information.
  • Camera and microphone Use : Users must consent to using the camera and microphone 
  • Advertising IDs : On platforms like iOS, businesses must obtain consent to use advertising IDs. 

  For example, Zoom asks the user if it can access the camera and the microphone by default.

  Utilise multiple data collection channels

  Instead of relying on just one source to collect first-party data, it is better to use multiple channels. Gather first-party data from diverse sources such as websites, mobile apps, CRM systems, email campaigns, and in-store interactions (for richer datasets). This way, businesses get a more complete picture of their customers.

  Implementing a strong data governance framework with proper tooling, taxonomy, and maintenance practices is also vital for better data usability.

  Use privacy-focused analytics tools 

  Focus on not just collecting data but also doing it in a way that’s secure and ethical. 

  Use tools like Matomo to track user interactions and gather meaningful analytics. For example, Matomo heatmaps can give you a visual insight into where users click and scroll, all while following all the data privacy laws.

  

  (Image Source) 

  What is second-party data ? 

  Second-party data is information that one company collects from its customers and shares with another company. It’s like “second-hand” first-party data because it’s collected directly from customers but used by a different business.

  Companies purchase second-party data from trusted partners instead of getting it directly from the customer. For example, hotel chains can use customer insights from online travel agencies, like popular destinations and average stay lengths, to refine their pricing strategies and offer more relevant perks.

  When using second-party data, it’s essential to :

  • Be transparent : Share with customers that their data is being shared with partners. 
  • Conduct regular audits : Ensure the data is accurate and handled properly to maintain strong privacy standards. If their data standards don’t seem that great, consider looking elsewhere.

  What is third-party data ? 

  Third-party data is collected from various sources, such as public records, social media or other online platforms. It’s then aggregated and sold to businesses. Organisations get third-party data from data brokers, aggregators and data exchanges or marketplaces. 

  Some examples of third-party data include life events from user social media profiles, like graduation or facts about different organisations, like the number of employees and revenue.

  For example, a data broker might collect information about people’s interests from social media and sell it to a company that wants to target ads based on those interests.

  Third-party data often raises privacy concerns due to its collection methods. One major issue is the lack of transparency in how this data is obtained. 

  Consumers often don’t know that their information is being collected and sold by third-party brokers, leading to feelings of mistrust and violation of privacy. This is why data privacy guidelines have evolved. 

  What is zero-party data ? 

  Zero-party data is the information that customers intentionally share with a business. Some examples include surveys, product ratings and reviews, social media polls and giveaways.

  Organisations collect first-party data by observing user behaviours, but zero-party data is the information that customers voluntarily provide. 

  

  Zero-party data can provide helpful insights, but self-reported information isn’t always accurate. People don’t always do what they say. 

  For example, customers in a survey may share that they consider quality above all else when purchasing. Still, looking at their actual behaviour, businesses can see that they make a purchase only when there’s a clearance or a sale.

  First-party data can give a broader view of customer behaviours over time, which zero-party data may not always be able to capture. 

  Therefore, while zero-party data offers insights into what customers say they want, first-party data helps understand how they behave in real-world scenarios. Balancing both data types can lead to a deeper understanding of customer needs.

  Getting valuable customer insights without compromising privacy 

  Matomo is a powerful tool for organisations that want to collect first-party data. We’re a full-featured web analytics tool that offers features that allow businesses to track user interactions without compromising the user’s personal information. Below, we share how.

  Data ownership

  Matomo allows organisations to own their analytics data, whether on-premise or in their chosen cloud. This means we don’t share your data with anyone else. This aligns with GDPR’s requirement for data sovereignty and minimises third-party risks.

  Pseudonymisation of user IDs

  Matomo allows organisations to pseudonymise user IDs, replacing them with a salted hash function. 

  

  (Image Source)

  Since the user IDs have different names, no one can trace them back to a specific person.

  IP address anonymisation

  Data anonymisation refers to removing personally identifiable information (PII) from datasets so individuals can’t be readily identified.

  Matomo automatically anonymises visitor IP addresses, which helps respect user privacy. For example, if the visitor’s IP address is 199.513.1001.123, Matomo can mask it to 199.0.0.0. 

  It can also anonymise geo-location information, such as country, region and city, ensuring this data doesn’t directly identify users.

  

  (Image Source) 

  Consent management

  Matomo offers an opt-out option that organisations can add to their website, privacy policy or legal page. 

  Matomo tracks everyone by default, but visitors can opt out by clicking the opt-out checkbox. 

  Our DoNotTrack technology helps businesses respect user choices to opt out of tracking from specific websites, such as social media or advertising platforms. They can simply select the “Support Do Not Track preference.”

  These help create consent workflows and support audit trails for regulators. 

  Data storage and deletion

  Keeping visitor data only as long as necessary is a good practice by default. 

  To adhere to this principle, organisations can configure Matomo to automatically delete old raw data and old aggregated report data. 

  Here’s a quick case study summarising how Matomo features can help organisations collect first-party data. CRO:NYX found that Google Analytics struggled to capture accurate data from their campaigns, especially when running ads on the Brave browser, which blocks third-party cookies.

  They then switched to Matomo, which uses first-party cookies by default. This approach allowed them to capture accurate data from Brave users without putting user privacy at stake. 

  The value of Matomo in first-party data strategies 

  First-party data gives businesses a reliable way to connect with audiences and to improve marketing strategies. 

  Matomo’s ethical web analytics lets organisations collect and analyse this data while prioritising user privacy. 

  With over 1 million websites using Matomo, it’s a trusted choice for organisations of all sizes. As a cloud-hosted service and a fully self-hosted solution, Matomo supports organisations with strong data sovereignty needs, allowing them to maintain full control over their analytics infrastructure.

  Ready to collect first-party data while securing user information ? Start your free 21-day trial, no credit card required.

• Find video resolution and video duration of remote mediafile

  22 février 2012, par osgx

  I want to write an program which can find some metainformation of mediafile. I'm interested in popular video formats, such as avi, mkv, mp4, mov (may be other popular too). I want basically to get :

  • Video size (720, 1080, 360 etc)
  • Total runtime of video (may be not very exact)
  • Number of audio streams
  • Name of video codec
  • Name of audio codec

  There is already the mediainfo, but in my program I want to get information about remote file, which may be accessed via ftp, http, samba ; or even torrent (there are some torrent solutions, which allows to read not-yet downloaded file).

  MediaInfo library have no support of samba (smb ://) and mkv format (for runtime).

  Also, I want to know, how much data should be downloaded to get this information. I want not to download full videofile because I have no enough disk space.

  Is this information in the first 1 or 10 or 100 KiloBytes of the file ? Is it at predictable offset if I know the container name and total file size ?

  PS : Platform is Linux, Language is C/C++

• Adding A New System To The Game Music Website

  1er août 2012, par Multimedia Mike — General

  At first, I was planning to just make a little website where users could install a Chrome browser extension and play music from old 8-bit NES games. But, like many software projects, the goal sort of ballooned. I created a website where users can easily play old video game music. It doesn’t cover too many systems yet, but I have had individual requests to add just about every system you can think of.

  The craziest part is that I know it’s possible to represent most of the systems. Eventually, it would be great to reach Chipamp parity (a combination plugin for Winamp that packages together plugins for many of these chiptunes). But there is a process to all of this. I have taken to defining a number of phases that are required to get a new system covered.

  Phase 0 informally involves marveling at the obscurity of some of the console systems for which chiptune collections have evolved. WonderSwan ? Sharp X68000 ? PC-88 ? I may be viewing this through a terribly Ameri-centric lens. I’ve at least heard of the ZX Spectrum and the Amstrad CPC even if I’ve never seen either.

  No matter. The goal is to get all their chiptunes cataloged and playable.

  Phase 1 : Finding A Player
  The first step is to find a bit of open source code that can play a particular format. If it’s a library that can handle many formats, like Game Music Emu or Audio Overload SDK, even better (probably). The specific open source license isn’t a big concern for me. I’m almost certain that some of the libraries that SaltyGME currently mixes are somehow incompatible, license-wise. I’ll worry about it when I encounter someone who A) cares, and B) is in a position to do something about it. Historical preservation comes first, and these software libraries aren’t getting any younger (I’m finding some that haven’t been touched in a decade).

  Phase 2 : Test Program
  The next phase is to create a basic test bench program that sends a music file into the library, generates a buffer of audio, and shoves it out to the speakers via PulseAudio’s simple API (people like to rip on PulseAudio, but its simple API really lives up to its name and requires pages less boilerplate code to play a few samples than ALSA).

  Phase 3 : Plug Into Web Player
  After successfully creating the test bench and understanding exactly which source files need to be built, the next phase is to hook it up to the main SaltyGME program via the ad-hoc plugin API I developed. This API requires that a player backend can, at the very least, initialize itself based on a buffer of bytes and generate audio samples into an array of 16-bit numbers. The API also provides functions for managing files with multiple tracks and toggling individual voices/channels if the library supports such a feature. Having the test bench application written beforehand usually smooths out this step.

  But really, I’m just getting started.

  Phase 4 : Collecting A Song Corpus
  Then there is the matter of staging a collection of songs for a given system. It seems like it would just be a matter of finding a large collection of songs for a given format, downloading them in bulk, and mirroring them. Honestly, that’s the easy part. People who are interested in this stuff have been lovingly curating massive collections of these songs for years (see SNESmusic.org for one of the best examples, and they also host a torrent of all their music for really quick and easy hoarding).
  
  In my drive to make this game music website more useful for normal people, the goal is to extract as much metadata as possible to make searching better, and to package the data so that it’s as convenient as possible for users. Whenever I seek to add a new format to the collection, this is the phase where I invariably find that I have to fundamentally modify some of the assumptions I originally made in the player.

  First, there were the NES Sound Format (NSF) files, the original format I wanted to play. These are files that have any number of songs packed into a single file. Playback libraries expose APIs to jump to individual tracks. So the player was designed around that. Game Boy GBS files also fall into this category but present a different challenge vis-à-vis metadata, addressed in the next phase.

  Then, there were the SPC files. Each SPC file is its own song and multiple SPC files are commonly bundled as RAR files. Not wanting to deal with RAR, or any format where I interacted with a general compression API to pull a few files out, I created a custom resource format (inspired by so many I have studied and documented) and compressed it with a simpler compression API. I also had to modify some of the player’s assumptions to deal with this archive format. Genesis VGMs, bundled either in .zip or .7z, followed the same model as SPC in RAR.

  Then it was suggested that I attempt to bring SaltyGME closer to feature parity with Chipamp, rather than just being a Chrome browser frontend for Game Music Emu. When I studied the Portable Sound Format (PSF), I realized it didn’t fit into the player model I already had. PSF uses a sort of shared library model for code execution and I developed another resource archive format to cope with it. So that covers quite a few formats.

  One more architecture challenge arose when I started to study one of the prevailing metadata formats, explained in the next phase.

  Phase 5 : Metadata
  Finally, for the collections to really be useful, I need to harvest that juicy metadata for search and presentation.

  I have created a series of programs and scripts to scrape metadata out of these music files and store it all in a database that drives the website and search engine. I recognize that it’s no good to have a large corpus of songs with minimal metadata and while importing bulk quantities of music, the scripts harshly reject songs that have too little metadata.

  Again, challenges abound. One of the biggest challenges I’m facing is the peculiar quasi-freeform metadata format that emerged as .m3u that takes a form similar to :

  #################################################################
  #
  # GRADIUS2
  # (c) KONAMI  by Furukawa Motoaki, IKACHAN
  #
  #################################################################
  nemesis2.kss::KSS,62,[Nemesis2] (Opening),2:23,,0
  
  nemesis2.kss::KSS,61,[Nemesis2] (Start),7,,0
  
  nemesis2.kss::KSS,43,[Nemesis2] (Air Battle),34,0-
  
  nemesis2.kss::KSS,44,[Nemesis2] (1st. BGM),51,0-
  
  [...]
  

  A lot of file formats (including Game Boy GBS mentioned earlier) store their metadata separately using this format. I have some ideas about tools I can use to help me process this data but I’m pretty sure each one will require some manual intervention.

  As alluded to in phase 4, .m3u presents another architectural challenge : Notice the second field in the CSV .m3u data. That’s a track number. A player can’t expect every track in a bundled chiptune file to be valid, nor to be in any particular order. Thus, I needed to alter the architecture once more to take this into account. However, instead of modifying the SaltyGME player, I simply extended the metadata database to include a playback order which, by default, is the same as the track order but can also accommodate this new issue. This also has the bonus of providing a facility to exclude playback of certain tracks. This comes in handy for many PSF archives which tend to include files that only provide support for other files and aren’t meant to be played on their own.

  Bright Side
  The reward for all of this effort is that the data lands in a proper database in the end. None of it goes back into the chiptune files themselves. This makes further modification easier as all of the data that is indexed and presented on the site comes from the database. Somewhere down the road, I should probably create an API for accessing this metadata.