← Blog

How-to seriesSeptember 28, 2026

How to research products on TikTok Shop

Research a TikTok Shop listing by market and product identity, preserve variant-level evidence, and distinguish observed metrics from estimated sales.

A TikTok Shop research brief should identify the exact product, variant, seller and market before comparing prices or creator activity. Two listings with a similar title can describe different pack sizes, bundles or sellers.

Use Vaaya to gather a bounded set of listing evidence, then decide which products need deeper review. The output here is a research table; it does not buy products or contact creators.

Specify the product and market

Start with a listing URL or a narrow product description. Include the country, currency, desired variant and the business question. “Find examples of how this product is demonstrated” needs different data from “compare the current offer with other stores.”

Connect through the Vaaya setup guide and use this prompt:

Research [TikTok Shop listing or product] in [market], for [question].
Required variant: [size/pack/model]. Use Vaaya consult and discover to verify
current routes, market support and quotes. Budget: [amount].
Preserve product and seller IDs, listing URLs, variant details and timestamps.
Label metrics exactly as the source does. Keep unknown fields blank.
Return a comparison table with source links and missing checks.
Do not purchase, add to cart, message sellers or contact creators.

1. Find the current listing route

Ask vaaya/discover for TikTok Shop product search and detail operations. The current catalog lists these TikHub read endpoints:

Operation Endpoint Required endpoint input
Product search /api/v1/tiktok/shop/web/fetch_search_products_list_v2 search_word
Product detail /api/v1/tiktok/shop/web/fetch_product_detail_v3 product_id
Product reviews /api/v1/tiktok/shop/web/fetch_product_reviews_v2 product_id

Each is called through tikhub/fetch with endpoint plus the relevant fields. The social-data guide documents that routing pattern.

Required-field lists alone do not settle market selection, pagination or optional filters. Ask consult for the selected endpoint's accepted inputs and confirm market support before using its result. If you cannot establish the market, leave the comparison unresolved instead of assuming a default.

2. Resolve product, seller and variant

Use the search response to identify candidates and carry their returned product IDs into detail requests. Match the title, brand, pack size and seller to the listing you intend to study. Preserve separate IDs for separate listings.

Read the complete detail response before buying more data. It may contain fields you need, but do not assume a section is present because a route is described as “full data.” Inspect what was actually returned.

Record price ranges as ranges. For a variant-level comparison, select the relevant variant and keep its attributes beside the price. A sample size, refill and full-size product should not become one interchangeable offer.

3. Add reviews or creator evidence only for your question

For product feedback, request a bounded review sample. Count the rows with usable text separately from ratings-only rows. Preserve variant information when present so comments about a bundle do not become claims about a single item.

For marketing research, ask discover for the current product-related video or creator operation. Verify its required identifiers and access requirements before execution. If it requires seller access or other credentials outside your task, record the limitation and use accessible public evidence.

Treat a linked video as an observed association. Do not infer a paid partnership, commission or sales contribution unless a source explicitly supplies that information. Keep unavailable creator fields unknown.

4. Build a comparison that retains the labels

This illustrative schema defines the research output; it does not contain a live product run.

Field What belongs here
Identity Product ID, seller, listing URL and market
Variant Exact model, size, pack and bundle contents
Offer Observed price, currency and retrieval time
Extra costs Shipping, tax or discount conditions when known
Platform metrics Original field label, value and stated period
Evidence Review or video links and relevant observations
Gaps Unsupported market, missing terms or unread content

Keep units sold, review counts and estimated sales in separate columns. Do not multiply an ambiguous sold count by today's price and present the answer as revenue.

Recheck anything that drives a decision

If you compare another store, verify the same product and variant there. Include delivery costs when available, and mark missing taxes or checkout conditions. The lowest displayed price may not be the lowest total cost.

For an empty or failed response, inspect the product ID, market and error before retrying. An unavailable listing does not prove zero demand. Save the actual Vaaya response and receipt, then recheck the chosen listing directly before a purchase, campaign commitment or published price claim.

Questions

Can I treat a listed sold count as revenue?

No. Preserve the provider’s label and time scope. Units, orders, estimated sales and revenue are different measures, and a public count may not reveal returns, discounts or timing.

Why does the market matter?

Availability, sellers, prices and product identifiers can differ by market. Establish the intended market and confirm that the chosen route supports it before comparing listings.

Does this workflow buy a product or contact a creator?

No. It produces a product research table. A purchase or creator outreach is a separate action that needs its own selected item, recipient and authorization.

Try Vaaya with your agent.

Connect your agent, choose a service, and try your first call with Vaaya.

npx @vaaya/mcp install