API chuyển đổi (CAPI) là gì và ảnh hưởng giá mỗi đơn

API chuyển đổi (CAPI) là cách gửi thông tin đơn hàng từ máy chủ của bạn thẳng về nền tảng quảng cáo, thay vì để trình duyệt của khách hàng gửi hộ. Nó ảnh hưởng trực tiếp tới giá mỗi đơn vì con số đó là phép chia: tiền đã chi chia cho số đơn nền tảng ghi nhận được. Nếu nền tảng chỉ thấy sáu mươi trong số một trăm đơn có thật, giá mỗi đơn trên báo cáo cao hơn thực tế gần gấp đôi.

Ở thị trường Việt, mức thất thoát thường lớn hơn người ta nghĩ. Rất nhiều đơn chốt qua tin nhắn, qua điện thoại, hoặc chốt sau vài ngày. Không đơn nào trong số đó đi qua trang cảm ơn, nên đoạn mã đo lường gắn trên website không bao giờ chạy.

Bài này đi theo đúng thứ tự bạn sẽ làm trong thực tế: hiểu hai đường báo chuyển đổi, đo xem mình đang mất bao nhiêu, chuẩn bị bốn thông tin bắt buộc, dựng cho một sự kiện trước, kiểm tra, rồi mới mở rộng. Kèm một ca thật và phần nói rõ việc này không giải quyết được gì.

API chuyển đổi (CAPI) là gì

Hãy bám vào một luồng mua hàng cụ thể để khỏi lạc vào chữ nghĩa kỹ thuật.

Một người thấy quảng cáo trên Facebook, bấm vào, xem trang sản phẩm, nhắn tin hỏi về kích cỡ, hai ngày sau nhắn lại và chốt mua, chuyển khoản, nhân viên ghi đơn vào phần mềm bán hàng. Đơn đó có thật, tiền đã về, và nó đến từ quảng cáo.

Nền tảng quảng cáo biết được gì trong chuỗi đó? Nó biết có người bấm vào quảng cáo. Sau đó nó mù hoàn toàn. Khách không quay lại website, không có trang thanh toán nào được mở, nên đoạn mã đo lường trên trang không có gì để báo.

API chuyển đổi là đường báo bù cho khoảng mù đó. Khi nhân viên đánh dấu đơn là đã xác nhận trong phần mềm bán hàng, hệ thống của bạn gọi thẳng tới nền tảng và nói: có một đơn, xảy ra lúc này, trị giá bằng này, của người có số điện thoại đã được mã hoá bằng này. Nền tảng đối chiếu, nhận ra đây chính là người đã bấm vào quảng cáo hai ngày trước, và ghi nhận đơn cho chiến dịch.

Mỗi nền tảng gọi việc này bằng một cái tên riêng. Meta gọi là Conversions API. Google Ads gọi là nhập chuyển đổi ngoại tuyến hoặc Enhanced Conversions for Leads tuỳ luồng. TikTok có Events API. Cơ chế giống nhau: máy chủ của bạn nói chuyện thẳng với máy chủ của nền tảng, không qua máy khách hàng.

Hai đường báo chuyển đổi khác nhau ở đâu

Đường qua trình duyệt

Cách cũ, và vẫn là cách phổ biến nhất. Bạn dán một đoạn mã vào website. Khi khách hoàn tất đơn, đoạn mã chạy trên máy của khách và gửi tín hiệu về nền tảng.

Nó hoạt động được, nhưng rơi rụng ở nhiều chỗ. Trình duyệt chặn mã theo dõi của bên thứ ba theo mặc định. Tiện ích chặn quảng cáo chặn thẳng tên miền của nền tảng. Khách đóng trang trước khi mã kịp gửi xong. Sóng điện thoại rớt đúng lúc đó. Trang cảm ơn không được tải vì luồng thanh toán chuyển sang một ứng dụng ngân hàng rồi không quay lại.

Mỗi trường hợp trong đó là một đơn có thật mà nền tảng không hề biết.

Đường gửi từ máy chủ

Hệ thống của bạn tự gửi tín hiệu: có thể là website, phần mềm bán hàng, hoặc phần mềm quản lý khách hàng. Cuộc gọi này đi từ máy chủ của bạn tới máy chủ nền tảng, không đi qua máy của khách.

Không tiện ích nào chặn được, vì nó không chạy trên máy khách. Và nó làm được hai việc mà đường trình duyệt không làm nổi: báo được đơn chốt sau nhiều ngày, và báo được đơn phát sinh hoàn toàn ngoài website.

Vì sao phải giữ cả hai

Nhiều người dựng xong đường máy chủ thì gỡ đoạn mã trên trang cho gọn. Đó là bước lùi.

