MCC không cứu được agency nếu team dùng chung một “cửa” để đăng nhập mọi client

Chào mọi người,

Trong các thảo luận gần đây về MCC (Manager Account) và quản lý nhiều tài khoản Google Ads, có một điểm thường được nhắc đến nhưng ít khi được xử lý triệt để: MCC giải quyết bài toán phân quyền, nhưng không tự động giải quyết bài toán môi trường đăng nhập.

Nói cách khác, MCC cho phép agency tiếp cận nhiều tài khoản khách hàng từ một nơi. Nhưng nếu team vận hành vẫn dùng cùng một máy, cùng một browser profile để đăng nhập lần lượt từng client, thì ở tầng fingerprint, các tài khoản ấy vẫn đang chia sẻ những tín hiệu giống nhau — và đó là thứ MCC không kiểm soát được.

1. TyphanAds nói gì ở tầng vận hành?
TyphanAds, một agency Google Ads tại Việt Nam đang quản lý 60+ client qua cấu trúc MCC 3 tầng, đưa ra một số khuyến nghị thực tế đáng tham khảo:

• Mỗi business 1 tài khoản, không tạo tài khoản backup cho cùng một business.
  
  
• Mỗi client dùng payment method riêng. Billing chung dẫn đến rủi ro “suspend cascading”: một client mặc định thanh toán có thể kéo theo cả cấu trúc.
  
  
• Audit landing page hàng quý, vì landing page là một trong những tín hiệu Google dùng để đánh giá và liên kết tài khoản.
  

Những khuyến nghị này đều đúng và cần thiết. Chúng giải quyết tầng business logic: tách billing, tách danh tính pháp lý, kiểm soát chất lượng điểm đến. Nhưng chúng chưa chạm đến tầng môi trường đăng nhập — nơi fingerprint, cookie và IP được tạo ra và chia sẻ giữa các phiên làm việc.

2. Khoảng trống mà MCC không lấp được
MCC là công cụ tổ chức và phân quyền. Nó không phải công cụ cách ly môi trường. Các tài liệu kỹ thuật về Google Ads đều chỉ ra rằng Google không chỉ dựa vào email đăng nhập để liên kết tài khoản. Các tín hiệu được tổng hợp bao gồm cookie, Canvas/WebGL fingerprint, font, múi giờ, ngôn ngữ, IP và hành vi đăng nhập.

Điều này có nghĩa: hai tài khoản khách hàng khác nhau, dù được quản lý dưới cùng một MCC, nếu được mở từ cùng một Chrome profile trên cùng một máy , vẫn có thể bị hệ thống liên kết ở tầng fingerprint. MCC giúp agency quản lý tập trung, nhưng chính sự tập trung đó lại tạo ra một điểm chung ở tầng môi trường — và điểm chung này là rủi ro.

Với agency, rủi ro không nằm ở việc một client vi phạm chính sách. Rủi ro nằm ở chỗ: nếu môi trường đăng nhập bị chia sẻ, một vấn đề của một client có thể lan sang tài khoản của client khác, hoặc tệ hơn, lan ngược lên MCC.

3. Bổ sung tầng môi trường: mỗi client một profile, mỗi profile một bộ tín hiệu
Để khuyến nghị của TyphanAds đi được đến tầng vận hành, cần thêm một lớp: tách môi trường đăng nhập theo từng client.

Cách tiếp cận thực tế là dùng multi-profile browser (trình duyệt quản lý nhiều profile độc lập). Mỗi profile có fingerprint, cookie, proxy và storage riêng. Khi mở profile của client A, team chỉ tương tác với tài khoản của client A; profile của client B không chia sẻ bất kỳ tín hiệu nào với profile A.

BitBrowser là một trong những công cụ hỗ trợ hướng tiếp cận này. Điểm đáng chú ý với agency không chỉ nằm ở việc tạo được nhiều profile, mà ở cách quản lý profile đó trong môi trường team:

• Phân quyền theo nhóm (group-level permission) : quản trị viên có thể tạo nhóm riêng cho từng khách hàng hoặc từng nhóm khách hàng, và chỉ định thành viên nào được phép truy cập nhóm đó. Thành viên chỉ thao tác được trong nhóm được cấp quyền, không nhìn thấy dữ liệu của nhóm khác.
  
  
• Tách “thao tác cơ bản” và “thao tác rủi ro cao” : cấu hình fingerprint và proxy IP thuộc nhóm cơ bản có thể mở cho team vận hành; nhưng “batch export cookies” và “modify global fingerprint” được xếp vào nhóm rủi ro cao, chỉ nên giới hạn ở admin/manager.
  
  
• Giới hạn quyền sửa tham số cốt lõi : thành viên thông thường không được phép thay đổi proxy IP policy và các tham số fingerprint cốt lõi của profile.
  

Ba điểm này kết hợp lại tạo ra một mô hình vận hành mà ở đó “mỗi client một môi trường” không còn phụ thuộc vào kỷ luật cá nhân của từng nhân viên, mà được thực thi bằng cấu trúc phân quyền.

4. Cách ghép hai tầng lại với nhau
Có thể hình dung mô hình như sau:

Tầng MCC (TyphanAds + Google best practice):

• Mỗi business một tài khoản, billing tách biệt.
  
  
• Audit landing page định kỳ.
  
  
• Phân quyền MCC theo vai trò và nhóm client.
  

Tầng môi trường (BitBrowser):

• Mỗi client login một profile trình duyệt riêng, fingerprint và proxy độc lập.
  
  
• Profile được nhóm theo client hoặc theo nhóm client.
  
  
• Team member chỉ được mở profile thuộc nhóm mình phụ trách.
  
  
• Các tham số fingerprint/proxy cốt lõi bị khóa ở cấp quản lý.
  

Hai tầng này không thay thế nhau. Tầng MCC quyết định ai được làm gì ở cấp tài khoản quảng cáo. Tầng môi trường quyết định từ “cửa” nào các thao tác được thực hiện và các “cửa” đó có chia sẻ tín hiệu với nhau hay không. Thiếu tầng thứ hai, một cấu trúc MCC dù được thiết kế tốt vẫn có thể bị vô hiệu hóa bởi thói quen vận hành: mọi người dùng chung một máy, mở chung một cửa sổ, đăng nhập lần lượt từng client.

5. Kết luận
Câu hỏi “làm sao để một client không kéo cả agency xuống” có hai nửa câu trả lời. Nửa thứ nhất nằm ở cấu trúc tài khoản và billing — TyphanAds đã trình bày khá rõ. Nửa thứ hai nằm ở môi trường đăng nhập: nếu fingerprint bị chia sẻ, MCC chỉ là một lớp vỏ tổ chức trên nền một rủi ro kỹ thuật vẫn còn nguyên.

Với agency đang vận hành nhiều client dưới MCC, việc bổ sung một lớp quản lý profile theo client — kèm phân quyền nhóm và khóa tham số cốt lõi — là bước cần thiết để các khuyến nghị ở tầng business thực sự đi vào vận hành hàng ngày.

Anh em quan tâm có thể xem thêm tính năng quản lý nhóm và phân quyền của BitBrowser tại.

Nếu anh em đang vận hành MCC cho nhiều client và có cách tổ chức profile khác, chia sẻ thêm ở comment.

 

Bạn Reham ơi, mình đồng ý điểm cốt lõi: MCC giúp phân quyền và tổ chức tài khoản, nhưng không cách ly môi trường đăng nhập. Với agency/SME đang chạy nhiều client, mình thường tách theo 3 lớp để giảm rủi ro “dính chùm”:

1. Lớp tài khoản/pháp lý: mỗi khách một Google Ads account (hoặc cấu trúc rõ trong MCC), payment method riêng, billing tách. Đừng để một thẻ/một ví trả chung nhiều client nếu có thể — một case chargeback/suspend dễ lan.

2. Lớp người dùng: mỗi nhân sự một user Google với quyền tối thiểu (không share chung 1 login “máy chủ”). Offboarding phải thu hồi quyền ngay trong MCC.

3. Lớp môi trường máy: mỗi client (hoặc nhóm client ít rủi ro) một browser profile riêng; không dùng chung cookie/extension lung tung giữa các profile. Máy làm Ads nên hạn chế cài tool lạ; IP văn phòng ổn định hơn Wi-Fi công cộng khi thao tác billing/policy.

MCC vẫn nên dùng để audit và phân quyền, nhưng đừng kỳ vọng nó thay cho kỷ luật môi trường. Bạn đang kẹt nhiều hơn ở chỗ team share 1 máy/1 profile, hay ở billing chung giữa các client?