Software companies
Product usage analytics: can SaaS telemetry be licensed?
By SourceX Editorial · Reviewed by Noah Loul ·
Short answer
SaaS telemetry can sometimes be licensed, but product analytics data licensing depends on two things: the level of detail and the usage data clause in your customer contracts. Aggregated statistics are often within a vendor's reserved rights; customer-level and user-level event streams usually need express contract rights, privacy review and de-identification first.
Key takeaways
- Usage data rights depend on the level of detail: aggregate, customer-level or user-level.
- Many SaaS agreements reserve rights to aggregated usage data, but those clauses often limit use to running, improving or benchmarking the service.
- Free text captured by analytics, such as search queries and AI prompts, is customer content, not telemetry.
- De-identification lowers privacy risk but does not create contract rights that were never granted.
What counts as product usage data?#
Product usage data is the record of how people use a software product, captured by the product itself rather than typed in as content. It ranges from service metrics that say nothing about any customer to event streams detailed enough to reconstruct one person's working day.
The last two items in the list below deserve a flag. Session replays and free-text events capture what users saw and typed, which puts them closer to customer content than to telemetry, whatever the analytics tool calls them.
- Service telemetry: latency, error rates, crash reports and infrastructure metrics.
- Product events: page views, clicks, feature use and workflow steps, often sent through an event pipeline to tools such as Segment, Amplitude, Mixpanel or Pendo.
- API logs: which endpoints each account called, when and with what result.
- Session replays: recordings of screens and cursor movement.
- Free-text events: in-app search queries, form inputs and prompts sent to AI features.
The rights table: aggregate, customer-level and user-level data#
Usage data rights change with the level of detail, so the first step is to sort every analytics source by what one record describes. The table shows the usual pattern; your signed contracts may differ.
Most interest from AI developers sits in the middle rows, where sequences of real actions show how people complete tasks in software. That is also where rights are tightest, which is why telemetry is rarely the first record family a SaaS company licenses.
| Level | Example | Typical contract position | Privacy exposure | Licensing outlook |
|---|---|---|---|---|
| Aggregate across customers | Monthly feature adoption across all accounts | Often covered by an aggregated or usage data clause | Low if small groups are suppressed | Most practical, but of limited interest to AI developers |
| Customer-level | Event stream for one account's workspace | Usually customer data or confidential information | Reveals a customer's business activity | Needs express rights or customer permission |
| User-level | Click paths tied to a user ID | Customer data that is also personal information | High; laws such as the CCPA or GDPR may apply | Rarely licensable without consent and strong de-identification |
| Session replays | Recorded screens and cursor paths | Customer content captured on screen | Very high | Usually excluded |
| Free-text events | Search queries and AI prompts | Customer content | High | Treat as content, not telemetry |
Which contract clauses decide the answer?#
The contract clauses that decide whether telemetry can be licensed are spread across the master agreement, the data processing agreement and the privacy policy. Read them together, since a broad usage data clause in one document can be narrowed by a purpose limit in another.
Order forms and negotiated amendments can override all of this for a single customer. Enterprise accounts in particular often strike the usage data clause or add a no-secondary-use term, so check signed versions, not only the standard template.
| Clause | What to look for | Warning sign |
|---|---|---|
| Customer data definition | Whether usage data sits inside or outside the definition | Usage data defined as customer data |
| Usage or aggregated data clause | Permitted purposes and whether third-party sharing is allowed | Use limited to operating and improving the service |
| License to the vendor | Scope of the vendor's right to use customer data | Use only to provide the service |
| Confidentiality | Whether account activity counts as confidential information | Broad definitions covering all use of the service |
| Data processing agreement | Purpose limits and sub-processor rules | Processing only on documented instructions |
| Privacy policy | What end users were told about analytics | No mention of sharing or secondary use |
| Benchmarking clause | Whether outputs may be published or shared | Benchmarks limited to internal use |
| Analytics tool agreement | Your export rights and any rights the analytics vendor keeps in your event data | Events held only in a tool whose terms or export limits prevent a full copy |
Why AI developers look at usage records at all#
AI developers look at usage records because agents that operate software need examples of how people actually move through real interfaces to finish real tasks. A sequence of steps that ends in an approved invoice, a scheduled shift or a resolved alert shows a path an agent could learn to follow.
Raw clickstreams without that context are weak. A buyer needs the event schema, a definition of what each event means and a way to tell which sequences ended in success. Without that documentation, even a large event warehouse is hard to use, and the effort to produce it should be weighed before any rights work begins.
Developers also ask how events were collected. Changes to the tracking plan, renamed events and periods when an SDK silently dropped data all change what a sequence means, so a dated change log for the event schema belongs in any serious package.
De-identification is not a substitute for rights#
De-identification reduces privacy risk in usage data, but it does not create contract rights the customer never granted. An event stream stripped of user IDs is still derived from one customer's account, and whether an aggregated data clause stretches to cover it is a question for counsel.
Usage data can also be easy to re-identify, because a distinctive path through a product can point to one user or one company. Measurement tools exist for this risk; Google's Sensitive Data Protection API, for example, offers re-identification risk metrics including k-anonymity, l-diversity, k-map estimation and delta-presence estimation. Running checks like these before any sample leaves the company is sound practice.
Typical controls for event data include suppressing groups below a set size, coarsening timestamps, dropping rare event types that act as fingerprints, and replacing account and user IDs with tokens that cannot be reversed outside the company. Each control trades some usefulness for privacy, so record the choices and the reasons behind them.
Illustrative: a construction scheduling vendor reviews its event data#
Illustrative: a fictional construction scheduling SaaS vendor streams product events into its data warehouse and uses a session replay tool for debugging. Its standard agreement lets it use aggregated, anonymized usage data to operate, improve and benchmark the service.
Counsel concludes that delivering event sequences to an outside developer for model training is not clearly within operating, improving or benchmarking the service, and finds that several enterprise customers struck the clause entirely. Session replays are ruled out because they show customers' project names and schedules on screen.
The company parks telemetry, moves ahead with its own support and engineering records instead, and drafts an opt-in usage data term for new contracts. If enough customers opt in, telemetry can be reconsidered later with clear rights in place.
How SourceX handles telemetry questions#
SourceX handles telemetry in the Rights step of the SourceX five-step transaction, before any preparation is planned. The review sorts each analytics source by level of detail and checks the signed contracts that govern it; telemetry without clear rights is excluded rather than reworked.
When a usage record family does proceed, the SourceX Evidence Packet records the permitted use, the contract basis, the de-identification method and the release authorization. Each case is assessed deal by deal with the supplier's counsel.
Frequently asked questions
Can we change our terms to allow licensing usage data?
Terms can change, but changes generally apply going forward and need clear notice. Retroactive changes that expand how existing data is used carry regulatory and customer-trust risk. Many companies prefer an opt-in term in new or renewed contracts over a quiet update to standard terms.
Do benchmarking clauses allow licensing to AI developers?
Usually not on their face. Benchmarking clauses typically let a vendor publish or use aggregate comparisons, such as industry averages, not deliver datasets to a third party. Read the exact wording, including any limit on sharing, before treating one as a basis for a license.
Is telemetry from a free or self-serve product treated differently?
It can be. Self-serve users accept click-through terms and a privacy policy rather than negotiated contracts, so what those documents said matters most, and consumer privacy laws are more likely to apply. Review those documents version by version, since each version governs the data collected while it was live.
Does aggregated data still count as personal information?
It depends on the law and the method. Data aggregated so that no person can reasonably be identified is often treated differently from personal information, but small groups or distinctive patterns can undo that. Counsel and a re-identification check should settle it for each dataset.
What about analytics on our own employees' use of internal tools?
That is employee data, governed by employee notices and workplace policies rather than customer contracts. It may be possible to include in limited form, but it needs its own review and usually stronger de-identification than customer telemetry.
Sources
- Google's Sensitive Data Protection API offers four re-identification risk-analysis metrics: k-anonymity, l-diversity, k-map estimation and delta-presence estimation. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.