Software companies
Sharing data licensing revenue with customers: a model for vertical SaaS
By SourceX Editorial · Reviewed by Noah Loul ·
Short answer
A vertical SaaS company can share data licensing revenue with customers through an opt-in program: each customer signs a separate consent, its records are de-identified and pooled, and a published formula divides net license revenue among contributors. The rule that matters most is simple: no customer's records enter a dataset without that customer's signed opt-in.
Key takeaways
- An opt-in revenue share turns customer records into contributed records, a stronger rights position than relying on silent contract clauses.
- The program rests on four parts: consent, de-identification, a share formula and reporting.
- Consent belongs in a separate addendum signed by an authorized person, not in updated terms of service.
- Formulas weighted by records that pass preparation reward quality instead of raw volume.
- Declining must cost a customer nothing in product access, pricing or support.
Why offer customers a share instead of relying on contract rights?#
Offering customers a share gives a vertical SaaS company explicit permission for records it may otherwise have no clear right to license. In many SaaS relationships the vendor processes customer records on the customer's behalf, and the master agreement or data processing addendum limits use to providing the service.
Even where an aggregated or anonymized data clause exists, it may not stretch to licensing records to an AI developer, and stretching it puts at risk the trust that vertical software depends on. Customers in a niche market talk to each other. A program they chose to join is far easier to defend than one they discover later.
A revenue share also changes what a dataset can contain. With consent, the vendor can include richer customer-generated content, such as job notes or case histories, rather than only usage counts and event logs.
The four parts of an opt-in data program#
An opt-in data program has four parts, and each needs a written decision before the first customer is invited: consent, de-identification, the share formula and reporting. Skipping any one of them tends to surface later as a dispute with a contributor.
| Part | What it decides | Where it is recorded |
|---|---|---|
| Consent | Which customers, record types and uses are included | Signed opt-in addendum for each customer |
| De-identification | What is removed before records leave the platform | Preparation standard and privacy record |
| Share formula | How net license revenue is divided among contributors | Program terms published to all participants |
| Reporting | What each contributor sees and when | Contributor statements and audit terms |
How should customer consent be structured?#
Customer consent should be a standalone opt-in addendum, signed by someone with authority to bind the customer, that names the record types, the permitted uses and the exit terms. A click-through update to terms of service is weak evidence that a customer agreed to have its records licensed.
The end-user point is easy to miss. Your customer is often the party that collected personal information from its own clients or staff, so it may need to update its notices before contributing, even though records are de-identified before release. A short notice template customers can adapt, plus a plain description of what preparation removes, takes most of the friction out.
- Scope: which record types are included, such as work orders, support conversations or scheduling history, and which never are.
- Permitted use: training, evaluation or both, and whether buyers may build commercial products.
- Withdrawal: how a customer leaves, and that withdrawal applies to future datasets rather than records already delivered.
- End-user notice: who updates notices to the customer's own clients or staff, and with what wording.
- Confidentiality: buyers never receive contributor names, and the contributor list stays private.
- Representations: the customer confirms it may contribute records about its own clients.
What de-identification has to happen before records are pooled?#
De-identification for a pooled program removes three layers before records leave the platform: the contributing customer's identity, the personal information of that customer's clients and staff, and free-text details that could re-identify either. Pooling helps, but it does not replace removal.
Vertical markets are small. A customer may be recognizable from its region, its unusual service mix or a distinctive naming convention in job codes, even with its name removed. Generalize locations, normalize internal codes and check whether any single contributor dominates a slice of the dataset.
Automated detection is a starting point, not a finish line. The documentation for Presidio, a widely used open-source detection tool, warns that automated detection cannot guarantee it finds all sensitive information and that additional protections should be used. Pair scanning with human review of samples from each contributor.
Which share formula fits your program?#
The right share formula is one that customers can verify from their own statements. Most programs choose among a handful of structures, and each rewards a different kind of contribution.
| Formula | How it works | Fits when | Watch for |
|---|---|---|---|
| Pro rata by volume | Share follows the count of records contributed | Record quality is similar across customers | Rewards bulk over usefulness |
| Weighted by usable records | Share follows records that pass preparation and are delivered | Quality varies widely between customers | Customers need to see why records were dropped |
| Equal participation share | Every participant receives the same portion | Contributions are broadly similar and the pool is small | Large contributors may feel underpaid |
| Subscription credits | Share is applied against future invoices | Customers prefer lower software costs to cash | Accounting and tax treatment of credits |
| Hybrid | A base participation share plus a weighted component | The program wants broad sign-up and quality | More complex statements |
What reporting do contributing customers expect?#
Contributing customers expect a periodic statement that shows what was licensed, under what terms and how their share was calculated. Define net revenue first, including which costs come off the top, such as preparation, delivery and transaction fees, so every contributor reads the same number the same way.
- Datasets released in the period that included the customer's records.
- The buyer category and permitted use, without naming the buyer unless the contract allows it.
- Records contributed, records delivered after preparation and the reasons for exclusions.
- Gross license revenue, deductions and net revenue for the pool.
- The customer's share under the published formula.
- Any withdrawals, disputes or changes to program terms.
Illustrative: a landscaping software company's contributor program#
Illustrative: a fictional vertical SaaS company sells scheduling, estimating and crew management software to commercial landscaping firms. An AI developer is interested in job records that connect site visits, estimates, crew assignments and completion notes.
The company's customer agreement treats job records as customer data, so the CEO launches an opt-in program instead of relying on the contract. Customers sign a one-page addendum covering job and estimate records only, with client names, addresses and crew names removed. The formula pays a base participation share plus a portion weighted by records that pass preparation, with the option to take it as subscription credit.
Many owner-operated customers join. Some enterprise customers decline because their own procurement policies bar contributing data, and nothing changes in their service. The first statement shows each contributor its delivered record count and its share, and the program terms stay fixed for the next dataset.
How SourceX fits a customer contribution program#
SourceX treats the SaaS company as the supplier and runs each license through the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. In the Rights step, every customer whose records are included must have a signed opt-in that covers the buyer's permitted use.
The SourceX Evidence Packet records provenance, licensing rights, permitted use, the privacy record and release authorization, which gives the SaaS company one document to support its contributor statements. How the customer share is calculated and paid stays governed by the program terms the SaaS company sets with its customers.
Frequently asked questions
Do customers who decline lose anything?
They should not. Declining must not affect product access, pricing, support or roadmap priority, and the program terms should say so. Tying participation to features or discounts on the core subscription can make consent look coerced, which weakens the rights position the program exists to create.
What happens when a contributing customer churns?
Settle this in the addendum. One workable approach: records already delivered stay under the existing license, the customer's records are excluded from future datasets, and shares from earlier datasets continue to be reported and paid under the original terms. Write it down before anyone churns.
Should the share be paid in cash or credits?
Either can work. Cash is simple to understand, while credits keep the benefit inside the software relationship and can be easier for customers to approve internally. Credits and cash may be treated differently for accounting and tax purposes on both sides, so check with your advisers before you choose.
Does a revenue share make customers co-licensors?
Not automatically. The structure depends on whether customers grant rights to the vendor, which then licenses to buyers, or license directly alongside the vendor. A single licensor is simpler for buyers, who then sign one agreement, but the choice is a contract design question for counsel.
Can we start with only one record type?
Yes, and that is usually wiser. Start with a record type customers understand, such as completed work orders, prove the consent, preparation and reporting steps, then offer more record types through an amended addendum that customers sign separately.
Sources
- Presidio's documentation warns that because it uses automated detection mechanisms, there is no guarantee it will find all sensitive information, so additional systems and protections should be employed. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.