Cách Xây Dựng Quy Trình Định Giá Cạnh Tranh: Theo Dõi 5.000 Mã Hàng Qua 8 Đối Thủ Hàng Ngày

Những điểm chính:

• Giá cả cạnh tranh là một bài toán tổng hợp, không phải là bài toán sản phẩm. Một đội ngũ định giá theo dõi 5,000 SKU trên 8 đối thủ cạnh tranh ở 4 thị trường đang thực hiện 160,000 lần đọc mỗi ngày. Kiến trúc có khả năng mở rộng là một cuộc gọi render cho mỗi URL với luồng dữ liệu cố định theo từng thị trường, cộng với một lược đồ đầu ra chuẩn hóa duy nhất — không phải 160,000 lần truy xuất ngẫu nhiên.
• Thị trường quy định luồng dữ liệu. Giá cả, tiền tệ và khả năng cung ứng thay đổi theo từng vùng và theo uy tín IP. Gán quốc gia proxy cho thị trường đang đo lường giữ cho mọi giá đã ghi lại có thể so sánh; việc trộn lẫn luồng dữ liệu từ Hoa Kỳ và EU trên cùng một SKU tạo ra một lịch sử giá trị không có ý nghĩa.
• Một lược đồ chuẩn duy nhất giữa các đối thủ cạnh tranh. DOM của mỗi nhà bán lẻ là khác nhau; bảng kho hàng thì không. Chuẩn hóa khi trích xuất: {your_sku, competitor, market, price_value, price_currency, availability, promo_state, captured_at}. Các quyết định đọc từ kho hàng, không phải từ HTML gốc.
• Chống phát hiện được xử lý ở phía máy chủ. Mỗi yêu cầu được render bên trong đám mây Scrapeless với luồng dữ liệu từ cư dân, thực thi JavaScript và ngẫu nhiên hóa dấu vân tay. Đường ống gửi một URL và một quốc gia; nó nhận lại HTML đã render. Không có nhị phân trình duyệt, không có logic xoay vòng proxy, và không có khách hàng CDP bên thứ ba trên máy của bạn.
• Đường ống kết thúc ở sự khác biệt, không phải ở HTML. Các trang đã render thô là bộ nhớ tạm. Tín hiệu mà các đội ngũ định giá hành động dựa vào là sự khác biệt giữa giá của bạn và giá của đối thủ, theo từng thị trường, từng SKU — được nâng lên đến một quy tắc định giá lại, một cảnh báo Slack, hoặc một bảng điều khiển của nhà phân tích.
• Miễn phí để bắt đầu. Tài khoản Scrapeless mới bao gồm thời gian chạy miễn phí — đăng ký tại app.scrapeless.com.

Giới thiệu: Từ dữ liệu web đến quyết định định giá cạnh tranh

Các đội ngũ định giá cạnh tranh đã phải sống với cùng một rào cản trong nhiều năm: giá cả thay đổi nhanh hơn dữ liệu cung cấp thông tin cho quyết định định giá. Một nhà bán lẻ sửa đổi giá ghi trên nhãn qua đêm; bảng BI cập nhật sau 48 giờ; khi nhà phân tích nhìn thấy sự chênh lệch, thời gian khuyến mãi đã khép lại. Dữ liệu web khép kín vòng lặp đó, nhưng chỉ khi lớp thu thập giữ tốc độ thay đổi và cung cấp một lược đồ mà kho hàng có thể tham gia.

Thách thức cấu trúc không phải là "trích xuất một trang sản phẩm." Nó là vận hành một đội ngũ trích xuất trên một tập hợp SKU, trên một tập hợp đối thủ cạnh tranh, trên một tập hợp thị trường — mỗi ngày, mỗi thị trường, mỗi nhà bán lẻ, với cùng một cam kết về độ chính xác. DOM của mỗi nhà bán lẻ quay vòng. Giá của mỗi thị trường địa phương hóa. Mỗi yêu cầu cần vượt qua lớp chống bot của nhà bán lẻ và trả lại HTML đã render sạch sẽ. Nghiên cứu điển hình OptiGroup của Octoparse đã ghi lại mẫu tương tự ở quy mô: 50 công ty con, hàng chục trang web đối thủ, giá khu vực, một lớp quyết định giá tập trung.