Đoạn mã trên trang mang theo thông tin về phiên truy cập mà máy chủ không có: khách đến từ quảng cáo nào, thiết bị gì, mã nhận diện trình duyệt mà nền tảng đã gắn từ lúc hiển thị quảng cáo. Máy chủ thì mang theo những đơn mà trang không nhìn thấy. Hai nguồn bù cho nhau chứ không thay nhau.

Điều kiện để dùng cả hai mà không bị đếm đôi: cả hai phải gửi kèm cùng một mã sự kiện cho cùng một đơn. Nền tảng dựa vào mã đó để nhận ra hai tín hiệu này nói về một việc.

Mất tín hiệu làm hỏng quyết định thế nào

Đây là phần đáng quan tâm nhất, vì nó cho thấy chuyện này không phải chuyện kỹ thuật mà là chuyện tiền.

Lấy một chiến dịch chi hai mươi triệu và mang về đúng một trăm đơn. Giá mỗi đơn thật là hai trăm nghìn.

Nền tảng chỉ ghi nhận sáu mươi đơn, vì bốn mươi đơn kia chốt qua tin nhắn hoặc bị chặn ở đường trình duyệt. Phép chia của nền tảng cho ra ba trăm ba mươi ba nghìn một đơn.

Hệ tối ưu của nền tảng đọc con số đó và kết luận chiến dịch này kém hơn mức mục tiêu, nên giảm phân phối và đẩy ngân sách sang chỗ khác. Nó không cố ý làm sai, nó tối ưu theo đúng dữ liệu nó có.

Bạn đọc cùng con số đó và kết luận quảng cáo đắt quá, nên giảm ngân sách. Cả hai kết luận đều sai, và cả hai đều hợp lý nếu chỉ nhìn báo cáo.

Cái hại kép ít người tính tới

Mất tín hiệu không chỉ làm báo cáo sai. Nó làm hệ tối ưu học sai, và cái này tốn hơn nhiều.

Các nền tảng đều học từ dữ liệu chuyển đổi để tìm thêm người giống người đã mua. Nếu bốn mươi phần trăm đơn không được báo về, hệ thống học từ một mẫu thiếu. Và mẫu đó không thiếu ngẫu nhiên: nó thiếu đúng nhóm khách hay dùng trình duyệt có chặn theo dõi, hoặc nhóm quen chốt đơn qua tin nhắn thay vì bấm mua trên web.

Nghĩa là quảng cáo dần được huấn luyện để tìm sai nhóm người. Cái hại này tích luỹ theo tháng và không hiện lên bất kỳ báo cáo nào, vì báo cáo chỉ so số của bạn với chính số của bạn.

Vì sao phải vá đo lường trước khi tối ưu

Mọi việc tối ưu đều là ra quyết định dựa trên số. Chọn chiến dịch nào để tăng ngân sách, tắt nhóm quảng cáo nào, giữ mẫu quảng cáo nào, đặt giá thầu bao nhiêu. Tất cả đọc từ cùng một bảng số liệu tài khoản.

Nếu bảng đó thiếu bốn mươi phần trăm đơn, và phần thiếu tập trung ở một số chiến dịch nhất định, thì việc tối ưu sẽ đẩy tiền ra khỏi đúng những chiến dịch đang chạy tốt. Càng tối ưu chăm chỉ càng lệch nhanh. Đây là lý do thứ tự đúng luôn là vá đo lường trước, tối ưu sau.

Bốn thứ bắt buộc trong một sự kiện gửi về

Một: mã sự kiện

Một chuỗi định danh duy nhất cho đơn đó, gửi kèm ở cả đường trình duyệt lẫn đường máy chủ.

Đây là trường hay làm sai nhất. Kiểu sai phổ biến: phía máy chủ dùng mã đơn hàng của phần mềm bán hàng, còn phía trình duyệt sinh một chuỗi ngẫu nhiên. Hai mã khác nhau nên nền tảng đếm thành hai đơn, và số liệu tăng gấp đôi một cách rất thuyết phục. Nhìn báo cáo thì thấy tháng này bùng nổ, thực tế là đang đếm mỗi đơn hai lần.

Cách làm đúng: sinh mã ở đúng một chỗ, thường là ngay khi đơn được tạo trong phần mềm bán hàng, rồi truyền cho cả hai bên cùng dùng.

Hai: thời điểm xảy ra

Ghi thời điểm đơn phát sinh, không phải thời điểm bạn bấm gửi.

