Сравнение по идентификаторам и событиям

Краткое содержание

Сравнение данных МТС Аналитики с Appmetrica
Статья помогает понять, как сравнивать данные МТС Аналитики с Appmetrica, акцентируя внимание на различиях в логике расчёта параметров и рекомендациях по выбору метода сравнения.

Как сравнивать данные
В статье приведена таблица с пятью способами сравнения: по Client ID, User ID, событиям, параметрам событий и идентификаторам сессий. Для каждого способа указаны особенности, возможные расхождения и рекомендации.

Способ 1. Идентификатор устройства (Client ID)
Сравнение по ma_client_id и appmetrica_device_id может привести к сильным расхождениям из-за различий в логике учёта идентификаторов. Для проверки стабильности Client ID рекомендуется использовать GAID. В статье приведён скрипт для сравнения и пример результата.

Способ 2. Уникальный идентификатор пользователя (User ID)
Этот способ позволяет точнее сравнивать данные по авторизованной зоне. Для сравнения используется скрипт, аналогичный методу 1, с заменой параметров.

Способ 3. Общее количество событий
Сравнение по количеству событий не рекомендуется для проверки идентичности данных, так как системы могут учитывать разные типы событий. В статье приведён скрипт для сравнения.

Способ 4. Уникальные сочетания параметров событий
Сравнение по уникальным сочетаниям EventName + EventLabel + EventCategory позволяет учитывать события, отсылаемые в обе системы. В статье описан скрипт для сравнения и пример результата.

Способ 5. Идентификатор сессии (ma_session_id)
Сравнение по сессиям не рекомендуется из-за различий в логике формирования сессий в Appmetrica и МТС Аналитике.

Причины различий в данных
В статье перечислены восемь причин, объясняющих расхождения в данных: различия в начальном времени отслеживания, видах событий, фильтрации, обновлении данных, методике подсчёта, сетевых проблемах, конфигурации отслеживания и порядке SDK в коде.

Используйте статью, если ваша задача — узнать больше про точность данных МТС Аналитики и сравнить данные Аналитики с другой системой. В этой статье рассматривается сравнение только с Appmetrica.

Заметка

Сравнивать данные МТС Аналитики с данными других систем, включая Appmetrica, можно по различным параметрам. Однако важно понимать значение и логику расчёта этих параметров в каждой системе аналитики.

Как сравнивать данные

Способ сравнения	Описание	Особенность
По Client ID (ma_client_id)	Пользовательский параметр. Уникальный идентификатор устройства, который присваивается МТС Аналитикой	Возможно сильное расхождение в данных при сравнении. В МТС Аналитике и Appmetrica различается логика учёта идентификаторов, поэтому не рекомендуем использовать этот способ
По User ID	Пользовательский параметр. Идентификатор пользователя, задается на стороне приложения	Самый точный способ сравнить данные по авторизованной зоне
По событиям	Общее количество событий	Количество уникальных событий в системах может не совпадать, так как одна система может учитывать одни события, например, технические, а другая — нет
По параметрам событий	Общее количество уникальных сочетаний EventName (название события) + EventLabel (ярлык события) + EventCategory (категория события)	Учитываются только сочетания название + ярлык + категория
По количеству идентификаторов сессий (ma_session_id)	Уникальный идентификатор сессии, который формируется автоматически и объединяет события в сессии	Возможно сильное расхождение в данных при сравнении. В МТС Аналитике и Appmetrica различается логика формирования сессий, поэтому не рекомендуем использовать этот способ

Способ 1. Идентификатор устройства (Client ID)

Сравнение можно производить по идентификаторам устройств: в МТС Аналитике — ma_client_id, в Appmetrica — appmetrica_device_id.

Замените значения переменных из блока:

with на актуальные для вашего продукта: start_date, end_date, os_name, app_version, build_version

from на соответствующую схему для вашего продукта, в коде эта схема называется your_product

Скрипт для сравнения:

WITH
    '2024-01-01' AS start_date
    , '2024-01-24' AS end_date
    , 'android' AS os_name
    , '1.12.0' AS app_version
    , '201' AS build_version
    , mtsa AS (
        SELECT
            count(DISTINCT ma_client_id) AS devices_mtsa
            , toDate(ma_hit_datetime) AS dates
        FROM your_product.ma_app_hits mwh
        WHERE
            toDate(ma_hit_datetime) BETWEEN start_date AND end_date
            AND ma_os_name ilike os_name
            AND ma_app_version_name = app_version
            AND ma_app_build_number = build_version
        GROUP BY dates)
    , ym AS (
        SELECT
            count(DISTINCT appmetrica_device_id) AS devices_ym
            , toDate(event_datetime) AS dates
        FROM your_product.app_events_all whav
        WHERE
            toDate(event_datetime) BETWEEN start_date AND end_date
            AND os_name ilike os_name
            AND app_version_name = CONCAT(app_version, '+', build_version)
        GROUP BY dates)
SELECT
    devices_mtsa
    , devices_ym
    , round(devices_mtsa/devices_ym*100, 2) prc
    , dates
FROM mtsa
FULL JOIN ym
USING(dates)
order by dates;

Подробнее про указанные в скрипте параметры

Расхождение при таком сравнении может быть связано с нестабильностью идентификатора устройства в Appmetrica.

Проверка стабильности Client ID

Стабильность Client ID можно проверить с помощью GAID. Для проверки используется рекламный идентификатор (GAID), который отсылается и в Appmetrica, и в МТС Аналитику. Затем подсчитывается количество Client ID и appmetrica_device_id для каждого GAID.

Замените значения переменных из блока from на соответствующую схему для вашего продукта, в коде эта схема называется your_product. Скрипт для сравнения:

WITH mtsa AS (
    SELECT
        ma_gaid gaid
        , count(DISTINCT ma_client_id ) mtsa_count
    FROM your_product.ma_app_hits mah
    WHERE ma_gaid <> ''
    GROUP BY ma_gaid
    HAVING mtsa_count > 1
), ym AS (
    SELECT
        google_aid gaid
        , count(DISTINCT appmetrica_device_id ) ym_counta
    FROM your_product.app_events_all aea
    WHERE google_aid <> ''
    GROUP BY google_aid
    HAVING ym_counta > 1
)
SELECT *
FROM mtsa
INNER JOIN ym USING(gaid)
ORDER BY 3 desc

Например, можно получить такой результат.

gaid	mtsa_count	ym_count
hg1234567890	39	97
yh987654321	74	86
jo5432167890	45	47

При проверке стабильности параметра Client ID с помощью GAID важно учитывать

1. На каждый GAID в МТС Аналитике приходится меньшее количество идентификаторов, чем в Appmetrica, поэтому сравнение по Client ID может давать непредсказуемый результат.
2. Для большинства девайсов Huawei отсутствует Client_Id, поскольку при генерации МТС Аналитика использует специальный параметр в устройстве (app_set_id), которого нет в этих устройствах.

Способ 2. Уникальный идентификатор пользователя (UserId)

Для более точного сравнения систем рекомендуем использовать идентификатор клиента. Это позволит сравнить данные по авторизованной зоне, данные в неавторизованной зоне не учитываются.

Чтобы сравнить данные по UserId, используйте скрипт для сравнения по Client ID, заменив необходимые параметры.

Способ 3. Общее количество событий

Вы сможете узнать разницу в количестве событий по каждому дню. Не рекомендуем использовать этот способ для проверки идентичности самих данных.

Замените значения переменных из блока:

with на актуальные для вашего продукта: start_date, end_date, os_name, app_version, build_version

from на соответствующую схему для вашего продукта, в коде эта схема называется your_product

Скрипт для сравнения:

WITH

    '2024-01-01' AS start_date
    , '2024-01-24' AS end_date
    , 'android' AS os_name
    , '1.12.0' AS app_version
    , '201' AS build_version
    , mtsa AS (
        SELECT
            count() AS hit_mtsa
            , toDate(ma_hit_datetime) AS dates
        FROM your_product.ma_app_hits mwh
        WHERE
            toDate(ma_hit_datetime) BETWEEN start_date AND end_date
            AND ma_os_name ilike os_name
            AND ma_app_version_name = app_version
            AND ma_app_build_number = build_version
        GROUP BY dates)
    , ym AS (
        SELECT
            count() AS hits_ym
            , toDate(event_datetime) AS dates
        FROM your_product.app_events_all whav
        WHERE
            toDate(event_datetime) BETWEEN start_date AND end_date
            AND os_name ilike os_name
            AND app_version_name = CONCAT(app_version, '+', build_version)
        GROUP BY dates)
SELECT
    hit_mtsa
    , hits_ym
    , round(hit_mtsa/hits_ym*100, 2) prc
    , dates
FROM mtsa
FULL JOIN ym
USING(dates);

Важно

В Appmetrica или МТС Аналитике могут быть события, которые не учитываются в другой системе аналитике, например, технические. Для более точного сравнения по событиям рекомендуем использовать Способ 4.

Способ 4. Уникальные сочетания параметров событий

Сравнение можно производить по уникальным событиям, отсылаемым в обе системы. Однако, в Appmetrica отсутствует уникальный идентификатор события, поэтому можно сравнить количество уникальных сочетаний «EventName (название события)» + «EventLabel (ярлык события)» + «EventCategory (категория события)» по датам.

Подробнее про параметры событий

Замените значения переменных из блока:

with на актуальные для вашего продукта: start_date, end_date, os_name, app_version, build_version

from на соответствующую схему для вашего продукта, в коде эта схема называется your_product

Скрипт для сравнения:

WITH
    '2024-01-01' AS start_date
    , '2024-01-24' AS end_date
    , 'android' AS os_name
    , '1.12.0' AS app_version
    , '201' AS build_version
    , mtsa AS (
        SELECT
            count(DISTINCT concat(ma_hit_name, EventCategory, EventLabel)) AS events_mtsa
            , toDate(ma_hit_datetime) AS dates
        FROM your_product.ma_app_hits mwh
        WHERE
            toDate(ma_hit_datetime) BETWEEN start_date AND end_date
            AND ma_os_name ilike os_name
            AND ma_app_version_name = app_version
            AND ma_app_build_number = build_version
        GROUP BY dates)
    , ym AS (
        SELECT
            count(DISTINCT concat(event_name, eventCategory, eventLabel)) AS event_ym
            , toDate(event_datetime) AS dates
        FROM your_product.app_events_all whav
        WHERE
            toDate(event_datetime) BETWEEN start_date AND end_date
            AND os_name ilike os_name
            AND app_version_name = CONCAT(app_version, '+', build_version)
        GROUP BY dates)
SELECT
    events_mtsa
    , event_ym
    , round(events_mtsa/event_ym*100, 2) prc
    , dates
FROM mtsa
FULL JOIN ym
USING(dates);

Пример результата:

events_mtsa	events_ym	dates
123	123	01.01.2024
156	149	02.01.2024
175	175	03.01.2024
789	787	04.01.2024

Также можно сравнить количество событий в разбивке каждого сочетания.

Замените значения переменных из блока:

with на актуальные для вашего продукта: start_date, end_date, os_name, app_version, build_version

from на соответствующую схему для вашего продукта, в коде эта схема называется your_product

Скрипт для сравнения:

WITH
    '2024-01-01' AS start_date
    , '2024-01-24' AS end_date
    , 'android' AS os_name
    , '1.12.0' AS app_version
    , '201' AS build_version
    ,ya AS (
        SELECT
            event_name AS ya_hit
            , eventCategory AS ya_cat
            , eventLabel AS ya_label
            , count(DISTINCT hitID) AS ya_cnt
        FROM your_product.app_events_all
        WHERE
            toDate(event_datetime) BETWEEN start_date AND end_date
            AND os_name ilike os_name
            AND app_version_name = CONCAT(app_version, '+', build_version)
        GROUP BY
            event_name
            , eventCategory
            , eventLabel)
    , mtsa AS (
        SELECT
            ma_hit_name AS mtsa_hit
            , EventCategory AS mtsa_cat
            , EventLabel AS mtsa_label
            , count(DISTINCT ma_hit_id) AS mtsa_cnt
        FROM your_product.ma_app_hits mwh
        WHERE
            toDate(ma_hit_datetime) BETWEEN start_date AND end_date
            AND ma_os_name ilike os_name
            AND ma_app_version_name = app_version
            AND ma_app_build_number = build_version
        GROUP BY ma_hit_name, EventCategory, EventLabel)
SELECT
    ya_hit
    , ya_cat
    , ya_label
    , mtsa_hit
    , mtsa_cat
    , mtsa_label
    , ya.ya_cnt
    , mtsa.mtsa_cnt
    , round(mtsa.mtsa_cnt/ya.ya_cnt*100, 2) prc
FROM ya
FULL JOIN mtsa
ON
    ya_cat = mtsa_cat
    AND ya_hit = mtsa_hit
    AND ya_label = mtsa_label
ORDER BY ya.ya_cnt + mtsa.mtsa_cnt DESC;

Например, при таком сравнении можно увидеть, что в одной системе есть событие scrn, а в другой — нет.

Способ 5. Идентификатор сессии (ma_session_id)

Не рекомендуем использовать сравнение по количеству идентификаторам сессий из-за различающийся логики расчёта и формирования сессий в Appmetrica и МТС Аналитике. В Аналитике сессию может начать технические события типа page-ping, а в Appmetrica точной информации об этом нет.

ya_hit	ya_cat	ya_label	mtasa_hit	mtsa_cat	mtsa_hit	ya_cnt	mtsa_cnt
Hit1	Cat1	Label1	Hit1	Cat1	Hit1	2 600	2 478
Hit2	Cat2	Label2	Hit2	Cat2	Hit2	5 290	5 270
Hit3	Cat3	Label3	Hit3	Cat3	Hit3	1 409	1 399
Hit4	Cat4	Label4	Hit4	Cat4	Hit4	7 550	7 498
scrn	8 000
Hit6	Cat5	Label5	Hit6	Cat5	Hit6	1 578	1 590

Причины различий в данных

1. Начальное время отслеживания: если вы запустили отслеживание событий в разных системах в разное время, количество отслеживаемых событий будет различаться.
2. Отслеживание разных видов событий: разные системы аналитики могут отслеживать разное количество и виды событий. Например, одна система может отслеживать клики на кнопки, а другая — прокрутку страницы.
3. Фильтрация данных: в разных системах могут применяться разные правила и параметры для фильтрации неактивных или «сомнительных» активностей пользователей (боты или повторные действия).
4. Временные различия обновления данных: некоторые системы могут обновлять данные в реальном времени, в то время как другие — с задержкой.
5. Методика подсчета уникальных событий: разные системы могут использовать разные методики для определения уникальности события.
6. Отклонения из-за проблем с сетью: передача данных о событиях может быть нестабильна из-за проблем с сетью, сервером или браузером. Это может привести к потере данных.
7. Проблемы с конфигурацией отслеживания: есть вероятность, что отслеживание событий не было правильно настроено в одной из систем.
8. Порядок SDK в коде: При установке одного SDK выше другого (в коде ресурса), он будет быстрее отрабатывать данные. Это может уменьшить количество поступающих событий.