Đo lường virtual tour bằng GA4 và GTM: sự kiện, postMessage, funnel

Nguyên nhân không phải GA4 kém. Tour 360 thường chạy trong một iframe, là một trang web riêng nằm lồng trong trang của bạn. Thẻ GA4 trên trang mẹ không nhìn được vào bên trong iframe đó. Người xem có thể đi qua mười cảnh, mở năm bảng thông tin, bấm nút gọi hotline ngay trong tour, và trang mẹ không biết gì.

Bài này hướng dẫn cách mở “hộp đen” đó: nên đo những sự kiện nào, lấy chúng từ engine dựng tour ra sao, đưa chúng qua ranh giới iframe an toàn, cấu hình Google Tag Manager và GA4, rồi dùng dữ liệu để sửa tour, đặt CTA và chạy remarketing. Bài viết dành cho người làm marketing cần hiểu đủ để giao việc, và cho lập trình viên cần mã mẫu để bắt tay vào làm.

Đo lường virtual tour bằng GA4: vì sao tour 360 là “hộp đen”

Một trang web thông thường được GA4 theo dõi khá đầy đủ nhờ các sự kiện tự động: xem trang, cuộn trang, bấm link ra ngoài. Tour 360 thì khác ở ba điểm.

Thứ nhất, toàn bộ tương tác trong tour không tạo ra lượt tải trang mới. Chuyển từ phòng khách sang phòng ngủ chỉ là engine thay ảnh panorama trên cùng một trang, nên GA4 không có lý do gì để ghi nhận.

Thứ hai, tour thường nằm trong iframe, đôi khi ở một tên miền hoặc tên miền phụ khác (ví dụ tour.tencongty.vn nhúng vào tencongty.vn). Trình duyệt cách ly hai trang này với nhau vì lý do bảo mật. Trang mẹ không đọc được trạng thái bên trong iframe, và ngược lại.

Thứ ba, nếu bạn đặt thêm một thẻ GA4 riêng bên trong trang tour, dữ liệu sẽ bị tách thành hai phiên, hai nguồn truy cập, và còn gặp giới hạn cookie bên thứ ba khi iframe ở tên miền khác. Kết quả là báo cáo rời rạc, khó ghép với chiến dịch quảng cáo đã đưa khách vào.

Hậu quả thực tế: bạn không biết khách dừng ở cảnh nào rồi rời đi, không biết hotspot nào được bấm nhiều, và không thể tạo tệp đối tượng gồm những người đã xem kỹ một căn hộ cụ thể để quảng cáo lại. Cách làm đúng là để tour “kể” cho trang mẹ biết điều gì vừa xảy ra, rồi trang mẹ gửi tất cả về một thuộc tính GA4 duy nhất.

Nên đo những sự kiện nào

Sai lầm hay gặp là muốn đo mọi thứ: mỗi lần xoay chuột, mỗi lần phóng to. Dữ liệu như vậy tốn hạn mức, khó đọc và hiếm khi dẫn đến quyết định nào. Bộ sự kiện dưới đây đủ để trả lời các câu hỏi kinh doanh quan trọng, và dễ mở rộng sau.

Một vài tham số bổ trợ đáng cân nhắc:

• tour_id
  : khi một website có nhiều tour (nhiều dự án, nhiều chi nhánh), tham số này cho phép lọc báo cáo theo từng tour.
• scene_id
  : định danh kỹ thuật của cảnh, đi kèm
  scene_name
  dễ đọc. Khi đổi tiêu đề hiển thị,
  scene_id
  giữ cho dữ liệu cũ và mới vẫn nối được với nhau.
• seconds_in_scene
  : số giây người xem ở cảnh vừa rời, gửi kèm
  scene_change
  . Đây là cách thực tế để biết cảnh nào giữ chân người xem, thay vì chỉ dựa vào thời gian tương tác chung của cả trang.
• lead_method
  : gửi kèm
  tour_lead_submit
  để tách form, gọi điện và Zalo.

Lưu ý về chuyện gọi điện: GA4 chỉ ghi nhận được việc khách bấm vào nút gọi, không biết cuộc gọi có thực sự kết nối hay không. Nếu cần đo cuộc gọi thật, phải dùng thêm giải pháp theo dõi cuộc gọi của tổng đài.