Điều này quan trọng vì đường máy chủ thường có độ trễ: hàng đợi xử lý, chạy theo lô mỗi giờ, hoặc đơn chốt sau vài ngày mới được xác nhận. Ghi sai thời điểm làm nền tảng quy đơn về sai ngày, và mọi báo cáo theo ngày đều lệch. Nặng hơn, đơn có thể rơi ra ngoài khoảng thời gian quy nguồn và không được tính cho chiến dịch nào cả.

Ba: giá trị đơn

Số tiền thật của đơn, kèm đơn vị tiền tệ.

Không có giá trị thì bạn chỉ đếm được số đơn, không tính được doanh thu trên chi phí. Với ngành mà giá trị đơn chênh nhau nhiều lần, đếm số đơn gần như vô nghĩa: một trăm đơn phụ kiện không bằng mười đơn máy chính. Nếu bạn muốn nền tảng tối ưu theo doanh thu chứ không theo số lượng, trường này là bắt buộc.

Bốn: dữ liệu nhận diện đã băm

Email và số điện thoại, băm trước khi gửi, không gửi thô.

Nền tảng dùng dữ liệu này để khớp đơn với người đã nhìn thấy quảng cáo. Không có nó, phần lớn sự kiện bạn gửi về sẽ tới nơi nhưng không nối được với ai, nên không quy được cho chiến dịch nào. Dữ liệu đến đủ, mà vẫn vô dụng.

Đây là trường hay bị quên nhất, và quên nó thì cả công dựng gần như không thu được gì.

Dựng CAPI trong thực tế: bốn bước, ai làm bước nào

Bước 1: chọn đúng một sự kiện để bắt đầu

Người làm: bên marketing. Đừng gửi mọi thứ ngay từ đầu. Chọn một sự kiện quan trọng nhất với việc kinh doanh của bạn, thường là đơn hoàn tất hoặc khách để lại thông tin.

Gửi nhiều loại sự kiện cùng lúc làm việc kiểm tra khó hơn hẳn, và khi có sai thì không biết sai ở luồng nào. Thêm sự kiện thứ hai sau khi sự kiện thứ nhất đã chạy đúng ít nhất hai tuần.

Bước 2: chọn chỗ trong hệ thống biết chắc đơn đã xảy ra

Người làm: bên kỹ thuật cùng bên vận hành đơn. Chỗ nào trong hệ thống của bạn biết chắc chắn rằng đơn đã hoàn tất? Thường là phần mềm bán hàng hoặc phần mềm quản lý khách hàng, hiếm khi là website.

Chọn đúng chỗ này quan trọng hơn cách gửi. Nếu gửi từ chỗ chưa chắc chắn, chẳng hạn ngay khi khách bấm nút đặt hàng mà chưa thanh toán, bạn sẽ báo về những đơn không tồn tại và dạy nền tảng tìm những người không mua.

Bước 3: gửi thử và đối chiếu bằng công cụ kiểm tra

Người làm: bên kỹ thuật, bên marketing ngồi cạnh xem. Mọi nền tảng đều có màn hình xem sự kiện nhận được theo thời gian thực. Gửi vài đơn thật, mở màn hình đó, kiểm ba việc: sự kiện có tới không, có đủ bốn trường không, và có bị đếm thành hai không.

Bước này hay bị bỏ vì ai cũng muốn xong việc. Bỏ nó thì bạn sẽ phát hiện lỗi sau ba tuần, bằng cách nhìn một con số vô lý trên báo cáo và không biết nó bắt đầu sai từ bao giờ.

Bước 4: theo dõi tỉ lệ khớp trong hai tuần đầu

Người làm: bên marketing. Nền tảng báo cho bạn bao nhiêu phần trăm sự kiện gửi về được nối với một người dùng cụ thể. Con số này là chỉ số sức khoẻ chính của cả luồng.

Tỉ lệ khớp thấp gần như luôn có nguyên nhân ở dữ liệu nhận diện: thiếu trường, băm sai định dạng, hoặc không chuẩn hoá trước khi băm. Rất hiếm khi nguyên nhân nằm ở chỗ khác, nên cứ soi vào đó trước.

Ba lỗi hay gặp

Lỗi 1: trùng sự kiện vì hai bên sinh mã khác nhau

Dấu hiệu nhận ra rất rõ: sau khi bật đường máy chủ, số đơn tăng đúng khoảng gấp đôi. Nếu bạn thấy con số đẹp bất thường như vậy, hãy nghi ngờ trước khi ăn mừng.

Nguyên nhân là mã sự kiện hai bên không giống nhau nên nền tảng không nhận ra đây là một đơn. Cách kiểm tra: mở báo cáo tỉ lệ trùng lặp mà nền tảng cung cấp, nếu tỉ lệ khử trùng lặp gần bằng không trong khi bạn đang chạy song song hai đường thì mã đang sai.

