Câu hỏi thường gặp về Quyền tác giả

Khi sử dụng Tenjin, bạn sẽ nhận thấy có hai loại lượt cài đặt: “Lượt cài đặt được báo cáo” và “Lượt cài đặt được theo dõi”.

Số lượt cài đặt được báo cáo là số lượt cài đặt mà Mạng quảng cáo tuyên bố đã mang lại cho từng chiến dịch của bạn. Số lượt cài đặt được theo dõi là số lượt cài đặt mà một bên thứ ba khách quan ghi nhận là thuộc về chiến dịch của Mạng quảng cáo đó, đồng thời tính đến các chiến dịch khác mà bạn đang chạy trên các mạng quảng cáo khác. Khi xem xét số lượt cài đặt được theo dõi, bạn đang xem xét một chỉ số cài đặt toàn diện – chỉ số này dựa trên tất cả các chiến dịch, ngay cả những chiến dịch mà bạn đang chạy trên các mạng quảng cáo khác. Ngược lại, "Lượt cài đặt được báo cáo" được tính toán một cách độc lập bởi mạng quảng cáo mà bạn đang sử dụng – chỉ dựa trên những gì mạng quảng cáo đó ghi nhận được.

Vậy liệu “Số lượt cài đặt được báo cáo” có phải luôn bằng “Số lượt cài đặt được theo dõi” không? Không phải lúc nào cũng vậy. Mục đích của việc phân bổ (Attribution) KHÔNG PHẢI là để làm cho “Số lượt cài đặt được theo dõi” bằng “Số lượt cài đặt được báo cáo”. Thực tế, đôi khi việc phân bổ lại phải làm điều hoàn toàn ngược lại. Mục đích của việc xác định nguồn gốc là xem xét một cách toàn diện TẤT CẢ các hoạt động chiến dịch trên các mạng quảng cáo khác nhau mà bạn đang sử dụng cùng lúc, và gán người dùng cho chiến dịch phù hợp nhất. Chỉ có một bên thứ ba khách quan mới có thể thực hiện điều này.

Ví dụ: Bạn đang chạy các chiến dịch trên hai mạng quảng cáo cùng lúc, đó là Applovin và TikTok. Bạn đã thiết lập CPI là $1.00 cho từng chiến dịch trên mỗi nền tảng quảng cáo. Một người dùng duy nhất nhấp vào chiến dịch Applovin của bạn, sau đó cùng người dùng đó nhấp vào chiến dịch TikTok của bạn và cài đặt ứng dụng. Điều gì sẽ xảy ra? Cách theo dõi các hoạt động của người dùng đó như thế nào?

Vì Applovin và TikTok không kết nối với nhau, nên không có cách nào để hai nền tảng này đối chiếu thông tin về người dùng duy nhất tương tác với cả hai chiến dịch quảng cáo trên hai mạng lưới riêng biệt cùng một lúc. Do đó, số lượt cài đặt được báo cáo của Applovin sẽ là “1” và số lượt cài đặt được báo cáo của TikTok cũng sẽ là “1”. Dưới đây là những gì chúng ta có được cho đến nay:

Nhưng điều này thật vô lý! Chúng ta chỉ thu hút được một người dùng duy nhất! Một người dùng duy nhất chỉ nên được liên kết với một trong các chiến dịch!

Đó chính là vấn đề mà cơ chế gán nguồn (Attribution) giải quyết. Bằng cách sử dụng nhà cung cấp dịch vụ gán nguồn bên thứ ba như Tenjin, Tenjin sẽ gán người dùng vào chiến dịch TikTok dưới dạng “Tracked Install” (dựa trên lần nhấp chuột cuối cùng trong trường hợp này). Như vậy, người dùng duy nhất đã nhấp vào Applovin rồi sau đó nhấp vào TikTok sẽ được liên kết với chiến dịch của TikTok chứ KHÔNG phải của Applovin. Trong ví dụ này, số liệu về “Lượt cài đặt được theo dõi” và “Lượt cài đặt được báo cáo” sẽ trông như sau:

Giờ đây, người dùng duy nhất đã được phân loại vào chiến dịch phù hợp trong Mạng quảng cáo để phục vụ cho việc phân tích sâu hơn các chiến dịch của bạn. Nếu người dùng bắt đầu tạo ra giá trị trọn đời (LTV), thì bạn sẽ biết được hiệu quả của khoản chi tiêu quảng cáo. Đây là cách duy nhất để bạn có thể đo lường ROI trên cơ sở so sánh tương đương.

Giả sử người dùng mới thu hút được tạo ra giá trị trọn đời (LTV) trong 90 ngày là $2.5. Phân tích của bạn sẽ cho thấy những điều sau:

Trong trường hợp này, ROI = (LTV/Chi phí - 1).

Điều này cho bạn biết rằng chiến dịch Google của bạn hiệu quả hơn chiến dịch Facebook đối với người dùng cụ thể đó.

Thông thường, mức chênh lệch tối đa là 30% đối với các hệ thống SAN và 10% đối với các hệ thống không phải SAN là điều có thể dự kiến được do các lý do sau đây:

• Các mạng quảng cáo bỏ qua công nghệ xác định nguồn gốc từ bên thứ ba – Meta, Twitter, Google và một số mạng khác dựa vào công nghệ nội bộ của riêng mình để thông báo cho các đối tác xác định nguồn gốc biết khi nào một lượt cài đặt nên được ghi nhận cho mạng của họ. Khi người dùng của các mạng quảng cáo này trùng lặp, công nghệ của bên thứ ba không thể kiểm soát việc liệu mạng quảng cáo có yêu cầu ghi nhận lượt cài đặt được báo cáo hay không, ngay cả khi công nghệ gán nguồn chỉ chọn một mạng quảng cáo duy nhất để liên kết với lượt tải xuống đó.
• Callback cài đặt và URL nhấp chuột chưa được thiết lập đúng cách – Vấn đề dễ khắc phục nhất là khi nhà quảng cáo thiết lập URL nhấp chuột và callback cài đặt không đúng cách. Thông thường, vấn đề này có thể được khắc phục ngay lập tức bằng cách kiểm tra lại xem đã sử dụng đúng URL nhấp chuột hay chưa và callback cài đặt trong công nghệ phân bổ (Attribution) có hoạt động bình thường hay không.
• Các SDK của mạng quảng cáo thường sử dụng các phương pháp theo dõi lượt nhấp và lượt cài đặt không chính xác – Khi một mạng quảng cáo không hỗ trợ việc thu thập ID quảng cáo (IDFA hoặc GAID), công nghệ phân bổ của bên thứ ba thường sẽ dựa vào phương pháp phân bổ xác suất.
• Sử dụng trùng lặp SDK của mạng quảng cáo và SDK theo dõi nguồn gốc – Các hệ thống theo dõi nguồn gốc sẽ gửi các sự kiện gọi lại cài đặt (Install Callbacks) đến mạng quảng cáo để thông báo cho mạng quảng cáo về một lượt cài đặt. Nếu ứng dụng có một SDK trùng lặp cũng gửi các sự kiện gọi lại cài đặt đến mạng quảng cáo, có thể dẫn đến việc tính trùng lặp số lượt cài đặt được báo cáo.
• Các mạng quảng cáo sử dụng “khoảng thời gian quy thuộc” khác với của chúng tôi (thường áp dụng cho các mạng SAN).

“Tỷ lệ giữ chân” là một khái niệm đơn giản, nhưng có một số chi tiết cần xem xét khi triển khai. Theo mặc định, tại Tenjin, chúng tôi tính toán tỷ lệ giữ chân “cổ điển”: người dùng được coi là giữ chân trong N ngày là người quay lại vào ngày thứ N kể từ khi được thu hút. Ngày người dùng quay lại có vẻ rõ ràng và đơn giản, nhưng thực tế có 2 cách để hiểu điều này: (1) sử dụng thời gian tuyệt đối hoặc (2) sử dụng thời gian tương đối. Ví dụ về thời gian tuyệt đối, một người dùng được thu hút vào ngày 1 tháng 5 và quay lại vào ngày 2 tháng 5 được gọi là người dùng 1 ngày. Tuy nhiên, nếu người dùng đó được thu hút vào lúc 23:59 ngày 1 tháng 5 và quay lại vào lúc 00:01 ngày 2 tháng 5, thì thực tế họ chỉ chờ 2 phút để quay lại.

• Tại Tenjin, theo mặc định, chúng tôi sử dụng đơn vị thời gian tương đối. Mỗi người dùng có “thời gian tồn tại” riêng, được tính bằng số ngày kể từ thời điểm thu hút. “Ngày sinh” của họ là ngày thu hút (ngày 0), và ngày 1 bắt đầu sau 24 giờ. Người dùng được giữ chân trong N ngày là người dùng quay lại trong khoảng thời gian từ 24N giờ đến 24(N+1) giờ sau khi thu hút.

Tỷ lệ giữ chân người dùng trong N ngày = số người dùng duy nhất được giữ chân trong N ngày / số người dùng duy nhất trong 0 ngày

• Chúng tôi tin rằng việc sử dụng thời gian tương đối sẽ tạo sự công bằng cho tất cả người dùng, bất kể họ đang ở múi giờ nào hay nhịp sinh học của họ ra sao. Điều này cũng giúp chúng tôi “chuẩn hóa” các chỉ số trọn đời khác, chẳng hạn như doanh thu lũy kế, ROI lũy kế và chi phí trên mỗi người dùng được giữ chân. (LƯU Ý) Tenjin hiện hỗ trợ tính toán Tỷ lệ duy trì người dùng bằng chiến lược nhóm dựa trên UTC. Với phương pháp này, Ngày 1 bắt đầu vào lúc nửa đêm UTC đầu tiên sau thời điểm cài đặt của mỗi người dùng. Phương pháp này giúp đồng bộ hóa việc tính toán Tỷ lệ duy trì người dùng với các nền tảng khác sử dụng dấu thời gian dựa trên UTC, từ đó giảm thiểu sự chênh lệch trong các chỉ số.

Để kích hoạt tính năng này cho tài khoản của bạn, hãy truy cập vào “Tài khoản của tôi” → “Quản lý người dùng” → “Chiến lược nhóm đối tượng” và chọn tùy chọn mong muốn.

Như chúng ta đã thấy ở trên, theo phương án giữ chân tương đối, người dùng được coi là vẫn giữ chân trong N ngày là người quay lại trong khoảng thời gian từ 24N giờ đến 24(N+1) giờ sau khi được thu hút

Có lẽ cách tốt nhất để hiểu điều này là xem xét một ví dụ.

• Những người dùng thuộc nhóm “Sept 1” đã được thu hút trong khoảng thời gian từ 00:00 ngày 01/09/2015 đến 23:59 ngày 01/09/2015.
• Người dùng “Sept 1” mới nhất (chúng ta hãy gọi anh ấy là Joe) có thể đã được thu hút vào lúc 23:59 ngày 01/09/2015.
• Ngày thứ 0 của Joe kéo dài 24 giờ, kết thúc vào lúc 23:59 ngày 02/09/2015.
• Nếu Joe quay lại vào bất kỳ thời điểm nào trong khoảng từ 23:59 ngày 02/09/2015 đến 23:59 ngày 03/09/2015, thì anh ấy sẽ được tính là người dùng duy trì trong 1 ngày.
• Do đó, Tỷ lệ duy trì trong 1 ngày của nhóm “1 tháng 9” sẽ chỉ được xác định chính thức vào lúc 00:00 ngày 04/09/2015.

Nói chung, Tỷ lệ duy trì sau x ngày của một nhóm người dùng cụ thể sẽ chỉ được xác định chính thức SAU (x+2) ngày ĐẦY ĐỦ kể từ khi thu hút người dùng. Hay nói cách khác, vào ngày thứ (x+3), tỷ lệ này sẽ giữ nguyên.

