server-side Google Tag Manager (sGTM) là gì, và tại sao nó lại quan trọng?

Thông thường, trang web của bạn chạy các thẻ theo dõi bên trong trình duyệt của khách truy cập — nhưng các trình duyệt (đặc biệt là Safari) và các trình chặn quảng cáo ngày càng chặn chúng nhiều hơn, vì vậy các lượt nhấp vào quảng cáo và doanh số bán hàng bị mất và ROI được báo cáo của bạn trông tệ hơn thực tế. Server-side GTM di chuyển công việc theo dõi đó sang một máy chủ do bạn kiểm soát, nhờ đó ít tín hiệu bị chặn hơn. Khi nó chạy trên miền phụ bên thứ nhất của riêng bạn, các yêu cầu sẽ hiển thị dưới dạng bên thứ nhất thay vì bên thứ ba, giúp chúng có khả năng chống chịu tốt hơn nhiều trước Safari ITP, Firefox ETP và các trình chặn quảng cáo — và dữ liệu sẽ nằm trong cloud của riêng bạn, không phải của nhà cung cấp.

Tại sao các chiến dịch quảng cáo trực tuyến ngay từ đầu đã bị 'mất' các chuyển đổi?

Một phần ngày càng tăng của các lượt mua hàng thực tế không bao giờ được gửi ngược trở lại nền tảng quảng cáo, vì vậy có vẻ như quảng cáo của bạn hoạt động kém hiệu quả hơn so với thực tế. Các nguyên nhân thông thường là Intelligent Tracking Prevention (ITP) của Safari, giới hạn các cookie trình duyệt được ghi bằng tập lệnh ở mức 7 days; các trình duyệt chặn cookie bên thứ ba; các trình chặn quảng cáo loại bỏ tập lệnh theo dõi; và khách truy cập từ chối sự đồng ý phân tích. Giao dịch mua bán vẫn diễn ra — chỉ là nền tảng không bao giờ biết về nó, vì vậy nó không thể ghi nhận công lao cho quảng cáo của bạn hoặc học hỏi từ đó.

Conversions API (CAPI) là gì, và nó khác gì so với pixel cũ?

Một pixel là một đoạn JavaScript nhỏ chạy trong trình duyệt của khách truy cập và báo cáo các sự kiện như 'Purchase' cho nền tảng quảng cáo. Một Conversions API (CAPI) cũng thực hiện công việc tương tự, nhưng theo phương thức server-to-server — máy chủ của riêng bạn gửi sự kiện trực tiếp đến API của nền tảng thay vì phụ thuộc vào trình duyệt. Do không phụ thuộc vào các cookie trình duyệt hay việc tải tập lệnh, CAPI tiếp tục báo cáo các chuyển đổi mà nếu chỉ dùng pixel thì đã bị bỏ sót.

Sự khác biệt giữa theo dõi server-side và theo dõi client-side là gì?

Theo dõi client-side (phía trình duyệt) chạy trong trình duyệt của khách truy cập, nơi các trình chặn quảng cáo, giới hạn cookie và tính năng ngăn chặn theo dõi có thể can thiệp vào nó. Theo dõi server-side chuyển công việc đó sang một máy chủ do bạn kiểm soát, sau đó máy chủ này sẽ chuyển tiếp các sự kiện sạch sẽ, đã được loại bỏ trùng lặp đến các nền tảng quảng cáo. Trình duyệt chỉ gửi sự kiện một lần đến tên miền của riêng bạn — mọi thứ dễ vỡ và dễ bị chặn sẽ được chuyển khỏi trình duyệt và đưa vào cơ sở hạ tầng mà bạn quản lý.

Nếu tôi sử dụng một Conversions API, tôi có cần pixel trình duyệt nữa không?

Có — thiết lập được khuyến nghị là chạy đồng thời cả pixel trình duyệt và server-side CAPI, chứ không phải chọn một trong hai. Pixel ghi lại ngữ cảnh trình duyệt phong phú và kích hoạt nhanh chóng, trong khi CAPI lấp đầy các khoảng trống mà pixel bỏ lỡ, vì vậy khi kết hợp lại, chúng phục hồi được nhiều chuyển đổi hơn so với khi hoạt động riêng lẻ. Cả hai được liên kết với nhau bằng một event ID dùng chung để nền tảng không tính một giao dịch bán hàng hai lần — đó là những gì quy trình loại bỏ trùng lặp xử lý.

Loại bỏ trùng lặp sự kiện (event deduplication) là gì, và tại sao nó lại quan trọng?

Khi cùng một chuyển đổi được báo cáo hai lần — một lần bởi pixel trình duyệt và một lần bởi server CAPI — nền tảng cần biết đó là một giao dịch bán hàng duy nhất, chứ không phải hai. Loại bỏ trùng lặp giải quyết vấn đề này bằng cách gắn thẻ cả hai báo cáo với cùng một event_id duy nhất, để nền tảng giữ lại một báo cáo và loại bỏ báo cáo trùng lặp. Nếu không có nó, các số liệu của bạn sẽ bị thổi phồng; có nó, Events Manager của Meta chỉ đơn giản hiển thị sự kiện là 'Deduplicated'.

fbp, fbc và các click ID là gì — và tại sao chúng lại bị mất?