Cách sửa: sinh mã ở một chỗ duy nhất và truyền xuống cho cả hai bên, đừng để mỗi bên tự tạo.

Lỗi 2: thiếu mã sự kiện ở một trong hai đường

Trường hợp thường gặp hơn cả lỗi trên: đường máy chủ có mã, đường trình duyệt không có, hoặc ngược lại. Kết quả giống hệt lỗi trùng nhưng khó soi hơn, vì lập trình viên nhìn phía mình thấy có mã đầy đủ nên khẳng định là đúng.

Cách kiểm tra chắc chắn nhất là đặt một đơn thật, rồi mở công cụ kiểm tra sự kiện và xem chính đơn đó xuất hiện mấy lần, mỗi lần mang mã gì.

Lỗi 3: sai định dạng mã hoá dữ liệu nhận diện

Băm là phép biến đổi một chiều, nhưng nó chỉ khớp được khi hai bên chuẩn hoá giống nhau trước khi băm. Chuỗi khác nhau một dấu cách sẽ cho ra hai kết quả băm hoàn toàn khác nhau.

Ba chỗ hay sai với dữ liệu Việt Nam: số điện thoại còn dấu cách hoặc dấu chấm giữa các cụm số; số điện thoại giữ dạng bắt đầu bằng số không thay vì mã quốc gia; email còn chữ hoa hoặc còn khoảng trắng thừa ở đầu cuối.

Triệu chứng của lỗi này là tỉ lệ khớp thấp bất thường trong khi mọi thứ khác trông vẫn ổn. Dữ liệu vẫn tới, không có lỗi nào báo về, chỉ là nền tảng không nối được với ai.

Lỗi phụ hay đi kèm: gửi cả đơn đã huỷ

Phần mềm bán hàng tạo đơn, luồng gửi bắn tín hiệu đi ngay, rồi khách huỷ. Nếu không có bước xử lý huỷ, nền tảng vẫn tin đơn đó tồn tại. Với ngành có tỉ lệ huỷ cao thì mức sai lệch này đủ để làm hỏng mọi quyết định.

Cách xử: chỉ gửi khi đơn đã ở trạng thái chắc chắn, hoặc gửi thêm một sự kiện đảo khi có huỷ.

Cách kiểm tra mình đang mất bao nhiêu tín hiệu

Trước khi dựng, nên biết vấn đề của mình lớn tới đâu. Ba cách đo, xếp từ dễ tới chắc.

Cách 1: đối chiếu với sổ bán hàng

Lấy tổng số đơn trong tháng theo phần mềm bán hàng của bạn, so với tổng số chuyển đổi mà nền tảng báo trong cùng tháng. Phần chênh chính là phần bạn đang mất, cộng thêm phần đơn không đến từ quảng cáo.

Cách này thô nhưng cho ngay một con số để quyết định. Chênh dưới mười phần trăm thì để sau cũng được. Chênh trên ba mươi phần trăm thì đây là việc cấp bách hơn mọi việc tối ưu khác trong tài khoản.

Muốn chính xác hơn thì lọc sổ bán hàng theo nguồn khách trước khi so, nếu phần mềm của bạn có ghi nguồn.

Cách 2: hỏi khách biết tới qua đâu

Thêm một câu vào biểu mẫu đặt hàng, hoặc để nhân viên hỏi khi chốt đơn. Cách này không chính xác vì người ta hay nhớ sai, nhưng nó bắt được nhóm đơn mà không hệ thống đo lường nào nhìn thấy: người thấy quảng cáo trên điện thoại lúc tối, ba ngày sau gọi điện đặt hàng.

Dùng nó như một phép kiểm tra chéo, không dùng làm con số chính thức.

Cách 3: so tỉ lệ chuyển đổi giữa các nguồn theo thời gian

Nếu tỉ lệ chuyển đổi từ một nguồn tụt bất thường trong khi lưu lượng giữ nguyên, khả năng cao là hỏng đo lường chứ không phải chất lượng khách kém đi. Chất lượng khách thường đổi từ từ, còn đo lường thì hỏng theo kiểu rơi thẳng đứng vào một ngày cụ thể, thường là ngày ai đó đổi gì đó trên website.

Đọc gì trên màn hình kiểm tra sự kiện

Sau khi đã dựng, ba ô này là ba ô cần nhìn mỗi lần mở công cụ kiểm tra của nền tảng.

Số sự kiện nhận được trong hai bốn giờ qua. So với số đơn thật trong sổ. Lệch nhiều nghĩa là luồng gửi rơi rớt.

Tỉ lệ khớp. Đây là ô quan trọng nhất và cũng là ô người ta hay lướt qua. Tỉ lệ này tụt dần theo tháng thường là do biểu mẫu bị bỏ bớt một trường, hoặc ai đó đổi cách chuẩn hoá số điện thoại.