Lấy sự kiện từ engine dựng tour

Engine dựng tour là phần mềm tạo ra trình phát tour HTML5, phổ biến nhất là Pano2VR và krpano. Cả hai đều cho phép chạy JavaScript khi có sự kiện, nên việc bắt sự kiện không cần sửa mã lõi. Cú pháp cụ thể có thể khác giữa các phiên bản, vì vậy luôn đối chiếu với tài liệu của phiên bản bạn đang dùng.

Pano2VR

Trình phát của Pano2VR có Player API cho phép đăng ký hàm lắng nghe sự kiện. Sự kiện quan trọng nhất là changenode, phát ra mỗi khi chuyển sang cảnh mới (Pano2VR gọi mỗi cảnh là một “node”). Ví dụ trong trang index.html mà Pano2VR xuất ra, đối tượng trình phát thường có tên pano:

var sceneEnteredAt = Date.now();
var lastScene = null;

pano.addListener('changenode', function () {
  var id = pano.getCurrentNode();
  var data = pano.getNodeUserdata(id) || {};
  var now = Date.now();

  sendTourEvent('scene_change', {
    scene_id: id,
    scene_name: data.title || id,
    previous_scene: lastScene,
    seconds_in_scene: lastScene ? Math.round((now - sceneEnteredAt) / 1000) : 0
  });

  lastScene = data.title || id;
  sceneEnteredAt = now;
});

Với hotspot, Pano2VR cho phép gắn hành động chạy JavaScript vào hotspot hoặc phần tử giao diện (skin). Bạn gọi sendTourEvent('hotspot_click', { hotspot_id: '...', category: '...' }) trong hành động đó. Nếu tour có form liên hệ nằm trong skin, hãy gọi tour_lead_submit ở bước gửi thành công, không phải ở lúc bấm nút mở form.

Chi tiết về Player API, Skin Editor và Logic Blocks có trong bài Pano2VR là gì.

krpano

krpano mô tả tour bằng XML và có phần tử <events> để gắn hành động vào các sự kiện của trình phát. Sự kiện onnewpano chạy khi cảnh mới được nạp. Hành động js() gọi một hàm JavaScript trên trang:

<events name="tracking" keep="true"
        onnewpano="js(onTourScene(get(xml.scene)));" />

<hotspot name="hs_bep_vat_lieu" ...
         onclick="js(onTourHotspot(get(name), 'vat_lieu')); ..." />

function onTourScene(sceneName) {
  sendTourEvent('scene_change', { scene_name: sceneName });
}
function onTourHotspot(id, category) {
  sendTourEvent('hotspot_click', { hotspot_id: id, category: category });
}

Thuộc tính keep="true" giữ phần tử sự kiện không bị xoá khi chuyển cảnh, nếu thiếu nó bạn chỉ ghi được cảnh đầu tiên.

Sự kiện tour_start

Cả hai engine đều không có sẵn một sự kiện mang nghĩa “người xem bắt đầu tương tác”. Cách đơn giản và ổn định là lắng nghe thao tác đầu tiên trên vùng chứa tour, chỉ một lần:

var tourStarted = false;
['pointerdown', 'wheel', 'keydown'].forEach(function (type) {
  document.addEventListener(type, function () {
    if (tourStarted) return;
    tourStarted = true;
    sendTourEvent('tour_start', { tour_id: 'du_an_a' });
  }, { once: true, passive: true });
});

Đưa sự kiện ra trang mẹ

Đến đây, tour đã biết điều gì vừa xảy ra và gọi hàm sendTourEvent. Việc còn lại là viết hàm đó để chuyển sự kiện ra trang mẹ, nơi Google Tag Manager đang chạy. Cách làm phụ thuộc vào việc tour và trang mẹ có cùng origin hay không. Origin gồm giao thức, tên miền và cổng: https://tencongty.vn và https://tour.tencongty.vn là hai origin khác nhau, dù cùng tên miền gốc.

Cùng origin: gọi thẳng dataLayer của trang mẹ

