What Data Can Estimate Willingness to Pay?

What Data Can Estimate Willingness to Pay?

A company can estimate willingness to pay from transaction history, responses to past prices, searches, clicks, cart behavior, location, device context, account attributes, purchased data, and inferences built from those signals. The estimate is not a fact about a person. It is a prediction for a particular offer under particular conditions.

The critical evidence question is whether a data category could support an estimate or whether it actually entered a named seller's decision. Those are different claims.

Willingness to pay is latent

Willingness to pay is the highest amount a person would accept for an offer at a given time. It cannot be observed directly. A purchase shows that the person's willingness to pay was at least the accepted price. A refusal shows that it may have been lower, but the refusal could also reflect timing, budget, product fit, trust, or distraction.

Sellers learn by observing choices across prices and contexts. A randomized price experiment can provide stronger evidence than a simple correlation because it varies the offer while attempting to hold other factors constant.

Jean-Pierre Dubé and Sanjog Misra's Personalized Pricing and Consumer Welfare used randomized field experiments to estimate a demand model and validate personalized prices in one large digital firm. The method shows how experimental variation can inform an estimate. The findings are specific to that setting and do not establish the effect of every personalized-pricing system.

Seven useful data families

The FTC's initial surveillance-pricing findings reported that the intermediaries it examined could use direct consumer data, inferred data, and first-party or third-party sources. The agency described examples including precise location, browser history, shopping history, time, channel, unpurchased cart items, and mouse movements.

The FTC's Issue Spotlight places data brokers and other intermediaries inside the larger system. A retailer does not have to collect every signal itself. It may receive a segment, score, recommendation, or tool from another company.

Raw data does not set the price

A usable pricing system needs several transformations.

flowchart LR
    A["Events and records"] --> B["Identity resolution"]
    B --> C["Features and inferences"]
    C --> D["Experiment or decision rule"]
    D --> E["Price, discount, rank, or fee"]
    E --> F["Outcome and feedback"]

Identity resolution links records to an account, device, household, or segment. Feature engineering converts raw activity into inputs such as purchase frequency, discount response, or time since a visit. A model or rule estimates an outcome. A treatment system selects a price, discount, product rank, or message. The result becomes new feedback.

Each stage can introduce error. Two devices may belong to one person. One household may contain people with different needs. A move may make location data stale. A cart may be abandoned because a child interrupted the session rather than because the price was too high.

The more specific the inference, the stronger the need for a correction path.

Correlation can become a proxy

A model does not need a field named income, race, disability, or urgency to reproduce differences associated with those traits. ZIP code, home value, purchase mix, work schedule, language, device patterns, and browsing activity can correlate with sensitive or protected characteristics.

That does not prove discriminatory intent or a legal violation. It means that feature review cannot stop at field names. A product team needs to test the relationship between inputs, predictions, treatments, and outcomes for affected groups.

The NIST AI Risk Management Framework is voluntary and does not decide pricing legality. Its Govern, Map, Measure, and Manage functions support the operational work needed here: define context, assign responsibility, document data and risks, test before and during use, measure impacts, and respond to failures.

NIST's Privacy Framework adds a data-processing view. It encourages organizations to understand their ecosystem roles, current practices, desired outcomes, and requirements across service providers. That matters when a seller receives a score from an intermediary but cannot explain the underlying data.

Experiments can estimate response without identifying motive

Pricing experiments are useful, but they are easy to describe too broadly.

A test can assign different prices or discounts to comparable groups and measure conversion. It can estimate an average response or support a demand model. It does not reveal why each participant acted. It may also interact with product ranking, fees, availability, delivery windows, or promotion language.

An experiment record should preserve the eligibility population, randomization unit, assignment time, treatment, control, product definition, total price, exclusions, outcome window, stopping rule, and analysis plan. If identity or segment data later changes the assignment, that should be visible in the record.

Without these details, a company may know that one treatment converted better but not whether it found willingness to pay, exploited friction, changed product visibility, or reached a different population.

How to move from possible to documented

The evidence ladder begins with capability. An official study or vendor document may show that a data source or feature can inform pricing. That is enough to discuss the market, but not to attribute a practice to a client.

Observed price differences are the next level. They establish an outcome worth investigating. A strong comparison holds product, quantity, time, location, inventory, delivery, membership, taxes, fees, and account benefits constant.

System evidence is stronger. Logs, specifications, model cards, data dictionaries, experiment assignments, API responses, contracts, disclosures, or discovery records can connect the input to the treatment.

An audit should then reconstruct one decision and review the distribution. A system can explain one quote while still producing an unacceptable pattern across customers.

The minimum questions for a vendor

A buyer of pricing technology should be able to obtain a plain account of the data received, the data derived, the identity method, the prediction target, the treatment options, the experiment logic, the price owner, the records retained, and the correction process.

If a vendor says its model is proprietary, that may limit disclosure of source code or weights. It does not remove the operator's need to know what categories of data enter the system, what decision it supports, how outcomes are tested, and how a person can challenge an error.

The same standard helps consumers and journalists. Ask what changed, what stayed constant, what the system knew, what it inferred, and what record could prove the connection.

[[What Is Surveillance Pricing]] provides the canonical terminology. [[When Is Variable Pricing Fair]] turns the evidence into a governance review. For a grocery-specific example of what an outside comparison can and cannot establish, read E099's [[Algorithmic Grocery Pricing - What Shoppers Can and Cannot See|Algorithmic Grocery Pricing: What Shoppers Can and Cannot See]].

This explainer was developed from FTC, economic, NIST, and preserved episode sources. AI assistance was used for research organization, drafting, and validation. The evidence map was last reviewed on July 27, 2026.