In May 2024, the U.S. Federal Trade Commission published a staff report titled "From Farms to Pharmacies to Flights" documenting how companies use consumer data and algorithmic systems to charge different people different prices for the same product. The report itself did not announce new rules. It announced something arguably more consequential: regulatory attention. By January 2025, enforcement actions and consent orders had followed, and the Commission made clear that while personalized pricing is not banned, companies that use customer data to influence pricing must be prepared to explain exactly when and how that happens.
For enterprise marketing operations leaders, the instinct may be to classify this as a commerce or pricing team concern. That instinct is wrong. The data that feeds personalized pricing, from behavioural signals to firmographic enrichment to engagement history, originates in and flows through marketing automation platforms, CRMs, and CDPs. If a downstream pricing algorithm uses a lead score, a segment membership flag, or a cookie-derived behavioural profile to adjust an offer, the marketing operations team is a participant in the pricing chain, whether or not anyone drew that line on an architecture diagram.
1. Historical context
Price discrimination has existed for as long as commerce itself. Airlines pioneered dynamic pricing in the 1980s with yield management systems that adjusted fares based on seat inventory and booking timing. Hotels followed. E-commerce platforms introduced A/B tested pricing pages in the early 2000s. None of this was new.
What changed was granularity. The explosion of first-party data collection, browser fingerprinting, and machine learning models capable of inferring willingness-to-pay from browsing patterns created conditions where price could be adjusted at the individual level, not the segment level. Amazon famously experimented with this in 2000, showing different users different prices for the same DVD. The backlash was swift, and Amazon called it a "price test" rather than price discrimination. But the capability never went away. It matured.
The regulatory response lagged. GDPR, enacted in 2018, focused on consent and data subject rights, not on the commercial outcomes those data practices enabled. The California Consumer Privacy Act (CCPA), effective January 2020, included provisions against discriminatory treatment of consumers who exercised privacy rights, but enforcement was slow. The FTC's 2024 report represents a different kind of regulatory posture: not a new statute, but a declaration that existing authority under Section 5 of the FTC Act (prohibiting unfair or deceptive practices) already covers personalized pricing that consumers cannot see or understand.
This matters for MarTech because the consent architectures built by most enterprise teams were designed to satisfy GDPR and CCPA requirements for data collection and communication preferences. They were not designed to account for how that data might be used in pricing logic three systems downstream. As we discussed in our analysis of how CDPs have entered their compliance era, the compliance surface area for customer data platforms has expanded beyond opt-in and opt-out into questions about what downstream processes consume the data those platforms manage.
"Surveillance pricing is a relatively new commercial practice, but it is rapidly growing... the Commission is committed to closely studying and scrutinizing this practice."
2. Technical analysis
The FTC's concern centers on opacity. When a consumer sees a price, they generally assume that price reflects supply, demand, and perhaps a promotional offer. Personalized pricing breaks that assumption by incorporating individual-level data (location, device type, purchase history, browsing behaviour, inferred income) into the price calculation. The consumer does not know this is happening, and has no way to compare the price they see with the price another consumer would see.
From a technical standpoint, the data pipeline that enables personalized pricing in a B2B or B2C enterprise typically works as follows:
Data collection layer
Marketing automation platforms (Oracle Eloqua, Adobe Marketo, Salesforce Marketing Cloud, HubSpot) collect behavioural data through web tracking scripts, email engagement metrics, form submissions, and event attendance records. CDPs aggregate this with transactional data from e-commerce systems, CRM records, and third-party enrichment providers. Visitor tagging and automated tracking implementations are the origin points for much of this data.
Signal processing layer
Lead scoring models, intent data overlays, and segment definitions translate raw behavioural data into structured signals. A prospect who has visited the pricing page three times, downloaded a comparison guide, and attended a product webinar receives a different score than one who opened a single email. These scores and segments are stored in the MAP or CDP and syndicated to downstream systems via API integrations or batch exports.
Pricing and offer logic layer
In B2C, this might be a dynamic pricing engine that adjusts displayed prices based on user attributes. In B2B, the equivalent is often less visible: a CPQ (configure-price-quote) system that suggests different discount tiers based on account-level data, or a sales enablement tool that surfaces different offer bundles based on a prospect's engagement history. The data flowing into these systems often originates in marketing automation.
The problem is that most enterprise teams have no documented lineage showing how data moves from the collection layer into the pricing layer. A data enrichment process that appends firmographic data to a contact record may seem innocuous when the enrichment is used for targeting. But if that same firmographic data (company revenue, employee count, industry vertical) feeds a pricing algorithm that charges larger companies more for the same product, the enrichment process becomes part of a personalized pricing chain.
This is not hypothetical. SaaS companies routinely adjust pricing by company size. The question the FTC is now asking is whether consumers (or business buyers, in some interpretations) are aware that this is happening and whether they have any ability to understand or contest it.
The consent gap
Most privacy compliance implementations focus on three areas: opt-in/opt-out for communications, cookie consent for tracking, and data subject access requests. None of these mechanisms currently address the question: "Is my data being used to determine the price I see?" The FTC's position suggests that this gap will need to close. Companies may need to disclose, at or before the point of pricing, whether and how personal data influenced the price.
For marketing operations teams, this means that the consent model must extend beyond communication preferences to cover data usage categories. A subscription center that lets a contact choose which emails they receive is necessary but insufficient if the same system's data feeds a pricing algorithm without disclosure.
3. Strategic implications
The FTC's attention to personalized pricing creates three distinct strategic pressures for enterprise marketing and revenue operations teams.
Data governance becomes cross-functional
Marketing operations teams have historically owned data quality, segmentation, and consent management within the marketing automation platform. Pricing was the domain of finance, product, or sales operations. The FTC's framework makes clear that data governance cannot stop at the boundary of the MAP. If marketing data feeds pricing logic, marketing operations must participate in the governance of that data flow. This requires new cross-functional processes and, in many organizations, new org chart relationships.
Consent architecture must expand its scope
As our earlier analysis of personalization without permission argued, consent is often treated as a checkbox exercise rather than a strategic capability. The FTC's personalized pricing notice makes this approach unsustainable. Consent must now cover not only "may we contact you" and "may we track you" but also "may we use your data to influence the commercial terms you see." This is a harder question to design into a user experience, but the regulatory direction is clear.
Data lineage becomes a compliance requirement
Most enterprise MarTech stacks lack end-to-end data lineage documentation. A contact record in Eloqua or Marketo may be enriched, scored, segmented, exported to a CRM, syndicated to a CDP, and consumed by a pricing engine, but no single system records that chain. If the FTC requires companies to explain how data influenced a specific price, organizations without data lineage will face an expensive and slow forensic exercise. Those with lineage will be able to respond with confidence.
Source: Consumer Reports nationally representative survey, September 2024
"Personal data is being used not just to target ads but to set prices, and consumers are largely in the dark about it."
4. Practical application
Enterprise marketing operations teams can take concrete steps now to prepare for the regulatory direction the FTC has signaled.
Audit data flows from MAP to pricing systems
Start by mapping every integration that moves data out of your marketing automation platform or CDP. For each integration, document what data fields are transferred, what systems consume them, and whether any of those systems influence pricing, discounting, or offer selection. This audit does not require new technology. It requires structured interviews with the teams that own downstream systems and a willingness to follow the data wherever it goes.
A platform maturity assessment can help identify which integrations are documented and governed and which are informal or legacy connections that no one has reviewed in years.
Extend your consent model to cover pricing data usage
Work with your legal and privacy teams to determine whether your current consent framework covers the use of customer data in pricing decisions. In most cases, it will not. Develop a data usage taxonomy that includes categories like "personalization of content," "personalization of offers," and "personalization of pricing." Map your existing data collection practices to these categories and identify gaps.
The technical implementation will vary by platform. In Oracle Eloqua, custom data objects and preference center configurations can capture granular consent preferences. In Adobe Marketo, custom fields and program-based consent tracking can achieve similar results. The design challenge is less about platform capability and more about defining the right consent categories and presenting them to users in a way that is clear without being overwhelming.
Build data lineage documentation
For every data field that could influence pricing (engagement score, segment membership, firmographic attributes, behavioural signals), document its origin, transformation steps, and downstream consumers. This documentation should live outside any single platform, in a shared data governance tool or even a well-maintained spreadsheet, and should be reviewed quarterly.
Organizations that have already invested in data management practices like data normalization and ETL solutions will find this easier. Those that have not should treat the FTC's notice as a forcing function to begin.
Establish a cross-functional pricing data governance committee
Create a recurring forum that includes marketing operations, sales operations, finance, product, and legal. The purpose is to review any changes to data flows, scoring models, or segmentation rules that could affect pricing logic. This committee should have authority to approve or block changes that introduce new data into pricing decisions without corresponding consent coverage.
Test your ability to explain a price
Pick a random customer or prospect. Can you explain, within 48 hours, what data was used to determine the price or offer they saw? If the answer is no, you have a compliance gap. Run this exercise quarterly until the answer is reliably yes.
5. Future scenarios
The FTC's current posture is disclosure-oriented, not prohibitive. But the trajectory of privacy regulation over the past decade has been consistently toward greater restriction. Several scenarios are plausible within the next 18 to 24 months.
Scenario 1: Mandatory pricing transparency disclosures
The most likely near-term outcome is a requirement, either through FTC rulemaking or consent decree precedent, that companies disclose when personalized pricing is in use. This would function similarly to cookie consent banners: a notice at the point of pricing that says, in effect, "The price you see may be influenced by data we have collected about you." Companies would need to provide an explanation upon request.
For enterprise B2B companies, this scenario would require CPQ systems to log the data inputs that influenced a quoted price and make that log available to the buyer. Marketing operations teams would need to ensure that the data flowing into CPQ systems is tagged with its provenance and consent status.
Scenario 2: Algorithmic impact assessments for pricing
The EU AI Act, which entered force in August 2024, requires high-risk AI systems to undergo conformity assessments. While pricing algorithms are not currently classified as high-risk under the Act, the precedent is set. The FTC could adopt a similar framework requiring companies to conduct and document algorithmic impact assessments for any system that uses personal data to influence pricing.
This would be a heavier compliance burden. Marketing operations teams would need to provide documentation of the data inputs, model logic, and fairness testing for any scoring or segmentation model whose outputs feed pricing systems. Organizations that have treated lead scoring as a marketing-internal optimization would need to reframe it as a regulated data process.
Scenario 3: Consumer data rights extended to pricing contexts
CCPA already gives California consumers the right to know what personal information a business has collected about them. A natural extension would be the right to know how that information influenced the prices they were charged. Several state privacy bills introduced in 2024 and 2025 include language moving in this direction.
If this scenario materializes, enterprises will need systems capable of generating price-explanation reports on demand, tied to individual data subjects. This is a significant technical challenge for organizations whose data stacks were not built with this kind of traceability in mind. The organizations best positioned will be those that have already invested in consent architecture and data lineage as described in the practical application section.
As we examined in the data trust crisis and operational neglect, the gap between data collection capabilities and data governance maturity has been widening for years. The FTC's personalized pricing notice may be the regulatory event that forces that gap to close.
6. Takeaways
- The FTC's personalized pricing notice is not a ban. It is a transparency mandate in formation. Companies that use customer data to influence pricing must be prepared to explain how.
- Marketing operations teams are implicated because the data that feeds pricing algorithms, including behavioural signals, engagement scores, firmographic attributes, and segment memberships, originates in marketing automation platforms and CDPs.
- Existing consent architectures were designed for communication preferences and cookie tracking. They do not cover the use of data in pricing decisions. This gap must close.
- Data lineage, the documented chain from data collection through transformation to downstream consumption, is the single most important capability for compliance readiness in this area.
- Cross-functional governance between marketing operations, sales operations, finance, and legal is required. Pricing data governance cannot be siloed.
- The regulatory trajectory points toward mandatory disclosure, algorithmic impact assessments, and expanded consumer data rights covering pricing contexts. The 18-to-24-month window to prepare is narrow.
- Organizations that treat this as a legal or compliance team problem, rather than an operations and architecture problem, will find themselves reactive when enforcement actions arrive.