Việc phải chờ đến 3 ngày trọn vẹn để chỉ số này ổn định có thể khiến người ta cảm thấy lạ lùng. Những ngày này xuất phát từ đâu và chúng ta giải thích chúng như thế nào? Trong trường hợp xấu nhất, một người dùng có thể được thu hút vào cuối ngày (“Ngày #1”). Ngày thứ 0 của người dùng này (khoảng thời gian 24 giờ đầu tiên) không được tính vào chỉ số duy trì (“Ngày #2”). Và trong trường hợp xấu nhất, người dùng có thể quay lại vào cuối khoảng thời gian 24 giờ của ngày thứ x (“Ngày #3”).

• Tenjin thu doanh thu từ giao dịch trong ứng dụng (IAP) trực tiếp từ SDK của bạn, trong khi iTunes Connect hoặc Google Play Console hiển thị số liệu này trực tiếp thông qua các giao dịch mua trên cửa hàng. Dựa trên kinh nghiệm của chúng tôi, chênh lệch giữa hai con số này có thể lên tới 20%.
• Đây là những khả năng có thể xảy ra nếu bạn phát hiện ra sự chênh lệch lớn.
• Doanh thu của Tenjin là doanh thu ròng (sau khi trừ phần hoa hồng 30% của Apple/Google Play Store)
• (Chỉ dành cho iOS) Nếu bạn không xác thực biên lai, Tenjin sẽ tính toàn bộ doanh thu được chuyển qua SDK của chúng tôi. Tuy nhiên, một số khoản doanh thu có thể bị Apple từ chối. Để tránh điều này, vui lòng đảm bảo sử dụng tính năng xác thực biên lai của chúng tôi (Bộ công cụ phát triển phần mềm (SDK) iOS)
• Nếu bạn mới tích hợp SDK của chúng tôi và việc cập nhật ứng dụng là tự nguyện, một số người dùng có thể chưa cài đặt SDK Tenjin. Trong trường hợp đó, bạn sẽ không thấy toàn bộ doanh thu được hiển thị trên Tenjin. Tình trạng này sẽ được khắc phục theo thời gian.

Khi nói chung về “doanh thu”, có hai loại doanh thu – theo nhóm (cohort) và không theo nhóm (non-cohort). Trong Tenjin, chúng tôi phân biệt rõ ràng giữa hai loại này. Theo định nghĩa, “doanh thu” luôn là giá trị không theo nhóm, còn “LTV” luôn là giá trị theo nhóm. Hãy xem một ví dụ. Giả sử hôm nay là ngày 20/10:

Trong ví dụ này,

• Tổng doanh thu = $94,27
• Tổng LTV trong 90 ngày = $91,70

Điều này có nghĩa là ứng dụng đã tạo ra $94,27 từ tất cả người dùng (bất kể thời điểm thu hút những người dùng đó là khi nào) trong tháng 9 (không theo nhóm), và ứng dụng đã tạo ra $91,70 trong suốt thời gian sử dụng từ những người dùng được thu hút vào tháng 9 (theo nhóm). Doanh thu thường hữu ích khi bạn quản lý dòng tiền hàng ngày, còn LTV dùng để đo lường ROI của chiến dịch.

Xin lưu ý sự khác biệt này khi so sánh các số liệu từ Tenjin với các số liệu bạn thấy trên các công cụ khác. Chúng tôi cũng phân tách riêng doanh thu từ giao dịch trong ứng dụng (IAP) (hoặc LTV) và doanh thu từ quảng cáo (hoặc LTV), để bạn có thể biết rõ nguồn gốc của doanh thu.

Doanh thu là dòng tiền hàng ngày trong khoảng thời gian đã chọn.

• Trong khoảng thời gian từ ngày 1 tháng 9 đến ngày 30 tháng 9, tất cả người dùng đã tạo ra $94.27 doanh thu từ các hoạt động trên ứng dụng (doanh thu từ mua hàng trong ứng dụng hoặc quảng cáo) diễn ra trong khoảng thời gian đó

LTV trong X ngày là doanh thu do người dùng mới (đã cài đặt ứng dụng) mang lại trong khoảng thời gian đã chọn, tính theo tổng lũy kế trong X ngày kể từ khi cài đặt ứng dụng.

• Điều quan trọng là phải xác định “hôm nay” là ngày nào so với khoảng thời gian đã chọn, bởi vì bạn cần biết người dùng nằm trong khoảng thời gian đó đã “cũ” bao nhiêu ngày. Nếu hôm nay là ngày 20 tháng 10 và khoảng thời gian được chỉ định là từ ngày 1 đến 30 tháng 9, thì những người dùng “lâu năm nhất” của bạn đã sử dụng được 50 ngày (20 tháng 10 trừ đi 1 tháng 9), còn những người dùng “mới nhất” đã sử dụng được 20 ngày. Tổng LTV trong 90 ngày là $91,70, bao gồm toàn bộ doanh thu do người dùng tạo ra trong 30 nhóm (mỗi ngày của tháng 9). Do đó, với khoảng thời gian trong ví dụ này, LTV 50 ngày, LTV 51 ngày…, LTV 89 ngày và LTV 90 ngày sẽ đều có cùng một giá trị, vì những người dùng lâu đời nhất của bạn chỉ có thể tạo ra doanh thu trong 50 ngày sau khi cài đặt.

Liệu doanh thu có bao giờ bằng LTV trong x ngày không?

Có lẽ là không. Để điều đó xảy ra, TẤT CẢ người dùng trong một ngày theo múi giờ UTC (từ 00:00 đến 23:59) phải có ngày cài đặt HOÀN TOÀN giống nhau. Điều này cực kỳ khó xảy ra.

Sự chênh lệch giữa số liệu DAU của Tenjin và Firebase là điều có thể dự đoán được, do logic được sử dụng để đếm và theo dõi số lượt cài đặt cũng như DAU trên hai nền tảng này là khác nhau. Trong Tenjin, chúng tôi sử dụng sự kiện app_open đầu tiên làm sự kiện Cài đặt và tất cả các sự kiện app_open tiếp theo sẽ được ghi lại cho các phiên. Chúng tôi cũng khuyến nghị luôn sử dụng phiên bản SDK Tenjin mới nhất và khởi tạo nó trong mỗi sự kiện OnResume. Nếu bạn vẫn thấy sự chênh lệch dữ liệu lớn, vui lòng gửi email cho chúng tôi tại support@tenjin.com kèm theo chi tiết để chúng tôi điều tra thêm.

Mã UUID (Mã nhận dạng cài đặt Analytics) do Tenjin tạo ra tại thời điểm cài đặt không được lưu trữ vĩnh viễn ở cấp độ thiết bị. Do đó, khi người dùng cài đặt lại ứng dụng, Mã nhận dạng cài đặt Analytics sẽ được đặt lại, dẫn đến việc tính số lượt cài đặt mới. Điều này có thể khiến số lượt cài đặt được theo dõi tăng nhẹ, tùy thuộc vào tần suất cài đặt lại.

Nếu bạn muốn có chỉ số ‘Số lần cài đặt lại được theo dõi’ cho ứng dụng của mình, vui lòng gửi email đến support@tenjin.com. Hiện tại, các lần cài đặt lại này sẽ chỉ được ghi nhận là đến từ nguồn tự nhiên.

Đối với sự kiện cài đặt: Meta thường tự động xử lý việc loại trừ trùng lặp các lượt cài đặt. Do đó, nếu cả Meta SDK và Tenjin đều báo cáo một lượt cài đặt, thì thông thường lượt cài đặt đó chỉ được tính một lần.

Đối với các sự kiện trong ứng dụng (chẳng hạn như giao dịch mua hàng, doanh thu hoặc số lần hiển thị quảng cáo): Các sự kiện này sẽ không được loại trừ trùng lặp tự động. Chỉ gửi sự kiện từ một nguồn duy nhất: Hãy chọn Tenjin hoặc Meta SDK để gửi các sự kiện trong ứng dụng của bạn, không chọn cả hai.

Tắt tính năng ghi nhật ký sự kiện tự động trong SDK của Meta: Nếu bạn đang sử dụng SDK của Meta, hãy tắt tùy chọn `autoLogAppEventsEnabled` để ngăn SDK này gửi các sự kiện liên quan đến doanh thu/giao dịch mua theo mặc định.

Đúng vậy! Tenjin hỗ trợ tính năng Ghi nhận nguồn (Attribution) cho Meta Instant Games. Để biết các bước chi tiết về cách thiết lập tính năng này, vui lòng liên hệ với đội ngũ hỗ trợ của Tenjin tại support@tenjin.com