Chúng là những mã định danh nhỏ giúp liên kết khách truy cập quay trở lại quảng cáo họ đã nhấp vào: fbp định danh trình duyệt, fbc mang click ID của Meta từ URL quảng cáo, và các nền tảng khác có mã định danh riêng của họ (gclid cho Google, ttclid cho TikTok). Chúng tồn tại trong cookie, vì vậy khi Safari ITP làm hết hạn cookie hoặc khách truy cập xóa trình duyệt của họ, liên kết sẽ bị đứt và chuyển đổi không còn được phân bổ cho quảng cáo đó nữa. Thiết lập server-side có thể lưu trữ những thông tin này trong một khoảng thời gian và tự động điền lại chúng vào chuyển đổi sau đó, giúp cứu vãn dữ liệu phân bổ mà nếu không thì sẽ bị mất.

BYOC có nghĩa là gì, và tại sao việc lưu trữ dữ liệu 'trong cloud của riêng bạn' lại quan trọng?

BYOC là viết tắt của Bring Your Own Cloud — hệ thống theo dõi được triển khai bên trong một tài khoản cloud do bạn sở hữu (Google Cloud, AWS, Azure hoặc riêng tư), không phải trên máy chủ của nhà cung cấp. Điều đó có nghĩa là dữ liệu quảng cáo và khách hàng thô của bạn không bao giờ rời khỏi phạm vi kiểm soát của bạn: bạn chọn khu vực, đặt thời gian lưu trữ và truy vấn dữ liệu trực tiếp mà không bị ràng buộc vào nhà cung cấp. Đối với các ngành bị quản lý nghiêm ngặt, việc 'dữ liệu được lưu trữ vật lý tại chỗ của chúng tôi' thường là sự khác biệt giữa một triển khai được cơ quan quản lý chấp nhận và một triển khai không được chấp nhận.

Việc phục hồi các chuyển đổi bị mất có thực sự cải thiện ROI/ROAS không — và bằng cách nào?

Tỷ suất hoàn vốn đầu tư quảng cáo chỉ có thể tính các chuyển đổi mà nền tảng thực sự nhận được, vì vậy việc phục hồi các chuyển đổi bị bỏ sót sẽ mang lại hai lợi ích. Thứ nhất, ROI/ROAS được báo cáo của bạn phản ánh doanh số bán hàng luôn có thực nhưng trước đây không thể nhìn thấy. Thứ hai — và mang tính bền vững hơn — thuật toán tối ưu hóa của nền tảng quảng cáo sẽ nhận được tín hiệu đầy đủ hơn về việc ai là người thực sự chuyển đổi, từ đó nhắm mục tiêu và đặt thầu chính xác hơn theo thời gian. Lợi ích lâu dài đến từ tín hiệu tốt hơn đó, chứ không chỉ là sự gia tăng báo cáo một lần.

Việc gửi các chuyển đổi bằng server-side có vi phạm quyền riêng tư của người dùng không?

Không nhất thiết phải như vậy, và một thiết lập được xây dựng tốt được thiết kế để không vi phạm. Dữ liệu cá nhân như email và số điện thoại được mã hóa SHA-256 trước khi được lưu trữ hoặc gửi đi — mã hóa là một phép biến đổi một chiều, vì vậy nền tảng có thể đối khớp dữ liệu đó mà không bao giờ nhận được văn bản thuần túy — và các lựa chọn đồng ý sẽ được kiểm tra trước khi bất kỳ sự kiện nào được gửi đi. Mục tiêu là đo lường chính xác dữ liệu bạn đã thu thập, chứ không phải thu thập thêm thông tin về mọi người hoặc giữ lại các chi tiết nhận dạng mà bạn không nên giữ.

Liệu điều này có xung đột với GA4 hoặc Google Tag Manager hiện tại của tôi không?

Không — server-side GTM hoạt động song song với những gì bạn đang chạy chứ không thay thế nó. Container GTM trên web hiện tại của bạn và GA4 tiếp tục hoạt động trong trình duyệt; container server-side là một đích đến riêng biệt nhận các sự kiện và chuyển tiếp các chuyển đổi đến các nền tảng quảng cáo, và thậm chí GA4 có thể được định tuyến qua đó để có số liệu phân tích kiên cố hơn. Không có gì trong việc gắn thẻ hiện tại của bạn phải bị loại bỏ để thêm một lớp server-side.

Tôi sẽ thấy kết quả nhanh như thế nào, và làm thế nào để đo lường chúng?

Khi các sự kiện bắt đầu hoạt động, nơi đầu tiên cần xem là chế độ xem chất lượng sự kiện của nền tảng quảng cáo — ví dụ như Events Manager của Meta — nơi các sự kiện server đã được loại bỏ trùng lặp sẽ xuất hiện cùng với các sự kiện trình duyệt trong vòng vài ngày. Thước đo rõ ràng nhất là mức tăng trong các chuyển đổi được phân bổ và Event Match Quality so với mức cơ sở chỉ dùng pixel của bạn, vì vậy việc ghi lại mức cơ sở đó trước khi bạn bắt đầu sẽ rất hữu ích. Hãy coi sự thay đổi ROI/ROAS được báo cáo là tiêu đề và tín hiệu tối ưu hóa phong phú hơn là phần thưởng dài hạn.

TopAdsROI khác biệt như thế nào so với Stape, Addingwell hoặc gtmserver.com?

Đó là những giải pháp lưu trữ đám mây tốt, nhưng họ lưu trữ dữ liệu của bạn trên cơ sở hạ tầng của họ. TopAdsROI triển khai vào cloud của riêng bạn — Google Cloud, AWS, Azure hoặc riêng tư — với kho tài liệu và kho dữ liệu trong dự án của bạn (Firestore + BigQuery trên GCP, hoặc các tài khoản tương đương trên AWS / Azure), nhờ đó bạn có quyền truy cập truy vấn trực tiếp, chính sách lưu trữ riêng và khu vực của riêng bạn. Chúng tôi cũng mô hình hóa trước cho 14 markets trên khắp Châu Á - Thái Bình Dương (APAC), Bắc Mỹ và Vương quốc Anh — mỗi thị trường có chế độ bảo mật riêng — trong khi các đơn vị khác cung cấp một nền tảng chung chung.

Dữ liệu khách hàng được lưu trữ ở đâu?

Bên trong cloud của riêng bạn — Google Cloud, AWS, Azure hoặc riêng tư — tại khu vực bạn chọn (ví dụ: Sydney, Tokyo hoặc Singapore cho khu vực APAC, các khu vực Hoa Kỳ cho Bắc Mỹ, hoặc London cho Vương quốc Anh). Email và số điện thoại được mã hóa SHA-256 trước khi chúng được đưa vào kho lưu trữ dữ liệu của bạn, do đó dữ liệu cá nhân ở dạng văn bản thuần túy không được duy trì theo thiết kế.

Những nền tảng quảng cáo nào được hỗ trợ?

Ngay từ ngày đầu tiên: Meta Conversions API (CAPI), TikTok Events API, LINE Conversion API, Google Ads (thông qua Google Ads API / Enhanced Conversions), và LinkedIn Conversions API. Và bởi vì TopAdsROI là BYOC, việc hỗ trợ nền tảng hoàn toàn có thể tùy chỉnh — chúng tôi có thể xây dựng một tích hợp server-to-server cho bất kỳ điểm đến nào thực sự cung cấp một Conversions / Events API (ví dụ: Microsoft/Bing, Snap, Pinterest, Reddit và X), được định cấu hình cho ngăn xếp của bạn theo yêu cầu. Giới hạn duy nhất là sự trung thực: chúng tôi tích hợp các nền tảng cung cấp một điểm cuối chuyển đổi server-side thực sự, chứ không phải các kênh chỉ có pixel trình duyệt.

Các bạn có hỗ trợ LINE Conversion API không?

Có — một cách tự nhiên (natively). LINE là một kênh chính ở Nhật Bản, Đài Loan, Thái Lan và Singapore, vì vậy chúng tôi đã xây dựng tích hợp LINE Conversion API hàng đầu cùng với Meta và TikTok.

Các bạn có hỗ trợ các chuyển đổi ứng dụng iOS / Android gốc không?

TopAdsROI BYOC là một sản phẩm web / H5 thuộc server-side: nó phục hồi các chuyển đổi web bị mất do Safari ITP và các giới hạn cookie thông qua sGTM + CAPI của riêng bạn — không có SDK ứng dụng nào liên quan hoặc bắt buộc cho việc đó. Nếu bạn cũng cần các chuyển đổi trong ứng dụng gốc (iOS / Android / React Native / Flutter) được chuyển tiếp tới các CAPI của nền tảng quảng cáo, sản phẩm cùng hệ thống của chúng tôi tại topadroi.com cung cấp các SDK đó dưới dạng bộ chuyển tiếp tín hiệu server-side (không phải là một MMP — nó không thực hiện phân bổ SKAdNetwork). Hãy chạy nó song song với MMP của bạn, hoặc hỏi chúng tôi và chúng tôi sẽ hướng dẫn bạn đến giải pháp phù hợp.

Tôi có cần các kỹ sư hoặc một đội ngũ DevOps để sử dụng giải pháp này không?

Đối với mô hình BYOC (trang web này), một số năng lực cloud và DevOps sẽ giúp ích, bởi vì bạn đang chạy một container và kho dữ liệu trong cloud của riêng mình — mặc dù việc triển khai là một quy trình được hướng dẫn, chứ không phải là một dự án tự làm. Nếu bạn không có năng lực đó, sản phẩm được quản lý cùng hệ thống của chúng tôi tại topadroi.com chạy cùng một ngăn xếp sGTM + CAPI trên edge của Cloudflare mà không cần thiết lập cloud, không cần Terraform và không cần DevOps. Bạn có thể so sánh hai sản phẩm này trực tiếp tại /compare/.

Chúng tôi có thể chuyển đổi từ SaaS sang BYOC sau này (hoặc ngược lại) không?

Có — cả hai sản phẩm đều chia sẻ cùng các biểu mẫu pháp lý và tính năng tương đương ở lớp CAPI. Việc di chuyển là xuất cấu hình cộng với triển khai lại trong môi trường mục tiêu của bạn. Một lộ trình phổ biến là bắt đầu trên SaaS (topadroi.com) để xác thực mức độ bao phủ của kênh và ROI, rồi nâng cấp lên BYOC khi quy mô, áp lực từ cơ quan quản lý hoặc vị thế kiểm toán yêu cầu chủ quyền dữ liệu. Hãy yêu cầu chúng tôi cung cấp tài liệu hướng dẫn di chuyển.

TopAdsROI được triển khai như thế nào, và mất bao lâu?

Một dự án thử nghiệm điển hình chạy từ 5–10 business days từ khi bắt đầu cho đến khi sự kiện đầu tiên truyền qua edge của bạn, tùy thuộc vào phạm vi. Việc triển khai đầy đủ trên nhiều nền tảng (Meta + TikTok + LINE + Google + LinkedIn) thường hoàn thành trong khoảng 30 days. Khung thời gian thay đổi tùy thuộc vào số lượng nền tảng và thị trường trong phạm vi.

Chúng tôi có thể tự lưu trữ trên cloud của chính mình không?

Có — đó là mô hình triển khai mặc định. Chúng tôi triển khai vào cloud của riêng bạn (Google Cloud, AWS, Azure hoặc riêng tư) để dữ liệu không bao giờ rời khỏi phạm vi kiểm soát của bạn, và chúng tôi duy trì trách nhiệm vận hành theo một Data Processing Addendum.

Làm thế nào để các bạn tuân thủ cải cách Đạo luật Quyền riêng tư của Úc?

Biểu mẫu chính sách của chúng tôi phù hợp với Các nguyên tắc quyền riêng tư của Úc (APP), chương trình Thông báo vi phạm dữ liệu (NDB), và nghĩa vụ minh bạch trong việc ra quyết định tự động mới (APP 1.7, có hiệu lực từ 10 December 2026). DPO của bạn sẽ thừa hưởng một biểu mẫu hoạt động thay vì bắt đầu từ một trang giấy trắng.

Làm thế nào để các bạn tuân thủ APPI của Nhật Bản?

Chúng tôi tuân thủ các quy tắc đồng ý về cung cấp cho bên thứ ba và thông tin có thể tham chiếu cá nhân của APPI từ sửa đổi năm 2022, và các quy tắc thông báo truyền tải ra bên ngoài theo Telecommunications Business Act đã được sửa đổi (có hiệu lực từ June 2023). Các công bố thông tin chuyển giao xuyên biên giới được soạn thảo sẵn bằng tiếng Nhật.

Tính khả dụng được điều chỉnh bởi SLA mà chúng tôi thỏa thuận với từng khách hàng, chứ không phải là một lời hứa công khai chung — chúng tôi có thể hướng tới các mức như 99.9% cho edge và lớp điều phối của mình, với cam kết chính xác được nêu trong biểu mẫu đơn đặt hàng của bạn. Chế độ Workers-bypass cũng cho phép đội ngũ vận hành của bạn phát lại các sự kiện theo cách thủ công từ kho dữ liệu của bạn nếu bất kỳ liên kết nào trong chuỗi bị suy giảm.

Giá cả được xác định như thế nào?

Giá cả được hiệu chuẩn theo bốn biến số: lượng sự kiện hàng tháng, số lượng thị trường đang hoạt động, các nền tảng quảng cáo trong phạm vi, và lựa chọn lưu trú dữ liệu. Có ba mô hình thương mại sẵn có — pay-as-you-go, đăng ký định kỳ, hoặc mua trọn gói vĩnh viễn. Hãy trò chuyện với chúng tôi để nhận báo giá phù hợp.

Có phiên bản được quản lý nào không nếu chúng tôi không có tài khoản cloud hoặc DevOps?

Có — sản phẩm cùng hệ thống của chúng tôi tại topadroi.com chạy cùng một ngăn xếp sGTM + CAPI đa nền tảng trên edge của Cloudflare. Cùng 15 lines of defence, không cần thiết lập cloud, không cần Terraform, không cần DevOps. 9 verified-live ad-platform CAPIs vào ngày đầu tiên (Meta, TikTok, Google Ads, GA4, X, Snap, Pinterest, Reddit, LinkedIn), với nhiều nền tảng hơn trong bản thử nghiệm; gói miễn phí bao gồm 100K events/month không cần thẻ tín dụng. Hãy chọn BYOC (sản phẩm này) khi bạn muốn dữ liệu nằm trong cloud của riêng bạn; chọn SaaS được quản lý khi tốc độ và việc không có cơ sở hạ tầng quan trọng hơn. So sánh song song tại /compare/.

Điều gì xảy ra nếu chúng tôi hủy bỏ?

Bạn giữ cloud của mình và tất cả dữ liệu trong đó — nó chưa từng tồn tại ở bất kỳ nơi nào khác, vì vậy không có gì để chúng tôi trả lại. Chúng tôi thu hồi quyền truy cập hỗ trợ triển khai trong vòng 48 hours và giao cho bạn một danh sách kiểm tra ngừng hoạt động. Không bị ràng buộc vào nhà cung cấp.

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

Câu hỏi người mua hỏi nhiều nhất

Những câu trả lời bằng ngôn ngữ dễ hiểu cho các câu hỏi mà người mua và người mới tìm hiểu thường hỏi nhất về theo dõi phía máy chủ và chủ quyền dữ liệu trên 14 thị trường của chúng tôi — APAC + Bắc Mỹ + Vương quốc Anh.

Quick answer

Server-side Google Tag Manager là gì?

Server-side Google Tag Manager chạy container gắn thẻ trên một máy chủ mà nhà quảng cáo sở hữu — thường là một dịch vụ container bên trong cloud của chính nhà quảng cáo (ví dụ: Cloud Run trên Google Cloud, hoặc các dịch vụ tương đương trên AWS, Azure hay private cloud). Nó cải thiện chất lượng dữ liệu và, khi chạy trên subdomain first-party của nhà quảng cáo, sẽ có khả năng chống chịu tốt hơn rất nhiều đối với các trình chặn quảng cáo và Safari ITP, đồng thời cho phép nhà quảng cáo kiểm soát chính xác những trường dữ liệu nào được phép chuyển đi trước khi đến tay các nền tảng quảng cáo. TopAdsROI triển khai container này cùng với Meta CAPI, TikTok Events API, LINE Conversion API, Google Ads CAPI, và LinkedIn Conversions API vào ngay bên trong cloud của nhà quảng cáo.

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

Những câu hỏi mà người mua và người mới tìm hiểu thường hỏi nhất — được trả lời bằng ngôn ngữ dễ hiểu. Bạn có câu hỏi khác? Hãy liên hệ với chúng tôi.

server-side Google Tag Manager (sGTM) là gì, và tại sao nó lại quan trọng?

Thông thường, trang web của bạn chạy các thẻ theo dõi bên trong trình duyệt của khách truy cập — nhưng các trình duyệt (đặc biệt là Safari) và các trình chặn quảng cáo ngày càng chặn chúng nhiều hơn, vì vậy các lượt nhấp vào quảng cáo và doanh số bán hàng bị mất và ROI được báo cáo của bạn trông tệ hơn thực tế. Server-side GTM di chuyển công việc theo dõi đó sang một máy chủ do bạn kiểm soát, nhờ đó ít tín hiệu bị chặn hơn. Khi nó chạy trên miền phụ bên thứ nhất của riêng bạn, các yêu cầu sẽ hiển thị dưới dạng bên thứ nhất thay vì bên thứ ba, giúp chúng có khả năng chống chịu tốt hơn nhiều trước Safari ITP, Firefox ETP và các trình chặn quảng cáo — và dữ liệu sẽ nằm trong cloud của riêng bạn, không phải của nhà cung cấp.
Tại sao các chiến dịch quảng cáo trực tuyến ngay từ đầu đã bị 'mất' các chuyển đổi?

Một phần ngày càng tăng của các lượt mua hàng thực tế không bao giờ được gửi ngược trở lại nền tảng quảng cáo, vì vậy có vẻ như quảng cáo của bạn hoạt động kém hiệu quả hơn so với thực tế. Các nguyên nhân thông thường là Intelligent Tracking Prevention (ITP) của Safari, giới hạn các cookie trình duyệt được ghi bằng tập lệnh ở mức 7 days; các trình duyệt chặn cookie bên thứ ba; các trình chặn quảng cáo loại bỏ tập lệnh theo dõi; và khách truy cập từ chối sự đồng ý phân tích. Giao dịch mua bán vẫn diễn ra — chỉ là nền tảng không bao giờ biết về nó, vì vậy nó không thể ghi nhận công lao cho quảng cáo của bạn hoặc học hỏi từ đó.
Conversions API (CAPI) là gì, và nó khác gì so với pixel cũ?

Một pixel là một đoạn JavaScript nhỏ chạy trong trình duyệt của khách truy cập và báo cáo các sự kiện như 'Purchase' cho nền tảng quảng cáo. Một Conversions API (CAPI) cũng thực hiện công việc tương tự, nhưng theo phương thức server-to-server — máy chủ của riêng bạn gửi sự kiện trực tiếp đến API của nền tảng thay vì phụ thuộc vào trình duyệt. Do không phụ thuộc vào các cookie trình duyệt hay việc tải tập lệnh, CAPI tiếp tục báo cáo các chuyển đổi mà nếu chỉ dùng pixel thì đã bị bỏ sót.
Sự khác biệt giữa theo dõi server-side và theo dõi client-side là gì?

Theo dõi client-side (phía trình duyệt) chạy trong trình duyệt của khách truy cập, nơi các trình chặn quảng cáo, giới hạn cookie và tính năng ngăn chặn theo dõi có thể can thiệp vào nó. Theo dõi server-side chuyển công việc đó sang một máy chủ do bạn kiểm soát, sau đó máy chủ này sẽ chuyển tiếp các sự kiện sạch sẽ, đã được loại bỏ trùng lặp đến các nền tảng quảng cáo. Trình duyệt chỉ gửi sự kiện một lần đến tên miền của riêng bạn — mọi thứ dễ vỡ và dễ bị chặn sẽ được chuyển khỏi trình duyệt và đưa vào cơ sở hạ tầng mà bạn quản lý.
Nếu tôi sử dụng một Conversions API, tôi có cần pixel trình duyệt nữa không?

Có — thiết lập được khuyến nghị là chạy đồng thời cả pixel trình duyệt và server-side CAPI, chứ không phải chọn một trong hai. Pixel ghi lại ngữ cảnh trình duyệt phong phú và kích hoạt nhanh chóng, trong khi CAPI lấp đầy các khoảng trống mà pixel bỏ lỡ, vì vậy khi kết hợp lại, chúng phục hồi được nhiều chuyển đổi hơn so với khi hoạt động riêng lẻ. Cả hai được liên kết với nhau bằng một event ID dùng chung để nền tảng không tính một giao dịch bán hàng hai lần — đó là những gì quy trình loại bỏ trùng lặp xử lý.
Loại bỏ trùng lặp sự kiện (event deduplication) là gì, và tại sao nó lại quan trọng?

Khi cùng một chuyển đổi được báo cáo hai lần — một lần bởi pixel trình duyệt và một lần bởi server CAPI — nền tảng cần biết đó là một giao dịch bán hàng duy nhất, chứ không phải hai. Loại bỏ trùng lặp giải quyết vấn đề này bằng cách gắn thẻ cả hai báo cáo với cùng một event_id duy nhất, để nền tảng giữ lại một báo cáo và loại bỏ báo cáo trùng lặp. Nếu không có nó, các số liệu của bạn sẽ bị thổi phồng; có nó, Events Manager của Meta chỉ đơn giản hiển thị sự kiện là 'Deduplicated'.
fbp, fbc và các click ID là gì — và tại sao chúng lại bị mất?

Chúng là những mã định danh nhỏ giúp liên kết khách truy cập quay trở lại quảng cáo họ đã nhấp vào: fbp định danh trình duyệt, fbc mang click ID của Meta từ URL quảng cáo, và các nền tảng khác có mã định danh riêng của họ (gclid cho Google, ttclid cho TikTok). Chúng tồn tại trong cookie, vì vậy khi Safari ITP làm hết hạn cookie hoặc khách truy cập xóa trình duyệt của họ, liên kết sẽ bị đứt và chuyển đổi không còn được phân bổ cho quảng cáo đó nữa. Thiết lập server-side có thể lưu trữ những thông tin này trong một khoảng thời gian và tự động điền lại chúng vào chuyển đổi sau đó, giúp cứu vãn dữ liệu phân bổ mà nếu không thì sẽ bị mất.
BYOC có nghĩa là gì, và tại sao việc lưu trữ dữ liệu 'trong cloud của riêng bạn' lại quan trọng?

BYOC là viết tắt của Bring Your Own Cloud — hệ thống theo dõi được triển khai bên trong một tài khoản cloud do bạn sở hữu (Google Cloud, AWS, Azure hoặc riêng tư), không phải trên máy chủ của nhà cung cấp. Điều đó có nghĩa là dữ liệu quảng cáo và khách hàng thô của bạn không bao giờ rời khỏi phạm vi kiểm soát của bạn: bạn chọn khu vực, đặt thời gian lưu trữ và truy vấn dữ liệu trực tiếp mà không bị ràng buộc vào nhà cung cấp. Đối với các ngành bị quản lý nghiêm ngặt, việc 'dữ liệu được lưu trữ vật lý tại chỗ của chúng tôi' thường là sự khác biệt giữa một triển khai được cơ quan quản lý chấp nhận và một triển khai không được chấp nhận.
Việc phục hồi các chuyển đổi bị mất có thực sự cải thiện ROI/ROAS không — và bằng cách nào?

Tỷ suất hoàn vốn đầu tư quảng cáo chỉ có thể tính các chuyển đổi mà nền tảng thực sự nhận được, vì vậy việc phục hồi các chuyển đổi bị bỏ sót sẽ mang lại hai lợi ích. Thứ nhất, ROI/ROAS được báo cáo của bạn phản ánh doanh số bán hàng luôn có thực nhưng trước đây không thể nhìn thấy. Thứ hai — và mang tính bền vững hơn — thuật toán tối ưu hóa của nền tảng quảng cáo sẽ nhận được tín hiệu đầy đủ hơn về việc ai là người thực sự chuyển đổi, từ đó nhắm mục tiêu và đặt thầu chính xác hơn theo thời gian. Lợi ích lâu dài đến từ tín hiệu tốt hơn đó, chứ không chỉ là sự gia tăng báo cáo một lần.
Việc gửi các chuyển đổi bằng server-side có vi phạm quyền riêng tư của người dùng không?

Không nhất thiết phải như vậy, và một thiết lập được xây dựng tốt được thiết kế để không vi phạm. Dữ liệu cá nhân như email và số điện thoại được mã hóa SHA-256 trước khi được lưu trữ hoặc gửi đi — mã hóa là một phép biến đổi một chiều, vì vậy nền tảng có thể đối khớp dữ liệu đó mà không bao giờ nhận được văn bản thuần túy — và các lựa chọn đồng ý sẽ được kiểm tra trước khi bất kỳ sự kiện nào được gửi đi. Mục tiêu là đo lường chính xác dữ liệu bạn đã thu thập, chứ không phải thu thập thêm thông tin về mọi người hoặc giữ lại các chi tiết nhận dạng mà bạn không nên giữ.
Liệu điều này có xung đột với GA4 hoặc Google Tag Manager hiện tại của tôi không?

Không — server-side GTM hoạt động song song với những gì bạn đang chạy chứ không thay thế nó. Container GTM trên web hiện tại của bạn và GA4 tiếp tục hoạt động trong trình duyệt; container server-side là một đích đến riêng biệt nhận các sự kiện và chuyển tiếp các chuyển đổi đến các nền tảng quảng cáo, và thậm chí GA4 có thể được định tuyến qua đó để có số liệu phân tích kiên cố hơn. Không có gì trong việc gắn thẻ hiện tại của bạn phải bị loại bỏ để thêm một lớp server-side.
Tôi sẽ thấy kết quả nhanh như thế nào, và làm thế nào để đo lường chúng?