Hướng dẫn này đi qua kiến trúc và mã Python cho lớp thu thập của một đường ống thông tin định giá dựa trên Scrapeless. Đầu ra là một luồng NDJSON chuẩn hóa cho bảng kho; đầu vào là tệp giỏ hàng mà nhà phân tích định nghĩa. Đọc một lần để nắm mẫu; tái sử dụng cho mọi đối thủ cạnh tranh bằng cách thay đổi bộ trích xuất theo từng nhà bán lẻ.

Những gì bạn có thể làm với nó

• Đọc giỏ hàng cạnh tranh hàng ngày. Theo dõi 5,000 SKU trên 8 đối thủ cạnh tranh ở 4 thị trường theo lịch trình hàng ngày với thời gian chạy giới hạn và một lược đồ chuẩn hóa duy nhất.
• Định giá lại theo thị trường cụ thể. Gán quốc gia luồng dữ liệu cho mỗi thị trường; lấy giá cả địa phương phản ánh những gì một người mua địa phương thực sự thấy, không phải giá dự phòng địa lý.
• Giám sát trạng thái khuyến mại. Ghi lại cả giá đã liệt kê và trạng thái khuyến mại (đang giảm giá, phần trăm giảm, nhãn thời gian) để kho hàng biết sự khác biệt giữa giá hàng ngày và khuyến mãi thanh lý.
• Kiểm toán tuân thủ MAP. So sánh giá được liệt kê của nhà bán lẻ với chính sách MAP (giá tối thiểu được quảng cáo) của bạn và nêu bật các vi phạm cho nhóm quản lý kênh.
• Theo dõi ra mắt sản phẩm mới. Theo dõi sự xuất hiện đầu tiên của các SKU đối thủ trong một danh mục; đường ống đóng vai trò như một tín hiệu "đối thủ có đang chuẩn bị ra mắt X không?".
• Dữ liệu độ co giãn giá. Các bức tranh hàng ngày trong 90 ngày tạo ra chuỗi thời gian mà quản lý doanh thu sử dụng để tính toán độ co giãn theo từng SKU.

Tại Scrapeless, chúng tôi chỉ truy cập dữ liệu công khai có sẵn trong khi hoàn toàn tuân thủ các luật, quy định và chính sách quyền riêng tư của trang web. Nội dung trong bài viết này chỉ dành cho mục đích minh họa.

Tại sao chọn Scrapeless cho định giá cạnh tranh

Scrapeless render mỗi URL mục tiêu trong một trình duyệt đám mây chống phát hiện được hỗ trợ bởi Chromium tự phát triển và trả lại HTML hoàn chỉnh qua một cuộc gọi API duy nhất. Đối với một đường ống thông tin định giá riêng biệt, nó mang lại:

• Proxy cư dân tại hơn 195 quốc gia, được gán theo từng yêu cầu với mã quốc gia — địa lý luồng dữ liệu là một trường cho từng thị trường.
• Render JavaScript phía đám mây. Các trang sản phẩm của nhà bán lẻ là ứng dụng React hoặc Next.js; phần tử giá được nạp sau khi hydrat hóa. js_render=True có nghĩa là đường ống của bạn đọc DOM sau khi vẽ, không phải vỏ shell SSR.
• Chống phát hiện phía máy chủ. UA, múi giờ, WebGL, canvas và cờ headless được ngẫu nhiên hóa trong đám mây theo từng yêu cầu. Không cần bảo trì plugin ẩn danh cục bộ, không cần cài đặt tệp nhị phân trình duyệt.
• Hình thức yêu cầu không trạng thái. Mỗi trang sản phẩm là một yêu cầu độc lập: gửi một URL cộng với một quốc gia, nhận lại HTML được render. Điều đó khớp sạch sẽ vào một giỏ hàng với hàng nghìn sản phẩm SKU độc lập.
• Một khóa API cho toàn bộ quy trình. Rendering, proxy dân cư và SDK đều tính phí chống lại cùng một tài khoản Scrapeless; không cần tích hợp theo từng cấp độ.

Nhận khóa API của bạn trong gói miễn phí tại app.scrapeless.com.

Các yêu cầu cần thiết

• Python 3.10 trở lên
• Một tài khoản Scrapeless và khóa API — đăng ký tại app.scrapeless.com
• Làm quen với HTTP kiểu requests và một thư viện chọn lọc CSS
• Một danh sách đối thủ mục tiêu và một tệp giỏ hàng SKU

