fbclid, gclid, msclkid là mã nhận dạng lượt nhấp gắn vào liên kết. Chúng ghi lại gì, vì sao chặn cookie không đủ, và Safari, Brave loại bỏ gì.
Bạn nhấp vào một liên kết trong bảng tin, và địa chỉ của trang vừa mở có thêm một đoạn đuôi dài: ?fbclid=IwAR… hoặc ?gclid=Cj0K…. Bạn không hề gõ đoạn đó, và bỏ nó đi thì trang vẫn hiển thị như cũ. Vậy nó là gì, có đang theo dõi bạn không? Trả lời ngắn gọn: có, đó chính là công dụng của nó. Bài này giải thích click ID là gì, vì sao chúng vẫn hoạt động khi cookie bị chặn, trình duyệt xử lý chúng thế nào và khi nào có thể xóa an toàn.
Điểm chính
fbclid,gclidvàmsclkidlà mã nhận dạng lượt nhấp. Chúng lần lượt do Meta (Facebook), Google Ads và Microsoft Ads gắn vào liên kết, để nền tảng nối được lượt truy cập trên một trang khác với lượt nhấp đã dẫn đến nó.- Chúng khác với thẻ
utm_. Thẻutm_campaign=springgiống nhau với mọi người nhấp vào chiến dịch đó. Click ID gắn với một lượt nhấp, nên các tính năng bảo vệ quyền riêng tư như bộ lọc của Brave xử lý hai loại này khác nhau. - Chúng nằm trong URL, không nằm trong bộ nhớ lưu trữ. Chặn cookie bên thứ ba và phân vùng bộ nhớ không đụng tới mã nhận dạng đi kèm ngay trong địa chỉ.
- Một số trình duyệt đã loại bỏ chúng. Brave xóa các click ID trong danh sách của mình khỏi yêu cầu xuyên trang; Safari chặn các tham số truy vấn theo dõi đã biết trong chế độ duyệt riêng tư và hạn chế những gì script fingerprinting đã biết có thể đọc từ URL.
- Xóa tham số trước khi chia sẻ liên kết thường vô hại, nhưng không phải lúc nào cũng vậy: một số trang lưu dữ liệu thực sự cần thiết trong chuỗi truy vấn.
Click ID là gì
Khi bạn nhấp vào quảng cáo, hoặc vào liên kết được chia sẻ trong một nền tảng, nền tảng có thể viết lại địa chỉ đích để nó mang theo một token trông như chuỗi ngẫu nhiên:
| Tham số | Do ai thêm | Tên đầy đủ |
|---|---|---|
fbclid | Meta (Facebook) | Facebook Click Identifier |
gclid | Google Ads | Google Click Identifier |
msclkid | Microsoft Advertising | Tham số tương đương gclid của Microsoft |
Token đến trang đích bằng hai đường cùng lúc: máy chủ nhận được nó trong yêu cầu tải trang, còn script phân tích hoặc quảng cáo của trang có thể đọc nó từ địa chỉ và gửi lại cho nền tảng. Nhờ đó nền tảng có thể khớp lượt truy cập với lượt nhấp ban đầu và, nếu bạn đang đăng nhập ở đó, có thể khớp luôn với tài khoản của bạn. Đó là cách nhà quảng cáo biết lượt nhấp này đã dẫn đến đơn hàng kia. Nhóm quyền riêng tư của Brave mô tả cùng chuỗi này trong bài viết về việc loại bỏ tham số truy vấn: các giá trị này được thêm vào URL bạn nhấp để nhà quảng cáo biết thêm về bạn và hành vi của bạn trên web.
Kỹ thuật chung này gọi là link decoration (trang trí liên kết): bên theo dõi thêm một tham số truy vấn định danh vào liên kết khi bạn rời một trang, rồi đọc lại khi bạn đến trang khác, nhờ đó nối hành vi của bạn giữa hai trang độc lập. Biến thể dùng chuyển hướng cũng dựa vào nó để mang mã, như đã trình bày ở bài bounce tracking, nên cơ chế đó không được lặp lại ở đây.
Click ID so với thẻ chiến dịch
Không phải tham số nào cũng mang tính cá nhân, và chính điều này quyết định tham số nào bị loại bỏ:
- Thẻ chiến dịch (
utm_source,utm_medium,utm_campaign) mô tả khách đến từ đâu. Mọi người nhấp cùng một liên kết trong bản tin đều mang giá trị giống nhau. Chúng trả lời câu hỏi "chiến dịch nào hiệu quả" mà không chỉ đích danh ai. - Click ID mô tả một lượt nhấp. Nếu giá trị là duy nhất, nó có thể được ghép với mọi thứ nền tảng đã biết về người nhấp.
Query String Filter của Brave nêu thẳng thiết kế này: nhắm vào các tham số được biết là gắn riêng với một người dùng, một địa chỉ email hoặc một lượt nhấp, mà không can thiệp vào việc theo dõi tổng quát ở cấp chiến dịch.
Vì sao chặn cookie không ngăn được chúng
Chặn cookie bên thứ ba và phân vùng bộ nhớ đều hạn chế những gì một bên thứ ba được nhúng có thể lưu và đọc lại giữa các trang. Còn click ID không cần bên thứ ba lưu gì cả. Nó đi cùng lần điều hướng, cả máy chủ của trang đích lẫn script của chính trang đó (ngữ cảnh bên thứ nhất) đều thấy nó, rồi trang chuyển nó cho nền tảng. Với trình duyệt, đó chỉ là một script bên thứ nhất bình thường gửi một yêu cầu bình thường.
Xóa cookie sau đó cũng không thay đổi được điều này. ID đã được gắn vào lúc nhấp và đã được gửi đi, còn một hồ sơ trình duyệt sạch nhấp cùng quảng cáo đó sẽ chỉ nhận một ID mới. Vì thế trình duyệt phải coi chính URL là thứ cần làm sạch.
Trình duyệt làm gì
Mỗi biện pháp dưới đây đều hẹp hơn "chặn mọi theo dõi", nên hãy đọc kỹ phạm vi.
Brave. Query String Filter xóa các tham số trong danh sách (cả tên và giá trị) trước khi thực hiện yêu cầu GET xuyên trang (non-same-site), bao gồm điều hướng, tài nguyên con và chuyển hướng. Nhờ vậy tham số không bao giờ đến máy chủ, thanh địa chỉ hay tiêu đề Referer, và script trên trang không thể khôi phục nó. Có một ngoại lệ được nêu rõ: nếu liên kết hủy đăng ký trong email cần một tham số định danh người dùng để hoạt động, Brave sẽ giữ lại. Bài viết năm 2020 của Brave, đã dẫn ở trên, nêu fbclid, gclid và msclkid làm ví dụ về những gì nó loại bỏ.
Safari. Ghi chú của WebKit cho Safari 17.0 liệt kê chặn các tham số truy vấn theo dõi đã biết trong liên kết trong số các bảo vệ mới của chế độ duyệt riêng tư. Ngoài ra, ghi chú của WebKit cho Safari 26.0 cho biết Safari ngăn các script fingerprinting đã biết đọc những dữ liệu có thể dùng để theo dõi điều hướng, như tham số truy vấn và document.referrer. Ở chế độ duyệt thông thường, Intelligent Tracking Prevention còn giới hạn thời hạn của cookie do script tạo trên trang đích bị nhận diện là có link decoration xuống 24 giờ; chi tiết ở bài Safari ITP từng cơ chế một.
Firefox. Chính sách chống theo dõi của Mozilla xếp việc trang trí URL vào dạng theo dõi xuyên trang qua điều hướng và cho biết Firefox "sẽ tìm cách xác định các tham số truy vấn mà trang web dùng để theo dõi" rồi xóa chúng khỏi các lần điều hướng cấp cao nhất xuyên trang. Ngoại lệ là việc ghi nhận nguồn (attribution) không gắn với từng người dùng cụ thể. Đây là một tuyên bố chính sách, không phải danh sách tham số hay lời hứa về cài đặt của bạn, nên đừng xem đó là sự đảm bảo cho bất kỳ tham số nào trong ba tham số này.
Chrome và các trình duyệt Chromium khác. Chúng tôi chưa xác minh được nguồn chính thức để trích dẫn, nên không đưa ra khẳng định nào ở đây. Với mọi trình duyệt đều có cách kiểm tra đơn giản: nhấp vào một liên kết có tham số này và xem nó có còn trên thanh địa chỉ khi trang mở ra không.
Tiêu đề Referer có rủi ro tương tự
Địa chỉ của trang bạn vừa rời đi cũng được gửi cho trang tiếp theo trong tiêu đề Referer. Nếu địa chỉ đó chứa click ID, ID có thể đi xa thêm một trang nữa. Trình duyệt hiện mặc định gửi giá trị đã cắt gọn: theo MDN, khi không đặt chính sách, mặc định là strict-origin-when-cross-origin, chỉ gửi origin với yêu cầu HTTPS khác nguồn và không gửi tiêu đề này khi đi từ HTTPS sang HTTP. Xem danh sách chính sách đầy đủ trong tài liệu Referrer-Policy của MDN. Safari còn đi xa hơn khi cắt mọi referrer bên thứ ba xuống còn origin, như bài về ITP đã dẫn ở trên giải thích.
Có nên xóa tham số không?
Khi chia sẻ liên kết thì thường là nên. Nếu phần trước dấu ? là địa chỉ bài viết hoặc sản phẩm bình thường, bạn có thể xóa mọi thứ từ ? trở đi và trang thường vẫn tải y như cũ. Nếu địa chỉ còn có các tham số khác, cách an toàn hơn là chỉ xóa đoạn fbclid=… (hoặc gclid=…, msclkid=…) và giữ lại phần còn lại. Dù cách nào, người nhận cũng sẽ không mang theo ID từ lượt nhấp của bạn, và liên kết ngắn hơn.
Hai lưu ý. Một số ứng dụng giữ dữ liệu thực sự cần thiết trong chuỗi truy vấn (từ khóa tìm kiếm, số trang, token phiên hoặc lời mời), xóa đi sẽ làm trang thay đổi hoặc hỏng, nên hãy mở thử liên kết đã làm sạch một lần trước khi gửi. Và xóa tham số không hoàn tác được lượt nhấp đã xảy ra: nền tảng đã thấy nó ngay lúc bạn nhấp. Chúng tôi không đề xuất tiện ích hay công cụ cụ thể nào; nếu trình duyệt có sẵn tính năng bảo vệ, hãy dùng nó.
URL đã làm sạch vẫn để lại gì
Loại bỏ click ID chỉ loại đi một mã nhận dạng tường minh. Trang web vẫn có thể nhận ra bạn mà không cần ai đưa mã, từ tổ hợp các thuộc tính trình duyệt để lộ. Đó là browser fingerprinting. Đây là lý do ID khách truy cập bền vững vẫn tồn tại sau khi xóa cookie, và cũng là lý do hướng dẫn về browser fingerprinting quan trọng không kém việc làm sạch URL.
Nói rõ về BrowserInsight: các công cụ của chúng tôi không kiểm tra liên kết bạn nhấp hay URL bạn truy cập. Kiểm tra vân tay chạy hoàn toàn trong trình duyệt của bạn và cho thấy trang web có thể đọc được gì về trình duyệt đó — lớp mà tính năng làm sạch URL không xóa được.
Câu hỏi thường gặp
fbclid có phải virus hay dấu hiệu tài khoản bị hack không?
Không. Nó chỉ là văn bản thuần trong địa chỉ và không chạy gì trên thiết bị của bạn. Việc nhìn thấy nó chỉ có nghĩa là liên kết đã đi qua một nền tảng có thêm click ID. Điều đáng quan tâm là quyền riêng tư, không phải phần mềm độc hại.
gclid nghĩa là gì?
Đó là viết tắt của Google Click Identifier. Với Google Ads, nó làm cùng việc mà fbclid làm cho Meta và msclkid làm cho Microsoft Advertising.
VPN hoặc cửa sổ riêng tư có xóa được click ID không?
VPN đổi địa chỉ IP của bạn chứ không đổi liên kết, nên ID vẫn đến nơi. Bản thân cửa sổ riêng tư cũng không đổi liên kết. Chế độ duyệt riêng tư của Safari nêu ở trên là một biện pháp bảo vệ cụ thể, không phải điều được ghi nhận cho chế độ riêng tư của mọi trình duyệt.
Kết luận
fbclid, gclid và msclkid là mã nhận dạng một lượt nhấp được ghi ngay vào liên kết, nên chúng vượt qua các biện pháp phòng vệ ở tầng cookie và bộ nhớ. Một số trình duyệt đang lấp khoảng trống này bằng cách làm sạch URL, nhưng mức độ bao phủ khác nhau tùy trình duyệt và chế độ. Xóa chúng khỏi liên kết bạn chia sẻ là thói quen hợp lý; chỉ cần nhớ rằng URL chỉ là một trong nhiều nguồn có thể cung cấp mã nhận dạng.
Đọc thêm:
