Looker 26.12 và những thay đổi đáng chú ý với đội ngũ phân tích marketing

Tổng quan

Looker 26.12 là một bản phát hành phục vụ vận hành báo cáo, không phải đợt ra mắt một nền tảng marketing. Ghi chú phát hành của Looker liệt kê bốn thay đổi về tính năng mà các dashboard marketing sẽ nhận thấy: Increased Row Limit chuyển sang trạng thái khả dụng chung (GA), Table Row Grouping và KPI Visualization ra mắt ở dạng Preview và được bật theo mặc định, còn các instance Looker (Google Cloud core) đạt chuẩn tuân thủ FIPS 140-3 cấp 1.

Cũng các ghi chú này liệt kê những bản sửa lỗi liên quan đến tự động hóa báo cáo: hình trực quan tùy chỉnh bị cắt trong bản xuất PDF, bộ lọc dạng nút bật tắt bị chồng lấn, kiểm tra kết nối OAuth thất bại trên trang quản trị Self-service Explores, và lệnh gọi API bằng tài khoản dịch vụ trả về lỗi 500. Với các đội ngũ phân tích marketing, các bản sửa lỗi này cần được kiểm thử hồi quy không kém việc tìm hiểu các tính năng mới.

Điều này quan trọng vì phần lớn các đội ngũ marketing không cần thêm một bản tóm tắt changelog nữa. Họ cần biết liệu các bảng chiến dịch, dashboard điều hành, báo cáo doanh thu và các bản xuất dữ liệu tự động có hoạt động khác đi hay không. Đây chính là chỗ Vanaxity, tác nhân AI cho SEO/GEO/AEO của Van Data Team, kết nối kỷ luật phân tích với vận hành nội dung: đầu vào báo cáo tốt hơn tạo ra brief tìm kiếm tốt hơn, bằng chứng vững hơn, dashboard gọn gàng hơn và nội dung sẵn sàng cho câu trả lời.

Ghi chú phát hành không bổ sung tính năng nào về nền tảng dữ liệu khách hàng, theo dõi, phân bổ chuyển đổi, kích hoạt tệp đối tượng, giá trị vòng đời khách hàng hay tỷ lệ rời bỏ. Tác động nằm ở vận hành báo cáo: bảng lớn hơn khi quản trị viên nâng giới hạn, việc đọc bảng rõ ràng hơn, bề mặt KPI chuẩn hơn, hạ tầng nhạy cảm về tuân thủ và các bản sửa lỗi đáng được QA trước khi các bên liên quan tin dùng các dashboard đã cập nhật.

Tại Van Data Team, chúng tôi bắt đầu bằng một câu hỏi đơn giản của người vận hành: điều gì thay đổi trong quy trình làm việc hằng tuần? Với nhiệm vụ theo dõi bản phát hành này, câu trả lời không phải là "chiến lược marketing mới". Câu trả lời là: rà soát các dashboard đang định hướng chiến lược marketing, rồi quyết định xem có hành vi mới nào về trực quan hóa và giới hạn số hàng nên làm thay đổi cách các nhà phân tích kiểm tra, xuất, giải thích và công bố bằng chứng hiệu suất hay không.

Những điểm cốt lõi cần nắm vững

Đây là những quyết định mà các đội ngũ phân tích marketing nên đưa ra, chứ không chỉ là những tính năng họ nên để ý.

• Looker 26.12 được triển khai từ ngày 12/7 đến ngày 26/7/2026, các instance được nâng cấp vào những thời điểm khác nhau trong khung thời gian đó.
• Increased Row Limit quan trọng vì tài liệu về giới hạn số hàng của Google cho biết giới hạn hiển thị mặc định của Explore trên trình duyệt là 5.000 hàng, trong khi tính năng này có thể cho phép quản trị viên cấu hình các kiểu trực quan hóa được hỗ trợ lên tới 50.000 hàng hoặc điểm dữ liệu.
• Table Row Grouping (Preview, bật theo mặc định) có thể hữu ích cho các cấu trúc phân cấp trong marketing, chẳng hạn từ kênh đến chiến dịch rồi đến nhóm quảng cáo, nhưng nó không khắc phục được mô hình dữ liệu yếu hay định nghĩa chỉ số không rõ ràng.
• Việc KPI Visualization giờ được bật theo mặc định (vẫn ở dạng Preview) nên kích hoạt một đợt rà soát các dashboard điều hành, các trang báo cáo cho hội đồng quản trị và các dashboard phân tích marketing định kỳ.
• Giới hạn số hàng của Connected Sheets là chuyện riêng: PPC Land đưa tin rằng bảng tổng hợp (pivot table) của Looker Connected Sheets có thể kéo tới 100.000 hàng, tăng từ mức 30.000 hàng, nhưng điều đó không giống với việc hiển thị dashboard ngay trong Looker.

Looker 26.12 có gì thay đổi?

Looker 26.12 thay đổi bốn điểm mà đội ngũ marketing sẽ thấy trên dashboard: giới hạn số hàng, bảng được nhóm, ô KPI và hỗ trợ tuân thủ.

Mốc thời gian quan trọng đối với việc lập kế hoạch triển khai: theo ghi chú phát hành của Looker, đợt triển khai cuốn chiếu của bản 26.12 bắt đầu vào Chủ nhật, ngày 12/7/2026, còn đợt triển khai cuối cùng và các bản tải xuống dự kiến hoàn tất chậm nhất vào Chủ nhật, ngày 26/7/2026, tức là một khung thời gian hai tuần trong đó các instance được nâng cấp vào những thời điểm khác nhau.

Dưới đây là ý nghĩa thực tế đối với các đội ngũ marketing:

Sai lầm chúng tôi thường thấy là coi các bản phát hành BI hoặc là "tin lớn", hoặc là "chẳng có gì phải làm". Lập trường tốt hơn của người vận hành thì hẹp hơn: xác định các bề mặt báo cáo dẫn dắt quyết định, kiểm thử các bề mặt đó và ghi lại những gì đã thay đổi.

Nếu đội ngũ của bạn dùng báo cáo về hiệu suất nội dung, tìm kiếm trả phí, pipeline bán hàng hoặc tài khoản để định hướng chiến lược SEO và tìm kiếm AI, Van Data Team có thể giúp biến bản phát hành này thành một đợt rà soát quy trình phân tích có phạm vi rõ ràng. Đầu ra mang tính thực tế: bản rà soát khoảng trống của dashboard, bản đồ tín hiệu, danh sách kiểm tra QA và phạm vi triển khai gắn với SEO/GEO/AEO tự động, chứ không phải một đợt kiểm toán BI chung chung.

Vì sao Increased Row Limit quan trọng với dashboard marketing

Increased Row Limit quan trọng vì dashboard marketing thường thất bại đúng ở điểm mà phần đuôi dài trở nên quan trọng.

Một nhà phân tích quảng cáo trả phí có thể dễ dàng tóm tắt hiệu suất theo kênh. Việc khó hơn là kiểm tra các hàng nằm dưới phần tóm tắt: cụm từ tìm kiếm, quảng cáo, khu vực địa lý, trang đích, nhóm sản phẩm, tài khoản hoặc các biến thể mẫu quảng cáo. Tài liệu về giới hạn số hàng của Looker từ Google cho biết giới hạn hiển thị mặc định của Explore trên trình duyệt là 5.000 hàng. Với nhiều đội ngũ marketing, mức trần đó là nơi việc điều tra dừng lại quá sớm.

Tính năng Increased Row Limit thay đổi mức trần đó cho các kiểu trực quan hóa được hỗ trợ. Google cho biết quản trị viên có thể đặt giới hạn lên tới 50.000 hàng hoặc điểm dữ liệu cho biểu đồ bản đồ, biểu đồ phân tán và biểu đồ bảng. CloudScoop đã đưa tin về bản xem trước (preview) vào ngày 16/3/2026; ghi chú phát hành 26.12 đưa tính năng này lên trạng thái khả dụng chung (GA).

Với các đội ngũ phân tích marketing, giá trị không nằm ở bản thân việc có "nhiều hàng hơn". Giá trị nằm ở khả năng kiểm tra tốt hơn trước khi xuất dữ liệu. Một số ví dụ hữu ích gồm:

• Bảng từ khóa tìm kiếm trả phí, nơi phần đuôi dài che giấu chi tiêu lãng phí hoặc nhu cầu mới nổi.
• Bảng từ chiến dịch đến nhóm quảng cáo rồi đến quảng cáo, nơi hiện tượng mẫu quảng cáo bị bão hòa xuất hiện bên dưới các mục hiệu quả nhất.
• Danh sách tài khoản ABM, nơi đội bán hàng và marketing cần cùng một góc nhìn về hoạt động của các tài khoản mục tiêu.
• Báo cáo theo khu vực địa lý, nơi các giá trị ngoại lai theo vùng không hiện ra trong bản tóm tắt cấp cao nhất.
• Báo cáo trang đích, nơi các trang có lưu lượng thấp mang lại những manh mối mạnh về tìm kiếm hoặc chuyển đổi.

Hãy xét một quản lý marketing vòng đời khách hàng tên là Priya. Đội của cô rà soát hiệu suất hành trình khách hàng mỗi tuần, nhưng dashboard thường chỉ hiển thị các chương trình nổi bật nhất. Sau khi quản trị viên rà soát thiết lập giới hạn số hàng, Priya có thể kiểm tra một bảng lớn hơn gồm các hàng chương trình, hành trình, chiến dịch và phân khúc ngay trong Looker trước khi yêu cầu xuất dữ liệu ra bảng tính. Kết quả không phải là một phát hiện thần kỳ. Đó là một vòng lặp ngắn hơn giữa câu hỏi, kiểm tra và quyết định.

Nhưng có một điểm cần lưu ý. Giới hạn cao hơn có thể tạo áp lực về hiệu năng, áp lực về quản trị và gánh nặng rà soát. Một dashboard về mặt kỹ thuật hiển thị được nhiều hàng hơn vẫn có thể trở nên chậm hơn, khó diễn giải hơn hoặc dễ bị dùng sai hơn. Quản trị viên nên nâng giới hạn ở những nơi có trường hợp sử dụng rõ ràng, chứ không nâng trên toàn hệ thống chỉ vì thiết lập đó tồn tại.

Điều đó cũng quan trọng với các đội ngũ nội dung cho tìm kiếm AI. Quy trình tác nhân của Vanaxity dùng bằng chứng để tạo ra nội dung tối ưu cho tìm kiếm và sẵn sàng cho câu trả lời. Nếu dashboard nguồn bị nhiễu hoặc được quản trị kém, pipeline nội dung sẽ thừa hưởng điểm yếu đó. Khả năng truy cập hàng tốt hơn chỉ có ích khi đi kèm các định nghĩa được kiểm soát, bước duyệt và kỷ luật xuất bản.

Table Row Grouping thay đổi cách đọc dashboard như thế nào

Table Row Grouping, ở dạng Preview và được bật theo mặc định trong bản 26.12, thay đổi cách nhà phân tích đọc các bảng dày đặc bằng cách làm cho cấu trúc phân cấp của doanh nghiệp hiện rõ ngay trong giao diện bảng.

Dữ liệu marketing vốn có tính phân cấp. Một kênh chứa các chiến dịch. Một chiến dịch chứa các nhóm quảng cáo. Một nguồn chứa các phương tiện, trang đích và nhóm nội dung. Một khu vực chứa các thị trường, tài khoản và cơ hội bán hàng. Bảng phẳng có thể hiển thị tất cả những điều đó, nhưng thường buộc người đọc phải tự dựng lại cấu trúc phân cấp trong đầu, từng hàng một.

Table Row Grouping mang lại cho các đội ngũ một bề mặt đọc gọn gàng hơn khi tính năng này khả dụng. Ví dụ, một dashboard quảng cáo trả phí có thể nhóm theo kênh, rồi chiến dịch, rồi nhóm quảng cáo. Một dashboard marketing vòng đời có thể nhóm theo chương trình, hành trình và chiến dịch. Một dashboard marketing doanh thu có thể nhóm theo khu vực, thị trường và tài khoản. Tính năng này hữu ích nhất khi cách nhóm phản ánh đúng cách doanh nghiệp vốn đang ra quyết định.

Đây không phải phép màu mô hình hóa dữ liệu. Tính năng này sẽ không sửa được tên chiến dịch bị trùng, UTM không nhất quán, định nghĩa kênh không rõ ràng hay các phép nối (join) yếu giữa dữ liệu marketing và dữ liệu doanh thu. Nếu mô hình bên dưới lộn xộn, việc nhóm hàng có thể khiến mớ lộn xộn đó trông ngăn nắp hơn thực tế.

Một danh sách kiểm tra QA thực tế nên bao gồm:

• Xác nhận cấu trúc phân cấp khi nhóm khớp với cách các bên liên quan thảo luận về hiệu suất.
• Kiểm tra xem tổng phụ và tổng cộng có còn dễ diễn giải không.
• So sánh chế độ xem có nhóm và không nhóm của cùng một dashboard.
• Rà soát các ảnh chụp màn hình dùng trong báo cáo định kỳ.
• Xác thực rằng bộ lọc vẫn cho ra kết quả nhóm như mong đợi.
• Tự hỏi liệu chế độ xem có nhóm giúp ra quyết định tốt hơn hay chỉ trông gọn gàng hơn.

Đây là lúc dashboard trở thành hạ tầng nội dung. Nếu đội ngũ của bạn công bố các phân tích hiệu suất, benchmark hoặc nội dung dẫn dắt tư duy (thought leadership) dựa trên phân tích marketing, các bảng được nhóm có thể giúp bằng chứng dễ kiểm tra hơn trước khi nó trở thành một tuyên bố công khai. Với các đội ngũ dùng tác nhân Vanaxity, dấu vết kiểm toán đó quan trọng vì các công cụ trả lời AI ưu ái những lời giải thích rõ ràng, có nguồn dẫn chứng.

Ý nghĩa của việc KPI Visualization được bật theo mặc định

Việc KPI Visualization được bật theo mặc định trong Looker 26.12 (vẫn ở dạng Preview) khiến ô KPI trở thành một bề mặt dashboard chuẩn hơn, vì vậy các đội ngũ nên rà soát tính nhất quán trong cách trình bày chỉ số.

Các đội ngũ marketing gắn bó hằng ngày với các ô KPI. Pipeline bán hàng. Doanh thu. Khách hàng tiềm năng đủ điều kiện. CAC. ROAS. Tỷ lệ chuyển đổi. Dự báo. Cơ hội bán hàng có nội dung hỗ trợ. Phiên truy cập tự nhiên. Yêu cầu demo. Bản phát hành không tự động tạo ra các chỉ số đó, và cũng không quyết định chỉ số nào quan trọng. Nó thay đổi trạng thái khả dụng mặc định của bề mặt trực quan hóa.

Điều đó nghe có vẻ nhỏ cho đến khi liên quan đến một dashboard điều hành. Một trang báo cáo cho hội đồng quản trị có thể đúng về mặt kỹ thuật nhưng vẫn gây khó hiểu nếu các ô KPI khác nhau về định dạng, kỳ so sánh, hành vi bộ lọc hoặc cách đặt tên. Khi một kiểu trực quan hóa trở thành tiêu chuẩn, sự thiếu nhất quán sẽ lộ rõ hơn.

Cách rà soát đúng rất đơn giản:

• Xác định các dashboard mà ban lãnh đạo và các đội bán hàng, quảng cáo trả phí, marketing vòng đời và nội dung đang sử dụng.
• Xác nhận các ô KPI dùng tên chỉ số và logic so sánh nhất quán.
• Kiểm tra xem bộ lọc có tác động lên ô KPI như mong đợi không.
• Xác thực rằng ảnh chụp màn hình và các bản xuất theo lịch vẫn hiển thị đúng.
• Ghi lại mọi ô có ý nghĩa phụ thuộc vào các giả định ẩn.

Hãy hình dung một đội doanh thu báo cáo pipeline bán hàng có nguồn từ marketing mỗi tuần. Ô KPI ở đầu dashboard trông gọn gàng, nhưng bảng đã lọc bên dưới lại dùng một trường ngày khác. Ở đây, chẳng cần đến công cụ mới nào cũng đủ gây nhầm lẫn. Điều họ cần là một bước duyệt buộc KPI, bảng, bản xuất và phần diễn giải phải khớp nhau.

Đó cũng là quan điểm của Van Data Team về nội dung cho tìm kiếm AI. Thời của mười liên kết xanh đã qua, nhưng tầng bằng chứng thì vẫn còn đó. Nếu một thương hiệu muốn được AI Overviews, ChatGPT, Gemini và Perplexity trích dẫn, các con số đằng sau bài viết cần truy vết được. Một bề mặt KPI rõ ràng là một phần của khả năng truy vết đó, chứ không phải đồ trang trí cho dashboard.

Hỗ trợ FIPS có ý nghĩa gì với các đội ngũ phân tích có quản trị

Hỗ trợ FIPS quan trọng với các đội ngũ phân tích có quản trị vì các môi trường báo cáo nhạy cảm về tuân thủ cần có sự tham gia của người phụ trách nền tảng và bảo mật trước khi các giả định về production thay đổi.

Ghi chú phát hành bổ sung chuẩn tuân thủ FIPS 140-3 cấp 1 cho các instance Looker (Google Cloud core). Nhiều đội ngũ marketing sẽ không thấy thay đổi gì trong cuộc họp chiến dịch hằng tuần. Với các tổ chức chịu sự quản lý theo quy định, các đội ngũ làm việc gần khu vực công, dịch vụ tài chính, y tế hoặc các đội ngũ doanh nghiệp chú trọng bảo mật, điều này có thể quan trọng đối với lộ trình của nền tảng phân tích.

Hãy giữ phạm vi thật gọn. Hạng mục phát hành này không phải là một đợt kiểm toán bảo mật toàn diện, và người làm marketing không nên biến nó thành một đợt như vậy. Hành động thực tế là mời những người phụ trách nền tảng, bảo mật, tuân thủ và phân tích tham gia trước khi thay đổi các giả định về báo cáo có quản trị.

Các câu hỏi cần đặt ra là:

• Những instance Looker nào nằm trong phạm vi?
• Những dashboard nào phục vụ báo cáo nhạy cảm về tuân thủ?
• Những bản xuất dữ liệu nào đi ra khỏi môi trường được quản trị?
• Những quy trình kết nối qua OAuth nào chạm tới dữ liệu chịu quản lý theo quy định?
• Những tác vụ tự động hóa qua API nào cần được xác thực sau khi triển khai?
• Những tuyên bố trong nội dung hoặc báo cáo nào dựa trên dữ liệu phân tích nhạy cảm?

Quan điểm của nhà sáng lập kiêm người vận hành rất thẳng thắn: hỗ trợ tuân thủ chỉ tạo ra giá trị khi tổ chức biết rủi ro báo cáo nằm ở đâu. Một dòng ghi chú về tính năng trong ghi chú phát hành không phải là một kế hoạch quản trị.

Nếu tầng phân tích của bạn phục vụ nội dung công khai, báo cáo cho nhà đầu tư, báo cáo cho đối tác hoặc việc xuất bản cho tìm kiếm AI, đây là thời điểm tốt để rà soát chuỗi tín hiệu. Van Data Team có thể xác định phạm vi cho đợt rà soát đó cùng đội ngũ đứng sau Vanaxity: hệ thống nguồn, định nghĩa dashboard, điểm phê duyệt, đầu ra nội dung và lộ trình phục hồi khi có sự cố.

Các đội ngũ phân tích marketing nên kiểm thử gì sau đợt triển khai

Các đội ngũ phân tích marketing nên kiểm thử những dashboard và tác vụ tự động hóa định hình quyết định trước khi tin dùng bất kỳ bản phát hành mới nào trong báo cáo định kỳ.

Một quy trình triển khai thực tế có hình dạng đơn giản: rà soát ghi chú phát hành, rà soát thiết lập quản trị, QA dashboard, các bên liên quan ký duyệt và triển khai có giám sát, trong đó các phát hiện QA được đưa ngược về thiết lập quản trị và các bản sửa mô hình ngữ nghĩa.

Hãy dùng sổ tay vận hành này làm tài liệu làm việc:

Việc đánh giá cần vượt ra ngoài câu hỏi "có tải được không?". Hãy xem xét chi phí rà soát, độ trễ khi dashboard được dùng thực tế, khả năng quan sát lỗi, ngân sách token nếu đầu ra của dashboard được đưa vào quy trình AI, và lộ trình phục hồi khi bản xuất hoặc tác vụ API bị hỏng. Một dashboard phân tích marketing là một phần của hệ thống production khi mọi người dùng nó để chi ngân sách, giải thích doanh thu hoặc công bố các tuyên bố công khai.

Với người dùng Vanaxity, hệ thống production đó mở rộng sang cả nội dung. Tác nhân có thể nghiên cứu, viết, minh họa, xuất bản và phân phối nội dung, nhưng vẫn cần đầu vào đáng tin cậy. Khi một bản phát hành Looker thay đổi hành vi của dashboard, quy trình nội dung cần biết tín hiệu nào đã được phê duyệt và tín hiệu nào vẫn đang được rà soát. Bạn có thể xem quy trình xuất bản để hiểu kỷ luật báo cáo chuyển thành đầu ra cho tìm kiếm và công cụ trả lời như thế nào.

Những sai lầm thường gặp cần tránh

Sai lầm lớn nhất là biến một bản phát hành BI mang tính thực tiễn thành một câu chuyện mơ hồ về chuyển đổi marketing.

Đừng mô tả bản phát hành này là đợt ra mắt CDP. Đừng gọi nó là một cuộc đại tu cơ chế phân bổ chuyển đổi. Đừng ngụ ý rằng nó tạo ra khả năng kích hoạt tệp đối tượng, mô hình hóa giá trị vòng đời, dự đoán khách hàng rời bỏ hay theo dõi đa kênh: ghi chú phát hành không liệt kê điều nào trong số đó. Đó là những hệ thống khác và những dự án khác.

Cũng tránh đánh đồng giới hạn của dashboard Looker với giới hạn trích xuất của Connected Sheets. PPC Land đưa tin rằng bảng tổng hợp của Connected Sheets có thể kéo tới 100.000 hàng, tăng từ mức 30.000 hàng. Đó là bối cảnh liên quan, không giống với cơ chế giới hạn số hàng của dashboard Looker được mô tả trong tài liệu về giới hạn số hàng của Google.

Những sai lầm khác mang tính vận hành nhiều hơn:

• Nâng giới hạn số hàng trên toàn hệ thống mà không hỏi dashboard nào thực sự cần.
• Cho rằng bảng lớn hơn sẽ tạo ra quyết định tốt hơn.
• Bỏ qua QA cho các dashboard mà ban lãnh đạo, đội bán hàng, tài chính hoặc quảng cáo trả phí sử dụng.
• Coi các hàng được nhóm là bằng chứng cho thấy mô hình dữ liệu đã sạch.
• Để các ô KPI sinh sôi mà không có tiêu chuẩn đặt tên và bộ lọc.
• Đăng bài viết về bản phát hành mà không liên kết các tuyên bố số liệu với nguồn sơ cấp.

Một ví dụ về nội dung sẽ làm rõ điều này. Giả sử một trưởng nhóm marketing tên Daniel yêu cầu viết nhanh một bài về bản phát hành vì "tìm kiếm AI rất chuộng nội dung kịp thời". Bản nháp viết vội nói rằng Looker giờ đây giúp người làm marketing kích hoạt tệp đối tượng và mô hình hóa tỷ lệ rời bỏ. Nghe thì ấn tượng, nhưng không có gì trong ghi chú phát hành hỗ trợ điều đó. Bản nháp tốt hơn bám sát những gì ghi chú liệt kê: quy mô dashboard, việc đọc bảng có nhóm, ô KPI mặc định, tình trạng tuân thủ và các bản sửa lỗi về độ tin cậy. Cách viết đó bớt hào nhoáng hơn. Nó cũng dễ được trích dẫn hơn.

Đây là lý do Vanaxity được xây dựng như một tác nhân cho SEO, GEO và AEO, chứ không chỉ là một công cụ viết. Các công cụ trả lời AI có nhiều khả năng trích dẫn hơn những nội dung trả lời trực tiếp, ghi rõ nguồn của các tuyên bố và không nói quá. Kết quả và bằng chứng đến từ độ chính xác trong vận hành không kém gì từ văn phong.

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

Nguồn tham khảo