Khi các sự kiện bắt đầu hoạt động, nơi đầu tiên cần xem là chế độ xem chất lượng sự kiện của nền tảng quảng cáo — ví dụ như Events Manager của Meta — nơi các sự kiện server đã được loại bỏ trùng lặp sẽ xuất hiện cùng với các sự kiện trình duyệt trong vòng vài ngày. Thước đo rõ ràng nhất là mức tăng trong các chuyển đổi được phân bổ và Event Match Quality so với mức cơ sở chỉ dùng pixel của bạn, vì vậy việc ghi lại mức cơ sở đó trước khi bạn bắt đầu sẽ rất hữu ích. Hãy coi sự thay đổi ROI/ROAS được báo cáo là tiêu đề và tín hiệu tối ưu hóa phong phú hơn là phần thưởng dài hạn.
TopAdsROI khác biệt như thế nào so với Stape, Addingwell hoặc gtmserver.com?

Đó là những giải pháp lưu trữ đám mây tốt, nhưng họ lưu trữ dữ liệu của bạn trên cơ sở hạ tầng của họ. TopAdsROI triển khai vào cloud của riêng bạn — Google Cloud, AWS, Azure hoặc riêng tư — với kho tài liệu và kho dữ liệu trong dự án của bạn (Firestore + BigQuery trên GCP, hoặc các tài khoản tương đương trên AWS / Azure), nhờ đó bạn có quyền truy cập truy vấn trực tiếp, chính sách lưu trữ riêng và khu vực của riêng bạn. Chúng tôi cũng mô hình hóa trước cho 14 markets trên khắp Châu Á - Thái Bình Dương (APAC), Bắc Mỹ và Vương quốc Anh — mỗi thị trường có chế độ bảo mật riêng — trong khi các đơn vị khác cung cấp một nền tảng chung chung.
Dữ liệu khách hàng được lưu trữ ở đâu?

Bên trong cloud của riêng bạn — Google Cloud, AWS, Azure hoặc riêng tư — tại khu vực bạn chọn (ví dụ: Sydney, Tokyo hoặc Singapore cho khu vực APAC, các khu vực Hoa Kỳ cho Bắc Mỹ, hoặc London cho Vương quốc Anh). Email và số điện thoại được mã hóa SHA-256 trước khi chúng được đưa vào kho lưu trữ dữ liệu của bạn, do đó dữ liệu cá nhân ở dạng văn bản thuần túy không được duy trì theo thiết kế.
Những nền tảng quảng cáo nào được hỗ trợ?

Ngay từ ngày đầu tiên: Meta Conversions API (CAPI), TikTok Events API, LINE Conversion API, Google Ads (thông qua Google Ads API / Enhanced Conversions), và LinkedIn Conversions API. Và bởi vì TopAdsROI là BYOC, việc hỗ trợ nền tảng hoàn toàn có thể tùy chỉnh — chúng tôi có thể xây dựng một tích hợp server-to-server cho bất kỳ điểm đến nào thực sự cung cấp một Conversions / Events API (ví dụ: Microsoft/Bing, Snap, Pinterest, Reddit và X), được định cấu hình cho ngăn xếp của bạn theo yêu cầu. Giới hạn duy nhất là sự trung thực: chúng tôi tích hợp các nền tảng cung cấp một điểm cuối chuyển đổi server-side thực sự, chứ không phải các kênh chỉ có pixel trình duyệt.
Các bạn có hỗ trợ LINE Conversion API không?

Có — một cách tự nhiên (natively). LINE là một kênh chính ở Nhật Bản, Đài Loan, Thái Lan và Singapore, vì vậy chúng tôi đã xây dựng tích hợp LINE Conversion API hàng đầu cùng với Meta và TikTok.
Các bạn có hỗ trợ các chuyển đổi ứng dụng iOS / Android gốc không?

TopAdsROI BYOC là một sản phẩm web / H5 thuộc server-side: nó phục hồi các chuyển đổi web bị mất do Safari ITP và các giới hạn cookie thông qua sGTM + CAPI của riêng bạn — không có SDK ứng dụng nào liên quan hoặc bắt buộc cho việc đó. Nếu bạn cũng cần các chuyển đổi trong ứng dụng gốc (iOS / Android / React Native / Flutter) được chuyển tiếp tới các CAPI của nền tảng quảng cáo, sản phẩm cùng hệ thống của chúng tôi tại topadroi.com cung cấp các SDK đó dưới dạng bộ chuyển tiếp tín hiệu server-side (không phải là một MMP — nó không thực hiện phân bổ SKAdNetwork). Hãy chạy nó song song với MMP của bạn, hoặc hỏi chúng tôi và chúng tôi sẽ hướng dẫn bạn đến giải pháp phù hợp.
Tôi có cần các kỹ sư hoặc một đội ngũ DevOps để sử dụng giải pháp này không?

Đối với mô hình BYOC (trang web này), một số năng lực cloud và DevOps sẽ giúp ích, bởi vì bạn đang chạy một container và kho dữ liệu trong cloud của riêng mình — mặc dù việc triển khai là một quy trình được hướng dẫn, chứ không phải là một dự án tự làm. Nếu bạn không có năng lực đó, sản phẩm được quản lý cùng hệ thống của chúng tôi tại topadroi.com chạy cùng một ngăn xếp sGTM + CAPI trên edge của Cloudflare mà không cần thiết lập cloud, không cần Terraform và không cần DevOps. Bạn có thể so sánh hai sản phẩm này trực tiếp tại /compare/.
Chúng tôi có thể chuyển đổi từ SaaS sang BYOC sau này (hoặc ngược lại) không?

