Báo cáo mặc định của GA4 trả lời rất tốt câu hỏi “có bao nhiêu phiên” nhưng gần như im lặng trước câu hỏi quan trọng hơn: những phiên đó có thật sự đọc bài không. Đây chính là khoảng trống mà custom dimensions và custom metrics sinh ra để lấp. Với người đang chạy chiến dịch traffic, đây là công cụ duy nhất cho phép bạn tự định nghĩa thước đo chất lượng thay vì chấp nhận bộ chỉ số đóng gói sẵn của Google.
Bài viết này hướng dẫn bạn hiểu đúng bản chất hai khái niệm, phân biệt ba phạm vi dữ liệu, triển khai đầy đủ qua GTM và quan trọng nhất: chọn đúng bộ tham số để đối soát traffic user thay vì đo cho có.
Custom Dimensions Và Custom Metrics Trong GA4 Là Gì?
Mọi báo cáo trong GA4 đều được dựng từ hai loại thành phần. Dimension (chiều dữ liệu) là thuộc tính mô tả — nó trả lời “ai”, “cái gì”, “ở đâu”, giá trị là chuỗi văn bản và thường nằm ở cột đầu tiên trong bảng. Metric (chỉ số) là con số đo lường — nó trả lời “bao nhiêu”, giá trị cộng dồn được và nằm ở các cột số phía sau.
GA4 cung cấp sẵn hàng trăm dimension và metric dựng sẵn: nguồn traffic, thiết bị, quốc gia, số phiên, tỷ lệ tương tác. Nhưng chúng đều là những thứ Google cho rằng ai cũng cần. Khi bạn cần đo một thứ đặc thù cho website của mình — chẳng hạn “bài này thuộc chuyên mục nào”, “người dùng đã đọc bao nhiêu giây”, “phiên này đến từ lô traffic ngày mấy” — Google không thể đoán trước được. Đó là lúc bạn tự khai báo.
Custom dimension là chiều dữ liệu do bạn tự định nghĩa, lấy giá trị từ một tham số (parameter) mà bạn gửi kèm vào event hoặc gán cho người dùng. Custom metric tương tự nhưng lấy giá trị dạng số và có thể tính tổng, tính trung bình.
Nếu bạn còn chưa nắm chắc cơ chế event và parameter, nên đọc trước bài Google Analytics 4 là gì để có nền tảng, vì toàn bộ phần sau đều xây trên đó.
Ba Phạm Vi (Scope) Và Hạn Mức Slot Cần Nhớ
Chọn sai scope là lỗi phổ biến nhất khi khai báo, và hậu quả là dữ liệu về nhưng báo cáo hiển thị sai lệch. GA4 có ba phạm vi:
Event-scoped — giá trị gắn với đúng một event. Đây là scope dùng nhiều nhất: mỗi lần người dùng xem một trang, tham số `content_type` đi kèm event đó mô tả riêng trang đó. Khi người dùng chuyển sang trang khác, giá trị mới ghi đè trong phạm vi event mới, không ảnh hưởng ngược lại.
User-scoped — giá trị gắn với người dùng và tồn tại xuyên suốt các phiên cho tới khi bị ghi đè. Phù hợp cho thuộc tính bền như “hạng thành viên”, “đã đăng ký hay chưa”. Nhược điểm là dữ liệu quá khứ không được gán lại: nếu hôm nay bạn gán `user_tier = premium`, các phiên tuần trước của người đó vẫn giữ giá trị cũ hoặc rỗng.
Item-scoped — chỉ dùng trong ngữ cảnh thương mại điện tử, gắn với từng sản phẩm trong mảng `items`. Ví dụ: chất liệu, size, nhà cung cấp.
Về hạn mức, tài khoản GA4 tiêu chuẩn cho phép 50 custom dimension event-scoped, 25 user-scoped và 10 item-scoped, cùng 50 custom metric. Con số nghe rất rộng rãi, nhưng có hai điều cần lưu ý: slot đã dùng chỉ có thể lưu trữ (archive) chứ không xóa hẳn khỏi lịch sử, và mỗi dimension khai báo thừa đều làm tăng nguy cơ báo cáo bị lấy mẫu khi dữ liệu lớn. Nguyên tắc thực dụng: chỉ khai báo tham số bạn đã biết chắc sẽ đưa vào báo cáo nào.
Quy Trình 5 Bước Triển Khai Chi Tiết
Bước 1 — Gửi tham số vào event. Việc khai báo trong giao diện GA4 chỉ có tác dụng khi dữ liệu đã thực sự chảy về. Cách phổ biến nhất là qua Google Tag Manager: trong thẻ GA4 Event, mở mục Event Parameters và thêm cặp tên–giá trị, với giá trị lấy từ một Variable (Data Layer Variable, DOM Element, hoặc biến tùy chỉnh). Nếu bạn chưa dựng GTM, xem hướng dẫn tại bài Google Tag Manager là gì.
Quy ước đặt tên rất đáng đầu tư ngay từ đầu: dùng snake_case toàn chữ thường (`reading_seconds`, không phải `ReadingSeconds`), tránh tiền tố `ga_`, `google_`, `firebase_` vì đây là tiền tố hệ thống bị chặn, và giữ độ dài dưới 40 ký tự.
Bước 2 — Xác minh bằng DebugView. Bật chế độ preview trong GTM rồi mở Admin > DebugView trong GA4. Bấm vào từng event trong luồng thời gian để xem danh sách parameter thực tế đã về. Đây là bước không được bỏ qua: nếu tham số chưa về đúng ở đây, khai báo ở bước 3 sẽ chỉ tạo ra một cột trống vĩnh viễn.
Bước 3 — Khai báo trong giao diện. Vào Admin > Data display > Custom definitions > Create custom dimension (hoặc metric). Điền tên hiển thị (đây là tên sẽ xuất hiện trong báo cáo, nên viết tiếng Việt dễ hiểu), mô tả, và quan trọng nhất là ô Event parameter — phải nhập chính xác tên tham số ở bước 1, phân biệt chữ hoa chữ thường.
Bước 4 — Chọn scope và đơn vị đo. Với dimension, chọn Event hoặc User. Với metric, ngoài scope bạn còn phải chọn Unit of measurement: Standard (số đếm thuần), Currency (tiền tệ), Distance (mét, km), hoặc Time (giây, phút, giờ). Chọn sai đơn vị khiến GA4 định dạng hiển thị sai — ví dụ khai `reading_seconds` là Standard sẽ ra “185” thay vì “3 phút 5 giây”.
Bước 5 — Chờ dữ liệu điền vào báo cáo. Custom definition không hồi tố. Dữ liệu chỉ được gán từ thời điểm khai báo trở đi, và thường mất 24–48 giờ để hiển thị ổn định trong báo cáo chuẩn. Trong thời gian chờ, bạn có thể dùng Explore để xem trước.
Bộ Chỉ Số Riêng Nên Đo Cho Traffic User
Đây là phần có giá trị thực tế nhất với người đang chạy chiến dịch traffic. Báo cáo mặc định chỉ cho bạn biết số phiên và tỷ lệ tương tác — hai con số dễ trông đẹp mà không nói được gì về chất lượng. Bốn tham số dưới đây thay đổi hoàn toàn bức tranh:
| Tham số | Loại | Scope | Trả lời câu hỏi |
|---|---|---|---|
| reading_seconds | Metric (Time) | Event | Người dùng ở lại thật bao lâu trên trang? |
| scroll_depth_pct | Metric (Standard) | Event | Họ cuộn tới đâu, hay thoát ngay đầu bài? |
| traffic_batch | Dimension | Event | Phiên này thuộc lô traffic nào? |
| content_type | Dimension | Event | Loại nội dung nào giữ chân tốt nhất? |
reading_seconds là chỉ số quan trọng nhất trong nhóm. GA4 mặc định chỉ có `engagement_time_msec` gộp chung toàn phiên, không tách theo trang. Khi bạn tự đo thời gian đọc từng bài và đưa vào một custom metric dạng Time, bạn có được thước đo gần nhất với khái niệm dwell time — thứ mà Google thực sự quan tâm nhưng không cung cấp sẵn cho bạn.
scroll_depth_pct bổ sung góc nhìn còn thiếu. Một phiên 90 giây nhưng cuộn 8% là dấu hiệu tab bị bỏ quên, không phải người đọc thật. Kết hợp hai chỉ số cho bạn ma trận bốn ô: đọc lâu + cuộn sâu (chất lượng cao), đọc lâu + cuộn nông (nghi tab nền), đọc nhanh + cuộn sâu (đọc lướt), đọc nhanh + cuộn nông (dấu hiệu pogo-sticking).
traffic_batch giải quyết bài toán quy kết. Khi bạn chạy nhiều lô traffic khác nhau, việc chỉ nhìn kênh tổng không cho biết lô nào hiệu quả. Gắn nhãn lô ngay từ URL đích rồi đọc vào dimension cho phép so sánh trực tiếp — đây là bổ sung tự nhiên cho hệ thống gắn thẻ UTM bạn đang dùng.
content_type giúp trả lời câu hỏi chiến lược: dạng nội dung nào giữ chân tốt nhất. Khi bạn biết bài hướng dẫn giữ người đọc lâu gấp đôi bài tin tức, kế hoạch xây cụm chủ đề của bạn có căn cứ số liệu thay vì cảm tính.
Cách Đọc Dữ Liệu Trong Explore Và Báo Cáo Chuẩn
Custom definition xuất hiện ở ba nơi. Trong Explore, bạn kéo chúng vào phần Dimensions/Metrics của biến rồi dựng bảng tự do — đây là nơi linh hoạt nhất và cũng là nơi dữ liệu hiện sớm nhất. Trong báo cáo chuẩn, bạn dùng nút chỉnh sửa báo cáo để thêm chúng làm dimension chính hoặc phụ. Trong Audiences, chúng trở thành điều kiện phân nhóm người dùng.
Một mẫu bảng đối soát dùng được ngay: dimension chính là `traffic_batch`, dimension phụ là `content_type`, các cột metric gồm số phiên, `reading_seconds` trung bình và `scroll_depth_pct` trung bình. Bảng này cho biết chính xác lô nào mang lại hành vi giống người đọc thật, thay vì chỉ đếm đầu phiên. Nếu bạn chưa quen thao tác báo cáo, bài cách đọc báo cáo GA4 đi chi tiết hơn về phần này.
Lưu ý về giá trị “(not set)”: khi một event không mang tham số tương ứng, GA4 hiển thị “(not set)”. Tỷ lệ này cao bất thường có hai nguyên nhân phổ biến — tham số chỉ được gắn trên một số trang, hoặc tên tham số khai báo lệch so với tên thực gửi đi. Cả hai đều kiểm tra được trong DebugView.
Sai Lầm Thường Gặp Khi Dùng Custom Definitions
- Khai báo trước, gắn tham số sau. Thứ tự ngược này tạo ra cột dữ liệu trống mà nhiều người tưởng là lỗi GA4. Luôn xác minh trong DebugView trước.
- Nhầm dimension với metric. Gửi một con số dưới dạng dimension khiến mỗi giá trị thành một hàng riêng — 500 giá trị khác nhau tạo ra bảng 500 dòng vô dụng và làm phình cardinality.
- Cardinality quá cao. Dimension có quá nhiều giá trị duy nhất (ví dụ gán ID phiên) khiến GA4 gộp phần đuôi vào “(other)”. Giữ số giá trị duy nhất trong khoảng vài chục là an toàn.
- Đưa dữ liệu định danh cá nhân vào tham số. Email, số điện thoại, tên đầy đủ đều vi phạm chính sách GA4 và có thể dẫn tới xóa dữ liệu. Nếu cần định danh, dùng ID đã băm.
- Chọn User-scope cho thuộc tính hay thay đổi. User-scope ghi đè và không hồi tố, nên dùng cho thuộc tính hay đổi sẽ khiến báo cáo lịch sử mâu thuẫn với hiện tại.
- Quên chọn Unit of measurement cho metric thời gian. Đây là lỗi nhỏ nhưng khiến toàn bộ số liệu hiển thị sai định dạng và không thể sửa hồi tố.
Kết Hợp Custom Definitions Với Chiến Lược Traffic
Điểm mấu chốt: chỉ số riêng không tự cải thiện thứ hạng, nhưng nó cho bạn bằng chứng để quyết định. Khi bạn có `reading_seconds` theo từng lô traffic, việc đánh giá hiệu quả chiến dịch sau 30 ngày chuyển từ phỏng đoán sang đối chiếu số liệu. Khi bạn thấy một dạng nội dung có scroll depth thấp bất thường, đó là chỉ dẫn cụ thể để sửa bố cục bài viết chứ không phải viết lại toàn bộ.
Lộ trình thực tế nên bắt đầu nhỏ: khai báo đúng bốn tham số ở bảng trên, chạy hai tuần để tích đủ dữ liệu, rồi mới mở rộng. Khai báo 20 dimension ngay từ đầu gần như luôn dẫn tới việc 15 trong số đó không bao giờ được nhìn tới.
Câu Hỏi Thường Gặp
Custom dimension có làm chậm website không?
Không đáng kể. Tham số được gửi kèm event đã có sẵn, không tạo thêm request mạng. Phần có thể ảnh hưởng tốc độ là code JavaScript bạn viết để tính giá trị (ví dụ theo dõi scroll) — nên dùng throttle và passive listener.
Tại sao dữ liệu đã về DebugView nhưng báo cáo vẫn trống?
Ba nguyên nhân theo thứ tự phổ biến: chưa đủ 24–48 giờ kể từ lúc khai báo; tên tham số trong ô Event parameter lệch so với tên thực gửi (phân biệt hoa thường); hoặc bạn đang xem khoảng thời gian trước ngày khai báo — custom definition không hồi tố.
Có thể xóa custom dimension đã tạo để lấy lại slot không?
Bạn chỉ có thể lưu trữ (archive), không xóa vĩnh viễn. Slot được giải phóng sau khi archive, nhưng dữ liệu lịch sử gắn với nó sẽ không còn truy vấn được trong báo cáo. Cân nhắc kỹ trước khi archive một dimension đã tích lũy dữ liệu dài.
Custom metric khác gì Calculated metric?
Custom metric nhận giá trị trực tiếp từ tham số bạn gửi lên. Calculated metric là công thức tính từ các metric đã có sẵn trong GA4 (ví dụ doanh thu chia số phiên), không cần gửi thêm dữ liệu. Hai thứ bổ sung cho nhau chứ không thay thế.
Nên khai báo bao nhiêu custom dimension là hợp lý?
Với website nội dung thông thường, 5–10 dimension event-scoped là đủ cho hầu hết nhu cầu phân tích. Tiêu chí đơn giản: nếu bạn không nêu được ngay báo cáo nào sẽ dùng nó, đừng khai báo.
Tổng Kết
Custom dimensions và custom metrics là ranh giới giữa việc xem số liệu GA4 và việc đo đúng thứ mình cần. Với người chạy traffic, chúng biến một dashboard chung chung thành hệ thống đối soát chất lượng: bạn biết lô nào cho hành vi giống người đọc thật, dạng nội dung nào giữ chân tốt, và trang nào cần sửa trước.
Ba việc nên làm ngay: gắn `reading_seconds` và `scroll_depth_pct` qua GTM, khai báo `traffic_batch` để tách từng chiến dịch, và dựng một bảng Explore đối soát theo mẫu ở trên. Sau hai tuần dữ liệu, bạn sẽ có căn cứ thật để quyết định thay vì tin vào con số phiên.
Zalo