Tỉ lệ khử trùng lặp. Khi chạy song song hai đường, một tỉ lệ khử trùng lặp lành mạnh chứng minh mã sự kiện đang hoạt động. Nếu nó bằng không, hai đường của bạn đang đếm riêng.

Một ca thật, kể đủ chi tiết

Ca này gộp từ vài tài khoản đã làm, không nêu tên khách hàng.

Bối cảnh. Một cửa hàng bán qua cả website lẫn tin nhắn. Báo cáo Meta nói giá mỗi đơn hơn ba trăm nghìn, trong khi mục tiêu của chủ cửa hàng là hai trăm nghìn. Vì con số đó, chủ cửa hàng đã giảm ngân sách hai lần trong hai tháng.

Bước đầu: đối chiếu. Sổ bán hàng ghi nhận số đơn cao hơn nền tảng khoảng bốn mươi phần trăm. Phần chênh nằm gần như trọn vẹn ở nhóm khách nhắn tin hỏi rồi chốt luôn trong tin nhắn, không bao giờ đi qua trang thanh toán.

Cách xử. Gửi sự kiện từ phần mềm quản lý khách hàng vào lúc đơn chuyển sang trạng thái đã xác nhận, kèm dữ liệu nhận diện băm từ số điện thoại khách để lại khi nhắn tin.

Kết quả về mặt số liệu. Số đơn nền tảng ghi nhận tăng đáng kể ngay trong tuần đầu, và giá mỗi đơn hiển thị giảm về gần mức thật.

Điểm quan trọng nhất, cũng là điểm hay bị hiểu sai. Không có đơn nào tăng thêm. Doanh thu tuần đó không đổi. Cái thay đổi là báo cáo bắt đầu nói đúng.

Đây là chỗ nhiều người vấp: họ thấy số đơn tăng mạnh sau khi bật, rồi đưa con số đó vào báo cáo nội bộ như một kết quả kinh doanh. Không có gì tăng cả, chỉ là phần đơn có thật được nhìn thấy đã tăng. Cách làm đúng là đánh dấu rõ ngày bật trên mọi biểu đồ và bắt đầu một mốc so sánh mới từ ngày đó, không so trực tiếp trước với sau.

Hệ quả thật thì tới sau. Vì hệ tối ưu nhận được dữ liệu đầy đủ hơn, nó bắt đầu tìm đúng nhóm người hơn. Việc này mất vài tuần và khó tách khỏi các yếu tố khác, nên ở đây không có con số. Đưa ra một con số cho phần đó sẽ là bịa.

Thứ tự làm nếu bắt đầu từ số không

Tuần 1: đo mức chênh. Đối chiếu sổ bán hàng với báo cáo nền tảng của tháng trước. Có con số rồi mới quyết định làm tới đâu. Nếu chênh dưới mười phần trăm, bạn có thể dừng ở đây và dành công cho việc khác.

Tuần 2: bật cảnh báo hỏng đo lường. Làm trước cả khi dựng luồng gửi. Đặt một quy tắc tự động báo khi số chuyển đổi ghi nhận về không, hoặc tụt mạnh so với cùng kỳ tuần trước. Mất năm phút và nó bảo vệ mọi quyết định sau đó.

Tuần 3 và 4: dựng cho một sự kiện, một nền tảng. Chọn nền tảng đang chi nhiều nhất và sự kiện quan trọng nhất. Gửi thử, đối chiếu bằng công cụ kiểm tra, theo dõi tỉ lệ khớp cho tới khi nó ổn định.

Tháng 2: mở rộng. Thêm nền tảng thứ hai, dùng lại đúng chỗ phát sinh sự kiện đã có. Đừng dựng luồng riêng cho từng nền tảng, vì như vậy mỗi lần đổi phần mềm bán hàng bạn phải sửa nhiều chỗ.

Tháng 3: nhìn lại các quyết định ngân sách cũ. Giờ mới là lúc đọc lại những chiến dịch bạn đã ghìm hoặc đã tắt dựa trên số cũ. Nhiều chiến dịch bị đánh giá oan sẽ lộ ra ở bước này, và đây chính là chỗ công sức ba tháng trước đó được trả lại.

Chuyện dữ liệu khách hàng: gửi cái gì, tuyệt đối không gửi cái gì

Gửi dữ liệu nhận diện đi, kể cả đã băm, vẫn là chuyển dữ liệu khách hàng cho một bên thứ ba. Phần này không phải chuyện kỹ thuật và không nên giao cho một mình bên kỹ thuật quyết.

Nên gửi