Nếu thư mục tour nằm trên chính tên miền website (ví dụ https://tencongty.vn/tour/du-an-a/), trang tour được phép truy cập đối tượng window.parent. Khi đó chỉ cần đẩy sự kiện thẳng vào dataLayer của trang mẹ:

function sendTourEvent(name, params) {
  var target = window.parent !== window ? window.parent : window;
  target.dataLayer = target.dataLayer || [];
  target.dataLayer.push(Object.assign({ event: name }, params || {}));
}

Đây là cách gọn nhất, nhưng chỉ chạy được khi cùng origin. Nếu sau này tour được chuyển sang tên miền phụ hoặc CDN, trình duyệt sẽ chặn truy cập window.parent.dataLayer và đo lường ngừng hoạt động mà không có thông báo lỗi rõ ràng trên giao diện. Vì vậy nhiều đội chọn dùng luôn postMessage ngay từ đầu.

Khác origin: postMessage và kiểm tra event.origin

postMessage là cơ chế chuẩn của trình duyệt để hai trang khác origin gửi tin nhắn cho nhau. Bên trong tour, hàm sendTourEvent gửi một gói dữ liệu có cấu trúc lên trang mẹ, và chỉ định rõ origin được phép nhận:

// Chạy bên trong trang tour (iframe)
var PARENT_ORIGIN = 'https://tencongty.vn';

function sendTourEvent(name, params) {
  var message = {
    source: 'vr-tour',
    event: name,
    params: params || {}
  };
  if (window.parent !== window) {
    window.parent.postMessage(message, PARENT_ORIGIN);
  } else {
    // Tour được mở trực tiếp, không nằm trong iframe
    window.dataLayer = window.dataLayer || [];
    window.dataLayer.push(Object.assign({ event: name }, message.params));
  }
}

Trên trang mẹ, đặt một đoạn mã nhận tin nhắn (có thể đưa vào GTM dưới dạng thẻ Custom HTML chạy trên mọi trang có tour, hoặc chèn trong theme):

// Chạy trên trang mẹ, nơi có Google Tag Manager
(function () {
  var TOUR_ORIGINS = ['https://tour.tencongty.vn'];
  var ALLOWED = ['tour_start', 'scene_change', 'hotspot_click', 'tour_lead_submit'];

  window.dataLayer = window.dataLayer || [];

  window.addEventListener('message', function (e) {
    if (TOUR_ORIGINS.indexOf(e.origin) === -1) return;   // sai nguồn: bỏ qua
    var d = e.data;
    if (!d || d.source !== 'vr-tour') return;             // không phải tin của tour
    if (ALLOWED.indexOf(d.event) === -1) return;          // tên sự kiện lạ: bỏ qua

    var clean = { event: d.event };
    Object.keys(d.params || {}).forEach(function (k) {
      var v = d.params[k];
      if (typeof v === 'string' || typeof v === 'number') clean[k] = v;
    });
    window.dataLayer.push(clean);
  });
})();

Ba lớp kiểm tra trong đoạn mã trên đều có lý do. Kiểm tra e.origin ngăn một trang bất kỳ (ví dụ quảng cáo nhúng hoặc tiện ích chat) bơm sự kiện giả vào báo cáo của bạn. Kiểm tra source và danh sách tên sự kiện giúp tránh nhầm với tin nhắn từ các iframe khác như video YouTube hay bản đồ. Lọc kiểu dữ liệu tham số giữ cho dataLayer không nhận đối tượng lạ.

Một lưu ý quan trọng về dữ liệu cá nhân: không gửi họ tên, số điện thoại hay email mà khách nhập trong form qua postMessage hay dataLayer. Chính sách của Google Analytics không cho phép đưa thông tin định danh cá nhân vào GA4. Sự kiện tour_lead_submit chỉ cần báo “đã gửi thành công”, còn nội dung form đi thẳng về hệ thống CRM hoặc email của bạn.

Cách nhúng iframe, thuộc tính allow và tải lười trên WordPress được trình bày trong bài nhúng virtual tour vào WordPress.

Cấu hình Google Tag Manager và GA4

Khi sự kiện đã vào dataLayer, phần còn lại là cấu hình, không cần viết thêm mã. Quy trình dưới đây giả định website đã cài GTM và có thẻ Google (Google tag) cho thuộc tính GA4.

1. 01

   Tạo biến Data Layer cho từng tham số

   Trong GTM, vào Variables, tạo các biến kiểu Data Layer Variable: scene_name, scene_id, hotspot_id, category, seconds_in_scene, tour_id, lead_method. Tên biến phải trùng chính xác với khoá đã đẩy vào dataLayer.

2. 02

   Tạo trigger Custom Event

   Tạo một trigger kiểu Custom Event, bật tuỳ chọn dùng biểu thức chính quy, tên sự kiện là tour_start|scene_change|hotspot_click|tour_lead_submit. Một trigger cho cả bốn sự kiện giúp container gọn, dễ bảo trì.

3. 03

   Tạo thẻ GA4 Event

   Tạo thẻ Google Analytics: GA4 Event, chọn Measurement ID của thuộc tính, tên sự kiện dùng biến có sẵn {{Event}} để giữ nguyên tên gốc. Thêm các tham số sự kiện trỏ tới biến đã tạo ở bước một. Gắn trigger ở bước hai.

4. 04

   Kiểm thử bằng Preview và DebugView

   Bật chế độ Preview của GTM, mở trang có tour, đi qua vài cảnh và bấm vài hotspot. Kiểm tra sự kiện xuất hiện trong Tag Assistant với đúng tham số, rồi đối chiếu trong DebugView của GA4. Thử cả trên điện thoại thật, vì thao tác chạm có thể khác chuột.

5. 05

   Đăng ký custom dimension

   Trong GA4, vào Admin, Custom definitions, tạo custom dimension phạm vi sự kiện cho scene_name, hotspot_id, category, tour_id, lead_method. Với seconds_in_scene, tạo custom metric. Thiếu bước này, tham số vẫn được thu nhưng không xuất hiện trong báo cáo và Exploration.

6. 06

   Đánh dấu key event

   Sau khi tour_lead_submit đã xuất hiện trong danh sách sự kiện của GA4, vào Admin, Events (hoặc Key events) và đánh dấu nó là key event. Từ đây nó được tính vào báo cáo chuyển đổi và có thể nhập sang Google Ads.

Hai lưu ý thường bị bỏ qua. Custom dimension chỉ có dữ liệu từ thời điểm đăng ký trở đi, không áp dụng ngược cho dữ liệu cũ. Vì vậy hãy đăng ký ngay khi bắt đầu đo, đừng đợi đến lúc cần báo cáo. Ngoài ra, nếu một tham số có quá nhiều giá trị khác nhau (ví dụ hotspot_id của một tour hàng trăm hotspot), báo cáo chuẩn của GA4 có thể gom phần đuôi vào dòng “(other)”. Khi đó dùng category để phân tích tổng quát và dùng Exploration khi cần chi tiết.

Nên tăng thời gian lưu dữ liệu sự kiện của thuộc tính lên mức tối đa cho phép trong phần cài đặt Data retention. Các báo cáo Exploration chỉ truy vấn được dữ liệu trong khoảng thời gian lưu này, mà mức mặc định khá ngắn cho các dự án bất động sản có chu kỳ bán hàng dài.

Funnel Exploration: từ sảnh đến form

Funnel Exploration trong mục Explore của GA4 cho phép bạn định nghĩa một chuỗi bước và xem bao nhiêu người đi tiếp, bao nhiêu người rơi rụng ở mỗi bước. Với tour 360, phễu điển hình trông như sau:

1. 01

   Bắt đầu tour

   Điều kiện: sự kiện tour_start. Đây là mẫu số thật của phễu, loại bỏ những người tải trang mà không chạm vào tour.

2. 02

   Vào cảnh chính

   Điều kiện: scene_change với scene_name là cảnh trọng tâm, ví dụ phong_khach của căn hộ mẫu hoặc sanh_chinh của showroom.

3. 03

   Tương tác sâu

   Điều kiện: hotspot_click với category thuộc nhóm có ý định mua cao, như bang_gia, vat_lieu hoặc mat_bang.

4. 04

   Để lại thông tin

   Điều kiện: tour_lead_submit.

Có hai kiểu phễu nên dựng song song. Phễu mở (open funnel) đếm người vào ở bất kỳ bước nào, phù hợp khi khách có thể vào tour từ một cảnh giữa chừng qua link chia sẻ. Phễu đóng (closed funnel) chỉ đếm người đi đúng từ bước một, phù hợp để đo hiệu quả kịch bản tham quan bạn đã thiết kế.

Hãy chia nhỏ phễu theo thiết bị và nguồn truy cập. Rất thường gặp tình huống phễu trên máy tính khá tốt nhưng trên điện thoại rơi mạnh ở bước hai, và nguyên nhân lại nằm ở nút điều hướng quá nhỏ hoặc cảnh tải chậm qua mạng di động. Những vấn đề này được bàn kỹ trong bài hotspot và giao diện mobile và tối ưu tốc độ tải virtual tour.

Dùng dữ liệu để sửa tour và bán hàng

Dữ liệu chỉ có giá trị khi dẫn đến một thay đổi cụ thể. Dưới đây là những câu hỏi mà bộ sự kiện trên giúp trả lời, kèm việc nên làm sau đó.

Tạo audience remarketing

GA4 cho phép tạo audience dựa trên sự kiện và tham số, ví dụ “người đã có scene_change với scene_name là can_2pn_mau_b và tổng thời gian ở cảnh đó trên hai phút, nhưng chưa có tour_lead_submit“. Khi thuộc tính GA4 đã liên kết với Google Ads, audience này có thể dùng để chạy quảng cáo nhắc lại đúng căn hộ khách đã xem kỹ.

Remarketing phải đi cùng trách nhiệm về quyền riêng tư. Ở Việt Nam, việc thu thập và xử lý dữ liệu cá nhân chịu sự điều chỉnh của Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15 và Nghị định 356/2025/NĐ-CP hướng dẫn luật này (cùng có hiệu lực từ 01/01/2026, thay thế Nghị định 13/2023/NĐ-CP). Website cần có thông báo và cơ chế đồng ý phù hợp trước khi đặt cookie quảng cáo. Ngoài ra, Google và Meta đều có chính sách hạn chế cá nhân hoá quảng cáo với các nhóm ngành nhạy cảm như y tế, và một số thị trường có quy định riêng cho quảng cáo nhà ở. Với tour bệnh viện, phòng khám, hãy tránh tạo audience dựa trên việc người xem đã vào khoa điều trị nào.

Bối cảnh rộng hơn về cách tour 360 tác động đến chuyển đổi và cách đánh giá hiệu quả đầu tư nằm ở bài VR tour tăng tỷ lệ chuyển đổi. Với dự án bất động sản, xem thêm cách bố trí tour trong phễu bán hàng ở bài ứng dụng VR trong bất động sản.

Đồng bộ sang Meta Pixel và Google Ads

Khi sự kiện đã nằm trong dataLayer, bạn có thể dùng cùng một nguồn đó cho nhiều nền tảng quảng cáo, không cần gắn thêm mã vào tour.

Google Ads. Cách đơn giản nhất là nhập key event tour_lead_submit từ GA4 vào Google Ads làm mục tiêu chuyển đổi. Nếu cần ghi nhận nhanh hơn hoặc dùng tính năng chuyển đổi nâng cao, có thể tạo thêm thẻ Google Ads Conversion trong GTM dùng chung trigger. Khi chạy cả hai, chỉ chọn một nguồn làm mục tiêu chính để chiến dịch không đếm trùng.

Meta Pixel. Trong GTM, tạo thẻ Custom HTML (hoặc dùng mẫu thẻ Meta Pixel từ thư viện mẫu cộng đồng) gửi sự kiện tương ứng: tour_lead_submit ánh xạ sang sự kiện chuẩn Lead, còn scene_change có thể gửi dạng sự kiện tuỳ chỉnh kèm scene_name. Từ đó tạo Custom Audience gồm người đã xem một cảnh cụ thể. Nếu đang dùng Conversions API phía máy chủ, cần gửi kèm mã sự kiện để Meta khử trùng giữa trình duyệt và máy chủ.

Nguyên tắc chung khi đồng bộ: tên sự kiện trong dataLayer là “nguồn sự thật”, mỗi nền tảng chỉ là một đích nhận. Đừng sửa tên sự kiện trong tour để chiều theo một nền tảng cụ thể, vì như vậy các nền tảng khác sẽ mất dữ liệu.

Giới hạn của dữ liệu: vì sao không bao giờ đủ hết

Một cam kết kiểu “ghi nhận mọi lượt tương tác” là không thực tế, dù cấu hình kỹ đến đâu. Có ít nhất bốn lý do khiến số liệu GA4 luôn thấp hơn thực tế.

Cách đọc đúng là coi dữ liệu GA4 như xu hướng và tỷ lệ, không như con số tuyệt đối. So sánh cảnh A với cảnh B, tháng này với tháng trước, phiên bản tour cũ với phiên bản mới. Những so sánh tương đối như vậy vẫn đáng tin dù tổng số bị hụt, vì phần hụt ảnh hưởng gần như đều lên các nhóm.

Một thói quen nên có: đặt cảnh báo hoặc ít nhất xem nhanh hằng tuần số lượng sự kiện scene_change. Nếu con số tụt về gần bằng không sau một lần cập nhật website hay tour, gần như chắc chắn cầu nối đã đứt, và bạn phát hiện sớm thay vì mất cả tháng dữ liệu.

Heatmap hướng nhìn: làm được gì, không làm được gì

Nhiều người muốn có “bản đồ nhiệt” cho tour 360 giống heatmap của trang web: chỗ nào trong căn phòng được nhìn nhiều nhất. Cần nói rõ trước: tour trên trình duyệt không biết mắt người xem đang nhìn vào đâu. Không có eye-tracking. Thứ duy nhất tour biết là hướng camera ảo đang quay về đâu.

Muốn có heatmap hướng nhìn, phải tự ghi lại ba thông số của camera theo chu kỳ, ví dụ vài giây một lần: góc ngang (yaw/pan), góc dọc (pitch/tilt) và trường nhìn (fov, cho biết người xem đang phóng to hay thu nhỏ). Cả Pano2VR và krpano đều cho phép đọc các giá trị này qua API. Dữ liệu sau đó được gom lại theo từng cảnh và vẽ thành lớp màu phủ lên ảnh equirectangular.

Có vài điểm kỹ thuật cần lưu ý nếu định làm:

• Không nên đẩy từng mẫu yaw/pitch thành sự kiện GA4.
  Khối lượng sự kiện sẽ rất lớn, nhanh chạm giới hạn và gần như không phân tích được trong giao diện GA4. Cách hợp lý hơn là gom dữ liệu phía trình duyệt rồi gửi theo lô về một điểm thu riêng, hoặc chỉ gửi bản tóm tắt đã chia ô khi người xem rời cảnh.
• Hướng camera không đồng nghĩa với sự chú ý.
  Trên điện thoại dùng con quay hồi chuyển, camera xoay theo tay người cầm máy, kể cả khi họ không thực sự quan tâm. Lớp heatmap nên được đọc cùng dữ liệu bấm hotspot và thời gian ở cảnh.
• Đây là phần phát triển riêng
  , không phải tính năng có sẵn của GA4 hay của engine dựng tour. Cần cân nhắc chi phí và lợi ích, và thường chỉ đáng làm với tour có lượng xem đủ lớn để dữ liệu có ý nghĩa.

Với phần lớn doanh nghiệp, bộ bốn sự kiện kèm seconds_in_scene và phân tích hotspot theo nhóm đã đủ để ra quyết định. Heatmap hướng nhìn là lớp bổ sung cho những dự án muốn tối ưu sâu bố cục từng cảnh.

Danh sách kiểm tra trước khi bàn giao

Trước khi coi phần đo lường là xong, hãy rà qua các điểm sau cùng đội dựng tour và người quản trị website:

• Quy ước tên cảnh, tên hotspot và nhóm hotspot đã được thống nhất bằng văn bản.
• Bốn sự kiện đều bắn đúng trong GTM Preview, trên cả máy tính và điện thoại thật.
• Trang mẹ kiểm tra
  event.origin
  và danh sách sự kiện hợp lệ; tour gửi
  postMessage
  với origin đích cụ thể, không dùng ký tự đại diện
  '*'
  .
• Không có dữ liệu cá nhân của khách trong
  dataLayer
  hay tham số sự kiện.
• Custom dimension, custom metric đã được đăng ký;
  tour_lead_submit
  đã là key event.
• Banner đồng ý cookie hoạt động và Consent Mode được cấu hình nếu chạy quảng cáo.
• Có một Funnel Exploration mẫu và một audience mẫu để đội marketing dùng ngay.

Nếu website chứa tour được dựng trên WordPress, phần nhúng và tải tour ảnh hưởng trực tiếp đến việc sự kiện có bắn ổn định hay không. Tổng quan về cách tour 360 chạy trên trang web, iframe và tên miền nằm trong bài virtual tour 360 hoạt động trên website như thế nào.

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

Tour đặt trên dịch vụ của bên thứ ba có đo lường bằng GA4 được không?

Phụ thuộc vào việc dịch vụ đó có cho phép chèn mã hoặc có tích hợp sẵn với GA4 hay không. Nhiều nền tảng thuê bao chỉ cho bạn nhập Measurement ID và tự gửi một số sự kiện cố định, khó tuỳ biến tên cảnh hay hotspot. Tour tự host xuất từ Pano2VR hoặc krpano cho bạn toàn quyền kiểm soát mã nên linh hoạt hơn nhiều.

Có nên cài GA4 thẳng vào trong trang tour thay vì gửi ra trang mẹ?

Chỉ nên làm khi tour được mở như một trang độc lập, ví dụ khách vào bằng link riêng hoặc mã QR. Khi tour nằm trong iframe trên website, cài GA4 bên trong sẽ tạo phiên riêng, mất thông tin nguồn quảng cáo và có thể bị chặn cookie. Cách đã nêu trong bài xử lý được cả hai trường hợp: có trang mẹ thì gửi ra ngoài, không có thì đẩy vào dataLayer của chính trang tour.

Bao lâu sau khi cài thì có số liệu để phân tích?

Sự kiện hiện trong DebugView gần như ngay lập tức, còn báo cáo chuẩn thường cần thêm thời gian để GA4 xử lý. Về mặt ý nghĩa, cần đủ lượng người xem trước khi kết luận cảnh nào tốt hơn cảnh nào. Với website ít truy cập, hãy gộp dữ liệu theo khoảng thời gian dài hơn thay vì đọc theo ngày.

Đổi tên cảnh trong tour sau khi đã chạy đo lường thì sao?

Dữ liệu cũ vẫn giữ tên cũ, dữ liệu mới mang tên mới, và GA4 coi đó là hai giá trị khác nhau. Nếu bắt buộc phải đổi tiêu đề hiển thị, hãy giữ nguyên scene_id hoặc giá trị gửi trong scene_name và chỉ đổi phần chữ người xem thấy. Đây là lý do nên tách tên kỹ thuật khỏi tên hiển thị ngay từ đầu.

Đo lường có làm tour tải chậm hơn không?

Đoạn mã lắng nghe sự kiện và gửi postMessage rất nhẹ, gần như không ảnh hưởng. Thứ có thể làm trang chậm là số lượng thẻ trong GTM, đặc biệt các thẻ quảng cáo tải thư viện nặng. Hãy giữ container gọn và chỉ kích hoạt thẻ liên quan đến tour trên những trang thực sự có tour.

Tôi có cần lập trình viên để làm phần này không?

Phần cầu nối trong tour và đoạn nhận tin trên trang mẹ cần người biết JavaScript, thường là đội dựng tour hoặc đội website. Phần cấu hình GTM, custom dimension, key event và Exploration thì người làm marketing quen GA4 có thể tự làm theo các bước trong bài. Quan trọng nhất là hai bên thống nhất trước bộ tên sự kiện và tham số.