Kiến trúc quy trình nhìn tổng quan

basket.yaml                      (đầu vào do nhà phân tích định nghĩa)
       │
       ▼
┌──────────────────┐
│   tổ chức        │  một nhiệm vụ cho mỗi (thị trường, đối thủ, SKU); đồng thời giới hạn
└──────┬───────────┘
       │
       ▼
┌──────────────────┐
│   Scrapeless     │  client.universal.scrape(url, country) — egress dân cư,
│  (render đám mây) │  JS rendering, chống phát hiện, tất cả phía máy chủ
└──────┬───────────┘
       │  HTML được render
       ▼
┌──────────────────┐
│   chuẩn hóa      │  extractor theo nhà bán lẻ → sơ đồ chuẩn
└──────┬───────────┘
       │
       ▼
prices.ndjson          (một hàng cho mỗi (sản phẩm, đối thủ, thị trường, ngày))
       │
       ▼
tải vào kho hàng + khác biệt so với giá của bạn + cảnh báo

Mỗi giai đoạn là một mô-đun Python; bảy bước dưới đây sẽ xây dựng từ dưới lên.

Bước 1 — Cài đặt SDK Scrapeless

pip install scrapeless lxml pyyaml

scrapeless là SDK Python chính thức; nó render các trang ở phía đám mây và trả về HTML, vì vậy không cần cài đặt tệp nhị phân trình duyệt và không cần thư viện tự động hóa của bên thứ ba. lxml là trình phân tích cú pháp; pyyaml đọc cấu hình giỏ hàng.

Bước 2 — Định nghĩa giỏ hàng

Đội ngũ giá cả sở hữu tệp này. Giữ nó đơn giản — thị trường, đối thủ, ánh xạ SKU. Một hàng cho mỗi (your_sku, đối thủ, competitor_url, thị trường):

# basket.yaml
markets:
  - US
  - GB
  - DE
  - JP

basket:
  - your_sku: SKU-1001
    name: "Acme Widget Pro"
    competitors:
      - retailer: target_competitor_a
        url:
          US: "https://competitor-a.com/p/widget-pro"
          GB: "https://competitor-a.co.uk/p/widget-pro"
          DE: "https://competitor-a.de/p/widget-pro"
          JP: "https://competitor-a.co.jp/p/widget-pro"
      - retailer: target_competitor_b
        url:
          US: "https://competitor-b.com/products/widget-pro"
          GB: "https://competitor-b.co.uk/products/widget-pro"

Một giỏ hàng 5.000 SKU sống trong cùng một hình dạng; kho hàng tham gia vào your_sku để đồng bộ với nguồn giá của bạn.

Bước 3 — Render một trang sản phẩm thông qua Scrapeless

Một lần gọi render cho mỗi (thị trường, SKU). Địa chỉ quốc gia thiết lập egress dân cư; js_render=True trả về DOM đã được hydrat hóa:

import os
from scrapeless import Scrapeless
from scrapeless.types.universal import (
    UniversalScrapingRequest, UniversalJsRenderInput, UniversalProxy,
)

client = Scrapeless()  # đọc SCRAPELESS_API_KEY từ biến môi trường

def scrape_rendered(url: str, market: str) -> str:
    """Render một trang sản phẩm trong đám mây Scrapeless và trả về HTML."""
    request = UniversalScrapingRequest(
        actor="unlocker.webunlocker",
        input=UniversalJsRenderInput(url=url, js_render=True, headless=True),
        proxy=UniversalProxy(country=market),
    )
    return client.universal.scrape(request)  # trả về HTML đã được render (str)

Địa chỉ quốc gia là trường nặng tải. Cùng một URL sản phẩm render một giá, tiền tệ và trạng thái sẵn có khác nhau theo từng khu vực, vì vậy việc định pin egress giữ cho mọi giá đã ghi nhận ở cùng một thị trường. js_render=True chờ cho trang được vẽ trước khi trả về, vì vậy các nhà bán lẻ React/Vue/Next.js trả về yếu tố giá, không phải một shell trống.

Bước 4 — Đi bộ giỏ hàng

Mỗi SKU là một cuộc gọi render độc lập, vì vậy việc đi bộ giỏ hàng là một vòng lặp đơn giản (hoặc một hồ bơi luồng giới hạn cho việc song song hóa). Không cần giữ session, không cần sưởi ấm trang chủ — việc render trong đám mây xóa bỏ lớp chống bot của nhà bán lẻ theo từng yêu cầu:

import yaml

def load_basket(path: str = "basket.yaml") -> dict:
    with open(path, encoding="utf-8") as f:
        return yaml.safe_load(f)

def walk_basket(basket: dict):
    """Trả về (your_sku, nhà bán lẻ, thị trường, url, html) cho mỗi mục trong giỏ hàng."""
    for item in basket["basket"]:
        for comp in item["competitors"]:
            for market, url in comp["url"].items():
                html = scrape_rendered(url, market)
                yield item["your_sku"], comp["retailer"], market, url, html

Đối với giỏ hàng 5,000-SKU, bọc scrape_rendered trong concurrent.futures.ThreadPoolExecutor và giới hạn số lượng công nhân ở mức mà kế hoạch tài khoản cho phép. Mỗi cuộc gọi là không có trạng thái, vì vậy tính song song tăng theo việc thêm công nhân — không có phiên chia sẻ để tranh chấp.

Lấy khóa API của bạn trên kế hoạch miễn phí: app.scrapeless.com

Bước 5 — Trích xuất vào lược đồ chính thống

DOM của mỗi nhà bán lẻ là khác nhau; bảng kho thì không. Nhiệm vụ của bộ trích xuất là biến bất kỳ thứ gì mà nhà bán lẻ hiển thị thành cùng một hình dạng mỗi lần. Lược đồ đầu ra (mỗi hàng tương ứng với (your_sku, đối thủ, thị trường, captured_at)):

from dataclasses import dataclass, asdict
from datetime import datetime, timezone
from typing import Optional
from lxml import html as lxml_html

@dataclass
class PriceRecord:
    your_sku: str
    competitor: str
    market: str
    url: str
    price_value: Optional[float]
    price_currency: Optional[str]
    availability: Optional[str]       # "còn_hàng" | "hết_hàng" | "đặt_trước" | None
    promo_state: Optional[str]        # "không" | "giảm_giá" | "xả_hàng" | None
    promo_discount_pct: Optional[float]
    captured_at: str                  # ISO-8601 UTC

Các bộ trích xuất theo nhà bán lẻ cắm vào cùng một loại trả về:

def extract_competitor_a(html: str, your_sku: str, market: str, url: str) -> PriceRecord:
    doc = lxml_html.fromstring(html)

    price_el = doc.cssselect("[data-test='price'] .value")
    currency_el = doc.cssselect("[data-test='price'] .currency")
    availability_el = doc.cssselect("[data-test='availability']")
    promo_el = doc.cssselect("[data-test='promo-badge']")

    availability = (
        "còn_hàng" if availability_el and "Có hàng" in availability_el[0].text_content()
        else "hết_hàng" if availability_el
        else None
    )

    return PriceRecord(
        your_sku=your_sku,
        competitor="target_competitor_a",
        market=market,
        url=url,
        price_value=_to_float(price_el[0].text_content()) if price_el else None,
        price_currency=currency_el[0].text_content().strip() if currency_el else None,
        availability=availability,
        promo_state="giảm_giá" if promo_el else "không",
        promo_discount_pct=_to_float(promo_el[0].get("data-discount-pct")) if promo_el else None,
        captured_at=datetime.now(timezone.utc).isoformat(),
    )

def _to_float(text) -> Optional[float]:
    if not text:
        return None
    cleaned = "".join(c for c in text if c.isdigit() or c == ".")
    try:
        return float(cleaned)
    except (ValueError, TypeError):
        return None

Mỗi nhà bán lẻ có hàm extract_<tên> riêng; mỗi hàm trả về cùng một PriceRecord. Bộ điều phối không biết DOM mà mỗi nhà bán lẻ sử dụng — chỉ biết tên hàm để gọi.

Ghi chú thiết kế bộ chọn:

• Ưu tiên thuộc tính [data-test='...'] khi nhà bán lẻ cung cấp. Chúng sống sót qua việc thay đổi tên lớp thẩm mỹ; những lớp như .text-lg.font-semibold thay đổi mỗi lần phát hành.
• Xem các trường không có là có thể null. Một giá None cho sản phẩm hết hàng là dữ liệu, không phải là thất bại.
• Ghi lại chuỗi tiền tệ mà nhà bán lẻ hiển thị. Không suy diễn tiền tệ từ thị trường — một số nhà bán lẻ liệt kê USD trên miền .de của họ cho các sản phẩm xuyên biên giới. Lưu lại những gì trang nói.

Bước 6 — Đưa vào NDJSON để tải kho

Ghi theo luồng vào NDJSON để ống dẫn tồn tại qua các gián đoạn giữa chừng mà không mất đi các bản ghi. Mỗi hàng là một SKU đã được hiển thị; tệp chỉ có thể thêm:

import json
from pathlib import Path

def append_records(records: list[PriceRecord], out_path: str = "prices.ndjson"):
    Path(out_path).parent.mkdir(parents=True, exist_ok=True)
    with open(out_path, "a", encoding="utf-8") as f:
        for r in records:
            f.write(json.dumps(asdict(r)) + "\n")

NDJSON tải trực tiếp vào Snowflake (COPY INTO ... FILE_FORMAT = (TYPE = JSON)), BigQuery (bq load --source_format=NEWLINE_DELIMITED_JSON), Redshift, ClickHouse và DuckDB. Chọn bất cứ cái nào mà chồng BI đã sử dụng; lược đồ là giống nhau.

Bước 7 — Tính toán sự khác biệt và định hướng quyết định giá

Tín hiệu mà nhóm định giá hành động không phải là giá thô — mà là sự khác biệt giữa giá của đối thủ và giá của bạn, theo thị trường, theo SKU. Sự khác biệt sống trong kho, không trong công cụ thu thập dữ liệu:

-- Khoảng cách giá hàng ngày, theo SKU theo đối thủ theo thị trường
WITH yours AS (
  SELECT sku, market, list_price, currency, captured_date
  FROM your_internal_prices
  WHERE captured_date = CURRENT_DATE
),
theirs AS (
  SELECT your_sku, competitor, market, price_value, price_currency,
         availability, promo_state, CAST(captured_at AS DATE) AS captured_date
  FROM competitor_prices
  WHERE CAST(captured_at AS DATE) = CURRENT_DATE
)
SELECT
  t.your_sku,
  t.competitor,
  t.market,
  y.list_price                                  AS our_price,
  t.price_value                                 AS their_price,

ROUND(100.0 * (y.list_price - t.price_value) / NULLIF(t.price_value, 0), 2) 
                                                AS price_gap_pct,
  t.availability,
  t.promo_state 
FROM theirs t 
LEFT JOIN yours y 
  ON y.sku = t.your_sku AND y.market = t.market 
WHERE y.list_price IS NOT NULL 
  AND t.price_value IS NOT NULL 
ORDER BY price_gap_pct DESC;

---

Hướng dẫn các hàng mà `price_gap_pct` vượt quá ngưỡng mà quy tắc định giá xác định:

- **Vượt ngưỡng giá của bạn** (ví dụ: bạn đắt hơn 5% so với đối thủ) → xem xét tái định giá.
- **Dưới ngưỡng MAP** → cảnh báo vi phạm MAP cho quản lý kênh.
- **Thay đổi trạng thái khuyến mãi kể từ hôm qua** → thông báo khuyến mãi cạnh tranh cho các quản lý ngành hàng.

Truy vấn khác nhau là hợp đồng giữa việc thu thập và quyết định. Chừng nào sơ đồ kho lưu trữ vẫn ổn định, các tấm BI hạ nguồn của đội ngũ định giá, cảnh báo và quy tắc định giá sẽ không bao giờ thay đổi khi một nhà bán lẻ thay đổi DOM của họ — chỉ có bộ trích xuất theo từng nhà bán lẻ trong Bước 5 là thay đổi.

---

## Những gì bạn nhận lại

Một dòng NDJSON cho mỗi (your_sku, đối thủ cạnh tranh, thị trường, ngày), có hình dạng như sau:

```json
{
  "your_sku": "SKU-1001",
  "competitor": "target_competitor_a",
  "market": "US",
  "url": "https://competitor-a.com/p/widget-pro",
  "price_value": 79.99,
  "price_currency": "USD",
  "availability": "in_stock",
  "promo_state": "on_sale",
  "promo_discount_pct": 15.0,
  "captured_at": "<ISO-8601 UTC timestamp written at read time>"
}

Những quan sát chân thực từ việc thực hiện mẫu:

• Thời gian hiển thị quan trọng hơn độ cụ thể của DOM. Một bộ chọn chạy trên shell SSR trả về chuỗi rỗng trước khi phần tử giá được vẽ. js_render=True trả về DOM sau khi cấp nước, điều này giúp bộ chọn giá xác định.
• Tiền tệ không thể bị lặp lại với thị trường. Các SKU xuyên biên giới đôi khi niêm yết bằng một loại tiền tệ không địa phương ngay cả trên miền đã được địa phương hóa. Lưu trữ chuỗi đã hiển thị; để kho lưu trữ lớp chuẩn hóa.
• Trạng thái khuyến mãi có ít nhất ba giá trị, không phải hai. none, on_sale, và clearance hoạt động khác nhau trong các quy tắc tái định giá — một giảm giá clearance báo hiệu hết hạn, không phải là một đẩy khuyến mãi.
• Khả năng sẵn có là trường có thể hành động thứ hai. Một khoảng cách giá 20% trên một SKU hết hàng không phải là tín hiệu cạnh tranh giống như khoảng cách tương tự trên một SKU còn hàng. Hiển thị cả hai cho lớp quyết định.
• Một sơ đồ chuẩn mực là quyết định chịu lực. Các trường theo từng nhà bán lẻ, quy ước tiền tệ, và định dạng khuyến mãi khác nhau; bảng kho lưu trữ thì không. Chuyển sự khác biệt vào các hàm trích xuất, giữ cho sơ đồ phẳng.

Kết luận: mở rộng quy trình định giá cạnh tranh của bạn

Quy trình giảm thành sáu bước: xác định giỏ → hiển thị từng SKU qua Scrapeless với lối ra gắn vào từng thị trường → trích xuất vào sơ đồ chuẩn mực → phát dòng đến NDJSON → tải vào kho lưu trữ → so sánh với giá của bạn. Mỗi bước đủ nhỏ để đọc; sự tổng hợp xử lý 5.000 SKU qua 8 đối thủ và 4 thị trường trong một cron hàng ngày.

Đối với cái nhìn so sánh nhà cung cấp về việc thu thập dữ liệu liên quan đến giá cả (đặc biệt là giá bất động sản), danh sách Các công cụ thu thập tốt nhất Zillow vào năm 2026 xếp hạng tám công cụ chống lại cùng một loại thách thức trong việc trích xuất giá địa phương. Đối với việc tải đầu ra NDJSON vào một kho lưu trữ đám mây, hướng dẫn Thu thập dữ liệu Scrapeless + Snowflake hướng dẫn các phương thức COPY INTO và stream.

Ghim quốc gia đầu ra theo từng thị trường, hiển thị từng SKU độc lập, chuẩn hóa khi trích xuất, lưu trữ một hàng chuẩn mực cho mỗi SKU/đối thủ/cách thị trường/ngày, và so sánh trong kho — không phải là bộ thu thập.

Sẵn sàng để xây dựng quy trình dữ liệu powered AI của bạn?

Tham gia cộng đồng của chúng tôi để nhận kế hoạch miễn phí và kết nối với các nhà phát triển xây dựng các quy trình định giá cạnh tranh: Discord · Telegram.

Đăng ký tại app.scrapeless.com để nhận thời gian chạy miễn phí và điều chỉnh các mẫu ở trên cho các thị trường, đối thủ và giỏ SKU mà quy trình định giá cần. Thông tin định giá tại scrapeless.com/en/pricing; trang sản phẩm giải pháp proxy có tại scrapeless.com/en/product/proxy-solutions; tài liệu SDK đầy đủ tại docs.scrapeless.com.

Câu hỏi thường gặp

Q1: Việc thu thập giá từ đối thủ cạnh tranh có hợp pháp không?

Giá cả là thông tin công khai trên các trang sản phẩm của nhà bán lẻ và việc so sánh giá là một thực tiễn thương mại đã được thiết lập tốt. Tính hợp pháp phụ thuộc vào những gì bạn thu thập, từ đâu, và theo điều kiện gì. Dữ liệu hiện công khai thường có thể truy cập; các điều khoản dịch vụ của trang web, luật bảo mật khu vực (GDPR, CCPA), và bản quyền áp dụng. Tư vấn pháp lý cho các trường hợp sử dụng có nguy cơ cao. Scrapeless chỉ truy cập dữ liệu công khai.

Q2: Tôi có cần một proxy cho định giá cạnh tranh không?

Có, và mã quốc gia quan trọng hơn việc quay vòng IP. Các nhà bán lẻ định giá theo thị trường; một yêu cầu rời khỏi Hoa Kỳ đến một tên miền `.co.uk` có thể trả về một mức giá tạm thời, một chuyển hướng, hoặc một geo-block. Gán mã quốc gia cho thị trường đang được đo đạc qua `UniversalProxy(country=...)`. Các proxy dân cư không bị rác ở hơn 195 quốc gia bao phủ giỏ giá thông thường mà không cần đưa một nhà cung cấp proxy riêng biệt vào hệ thống.

**Q3: Làm thế nào tôi xử lý các thách thức chống bot và phát hiện bot?**

Việc kết xuất diễn ra ở phía máy chủ trong đám mây Scrapeless với đầu ra dân cư, thực thi JavaScript thực, và đánh dấu ngẫu nhiên, do đó yêu cầu đạt đến nhà bán lẻ trông giống như một trình duyệt thông thường từ một IP dân cư trong thị trường mục tiêu. Cài đặt `js_render=True` để phản hồi là DOM sau khi đã hydrat hóa thay vì một lớp kết xuất trước, và gán mã quốc gia cho thị trường mà bạn đo lường.

**Q4: Tần suất của pipeline nên chạy như thế nào?**

Hàng ngày là nhịp điệu tiêu chuẩn cho các quyết định định giá lại; hàng giờ là thực tế cho việc giám sát trong khoảng thời gian khuyến mại nơi mà giá thay đổi trong ngày. Chi phí theo SKU bị giới hạn bởi một cuộc gọi kết xuất duy nhất, do đó một giỏ 5,000 SKU với nhịp độ hàng ngày nằm gọn trong ngân sách của một cửa hàng cron đơn. Tần suất cao hơn làm tăng chi phí theo tuyến tính — hãy chọn nhịp điệu mà quyết định giá thực sự tiêu thụ.

**Q5: Chuyện gì xảy ra khi một nhà bán lẻ thay đổi DOM của mình?**

Extractor theo từng nhà bán lẻ trong Bước 5 là tệp duy nhất thay đổi. Lược đồ chuẩn, bảng kho, các ô BI, truy vấn khác biệt, và các quy tắc cảnh báo đều không bị ảnh hưởng. Kiểm tra lại các bộ chọn khi một nhà bán lẻ phát hành bản cập nhật; ưu tiên các thuộc tính `[data-test='...']` khi có sẵn; coi extractor như là lớp biến động và lược đồ như là lớp ổn định.

**Q6: Tôi có thể chạy nhiều nhà bán lẻ song song không?**

Có. Mỗi cuộc gọi kết xuất là không trạng thái, vì vậy bộ điều phối phân chia các nhiệm vụ (thị trường, đối thủ, SKU) qua một nhóm luồng và giới hạn số lượng công nhân theo mức mà kế hoạch tài khoản cho phép. Tính song song mở rộng bằng cách thêm công nhân, không phải chia sẻ một phiên — không có kết nối nào bị giữ để tranh chấp.

**Q7: Làm thế nào tôi ghi lại trạng thái khuyến mãi và tỷ lệ giảm giá?**

Extractor trong Bước 5 đọc huy hiệu khuyến mãi trực tiếp từ DOM đã kết xuất và lưu trữ cả `promo_state` (`"on_sale"`, `"clearance"`, `"none"`) và `promo_discount_pct` dưới dạng các trường riêng biệt. Kho lưu trữ kết hợp cả hai vào truy vấn khác biệt để quy tắc định giá có thể phân nhánh trên "đối thủ có đang giảm giá ngay bây giờ không?" so với "giá hàng ngày của đối thủ là gì?"

**Q8: Còn về các đồng tiền quốc tế và tỷ giá hối đoái thì sao?**

Lưu chuỗi đồng tiền đã kết xuất theo từng bản ghi (`USD`, `EUR`, `JPY`, `GBP`). Chuyển đổi tiền tệ thuộc về lớp kho, không phải công cụ thu thập — giữ giá thô + đồng tiền thô + thị trường trong NDJSON, và thực hiện một phép nối tỷ giá hối đoái hàng ngày ở phía BI. Bằng cách này, một tỷ giá xấu không làm hỏng toàn bộ lịch sử.