Có — cả hai sản phẩm đều chia sẻ cùng các biểu mẫu pháp lý và tính năng tương đương ở lớp CAPI. Việc di chuyển là xuất cấu hình cộng với triển khai lại trong môi trường mục tiêu của bạn. Một lộ trình phổ biến là bắt đầu trên SaaS (topadroi.com) để xác thực mức độ bao phủ của kênh và ROI, rồi nâng cấp lên BYOC khi quy mô, áp lực từ cơ quan quản lý hoặc vị thế kiểm toán yêu cầu chủ quyền dữ liệu. Hãy yêu cầu chúng tôi cung cấp tài liệu hướng dẫn di chuyển.
TopAdsROI được triển khai như thế nào, và mất bao lâu?

Một dự án thử nghiệm điển hình chạy từ 5–10 business days từ khi bắt đầu cho đến khi sự kiện đầu tiên truyền qua edge của bạn, tùy thuộc vào phạm vi. Việc triển khai đầy đủ trên nhiều nền tảng (Meta + TikTok + LINE + Google + LinkedIn) thường hoàn thành trong khoảng 30 days. Khung thời gian thay đổi tùy thuộc vào số lượng nền tảng và thị trường trong phạm vi.
Chúng tôi có thể tự lưu trữ trên cloud của chính mình không?

Có — đó là mô hình triển khai mặc định. Chúng tôi triển khai vào cloud của riêng bạn (Google Cloud, AWS, Azure hoặc riêng tư) để dữ liệu không bao giờ rời khỏi phạm vi kiểm soát của bạn, và chúng tôi duy trì trách nhiệm vận hành theo một Data Processing Addendum.
Làm thế nào để các bạn tuân thủ cải cách Đạo luật Quyền riêng tư của Úc?

Biểu mẫu chính sách của chúng tôi phù hợp với Các nguyên tắc quyền riêng tư của Úc (APP), chương trình Thông báo vi phạm dữ liệu (NDB), và nghĩa vụ minh bạch trong việc ra quyết định tự động mới (APP 1.7, có hiệu lực từ 10 December 2026). DPO của bạn sẽ thừa hưởng một biểu mẫu hoạt động thay vì bắt đầu từ một trang giấy trắng.
Làm thế nào để các bạn tuân thủ APPI của Nhật Bản?

Chúng tôi tuân thủ các quy tắc đồng ý về cung cấp cho bên thứ ba và thông tin có thể tham chiếu cá nhân của APPI từ sửa đổi năm 2022, và các quy tắc thông báo truyền tải ra bên ngoài theo Telecommunications Business Act đã được sửa đổi (có hiệu lực từ June 2023). Các công bố thông tin chuyển giao xuyên biên giới được soạn thảo sẵn bằng tiếng Nhật.
SLA là gì?

Tính khả dụng được điều chỉnh bởi SLA mà chúng tôi thỏa thuận với từng khách hàng, chứ không phải là một lời hứa công khai chung — chúng tôi có thể hướng tới các mức như 99.9% cho edge và lớp điều phối của mình, với cam kết chính xác được nêu trong biểu mẫu đơn đặt hàng của bạn. Chế độ Workers-bypass cũng cho phép đội ngũ vận hành của bạn phát lại các sự kiện theo cách thủ công từ kho dữ liệu của bạn nếu bất kỳ liên kết nào trong chuỗi bị suy giảm.
Giá cả được xác định như thế nào?

Giá cả được hiệu chuẩn theo bốn biến số: lượng sự kiện hàng tháng, số lượng thị trường đang hoạt động, các nền tảng quảng cáo trong phạm vi, và lựa chọn lưu trú dữ liệu. Có ba mô hình thương mại sẵn có — pay-as-you-go, đăng ký định kỳ, hoặc mua trọn gói vĩnh viễn. Hãy trò chuyện với chúng tôi để nhận báo giá phù hợp.
Có phiên bản được quản lý nào không nếu chúng tôi không có tài khoản cloud hoặc DevOps?

Có — sản phẩm cùng hệ thống của chúng tôi tại topadroi.com chạy cùng một ngăn xếp sGTM + CAPI đa nền tảng trên edge của Cloudflare. Cùng 15 lines of defence, không cần thiết lập cloud, không cần Terraform, không cần DevOps. 9 verified-live ad-platform CAPIs vào ngày đầu tiên (Meta, TikTok, Google Ads, GA4, X, Snap, Pinterest, Reddit, LinkedIn), với nhiều nền tảng hơn trong bản thử nghiệm; gói miễn phí bao gồm 100K events/month không cần thẻ tín dụng. Hãy chọn BYOC (sản phẩm này) khi bạn muốn dữ liệu nằm trong cloud của riêng bạn; chọn SaaS được quản lý khi tốc độ và việc không có cơ sở hạ tầng quan trọng hơn. So sánh song song tại /compare/.
Điều gì xảy ra nếu chúng tôi hủy bỏ?

Bạn giữ cloud của mình và tất cả dữ liệu trong đó — nó chưa từng tồn tại ở bất kỳ nơi nào khác, vì vậy không có gì để chúng tôi trả lại. Chúng tôi thu hồi quyền truy cập hỗ trợ triển khai trong vòng 48 hours và giao cho bạn một danh sách kiểm tra ngừng hoạt động. Không bị ràng buộc vào nhà cung cấp.

Có câu hỏi nào chúng tôi bỏ sót?

Một solutions engineer cấp cao sẽ liên hệ trong vòng 1 ngày làm việc.

Trò chuyện miễn phí Bảo mật