How to research an Amazon product

Research an Amazon product by fixing its identity first: marketplace, ASIN and selected variant. Then read the listing and a bounded review sample against the question you need answered. A seller's product claim, a reviewer's experience and your agent's inference should remain visibly separate.

This is a research workflow for a product you supply. It does not claim that an example purchase, review analysis or paid call has already happened.

Give the agent the exact listing

A product name can cover several sizes, generations and bundles. Supply the product URL and explain what would make the item unsuitable for you. For a monitor, that might be a required port and a maximum desk depth; for a replacement part, it might be an exact compatible model.

After connecting Vaaya, paste:

Research [Amazon product URL] in [marketplace country].
Selected variant: [model, size, color, quantity or bundle].
I need to know [questions and required features].
Read the product details first, then only the reviews needed for those questions.
Keep seller claims, reviewer reports and your inferences separate.
Return source URLs, retrieval times, variant mismatches and missing evidence.
Stay within [total research budget]. Do not order anything.

Use the same criteria for every competing product. Otherwise, one detailed listing can appear stronger merely because the agent asked more questions about it.

Inspect the listing before buying more data

1. Confirm the route and inputs. Ask consult for apify/amazon-product for the supplied URL or ASIN. The current Vaaya schema requires an array named Params with that capitalization. Obtain the exact array-item shape from the current service instructions; do not guess it from another Apify actor's examples.

2. Check the returned identity. Match marketplace, ASIN, title and variant to the request. Record the seller and condition when present. Stop the comparison if the response resolves to a different bundle or generation. A successful HTTP response does not establish that the right product was retrieved.

3. Extract only decision-relevant fields. Capture the specifications and listing claims that answer the brief. Keep the supporting source for each consequential detail. A missing compatibility field should remain unknown, even when the product photograph looks similar to a compatible version.

4. Read a bounded review sample. If the details do not answer the user's question, apify/amazon-reviews accepts productUrls and an optional maxItems limit. Ask for the supported item shape and available filters before execution. Record how many reviews came back and whether their dates or variants are visible.

5. Return findings and open questions. Summarize recurring observations in the collected sample, link to the relevant evidence and list what needs a manufacturer or seller answer. Do not convert an isolated report into a claim about every unit of the product.

The Vaaya catalog supplies current action schemas and prices. Keep the quote and actual reported charge beside each retrieval so a larger comparison can reuse the first result rather than paying for it twice.

Use a product sheet and a review sheet

The product sheet should contain:

marketplace | asin | selected_variant | title | seller | condition
observed_price | currency | price_checked_at | source_url
required_feature | evidence | status_confirmed_or_unknown

Keep review observations in a separate table:

review_id_or_url | review_date | reported_variant | rating
question_addressed | observation | source_excerpt | limitation

A review from a previous model can still be useful background, but should not silently support a claim about the selected version. Deduplicate copied reviews and keep the raw sample available for a human read-through. Avoid unnecessary collection of reviewer profile details.

Resolve mismatches before ranking products

If the result is blocked, incomplete or missing reviews, return the limitation. Ask for another accessible source only when it could answer a stated question. Repeating identical calls without changing the source or input spends the budget without improving the brief.

When the same product has several offers, keep the offer comparison separate from product quality. Use the cross-store comparison workflow for seller, condition and delivery differences. Before a buying decision, open the current product page and confirm the selected variant, seller and final terms yourself.

Questions

Can the review sample prove the product is reliable?

No. It can identify reported experiences and questions to investigate. A retrieved sample may be incomplete, biased, duplicated or tied to multiple variants.

Is a listed price the final price I will pay?

Not necessarily. Seller, shipping, taxes, discounts, destination and selected variant can change the checkout amount. Recheck the current offer directly.

Do I need separate product and review calls?

Only if the detail response lacks the review evidence your question requires. Inspect the first response before buying another retrieval.