Wikimedia Pageviews API: lượt xem theo ngày và ngày thiếu
Wikimedia Pageviews API là endpoint công khai trả số lượt xem của một trang Wikipedia theo ngày hoặc theo tháng, tách theo kiểu truy cập và kiểu tác nhân. Bài này viết cho người dựng bảng lượt xem để theo dõi mức quan tâm tới một chủ đề, hay gặp lỗi mã hóa tên trang và hiểu nhầm ngày không có số liệu. ProxyVN gọi API thật ngày 05/11/2026 với vài trang tiếng Việt và tiếng Anh, ghi lại từng ca lệch số.
Wikimedia Pageviews API: mục tiêu và phạm vi không lặp
Phần này chốt bài toán, đầu ra và ranh giới với bài Wikidata đã có.
Bài toán cần giải
Một nhóm nội dung muốn biết mức quan tâm tới vài chủ đề ẩm thực và địa danh trên Wikipedia tiếng Việt theo từng ngày. Họ gọi API, ghép số vào bảng tính và vẽ biểu đồ. Vài tuần sau, có người phát hiện một trang có tổng lượt xem bằng 12 trong khi trang thật có hàng chục nghìn. Lỗi nằm ở cách ghép URL.
Đầu ra nghiệm thu
Đầu ra là bảng gồm project, article, timestamp, access, agent, views. Đi kèm là phần kiểm: tên trang đã mã hóa đúng chưa, có ngày nào thiếu trong khoảng yêu cầu, tổng theo ngày có khớp số theo tháng, và tham số nào đã dùng để lấy từng dòng.
Ranh giới với bài Wikidata và bài revisions
Bài Wikidata SPARQL bằng Python truy vấn thực thể và thuộc tính. Bài này không đụng tới thực thể. Nó chỉ đếm lượt xem trang theo bộ lọc. Lịch sử sửa trang thuộc về MediaWiki revisions API, một bài khác trong cùng cụm, ở đây không nhắc lại.
Giới hạn của lab
Lab gọi API thật, nghỉ 1,2 giây giữa các lời gọi, tổng khoảng 50 lời gọi. Các trang mẫu chọn ngẫu nhiên theo chủ đề ẩm thực, địa danh Việt Nam và vài trang tiếng Anh có ký tự đặc biệt. Số liệu là của tháng 10/2026, gọi ngày 05/11/2026, có thể được Wikimedia hiệu chỉnh sau.
Ai nên đọc
Người làm nội dung, nghiên cứu thị trường hay báo chí dữ liệu cần một chỉ số quan tâm công khai. Kỹ sư dữ liệu dựng pipeline lượt xem hằng ngày. Người viết script thu thập cần biết cách gọi API đúng mà không phải cào HTML của công cụ Pageviews.
Những gì bài không làm
Bài không tính unique users, không suy ra nhân khẩu học, không giải thích thuật toán phân loại bot của Wikimedia. Bài cũng không dùng các endpoint editors, edits hay unique devices. Phạm vi chỉ là per-article và một lời gọi aggregate để đối chiếu.
Thuật ngữ dùng trong bài
Project là tên miền dự án như vi.wikipedia.org. Article là tên trang, khoảng trắng thay bằng gạch dưới. Access là kênh truy cập: all-access, desktop, mobile-web, mobile-app. Agent là kiểu tác nhân: all-agents, user, spider, automated. Granularity là độ hạt: daily hoặc monthly.
Lượt xem dùng để làm gì
Lượt xem là tín hiệu thô về mức quan tâm. Một trang tăng lượt xem đột ngột thường đi cùng tin tức, sự kiện hay mùa vụ. Nhóm nội dung dùng nó để chọn chủ đề, nhóm nghiên cứu dùng để đo mức chú ý của công chúng. Cả hai đều cần số đúng bộ lọc và đúng tên trang.
Thu lượt xem trang theo project/access/agent/granularity với Wikimedia Pageviews API
Phần này đi qua dạng URL và response đã chạy.
Dạng URL của per-article
Tài liệu Analytics API về page metrics mô tả dạng đường dẫn /metrics/pageviews/per-article/{project}/{access}/{agent}/{article}/{granularity}/{start}/{end}. Lab gọi qua https://wikimedia.org/api/rest_v1. Mọi tham số nằm trong path, không có query string.
Định dạng ngày
Start và end viết YYYYMMDD, có thể thêm giờ HH ở cuối. Lab dùng 20261001 và 20261031 cho tháng 10. Timestamp trong response có dạng 2026100100, tức là ngày cộng giờ 00.
Một item trong response
Response là object có mảng items. Mỗi item có project, article, granularity, timestamp, access, agent, views. Item mẫu của trang Hà Nội: project vi.wikipedia, article Hà_Nội, granularity daily, timestamp 2026100100, access all-access, agent user, views 1157.
Project trong response khác project trong URL
URL dùng vi.wikipedia.org nhưng item trả project là vi.wikipedia, không có .org. Khi ghép bảng từ nhiều nguồn, chuẩn hóa một kiểu. Lab giữ kiểu trong response và ghi kiểu trong URL vào cột tham số riêng.
User-Agent theo chính sách Wikimedia
Wikimedia yêu cầu client tự động gửi User-Agent có tên công cụ và thông tin liên hệ, theo chính sách User-Agent của Wikimedia Foundation. Lab dùng tên client chung của dự án kèm đường dẫn website, không dùng email cá nhân. User-Agent mặc định của thư viện có thể bị chặn hoặc giới hạn chặt hơn.
Ví dụ request bằng Python
import requests, time, urllib.parse as up
s = requests.Session()
s.headers["User-Agent"] = "ProxyVN-docs-lab/1.0 (https://proxy.vn/; low-volume documentation test) python-requests"
B = "https://wikimedia.org/api/rest_v1/metrics/pageviews/per-article"
def pv(project, title, access="all-access", agent="user", gran="daily",
start="20261001", end="20261031"):
t = up.quote(title.replace(" ", "_"), safe="")
r = s.get(f"{B}/{project}/{access}/{agent}/{t}/{gran}/{start}/{end}", timeout=30)
time.sleep(1.2)
return r.status_code, (r.json().get("items", []) if r.ok else [])
st, items = pv("vi.wikipedia.org", "Hà Nội")
print(st, len(items), sum(i["views"] for i in items))Kết quả lời gọi đầu tiên
Lời gọi cho Hà Nội, agent user, all-access, daily, tháng 10 trả HTTP 200 với 31 item, tổng 34276 lượt xem. Ngày 01/10 có 1157 lượt. Không ngày nào thiếu. Đây là trang có lượng xem ổn định, dùng làm mốc đối chiếu cho các ca khó hơn.
Response lỗi có cấu trúc
Khi lỗi, API trả JSON có detail, method, status, title, type và uri. Type là about:blank, title là Not Found. Dạng này giống problem details trong RFC 9457. Pipeline đọc trường detail để phân biệt invalid route với không có dữ liệu, thay vì chỉ nhìn mã 404.
Cache ở phía Wikimedia
Header response có cache-control s-maxage=14400, max-age=14400 và x-cache cho thấy bản được phục vụ từ cache. Gọi lại cùng URL trong 4 giờ gần như chắc ra cùng số. Không cần gọi lặp để có số mới hơn, số theo ngày chỉ đổi khi Wikimedia xử lý xong ngày tiếp theo.
Chọn project, article, access và agent trong Wikimedia Pageviews API
Chọn sai bộ lọc là nguồn lệch số phổ biến nhất.
Agent user là mặc định hợp lý
Ma trận agent và access
Trang Phở trên Wikipedia tiếng Việt tháng 10/2026 có all-agents 5075, user 3409, spider 962, automated 704. Cộng ba nhóm con ra đúng 5075. Gần một phần ba lượt xem là bot. Biểu đồ quan tâm của người đọc nên dùng agent user.
Spider và automated khác nhau
Spider là bot tự khai báo, ví dụ crawler của công cụ tìm kiếm. Automated là traffic Wikimedia phân loại là tự động dù không tự khai. Với trang Phở, spider 962 và automated 704. Hai nhóm đều không phải người đọc, nhưng gộp chung làm mất thông tin khi muốn hiểu vì sao một trang tăng đột biến.
Access chia theo kênh
Với agent user, Phở có desktop 1557, mobile-web 1830, mobile-app 22. Tổng là 3409, khớp all-access. Ở trang này mobile-web nhiều hơn desktop. App rất ít. Nếu chỉ lấy desktop, số quan tâm bị cắt hơn một nửa.
Ma trận đã chạy
Agent |
all-access |
desktop |
mobile-web |
mobile-app |
|---|---|---|---|---|
all-agents |
5075 |
3056 |
1994 |
25 |
user |
3409 |
1557 |
1830 |
22 |
spider |
962 |
891 |
71 |
0 |
automated |
704 |
608 |
93 |
3 |
Nên lấy bao nhiêu tổ hợp
Mười sáu tổ hợp agent và access cho một trang là quá nhiều cho pipeline hằng ngày. Lab chạy đủ để hiểu dữ liệu một lần. Pipeline thường chỉ cần user all-access, cộng thêm all-agents all-access để biết tỉ lệ bot. Hai lời gọi mỗi trang là vừa.
Kiểm cộng dồn
Lab kiểm hai điều: tổng các agent con bằng all-agents, tổng các access con bằng all-access. Cả hai đều khớp với trang Phở. Kiểm này nên chạy trong pipeline. Khi một hàng không khớp, nghĩa là một lời gọi bị lỗi hoặc dữ liệu ngày đó chưa xử lý xong.
Spider gần như toàn desktop
Spider của Phở có 891 trên desktop và 0 trên mobile-app. Automated cũng nghiêng về desktop với 608. Lượt xem desktop của trang này vì vậy bị bot đẩy lên nhiều hơn mobile. Ai so desktop với mobile mà dùng all-agents sẽ kết luận sai về thói quen người đọc.
Project phải đúng ngôn ngữ
Cùng chủ đề Hà Nội, trang tiếng Việt là Hà Nội trên vi.wikipedia.org, trang tiếng Anh là Hanoi trên en.wikipedia.org. Hai trang là hai bài khác nhau, số lượt xem không cộng lẫn. Bảng phải có cột project để tránh gộp nhầm.
Tên trang có thể đổi
Trang Wikipedia có thể được di chuyển sang tên mới. Lượt xem trước khi đổi tên nằm dưới tên cũ, lượt xem sau nằm dưới tên mới. Theo dõi dài hạn cần ghi lịch sử tên của trang, lấy từ nhật ký di chuyển của MediaWiki, rồi gọi Pageviews cho từng tên theo đúng giai đoạn.
Trang chuyển hướng đếm riêng
Gọi vi.wikipedia.org với tên Ha Noi và Hanoi đều trả 404. Hai tên này có thể là trang chuyển hướng hoặc không tồn tại. Pageviews đếm theo đúng tên trang được yêu cầu. Lượt xem đi qua chuyển hướng không tự cộng vào trang đích theo cách người dùng thường nghĩ. Lab lấy tên trang chuẩn trước khi gọi.
Mã hóa tên trang và đặt granularity/start/end trong Wikimedia Pageviews API
Phần này cho thấy một ký tự sai có thể đổi cả kết quả.
Dấu gạch chéo trong tên trang
Lỗi mã hóa tên trang
Trang AC/DC trên Wikipedia tiếng Anh. Mã hóa đúng thành AC%2FDC trả 200, 31 ngày, tổng 142191. Để nguyên dấu gạch chéo thì API trả 404 với detail là invalid route. Dấu gạch chéo bị hiểu là ngăn cách path, route không còn đúng số phần.
Dấu cộng trong tên trang
Trang C++ mã hóa thành C%2B%2B trả 31 ngày, tổng 55029. Để nguyên dấu cộng thì API vẫn trả 200, nhưng chỉ 22 ngày, tổng 12. Article trong response là C__. Dấu cộng bị hiểu là khoảng trắng rồi đổi thành gạch dưới, API trả số của một trang khác.
Vì sao C__ lại có dữ liệu
Trang C__ có 22 ngày có dòng và tổng 12 lượt xem. Có thể đó là lượt truy cập do người gõ sai, hoặc do chính các client mã hóa sai như ca này. Lab không truy nguyên. Điều cần nhớ là API không báo lỗi, nó trả đúng số của tên trang mà nó nhận được.
Lỗi im lặng nguy hiểm hơn lỗi 404
Ca AC/DC báo lỗi ngay. Ca C++ không báo gì, chỉ trả số sai. Pipeline không kiểm trường article trong response với tên đã gửi sẽ ghi 12 lượt xem cho C++ mà không ai biết. Đây là lý do bảng nghiệm thu có cột so tên trang.
Ký tự tiếng Việt
Trang Hà Nội và Phở trả cùng kết quả dù mã hóa bằng quote hay để requests tự xử lý. Requests tự mã hóa ký tự ngoài ASCII trong path thành UTF-8 phần trăm. Với tiếng Việt, rủi ro nằm ở việc trộn dạng Unicode dựng sẵn và tổ hợp, không nằm ở mã hóa.
Các ký tự khác cần để ý
Ngoài dấu gạch chéo và dấu cộng, các ký tự như dấu chấm hỏi, dấu thăng, dấu và, dấu phần trăm, dấu ngoặc kép đều có nghĩa riêng trong URL. Tên trang có dấu chấm hỏi mà không mã hóa sẽ bị cắt thành query string. Quy tắc mã hóa tất cả, không để ký tự nào an toàn, là cách đơn giản nhất.
Dạng Unicode của tiếng Việt
Chữ "ở" trong Phở có thể viết bằng một ký tự dựng sẵn hoặc bằng chữ "o" cộng dấu móc cộng dấu hỏi. Hai dạng hiển thị giống nhau nhưng mã hóa ra chuỗi byte khác. Wikipedia lưu tên trang theo dạng NFC. Nên chuẩn hóa NFC trước khi mã hóa, đặc biệt khi tên trang lấy từ tệp Excel hay văn bản người nhập tay.
Quy tắc mã hóa của lab
Thay khoảng trắng bằng gạch dưới, rồi gọi urllib.parse.quote với safe bằng chuỗi rỗng. Mọi ký tự đặc biệt, kể cả dấu gạch chéo, cộng, chấm hỏi, và, đều bị mã hóa. Sau khi nhận response, so item article với tên đã chuẩn hóa. Lệch thì đánh dấu dòng đó.
Bảng các ca mã hóa
Trang |
Không mã hóa |
Mã hóa đủ |
|---|---|---|
Hà Nội |
200, 34276 |
200, 34276 |
Phở |
200, 3409 |
200, 3409 |
AC/DC |
404 invalid route |
200, 142191 |
C++ |
200, 12 (trang C__) |
200, 55029 |
Daily và monthly
Hà Nội tháng 10 theo monthly trả một item timestamp 2026100100, views 34276. Tổng 31 item daily cũng là 34276. Hai cách lấy khớp nhau với agent user. Pipeline lấy cả hai có thể dùng monthly làm phép kiểm cho daily.
Monthly cần start và end bao trọn tháng
Với monthly, lab đặt start 20261001 và end 20261031. Nếu end rơi vào giữa tháng, kết quả có thể không có tháng đó hoặc có tháng chưa đủ ngày, tùy cách API xử lý. Lab chưa thử ca này. Quy tắc an toàn là chỉ lấy monthly cho tháng đã kết thúc.
End date chưa có dữ liệu
Gọi Phở từ 20261101 tới 20261130 vào ngày 05/11 trả 200 với 4 item, item cuối là 2026110400. API không báo lỗi khi end vượt ngày có dữ liệu, chỉ trả những ngày đã có. Pipeline không được coi 26 ngày còn lại là 0.
Đối soát ngày thiếu và tổng lượt xem theo cùng bộ lọc với Wikimedia Pageviews API
Ngày thiếu không đồng nghĩa với 0, và 0 không đồng nghĩa với thiếu.
Trang có ngày thiếu
Ngày thiếu khác ngày 0
Trang Chùa Keo tháng 10/2026, agent user, trả 28 item. Thiếu 3 ngày: 05, 11 và 22/10. Trong 28 item có 6 item views bằng 0. Nghĩa là API vừa có ngày ghi 0 vừa có ngày không có dòng. Hai trạng thái này phải giữ khác nhau.
Trang gần như không có lượt xem
Trang Tháp Ponagar trả 2 item, cả hai views 0, thiếu 29 ngày. Ba trang khác gồm Tháp Bà Ponagar, Phường Bến Nghé và Đồi Thông Hai Mộ trả 404 cho cả tháng. Detail của 404 nói ngày hợp lệ nhưng không có dữ liệu, hoặc project chưa nạp.
404 của trang không tồn tại giống hệt
Gọi một tên trang bịa trả cùng 404 với cùng detail. API không phân biệt trang không tồn tại với trang tồn tại nhưng không ai xem. Muốn biết trang có tồn tại, phải hỏi MediaWiki API riêng. Pageviews chỉ trả lời câu hỏi về lượt xem.
Mã điền ngày thiếu
import datetime as dt
days = [(dt.date(2026, 10, 1) + dt.timedelta(k)).strftime("%Y%m%d00") for k in range(31)]
got = {i["timestamp"]: i["views"] for i in items}
rows = [{"timestamp": d, "views": got.get(d), "status": "co_dong" if d in got else "khong_co_dong"}
for d in days]
missing = [r["timestamp"] for r in rows if r["status"] == "khong_co_dong"]Vì sao có cả ngày bằng 0 lẫn ngày không có dòng
Lab không biết chính xác cơ chế bên trong khiến Chùa Keo có ngày ghi 0 và ngày không có dòng. Có thể ngày ghi 0 là ngày chỉ có traffic thuộc nhóm agent khác user. Dù lý do là gì, dữ liệu trả về cho thấy hai trạng thái tồn tại song song, và pipeline phải giữ được cả hai.
Để trống thay vì điền 0
Bảng của lab ghi views rỗng và status khong_co_dong cho ngày thiếu. Biểu đồ có thể chọn vẽ khoảng trống hoặc điền 0 theo quyết định của người dùng. Dữ liệu gốc không bị ghi đè bằng giả định.
Tổng có điều kiện
Tổng lượt xem một tháng chỉ cộng các ngày có dòng. Bảng ghi kèm số ngày có dòng và số ngày thiếu. Tổng 37 của Chùa Keo đi kèm chú thích 28 trên 31 ngày. Người đọc biết con số nhỏ đó có thể thấp hơn thực tế một chút.
Trang ít lượt xem dễ bị nhiễu
Trang có vài lượt mỗi ngày dao động mạnh theo tỉ lệ. Một ngày tăng từ 1 lên 5 là gấp năm lần nhưng không mang nhiều ý nghĩa. Báo cáo nên đặt ngưỡng tối thiểu, ví dụ chỉ xét xu hướng khi tổng tháng trên vài trăm lượt.
Đối chiếu với aggregate
Lời gọi aggregate cho toàn bộ Wikipedia tiếng Việt, agent user, ba ngày đầu tháng 10 trả 1303509, 1354811 và 1284726. Lab dùng con số này để đặt lượt xem từng trang vào bối cảnh, ví dụ Hà Nội chiếm bao nhiêu phần nghìn tổng traffic ngày đó.
Lưu tham số cùng kết quả, không diễn giải thành unique users trong Wikimedia Pageviews API
Một con số lượt xem không có bộ lọc đi kèm là con số không dùng lại được.
Cột tham số bắt buộc
Mỗi dòng bảng có project_url, project, article_requested, article_returned, access, agent, granularity, start, end, timestamp, views, status, fetched_at. Có cột này, ai đọc bảng cũng tái lập được lời gọi.
Lượt xem không phải người xem
Một người mở trang Phở ba lần trong ngày tạo ba lượt xem. Agent user loại bot đã biết, không loại lượt xem lặp. Báo cáo không được viết "3409 người đọc trang Phở". Viết đúng là "3409 lượt xem từ tác nhân phân loại là người dùng".
Số có thể được hiệu chỉnh
Wikimedia có thể xử lý lại dữ liệu khi phát hiện traffic tự động bị phân loại sai. Cột fetched_at cho biết số lấy lúc nào. Khi so với báo cáo cũ, chênh lệch nhỏ có thể do hiệu chỉnh chứ không phải lỗi pipeline.
So sánh giữa các trang
So lượt xem Hà Nội với Phở chỉ có nghĩa khi cùng project, cùng access, cùng agent, cùng khoảng ngày. Bảng có đủ cột tham số thì mã so sánh có thể từ chối ghép hai dòng khác bộ lọc.
Đừng cào HTML của công cụ Pageviews
Công cụ web Pageviews Analysis là giao diện dùng chính API này. Cào HTML của nó vừa chậm vừa dễ vỡ. Gọi thẳng API cho cùng số, có cấu trúc, và tôn trọng hạ tầng của Wikimedia hơn.
Ghi chú về giờ
Timestamp daily kết thúc bằng 00, theo giờ UTC. Ngày 01/10 trong API là 01/10 UTC, tức từ 7 giờ sáng 01/10 tới 7 giờ sáng 02/10 giờ Việt Nam. Khi đối chiếu với sự kiện xảy ra buổi tối ở Việt Nam, lượt xem có thể rơi vào ngày UTC hôm sau.
Bảng tóm tắt cách diễn giải
Quan sát |
Diễn giải đúng |
Diễn giải sai |
|---|---|---|
views 3409 agent user |
3409 lượt xem |
3409 người |
Ngày không có dòng |
Không có số liệu |
0 lượt xem |
404 cả khoảng |
Không có dữ liệu |
Trang không tồn tại |
end vượt ngày hiện tại |
Chỉ trả ngày đã có |
Các ngày sau bằng 0 |
Đầu ra nghiệm thu: Bảng project article timestamp views và kiểm URL encoding cùng ngày thiếu của Wikimedia Pageviews API
Phần này liệt kê điều kiện để coi bảng là xong.
Tệp bảng lượt xem
Mỗi dòng một ngày của một trang theo một bộ lọc. Có đủ các cột tham số ở phần trước. Ngày thiếu có dòng với views rỗng và status khong_co_dong.
Kiểm mã hóa
Mọi dòng có article_returned khớp article_requested sau chuẩn hóa. Lab chạy kiểm này trên các ca mẫu: C++ không mã hóa ra C__, bị đánh dấu lệch. Các ca mã hóa đủ đều khớp.
Kiểm ngày thiếu
Mỗi trang có số ngày có dòng, số ngày thiếu và danh sách ngày thiếu. Chùa Keo ghi 28, 3 và danh sách 05, 11, 22/10. Trang trả 404 ghi 0 ngày có dòng, 31 ngày thiếu, lý do 404.
Kiểm cộng dồn
Tổng agent con bằng all-agents, tổng access con bằng all-access, tổng daily bằng monthly. Lab kiểm với Phở và Hà Nội, đều khớp.
Mã kiểm tên trang trả về
Hàm kiểm lấy article đầu tiên trong items, so với tên đã chuẩn hóa NFC và thay khoảng trắng. Khác nhau thì gắn cờ name_mismatch cho mọi dòng của trang đó. Với dữ liệu lab, ca C++ không mã hóa sẽ bật cờ vì article trả về là C__, các ca còn lại khớp tên.
Bảng nghiệm thu của lab
Bảng nghiệm thu lượt xem
Hạng mục |
Kết quả 05/11/2026 |
|---|---|
AC/DC không mã hóa |
404 invalid route |
C++ không mã hóa |
200 nhưng trang C__ |
Tổng agent Phở |
3409 + 962 + 704 = 5075 |
Daily và monthly Hà Nội |
34276 = 34276 |
Chùa Keo |
28 ngày có dòng, 3 thiếu, 6 ngày 0 |
Trang ít xem và trang bịa |
Cùng 404 |
Tháng 11 gọi ngày 05/11 |
4 item tới 04/11 |
Những gì lab chưa chạy
Lab chưa thử granularity theo giờ của các endpoint khác, chưa thử project khác Wikipedia như Wiktionary, chưa thử top articles, chưa đo giới hạn tốc độ. Lab cũng chưa thử các tháng cũ nhiều năm, nơi cách phân loại agent có thể khác hiện nay.
Vận hành Wikimedia Pageviews API trong pipeline hằng ngày
Pipeline lượt xem chạy mỗi ngày, nên phải nhẹ và không ghi đè sai.
Lịch chạy
Số theo ngày có sau khi ngày đó kết thúc và được xử lý. Gọi ngày 05/11 thấy dữ liệu tới 04/11. Chạy pipeline một lần mỗi ngày, lấy ngày hôm qua, là đủ. Gọi nhiều lần trong ngày chỉ đọc lại cache.
Lấy theo khoảng thay vì từng ngày
Một lời gọi trả cả tháng cho một trang. Đừng gọi 31 lần cho 31 ngày. Với 100 trang theo dõi, một lượt cập nhật tháng chỉ cần 100 lời gọi, nghỉ khoảng một giây giữa các lời gọi là vừa.
Ghi đè có kiểm soát
Khi gọi lại một tháng cũ, so số mới với số đã lưu. Khác thì ghi bản mới kèm fetched_at mới, giữ bản cũ trong bảng lịch sử. Báo cáo dùng bản mới nhất, nhưng vẫn giải thích được vì sao số đổi.
Danh sách trang theo dõi
Danh sách trang nên lưu trong tệp riêng với các cột project, title, ghi chú, ngày thêm. Khi trang bị đổi tên, thêm dòng mới và ghi ngày đổi, không sửa dòng cũ. Pipeline đọc tệp này mỗi lượt chạy.
Theo dõi tỉ lệ bot
Lưu cả all-agents giúp phát hiện trang bị bot đẩy lượt xem. Khi tỉ lệ user trên all-agents của một trang tụt mạnh, có thể có crawler mới đang quét trang đó. Đây là tín hiệu để đọc kỹ trước khi báo cáo một đợt tăng quan tâm.
Xử lý lỗi
404 invalid route là lỗi mã hóa, sửa mã. 404 không có dữ liệu là trạng thái hợp lệ, ghi lại. 429 là gọi quá nhanh, giảm nhịp. 5xx thì thử lại sau, không quá ba lần.
Proxy ở tầng mạng
API Wikimedia công khai, gọi thẳng là cách nên dùng. Proxy chỉ cần khi mạng nội bộ bắt buộc. Proxy không làm API trả số khác, và dùng nhiều IP để vượt giới hạn tốc độ là trái chính sách. Cấu hình chuỗi proxy theo bài định dạng proxy, vai trò proxy trong thu thập có ở bài Web Scraping proxy là gì. Khi cần IP Việt Nam cho tác vụ khác, anh em có thể mua proxy tại trang chủ ProxyVN.
Kiểm định kỳ một trang mốc
Mỗi lượt chạy nên lấy thêm một trang mốc có lượng xem ổn định như Hà Nội. Nếu trang mốc bỗng trả 404 hoặc số giảm mạnh bất thường, lỗi nhiều khả năng nằm ở pipeline hoặc ở phía API, không nằm ở các trang đang theo dõi.
Khóa phiên bản
Lab chạy Python 3.12.10, requests 2.34.2 trên Windows. Đường dẫn rest_v1 và dạng path có thể đổi khi Wikimedia chuyển hẳn sang tên miền Analytics API mới. Ghi base URL vào cấu hình, không viết cứng trong nhiều chỗ.
Mã hóa tên trang đủ, so tên trang trả về, giữ ngày thiếu là rỗng. Ba việc đó chặn phần lớn lỗi số liệu lượt xem.
Wikimedia Pageviews API: câu hỏi thường gặp
Các câu dưới đây gom những điểm hay bị hỏi.
Có cần API key không?
Không. Chỉ cần User-Agent có tên công cụ và thông tin liên hệ.
Vì sao C++ ra số rất nhỏ?
Dấu cộng không mã hóa bị hiểu là khoảng trắng, API trả số của trang C__. Mã hóa thành C%2B%2B.
Ngày không có dòng có phải 0 lượt xem?
Không nên coi là 0. API không trả dòng cho ngày đó. Ghi rỗng và để người dùng quyết định.
404 có nghĩa là trang không tồn tại?
Không chắc. Trang ít người xem và trang bịa trả cùng một 404. Kiểm sự tồn tại bằng MediaWiki API.
Agent user có loại hết bot không?
Không. Nó loại bot được phân loại. Một phần traffic tự động vẫn có thể lọt vào nhóm user.
Lượt xem có cho biết số người đọc không?
Không. Một người có thể tạo nhiều lượt xem. Đừng gọi đây là số người dùng.
Có lấy được lượt xem theo giờ không?
Endpoint per-article dùng trong lab hỗ trợ daily và monthly. Lab chưa chạy dữ liệu theo giờ, nên không khẳng định ở đây.
Lượt xem của trang chuyển hướng có cộng vào trang đích không?
Pageviews đếm theo tên trang được yêu cầu. Muốn tính cả trang chuyển hướng, lấy danh sách chuyển hướng rồi gọi riêng từng tên.
Có nên cộng lượt xem nhiều ngôn ngữ?
Được, nếu bảng ghi rõ từng project và tổng chỉ là phép cộng có chú thích. Đừng trình bày tổng đó như lượt xem của một bài.
Wikimedia Pageviews API và những điều cần nhớ
Wikimedia Pageviews API trả số lượt xem đáng tin khi chọn đúng project, access và agent, mã hóa tên trang đủ mọi ký tự đặc biệt, và giữ ngày thiếu khác với ngày bằng 0. Kiểm tên trang trả về, kiểm cộng dồn giữa agent và access, lưu tham số cùng từng dòng, và không bao giờ diễn giải lượt xem thành số người. Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam khuyên anh em giữ bảng kiểm mã hóa và ngày thiếu như một phần cố định khi dùng Wikimedia Pageviews API.