Chỉ những trường phục vụ đúng việc khớp người: email đã băm, số điện thoại đã băm, và mã đơn hàng dùng làm mã sự kiện. Thêm nữa thì cân nhắc từng trường một, và mỗi trường phải trả lời được câu hỏi nó giúp khớp thêm bao nhiêu.

Tuyệt đối không gửi

Đừng gửi email hay số điện thoại ở dạng thô. Đừng gửi nội dung tin nhắn, ghi chú của nhân viên bán hàng, hay bất cứ trường tự do nào, vì bạn không kiểm soát được người ta đã gõ gì vào đó. Đừng gửi số tài khoản, số căn cước, thông tin sức khoẻ, hay bất cứ dữ liệu nhạy cảm nào, kể cả đã băm.

Ba điều kiện tối thiểu trước khi bật

Một: chính sách của bạn phải nói việc này. Nếu chính sách riêng tư trên website không đề cập việc chia sẻ dữ liệu với đối tác quảng cáo, sửa nó trước khi gửi dòng dữ liệu đầu tiên.

Hai: băm đúng cách. Băm không phải mã hoá, nó không đảo ngược được. Nhưng băm sai định dạng hoặc không chuẩn hoá trước khi băm thì vừa làm tỉ lệ khớp thấp vừa không đạt mục đích bảo vệ.

Ba: chỉ gửi cái cần. Càng ít trường rời khỏi hệ thống của bạn càng tốt. Mỗi trường thêm vào là một rủi ro thêm mà không chắc đổi lại được gì.

Ba con số nên theo dõi hằng tháng

Sau khi dựng xong, ba con số này cho biết luồng còn khoẻ hay đã âm thầm hỏng.

Số sự kiện gửi thành công so với số đơn trong sổ. Tỉ lệ này nên ổn định qua các tháng. Tụt đột ngột nghĩa là luồng gửi đứt ở đâu đó, thường là sau một lần cập nhật phần mềm bán hàng.

Tỉ lệ khớp. Nền tảng báo sẵn con số này. Giảm dần thường do dữ liệu nhận diện ngày càng thiếu, chẳng hạn biểu mẫu mới bỏ bớt ô email để tăng tỉ lệ điền.

Tỉ lệ trùng lặp. Nếu nền tảng báo có sự kiện bị coi là trùng ở mức bất thường, mã sự kiện đang có vấn đề, thường là do một bên đổi cách sinh mã mà bên kia không biết.

Ba con số này nên nằm trong bản tổng hợp hằng tháng, đọc cùng lúc với báo cáo hiệu quả. Chờ tới lúc nghi ngờ mới đi tra thì thường đã mất vài tuần ra quyết định trên số sai.

Ngành nào mất nhiều tín hiệu nhất

Mức thất thoát không đều giữa các ngành. Bốn nhóm dưới đây mất nhiều hơn hẳn mặt bằng chung.

Chốt đơn qua tin nhắn hoặc điện thoại

Nhóm mất nhiều nhất ở thị trường Việt. Khách thấy quảng cáo, nhắn tin hỏi, chốt trong tin nhắn, chuyển khoản. Không bước nào đi qua trang thanh toán nên đoạn mã trên trang không thấy gì cả.

Với nhóm này, gửi từ máy chủ không phải là cải thiện, nó là cách duy nhất để nền tảng biết đơn tồn tại.

Chu kỳ mua dài

Bất động sản, giáo dục, phần mềm doanh nghiệp, dịch vụ tư vấn. Khoảng cách từ lúc bấm quảng cáo tới lúc chốt tính bằng tuần hoặc bằng tháng.

Khoảng thời gian quy nguồn của nền tảng thường không đủ dài để bắt được. Gửi từ máy chủ cho phép báo về đơn chốt muộn kèm đúng thời điểm phát sinh, nên đơn còn cơ hội được tính.

Bán cho nhóm khách rành công nghệ

Tỉ lệ dùng trình duyệt chặn theo dõi ở nhóm này cao hơn mặt bằng chung, nên mất tín hiệu ở đường trình duyệt nặng hơn. Điểm đáng lo là mất không ngẫu nhiên: bạn mất đúng nhóm khách có sức mua tốt trong nhiều ngành.

Tỉ lệ trả hàng cao

Nhóm này ngược lại: không thiếu tín hiệu mà thừa. Đơn được ghi nhận rồi bị trả, nhưng nền tảng không biết, nên nó tiếp tục tìm thêm người giống những người đã trả hàng.

Cách xử khác hẳn ba nhóm trên: gửi sự kiện đảo khi có trả hàng, hoặc chỉ gửi khi đơn đã qua thời hạn đổi trả.

Ai trong đội nên phụ trách việc này

