Two employees put the same pouch in their baskets. One owes less. Before calling it personalized pricing, the buyer needs to know which number changed. Did the seller quote a different price, did the employee earn a published discount, or did the employer pay part of the bill? All three can produce different checkout totals. They call for different explanations, and a screenshot of the last screen cannot distinguish them.
What the October order actually asks for
On October 28, 2026, the US Federal Trade Commission announced information orders to nine companies covering airlines, ride services, delivery and retail. The study concerns how personal information may affect prices offered to consumers and compensation offered to workers. The commissioners voted to issue orders; they did not vote that the recipients had broken the law. Nor is the announcement an order directed to every business that operates an employee merchandise store.
The study design matters more to a procurement team than the list of recipients. The published model order asks about methods, inputs and disclosures. Its general records window runs from January 1, 2023 through full compliance unless a specification directs otherwise. The response clock is different: recipients have 45 days from receipt. Neither date tells a reader how often anyone paid more. The public document is a request for evidence, not a dataset of completed transactions.
Two tests before changing a store policy
Consider a hypothetical loyalty store. Both test accounts see a $40 list price for the pouch, but a posted member tier provides a $4 discount. Compare accounts side by side at the same time, for the same variant, destination, currency and delivery speed. Capture the price before discount, tier adjustment, shipping, tax and final amount separately. If both accounts enter the same tier and the difference disappears, that supports the tier explanation in this test. It does not rule out a separate pricing model in another channel. If the difference persists, the pricing owner needs the rule version and the inputs actually evaluated, not a promise that the published policy is correct.
Now consider a different hypothetical: an employer funds the entire gift and the recipient sees no cash price. Compare the supplier’s merchandise charge on the employer invoice with the recipient’s entitlement and any optional top-up. The invoice can be identical even where two employees owe different amounts because different subsidies apply. Conversely, a checkout that reads zero tells finance nothing about what the merchant charged the employer. Ask the privacy lead which data reaches the pricing service, and test that changing a synthetic recipient’s browsing history alone cannot change the approved charge. Keep the discrepancy open if the team cannot reproduce or explain the result. No real customer transaction is implied by either example.
Build an evidence map before asking whether a price is personalized
A useful audit starts with a map of numbers, data and owners. “Checkout price” is too broad to be a field name. For every test order, record the supplier’s base merchandise charge, catalog or contract adjustment, member or audience discount, employer subsidy, optional upgrade, delivery charge, tax and final amount shown to the recipient. Put the source system and calculation owner beside each line. A difference that begins in the subsidy ledger should not be investigated as though the merchant changed its base price.
| Question | Evidence to retain | Primary owner | What the evidence cannot prove alone |
|---|---|---|---|
| Did the supplier’s unit price change? | time-stamped quote, SKU and variant, contract version, currency | procurement and pricing | why the rule changed |
| Did eligibility change the recipient’s share? | audience rule, tier, entitlement and effective date | program owner | that the supplier personalized a price |
| Did personal data enter a decision? | field inventory, purpose, rule or model version, access log | privacy and engineering | legality or consumer expectation |
| Was the difference explained before commitment? | recipient-facing notice and test capture | legal, product and support | that every live path displayed it |
| Did fulfillment create the difference? | destination, delivery level, tax and duty calculation | operations and finance | that the merchandise price varied |
This map also prevents a common false positive. Two recipients may belong to different countries, select different delivery speeds, or incur different tax treatment. Those conditions can legitimately change the final amount without saying anything about a person’s inferred willingness to pay. The test is not “are totals always identical?” The test is “can the team explain each difference with an approved, disclosed input and reproduce it under controlled conditions?”
The inverse mistake is equally risky. A team may assume that a published member tier explains a difference even though the live decision also uses an unlisted signal. Matching the visible tier is therefore a starting control, not a complete answer. Retain the actual rule or configuration version that ran. If an outside platform makes the decision and does not expose that evidence, record the limitation and decide whether the feature should remain enabled. A vendor assurance is not a substitute for a reproducible test.
Read the FTC action as an information request, not a finished rule
The October inquiry sits beside, but is not the same as, the FTC’s August 2026 proposal. In August, the agency sought comment on a proposed enforcement policy statement concerning undisclosed use of personal information to set an individualized price. The FTC’s August release expressly described a proposal and invited public comment. A proposal, a study order and a final enforcement action are three different procedural objects. A company-store team should label each one accurately in its risk register.
The October Section 6(b) orders ask specified recipients to provide information. The FTC says this authority supports broad studies that do not have a specific law-enforcement purpose. That statement is important because a study can reveal practices without alleging a violation against every recipient. The public announcement identifies the agency’s questions and the nine recipients; it does not publish their responses, validate a particular pricing model or calculate consumer harm. As of the source cutoff used for this edition, the checked public materials did not contain later findings from these orders. Absence of a published result is not proof that responses, private discussions or later work do not exist.
For a buyer, the practical lesson is documentation. The model order’s focus on inputs, tools, procedures, testing and disclosures suggests the kind of record that makes a pricing explanation testable. That does not make the model order a compliance checklist for an unrelated company store. It offers a disciplined set of questions: Which data entered the process? Which rule or model transformed it? Which human or system approved the output? What did the buyer see before acting? What monitoring caught an unexpected result?
A risk note should therefore separate four columns: verified event, attributed regulator view, internal analysis and unknown. The verified event is that the FTC announced orders on October 28. The attributed view is what the FTC says it wants to scrutinize. The analysis is that company-store buyers can use similar evidence categories in their own controls. The unknowns include the recipients’ actual practices, their responses and any eventual conclusions. Keeping those columns separate is more valuable than turning a new inquiry into a dramatic but unsupported headline.
Decide which data is allowed to influence which number
Once the team can reproduce the difference, it should ask whether the input belongs in that decision at all. Delivery postal code may be necessary to calculate shipping. It does not follow that the same field should help predict willingness to pay. A department code may determine an employer subsidy. It does not automatically justify changing the supplier’s merchandise price. Purchase history may help a recipient find a relevant product, but recommendation and pricing are different purposes.
Create an input register with four fields for every item: source, intended purpose, decision affected and retention period. Add a fifth field for the owner who can stop its use. The register should distinguish information supplied by the person, information created by the program and information inferred from behavior. “Customer data” is not precise enough. The difference between a declared delivery address and an inferred urgency score matters when explaining a price.
Then run a necessity test. If a price or subsidy can be administered with a fixed audience rule, ask why a behavioral signal is needed. If it is needed, define the benefit and the failure condition before launch. Do not accept “the model improves conversion” without a measured test, a stable comparison and a decision about which tradeoffs are acceptable. A higher order rate can coexist with confusing or unfair experiences. This article does not claim that any particular signal is prohibited; it asks the buyer to make the choice visible and reviewable.
Access should follow the same boundary. Procurement may need the contract price but not raw browsing history. Recipient support may need the explanation displayed at checkout but not the model features behind it. Finance may need the subsidy and invoice, not a behavioral profile. Engineering may operate the rule while legal and privacy review its stated purpose. Limiting access reduces the chance that a field collected for delivery quietly becomes a general-purpose input.
Finally, set an expiration rule. Campaign audiences, loyalty tiers and employer benefits change. A person who qualified last quarter may not qualify now; a data field justified for one pilot may not belong in the permanent program. Record the effective date of each rule, the last review, the next review and the treatment of old records. “We have always used it” is not evidence of a current decision.
Test the path as a buyer, a recipient and an operator
A good test suite uses controlled accounts and one-variable changes. Begin with a baseline account. Freeze product, variant, quantity, timestamp window, currency, destination, delivery method, tax status and device state. Record the full price breakdown. Clone the account, then change one approved factor such as a published membership tier. If the amount changes, the team should be able to point to the exact rule and notice. If it does not, that is also evidence about the tested path.
Next, test a factor that should not affect the merchandise price. Change a synthetic browsing history while holding approved pricing inputs constant. Change device type or referral path. Change a non-price preference. The expected result must be written before the test. If an unexpected difference appears, do not keep clicking until it disappears. Preserve the first result, the request context, the rule version and any available decision log. Repetition without a fixed protocol can erase the conditions needed to diagnose the problem.
Run the same exercise from three viewpoints. The buyer view asks whether contract, campaign and catalog rules match. The recipient view asks what was visible before selection and payment. The operator view asks which services and data produced the result. These perspectives will not always show the same number. The point is to reconcile them, not to force a single screenshot to carry the entire explanation.
Include negative and failure cases. What happens when the audience file is stale, a recipient belongs to two tiers, a subsidy runs out, a price service times out or a tax calculation arrives late? Define whether the store stops, falls back to a fixed price or allows an order that will be reconciled later. Silent fallback is especially difficult to investigate. The acceptance record should state which fallback was tested, what recipients saw and how support can identify affected orders.
Test geography and time deliberately. A price may change because a promotion expired between two captures or because one destination includes a different tax or delivery charge. Synchronize tests where possible and show components separately. For a multi-country gifting program, do not extrapolate a US test to Taiwan, Japan or Korea. Local data, price-display, consumer and employment questions require local review. The US inquiry can inform the evidence method without becoming a universal legal conclusion.
Put owners and stop conditions into the operating workflow
The program owner should own the business purpose, audience and recipient promise. Procurement should own contract pricing, catalog configuration and supplier evidence. Finance should own subsidies, charge allocation and reconciliation. Privacy or legal reviewers should determine the review needed for actual data use and notices. Engineering should identify the rule, model and logs that produced the outcome. Operations and recipient support should own exceptions, delivery effects and explanations. Naming these owners before a discrepancy avoids a meeting in which everyone can describe the issue but no one can stop it.
Use a five-stage workflow. First, classify the program: employee benefit, member purchase, customer reward or another purpose. Second, approve the audience, budget, permitted inputs and recipient explanation. Third, configure the catalog and pricing path, preserving version identifiers. Fourth, pilot with controlled accounts and reconcile the supplier charge, employer funding and recipient amount. Fifth, approve or reject release with the exact evidence packet. A later change to a pricing input, notice or material rule should trigger focused revalidation.
The stop condition should be concrete. Pause the affected path when the team cannot explain a material price divergence, when an unapproved input reaches the pricing decision, when the live notice does not match the rule, or when an uncertain system change prevents reliable reproduction. Pausing does not mean accusing a vendor or declaring a legal violation. It means preventing additional unexplained outcomes while the owners preserve evidence and decide what to do.
Recovery should also be prewritten. Freeze the rule version and affected time window. Identify potentially affected orders without expanding access beyond what is necessary. Move to an approved fixed-price or fixed-entitlement fallback if one exists. Correct the configuration, repeat the controlled tests and document the disposition of each exception. If recipients may have received an unclear or incorrect amount, route remediation through the authorized legal, finance and support owners. Do not improvise a public statement from a technical test result.
Release evidence should include the signed owner decision, the current audience and subsidy policy, the permitted-data register, test cases with expected and actual results, source dates, rule versions, screenshots or transaction extracts, exception disposition and next review date. Also confirm that no duplicate entitlement or unauthorized issuance occurred. An approval checkbox without the underlying version is weak evidence because the live logic may change while the label stays the same.
Compare three store designs without pretending there is one winner
A fixed-price catalog is easiest to explain: the supplier unit price remains the same for recipients under the same stated conditions. It limits personalization and may sacrifice some merchandising flexibility, but it simplifies testing, support and reconciliation. It is a strong baseline when a team has little evidence about the behavior of a dynamic pricing component.
A fixed catalog with explicit employer entitlements separates the merchandise price from the recipient’s share. Departments or audiences may receive different budgets, yet the supplier price and the funding rule remain visible in separate records. This supports many employee and customer gifting programs without estimating each person’s willingness to pay. Its risk is operational: stale eligibility, overlapping tiers and confusing top-up messages can still produce unequal or unexpected outcomes.
An individualized pricing model changes a price using person-specific or inferred information. It may promise relevance or commercial optimization, but it requires the strongest explanation of inputs, purpose, disclosure, testing and monitoring. The August FTC proposal expresses an enforcement view about undisclosed use; it does not create a blanket statement that every personalized price is prohibited. A buyer considering this design needs an actual legal and privacy review tied to the precise practice, not a generic label.
The comparison is therefore about fit, not ranking. A recognition campaign with an employer-funded choice may need no consumer price at all. A public merchandise store may require clear unit prices and carefully separated promotions. A loyalty program may use an explicit tier that recipients understand. Teams should choose the least complex design that meets the program purpose and for which they can retain reliable evidence. Complexity without a distinct buyer benefit creates more failure paths than value.
Cost, choice, delay, data, control and evidence should be compared together. A fixed design can reduce data and testing cost but narrow optimization. An entitlement design can preserve recipient choice but add reconciliation. An individualized design can increase control granularity while moving important decisions into a less transparent service. No design should be accepted because it appears first in a vendor presentation, including a Giftpack option.
Keep measurement honest after launch
Do not use revenue or conversion alone as the acceptance test. Those measures can improve while explanations become less consistent. Track the rate of unexplained price differences found in controlled tests, the percentage of live pricing rules linked to a current owner and notice, the age of the oldest unresolved exception, and the percentage of recipient-support cases that can be reconciled to a rule version. These are operational measures, not proof of legal compliance.
Separate program outcomes from audit outcomes. Redemption, choice completion, delivery success and support volume describe the gifting experience. Price parity tests, notice coverage, data-input review and exception closure describe governance. A program can perform well on one set and poorly on the other. Combining them into one score hides the tradeoff.
Use samples deliberately. A handful of test accounts cannot prove that a complex model treats every recipient as expected. It can detect reproducible defects and confirm known rules. Define the sampled products, audiences, regions, devices and times. Record exclusions. If the supplier cannot provide population-level evidence, state that limitation instead of projecting a sample result across the program.
Review after material changes, not only on a calendar. A new price service, added data field, changed eligibility feed, revised disclosure, new country or new checkout flow can invalidate prior evidence. Quarterly review may still be useful, but the change trigger is what connects governance to the system recipients actually use. Preserve old results so the team can distinguish a new defect from a longstanding condition.
Where data is uncertain, use “unknown” as a valid result. The FTC inquiry does not provide outcome statistics for company stores. The hypothetical cases here do not establish customer results. Giftpack has not been identified as a recipient of the orders. Avoid converting uncertainty into an estimate simply to fill a report. A clear unknown with a named owner and next test is more actionable than an invented percentage.
What company-store buyers should do next
Start with one product, two controlled accounts and a line-by-line reconciliation. Confirm the supplier price, any published discount, the employer subsidy, delivery and tax. Identify every data field that can affect those lines and the owner who approved it. Compare what the rule did with what the recipient was told. If the difference is unexplained, pause the affected path, preserve the evidence and use an approved fallback while privacy, legal, finance, procurement and technical owners review it.
Then build the evidence packet that could survive staff turnover: source dates, program purpose, audience and entitlement policy, rule and model versions, permitted inputs, test conditions, expected and actual results, notices, exception decisions and the next review trigger. Keep FTC study facts separate from the company’s own analysis. Recheck the agency’s public materials before relying on this event in a later decision; an October 28 announcement is not a timeless summary of future findings.
Giftpack’s enterprise gifting information describes options for organizing audiences, gift choice and fulfillment. In a suitable program, those capabilities can support a fixed gift or clearly defined entitlement while the buyer retains responsibility for pricing, privacy, legal and employment decisions. Use a platform configuration only after the governing owners approve the actual inputs, recipient explanation and evidence path. Giftpack does not replace those decisions, and this analysis is not legal advice.