Updated at vs. Added at: Two Different Freshness Signals in Affiliate.com's Product Data

Updated at and Added at can look like interchangeable timestamps. They are not. For affiliate operators, the distinction matters because one can describe the age of a product record, while the other can describe how recently that record changed.

Affiliate.com normalizes product information from more than 30 affiliate networks, tens of thousands of merchant programs, and over a billion products into searchable fields spanning merchant, inventory, pricing, identifiers, attributes, and source metadata. The supplied knowledge base explicitly identifies Last Updated as a searchable field. It does not separately document Added at, so teams should confirm the exact field semantics in their API response or Query Builder before treating Added at as a guaranteed search control.

Updated at answers: How recently did this record change?

Updated at, represented in Affiliate.com documentation as Last Updated, is the more useful timestamp when the question is operational freshness.

A product may have existed in the dataset for months, yet its merchant supplied information can change repeatedly. Final price may move. A sale can begin. Availability can shift. A merchant can revise the title or description.

That makes Last Updated useful when evaluating records whose commercial details are volatile. Affiliate.com lists Last Updated alongside searchable product metadata, while pricing, availability, identifiers, merchants, networks, and attributes can be layered into the same retrieval workflow.

Consider a deal editor reviewing a branded appliance. The record itself may be old, but if its final price, sale discount, or availability was refreshed recently, the offer can still be operationally current.

The timestamp therefore answers a narrow question:

When was this product record most recently refreshed or changed?

It does not, by itself, tell you when Affiliate.com first encountered the product.

Added at answers a different question

Where an Affiliate.com response or downstream dataset exposes an Added at value, the useful interpretation is record age: when the product entered that dataset or workflow.

That distinction matters because novelty and freshness are different concepts. A newly added product can contain information that has never changed since ingestion. An older product can have very recent price or inventory updates.

Because Added at is not defined as a searchable field in the supplied knowledge base or the public Product API documentation reviewed for this article, do not build production logic around an assumed definition without validating the field in your own response schema.

The conceptual difference is simple:

1. Added at describes when a record became known to the system or dataset.
2. Updated at describes when that known record was subsequently refreshed or modified.

For research teams, those signals answer different questions. Added at can help identify newly observed assortment. Updated at can help evaluate the recency of information attached to an established product.

Freshness only becomes useful after product identity is controlled

Timestamp analysis becomes misleading when records are not normalized around product identity.

Suppose three merchants sell the same headphones under three different titles. One listing says the full model name. Another shortens it. A third adds promotional language. Looking only at timestamp values can make three merchant offers appear to be three distinct products.

Affiliate.com addresses that problem with normalized identifiers such as barcode, GTIN, UPC, MPN, SKU, and ASIN. Barcode matching is especially useful when you need to establish that two merchant listings refer to the same physical product despite inconsistent titles.

Only after identity is resolved should freshness enter the decision.

A practical freshness workflow

Imagine a product team monitoring offers for a specific running watch.

1. Start with the exact barcode when available. If you begin with an Amazon product, Affiliate.com also supports ASIN to barcode conversion for matching against other merchants.
2. Keep deduplication off when you want to inspect every merchant offer for that exact product.
3. Layer merchant or network filters if the workflow should consider only selected programs.
4. Filter to the required currency and availability state.
5. Compare regular price, final price, sale discount, and Last Updated across the matching offers.

The result is much more defensible than sorting a broad keyword search by timestamp. Identity is fixed first. Commercial conditions come second. Freshness becomes an additional decision variable rather than a substitute for product matching.

How product teams should use Updated at

Updated at is most valuable as a governance signal, not as an automatic ranking rule.

A recent timestamp does not prove that an offer is the best offer. It simply tells you something about recency. Price, discount, availability, currency, merchant eligibility, and product identity still determine whether the record fits the use case.

For a deal page, for example, you might require an exact barcode match, in stock status, USD currency, and a minimum sale discount. Then inspect Last Updated to understand whether the records supporting that comparison have been refreshed recently.

For a market research workflow, you might reverse the emphasis. Start with a broad Any search, narrow by brand and category, then use freshness metadata to examine which portions of the assortment appear to be changing most recently. Affiliate.com supports the broad to precise pattern through the Any field and layered filters.

Deduplication changes what freshness means

Deduplication deserves special attention because it changes the unit you are looking at.

With deduplication enabled, identical products can be consolidated so users see a cleaner product level result. With deduplication disabled, individual merchant offers remain visible, which is often preferable when comparing price, discount, availability, or freshness across sellers.

For freshness analysis, offer level visibility is frequently more informative. Two merchants can sell the same barcode while refreshing their records at different times.

The product is identical. The commercial evidence is not.

Treat freshness as one layer of product quality

The strongest affiliate product workflows do not ask whether a record is simply fresh. They ask whether it is the right product, from an eligible source, under the right commercial conditions, with sufficiently recent information.

That hierarchy keeps timestamp logic in its proper place.

Identity comes from normalized identifiers. Scope comes from merchant and network filters. Commercial context comes from regular price, final price, discount, currency, and availability. Deduplication controls whether you inspect a unified product or each merchant offer. Last Updated then helps you judge recency within that already controlled result set.

Use the Affiliate.com Query Builder to test this sequence visually, then move the validated query into the Product API when the workflow is ready for automation. Before publishing price or stock sensitive content, verify the current result in the live interface, since those fields can change as merchant and network data refreshes.