Using Affiliate.com Pricing Fields to Structure Deal and Offer Logic

Affiliate.com pricing fields are the structured values that help teams decide whether a product belongs in a deal module, offer comparison, sale page, product card, or shopping assistant result. For existing API users, the work is not simply finding discounted products. The work is defining the rules that separate a useful offer from a noisy one.

Affiliate.com normalizes product data across more than 30 networks, tens of thousands of merchant programs, and over a billion products, with searchable fields for currency, regular price, final price, sale price, sale discount, on sale status, availability, merchant, network, brand, barcode, SKU, MPN, and ASIN. That field structure lets teams build deal logic with rules instead of manual review.

Why pricing fields need structure

A “deal” is not a field. It is a decision.

One team may define a deal as any product marked on sale. Another may require at least 25 percent off, in stock, in USD, from a selected merchant list, with deduplication on for clean browsing. A comparison product may need the opposite logic, with deduplication off so users can see multiple merchant offers for the same barcode matched item.

Affiliate.com gives teams the raw ingredients for those decisions. The important part is choosing which pricing field should drive each experience.

The core pricing fields and when to use them

Regular price

Regular price is the reference point. It is useful when you need to understand the baseline from which a discount is being presented.

Use regular price when the experience needs context, such as “was” pricing, markdown review, or discount validation. Do not treat it as the customer’s expected checkout price without checking the live result context.

Final price

Final price is usually the most important field for offer ranking because it reflects the current product price after available markdowns in the product record. It is the right field when the user cares about what an item costs in the comparison moment.

Use final price for:

1. Best offer sorting
2. Price ceiling filters
3. Comparison Sets
4. Budget based discovery
5. Offer ranking across merchants

Affiliate.com’s prior product guidance distinguishes regular price, final price, and discount so teams can compare offers with more precision than title matching or merchant level browsing would allow.

Sale price and sale discount

Sale price and sale discount help teams structure promotional logic. Sale price gives the marked down amount, while sale discount helps qualify the depth of the offer.

Use sale discount when the editorial promise is savings based. A page called “Deals under $100” should probably rank by final price. A page called “Biggest markdowns on running shoes” should probably filter or sort by sale discount.

Currency and ship price

Currency is not a display detail. It is part of the commercial rule.

A result set that mixes USD, GBP, EUR, and CAD without intent can distort comparisons. Use currency filters early when building country specific experiences, regional sale pages, or cross currency workflows. Ship price can add useful context when available, especially for offer review, but avoid implying a guaranteed total cost unless the live UI confirms the current data.

A practical deal logic workflow

Imagine an API customer building a seasonal sale module for outdoor jackets. The first query starts broad because the merchandising team wants to see the market.

Start with:

1. Any contains “outdoor jacket”
2. Currency equals USD
3. In Stock equals true
4. On Sale equals true

Then layer commercial rules:

1. Brand equals Patagonia, Columbia, The North Face, or Marmot
2. Sale Discount is greater than 20 percent
3. Final Price is less than 250
4. Merchant ID is limited to selected retailers
5. Network ID is limited to selected network sources
6. Sort by Sale Discount or Final Price
7. Deduplication is on for a clean product grid

This query is not just narrower. It is more honest. The team has moved from “show me sale jackets” to “show in stock jackets, in the right currency, from intended sources, with meaningful markdowns, suitable for this page.”

Where identifiers improve offer logic

Pricing fields tell you what the offer looks like. Identifiers help verify what the product is.

That distinction matters in comparison workflows. Two jackets may have similar names, similar images, and similar prices, but differ by model, size, bundle, generation, or merchant specific listing. When exact product matching matters, use structured identifiers such as barcode, SKU, MPN, or ASIN instead of relying on product title alone.

Affiliate.com’s knowledge base shows barcode matching being used to identify the same product across merchants, even when product titles differ. That is what allows teams to compare merchant offers around the same underlying item, rather than comparing lookalikes.

Deduplication changes the meaning of a pricing result

Deduplication should follow the user experience.

Turn deduplication on when the goal is discovery. A shopper browsing “best discounted coffee makers” does not need five repeated listings for the same product before seeing variety.

Turn deduplication off when the goal is offer comparison. If the same barcode matched product is sold by multiple merchants, showing those merchant level offers can help users compare final price, discount, availability, and source.

This is where pricing logic and product identity meet. Deduplication controls whether the result set behaves like a product catalog or an offer table.

Decision criteria for deal and offer queries

Before saving a pricing query, decide what the query is meant to optimize.

Use final price when

1. The user has a budget
2. The page ranks affordable options
3. The experience compares merchant offers
4. The query needs a price ceiling or floor

Use sale discount when

1. The editorial angle is markdown depth
2. The experience highlights savings
3. The team wants to suppress shallow discounts
4. The result set should prioritize promotional intensity

Use on sale when

1. The first pass needs to separate sale from non sale products
2. The team plans to refine with discount thresholds later
3. The module is a general sale surface

Use currency when

1. The experience is regional
2. The comparison must stay within one market
3. The page should not mix monetary contexts
4. Cross currency review is intentional rather than accidental

A simple review checklist

Before a pricing query moves into production, review it in the Query Builder.

1. Is the query using final price, sale price, or sale discount for the correct reason?
2. Is currency filtered before price comparisons are made?
3. Is availability or in stock included when unavailable products should be excluded?
4. Are merchant and network filters aligned with the intended source set?
5. Is brand filtering needed to avoid broad category noise?
6. Is barcode, MPN, SKU, or ASIN needed for exact product matching?
7. Is deduplication set for discovery or offer comparison?
8. Has the result set been checked in the live UI before publishing?

The strongest pricing queries are not the most complex. They are the ones where every field has a job.

The operating principle

Pricing fields should not be treated as labels that decorate a product card. They are decision fields that structure what gets retrieved, ranked, compared, and published.

Use Affiliate.com’s Query Builder to test one existing deal query with three variants: sort by final price, filter by sale discount, and toggle deduplication on and off. Then inspect how the result set changes. That exercise will usually reveal whether the experience is built for bargain discovery, exact product comparison, or a cleaner offer review workflow.