Câu hỏi nghe nhỏ nhưng nó quyết định luồng gửi có sống được quá sáu tháng hay không.

Người dựng thường là bên kỹ thuật. Người hưởng lợi là bên marketing. Người phát hiện ra khi hỏng lại hay là bên bán hàng, vì họ là người thấy đơn có thật trong khi báo cáo nói không có.

Ba bên khác nhau, và đó chính là lý do luồng gửi hay hỏng âm thầm. Bên kỹ thuật đổi phần mềm bán hàng mà không nghĩ tới quảng cáo. Bên marketing thấy số tụt và tưởng chiến dịch kém đi. Bên bán hàng thậm chí không biết có một luồng như vậy tồn tại để mà hỏng.

Cách xử rẻ nhất: thêm một dòng vào danh sách kiểm tra sau mỗi lần thay đổi phần mềm bán hàng, nội dung là kiểm tra luồng gửi sự kiện. Mất một phút và nó chặn được nguyên nhân phổ biến nhất.

Cách chắc hơn: đặt cảnh báo tự động khi số sự kiện gửi thành công tụt mạnh, để việc phát hiện không phụ thuộc vào việc có ai nhớ hay không.

Về mặt trách nhiệm, nên có đúng một người chịu trách nhiệm cuối, và người đó nên nằm ở bên marketing, vì đó là bên chịu hậu quả trực tiếp khi số sai.

Việc này không giải quyết được gì

Nói rõ để khỏi kỳ vọng sai và khỏi hứa sai với sếp.

Không làm quảng cáo tốt lên. Nó làm con số đúng lên. Nếu chiến dịch thật sự kém, số đúng sẽ cho thấy nó vẫn kém, chỉ là kém đúng mức chứ không kém quá mức.

Không khôi phục dữ liệu đã mất. Nó chỉ có tác dụng từ lúc bật trở đi. Những tháng trước vẫn thiếu, và bạn không nên so sánh trực tiếp giai đoạn trước với sau.

Không thay được việc quy nguồn cho đúng. Nó báo đơn về nền tảng nào bạn gửi tới. Đơn đó thật sự đến từ đâu, quảng cáo hay tìm kiếm hay bạn bè giới thiệu, vẫn là một câu hỏi riêng cần công cụ riêng.

Khi nào chưa cần làm

Nói cho cân, vì không phải tài khoản nào cũng cần.

Chưa chạy quảng cáo đều đặn. Nếu bạn mới thử vài tuần và ngân sách chưa ổn định, công dựng luồng lớn hơn phần thu về. Bật cảnh báo hỏng đo lường là đủ cho giai đoạn này.

Mức chênh dưới mười phần trăm. Phần cải thiện sẽ không đổi được quyết định nào, để dành công sức cho việc khác.

Toàn bộ đơn đi qua một cổng thanh toán duy nhất. Hiếm, nhưng có, thường là bán cho doanh nghiệp qua một quy trình chặt. Ở đây đoạn mã trên trang đã bắt gần hết.

Đang có vấn đề lớn hơn. Nếu tài khoản đang rò tiền ở chỗ khác, hoặc trang đích đang hỏng, xử việc đó trước. Đo đúng một con số trong khi có một chiến dịch đang đốt tiền thì không cứu được gì.

Giải nghĩa vài chữ hay gặp trong tài liệu nền tảng

Sự kiện

Một việc đã xảy ra mà bạn muốn nền tảng biết: khách xem sản phẩm, thêm vào giỏ, hoàn tất đơn, để lại số điện thoại. Mỗi loại là một sự kiện riêng và được đếm riêng.

Khử trùng lặp

Việc nền tảng nhận ra hai tín hiệu về cùng một chuyện là một, không phải hai. Làm được nhờ mã sự kiện chung giữa hai đường gửi.

Băm

Biến một chuỗi thành một chuỗi khác theo cách không đảo ngược được. Cùng một email luôn cho ra cùng một chuỗi băm nên nền tảng khớp được, nhưng từ chuỗi băm không suy ngược ra email.

Điều kiện để khớp: cả hai bên phải chuẩn hoá giống nhau trước khi băm, gồm bỏ khoảng trắng thừa, chuyển về chữ thường, và đưa số điện thoại về cùng một dạng.

Tỉ lệ khớp

Phần trăm sự kiện bạn gửi mà nền tảng nối được với một người dùng cụ thể. Sự kiện tới nơi mà không khớp được thì gần như không có tác dụng gì với việc tối ưu.

Khoảng thời gian quy nguồn

Khoảng thời gian mà nền tảng còn tính một đơn là do quảng cáo mang lại, tính từ lúc người dùng nhìn thấy hoặc bấm vào quảng cáo. Ngoài khoảng đó thì đơn vẫn xảy ra nhưng không được quy về chiến dịch nào.

Chuyển đổi ngoại tuyến

Đơn phát sinh không qua website: tại cửa hàng, qua điện thoại, qua nhân viên bán hàng. Gửi từ máy chủ là cách duy nhất báo về được nhóm này.

Ba việc làm được trong tuần này

Việc 1: đối chiếu một tháng. Lấy số đơn trong sổ bán hàng của tháng trước, so với số chuyển đổi nền tảng báo. Ghi lại tỉ lệ chênh. Mất mười lăm phút và cho biết vấn đề của bạn lớn tới đâu, trước khi bạn xin ai duyệt gì.

Việc 2: bật cảnh báo hỏng đo lường. Một quy tắc tự động báo khi số chuyển đổi ghi nhận về không hoặc tụt mạnh so với tuần trước. Mất năm phút. Nó không sửa được gì, nhưng nó đứng giữa một lần hỏng đo lường và cả tháng ra quyết định trên số sai.

Việc 3: hỏi bên kỹ thuật một câu. Hệ thống của mình có chỗ nào biết chắc đơn đã hoàn tất, và từ chỗ đó có gọi ra ngoài được không. Nếu câu trả lời là có, phần khó nhất đã xong rồi.

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

Doanh nghiệp nhỏ có cần không?

Cần nếu bạn đang dựa vào con số giá mỗi đơn để ra quyết định. Mức mất tín hiệu không phụ thuộc quy mô mà phụ thuộc vào tỉ lệ khách dùng trình duyệt có chặn và tỉ lệ đơn phát sinh ngoài website. Nếu phần lớn đơn của bạn chốt qua điện thoại hoặc tin nhắn thì mức chênh còn lớn hơn nhiều so với một cửa hàng trực tuyến thuần tuý.

Nền tảng có tự bù phần thiếu không?

Các nền tảng đều có cơ chế ước lượng phần chuyển đổi không đo được và con số ước lượng đó xuất hiện trong báo cáo. Nhưng ước lượng vẫn là ước lượng: nó không giúp hệ tối ưu học từ những người mua thật, vì nó không biết cụ thể ai đã mua.

Cần lập trình viên không?

Với các nền tảng bán hàng phổ biến thì thường đã có sẵn tích hợp, chỉ cần nối tài khoản và bật. Với hệ thống tự dựng thì cần, nhưng phần việc không lớn: chủ yếu là gọi một đầu API khi đơn chuyển sang trạng thái hoàn tất.

Bao lâu thì thấy thay đổi trên báo cáo?

Số đơn ghi nhận thường tăng ngay trong vài ngày đầu. Việc hệ tối ưu học lại từ dữ liệu đầy đủ hơn thì lâu hơn, thường vài tuần, vì nó cần đủ khối lượng sự kiện mới.

Có làm tăng chi phí quảng cáo không?

Không trực tiếp. Nhưng nếu trước đây bạn đang ghìm ngân sách vì tưởng giá mỗi đơn cao, thì sau khi thấy số thật bạn có thể quyết định chi nhiều hơn. Đó là quyết định của bạn, không phải hệ quả kỹ thuật.

Gửi từ máy chủ có làm số liệu tăng ảo không?

Không, nếu khử trùng lặp đúng. Có, nếu mã sự kiện hai bên khác nhau, và đó là lỗi kỹ thuật phát hiện được bằng cách xem tỉ lệ trùng lặp mà nền tảng báo. Nếu số đơn tăng đúng gấp đôi sau khi bật thì gần như chắc chắn là lỗi này.

Gửi cho nhiều nền tảng cùng lúc được không?

Được, và nên. Mỗi nền tảng có định dạng riêng nhưng nguồn dữ liệu là một. Cách dựng gọn là một chỗ phát sinh sự kiện rồi phân phối đi các nền tảng, thay vì mỗi nền tảng một luồng riêng phải bảo trì riêng.

Đã dùng công cụ quản lý thẻ rồi thì có cần nữa không?

Công cụ quản lý thẻ chạy trên trình duyệt vẫn thuộc đường thứ nhất, nên vẫn dính đủ các nguyên nhân mất tín hiệu đã nói ở trên. Nó giúp bạn quản lý các đoạn mã gọn hơn, nhưng không thay được đường gửi từ máy chủ.

Đọc thêm: nhật ký thay đổi: vì sao mọi việc tự động làm đều phải lật lại được, 19 quy tắc tự động mẫu, bắt đầu từ đâu, và đặt ngưỡng dừng chiến dịch tiêu tiền không ra đơn.

Kiểm tra đo lường trên tài khoản của mình ở orova.vn.