Вкратце: Записывайте внутренние события после установки (например, вход в систему, регистрация или покупка внутри приложения), приписываемые медиаисточникам и кампаниям.
Зачем необходимо записывать внутренние события?
Внутренние события предоставляют представление о том, что происходит в вашем приложении, и являются идеальным инструментом для определения ценности, значения пользователей приложения и качества трафика из различных медиаисточников. Запись внутренних событий помогает измерять такие ключевые показатели эффективности, как ROI (окупаемость инвестиций) и LTV (пожизненная ценность пользователя).
Когда пользователи регистрируются, проходят обучение, добавляют товары в корзину или совершают покупки, данные о внутренних событиях могут фиксировать такие события с деталями. Реализация внутренних событий обязательна для всех целей анализа после установки.
О внутренних событиях
Внутреннее событие приложения включает в себя название события и может содержать параметры события. Когда вы добавляете параметры события к внутреннему событию приложения, они называются внутренними событиями приложения. Параметры события предоставляют больше контекста и информации о происходящем событии. Например, полезно знать, что пользователь сделал бронирование, но параметры события позволяют уточнить тип покупки, пункт назначения и выручку.
Совет
Хотите узнать больше о внутренних событиях? Ознакомьтесь с этим коротким информативным курсом на учебном портале AppsFlyer.
Стандартные и настраиваемые события
Внутренние события, которые вы хотите отправлять, требуют внедрения кода вашим разработчиком, где это применимо, в вашем приложении. Названия событий и параметры событий классифицируются следующим образом:
-
Предопределенные: Это названия событий и параметры событий, которые обычно используются в различных приложениях. Мы настоятельно рекомендуем использовать предопределенные имена событий и параметры событий как можно чаще по следующим причинам:
- Предзаданные имена обеспечивают беспрепятственное сопоставление событий с партнёрами.
- Если AppsFlyer решит изменить название события или параметра, ваша реализация останется обратно совместимой.
- Пользовательский: Это названия событий и параметры, которые вы определяете для конкретных сценариев использования вашим пользователем в приложении. Вы можете использовать любую строку с названием пользовательского события или параметра, но имейте в виду, что для пользовательских событий требуется поддержка со стороны вашего разработчика. Смотрите Советы и Ограничения.
Доход от внутренних событий приложения
В разделах ниже описывается, как отправлять события доходов в AppsFlyer и сопоставлять параметры, которые эти события содержат. Тем не менее, важно отметить, что подписка ROI360 позволяет получать самые точные и актуальные данные о затратах и доходах (включая данные о доходах от покупок в приложении, подписок и рекламы). Подробнее о ROI360
Доход от события
af_revenue - параметр по умолчанию для отчетности о доходах. Передаваемая выручка в af_revenueпополняет все метрики выручки во всех продуктах AppsFlyer (дэшборды, LTV, когорты, ROAS, ROI) и включается в постбэки партнеров. Всегда используйте его с событиями в приложении, которые представляют фактическое получение выручки в вашей бизнес-логике.
Если вы также хотите передавать выручку с учётом собственной логики — например, за вычетом комиссии магазина и налогов — можно дополнительно отправлятьaf_net_revenue . Это дополнение кaf_revenue, не замена. См. «Чистый доход» ниже.
Вы также можете записывать отрицательную выручку, если пользователь отменяет покупку или если вы оформляете возврат. Для регистрации отрицательного дохода всё, что вам нужно сделать – это добавить знак минус (-) к значению дохода, которое вы передаете в af_revenue.
Если нужно регистрировать такие события, как отмена транзакции или возврат денег, то с помощью параметраaf_revenue можно также передавать значения отрицательного дохода.
Значение дохода должно содержать только числа (и десятичную точку, если требуется):
- Не включайте никаких других символов и не форматируйте значение дохода каким-либо другим способом. Это означает отсутствие запятых, знаков валют (например, $), специальных символов и текста.
- AppsFlyer предоставляет значение доход с точностью до 5 знаков после запятой .
- Диапазон этого значения должен составлять от -1 000 000 до +1 000 000 в долларах США или эквивалентную сумму в оригинальной валюте. Суммы за пределами диапазона отображаются в отчетах по сырым данным, а не в агрегированных отчетах.
- Пример: 1234.56
- Если доход передается в виде строки, то значение, заключенное в кавычки, должно быть действительным. Например: «1234,56».
Примечание:
- AppsFlyer отображает точную выручку, отправленную из SDK в
af_revenueЭти данные не включают никаких расчетов НДС, комиссий магазина приложений и т. п., кроме случаев, когда это предусмотрено разработчиком на стороне SDK перед отправкой в AppsFlyer. Если вы хотите отправить отчет о доходах после таких вычетов, отправьте их дополнительно.af_net_revenue(см. Чистая выручка).
Параметр af_currency содержит обозначение валюты, указанной в параметре af_revenue (или af_price). Если в параметрах события нет af_currency, AppsFlyer отправляет его со значением по умолчанию – «USD».
Можно использовать af_price как денежный параметр, который не считается доходом (как, например, в событии «Добавить в корзину»). Этот параметр относится к цене отдельного элемента. Общая сумма всех покупок отображается параметром af_revenue.
Чистый доход
Параметр af_net_revenue предоставляет необязательный дополнительный способ отчета о доходах, если вы хотите применить собственную логику к сумме дохода, например, доход после вычета комиссий магазина приложений, налоговых вычетов, валовой прибыли или сервисных сборов.
af_net_revenue не заменяет af_revenue. Продолжайте отправлятьaf_revenue как обычно и добавьте к немaf_net_revenue, когда вам потребуется отчетность по сети.
- Валюта следует
af_currency(по умолчанию доллары США), аналогичноaf_revenue. - Поскольку нет предопределенной константы SDK для
af_net_revenue, необходимо передать его в качестве пользовательского параметра вместе с ключом.af_net_revenue. - Чистая выручка лежит в основе «чистых» метрик (чистая выручка, чистый ROI, чистый ROAS, чистый ARPU и чистая валовая прибыль) в «Моих дэшбордах».
Примечание
Если вы используете ROI360 дохода магазина,af_net_revenue заполняется автоматически для покупок и подписок в приложении, поэтому вам не нужно отправлять данные.af_net_revenue для этих событий. Чистая выручка равна валовому доходу за вычетом комиссий магазина приложений и налогов.
Валюта выручки
Важно понимать, как AppsFlyer обрабатывает настройки валюты и конвертацию валюты.
AppsFlyer обрабатывает разницу между валютой в настройках приложения и валютой внутренних событий с помощью конвертации валют.
На диаграмме выше показан следующий процесс:
- События в приложении отправляются — для каждого события используется разная валюта.
- AppsFlyer нормализует все валюты до доллара США.
- AppsFlyer обрабатывает данные о выручке.
- На дэшборде данные о доходах отображаются в валюте настроек приложения.
- AppsFlyer вводит данные о доходах в отчеты по сырым данным как в валюте события, так и в валюте настроек приложения.
AppsFlyer использует Open Exchange Rates для конвертации валют. Курс обмена обновляется ежечасно. Всякий раз, когда AppsFlyer выполняет конвертацию валюты, он использует обменный курс последнего обновления.
Конвертация валюты
Пример
В настройках приложения вы выбрали валюту GBP. Пользователь из Франции приобретает товар в вашем приложении. Цена указана в евро (€). Внутреннее событие, которое вы отправляете в AppsFlyer, выглядит следующим образом:
Map<String, Object> eventValue = new HashMap<String, Object>();
eventValue.put(AFInAppEventParameterName.REVENUE,200);
eventValue.put(AFInAppEventParameterName.CONTENT_TYPE,"category_a");
eventValue.put(AFInAppEventParameterName.CONTENT_ID,"1234567");
eventValue.put(AFInAppEventParameterName.CURRENCY,"EUR");
AppsFlyerLib.getInstance().trackEvent(getApplicationContext() , AFInAppEventType.PURCHASE , eventValue);
В этом случае AppsFlyer конвертирует доход из евро в доллары США и затем в фунты стерлингов. Предположим, обменный курс составляет 1 евро = 1,13 доллара. Таким образом, €200 превращаются в $226,85. Далее AppsFlyer конвертирует доллары США в фунты стерлингов. Предположим, что курс обмена составляет 1 доллар США = 0,78 фунта стерлингов. Таким образом, $226,85 превращается в £176,92.
Отображение валюты
Валюта задается в настройках приложения. Валюта, которую вы установили в настройках приложения, является валютой, которая отображается на дэшборде. Независимо от того, в какой валюте вы отправляете внутренние события приложения, доход на дэшборде всегда отображается в той валюте, которую вы установили в настройках приложения.
Пример
Допустим, вы отправляете внутренние события с валютой, отличной от той, что установлена в настройках приложения, или вообще без валюты. В этом примере валюта в настройках приложения задана как GBP.
Вы отправляете три события в приложении в AppsFlyer.
- Событие A имеет доход 234 и GBP в качестве валюты.
- Событие B имеет доход 171 и EUR в качестве валюты.
- Событие C имеет доход 171 , но валюта не указана.
Данные о выручке на дэшборде
Доход, который отображается на дэшборде, — это конвертированное значение из валюты внутреннего события в доллары США, а затем в валюту настроек приложения.
Если в событии не указана валюта, AppsFlyer по умолчанию использует USD. На дэшборде отображается событие и доход следующим образом:
| Внутренние события | Уникальные пользователи | Количество действий | Выручка |
|---|---|---|---|
| A | 1 | 1 | £234 |
| B | 1 | 1 | £149.4 — конвертировано из EUR в USD, а затем в GBP. |
| C | 1 | 1 | £132,9 – по умолчанию в долларах США, так как валюта не указана. Конвертировано напрямую из доллара США в фунт стерлингов. |
Данные о доходах в отчётах по сырым данным
Если в настройках приложения вы установили валюту GBP, но отправляете внутренние события с другой валютой, отчет по сырым данным показывает доход в валюте настроек приложения и валюте внутреннего события.
Если в настройках приложения вы установили валюту GBP, но отправляете внутренние события без валюты, отчет по сырым данным показывает доход в валюте настроек приложения и в долларах США.
Отчет по сырым данным о внутренних событиях отображает событие и доход следующим образом:
| Событие | Выручка от события | Валюта выручки от события | Выручка от события в фунтах стерлингов |
|---|---|---|---|
| A | 234 | GBP | 234 |
| B | 171 | евро. | 149.4 — конвертировано из евро в доллары США, а затем в фунты стерлингов. |
| C | 171 | USD | 132.9 по умолчанию использует USD, поскольку валюта не указана. Конвертировано напрямую из доллара США в фунт стерлингов. |
Отправка событий
Существует несколько способов отправить внутренние события в AppsFlyer:
- AppsFlyer SDK (пакет средств разработки ПО): Это наиболее распространенный способ отправки событий. Вы можете отправлять события в приложении, которые фиксируют действия пользователя в приложении, используя API событий в приложении AppsFlyer на уровне SDK (пакета средств разработки ПО).
- API сервер-сервер: Используйте API сервер-сервер для отправки событий, происходящих вне мобильного приложения, напрямую в AppsFlyer. Например, если у вас есть пользователь, который активен как в веб-, так и в мобильном интерфейсе, вы можете фиксировать события из обоих источников и приписывать их одному и тому же пользователю в AppsFlyer. Это может быть как внутреннее событие, так и другие события, такие как события на веб-сайте, события в колл-центре или покупки в вашем физическом магазине.
- Проверка получения: Это безопасный механизм, в котором платежная платформа, такая как Apple или Google, проверяет, что внутренняя покупка действительно совершена, как это сообщается. Проверка покупок является основным инструментом для предотвращения мошеннических событий по выручке. Это также помогает вам видеть реальную выручку и отфильтровывать незавершенные покупки внутри приложения.
- Гибридные приложения: Эти приложения сочетают в себе нативные представления и HTML-контент и могут также фиксировать события в приложении. Однако, поскольку SDK (пакет средств разработки ПО) может отправлять события только с нативной стороны, разработчикам приходится пересылать все данные событий в нативный код.
Настройка событий в приложении
Процесс настройки событий в приложении требует совместной работы маркетолога и разработчика следующим образом:
| Шаг | Роль | Задача | Подробности |
|---|---|---|---|
| 1 | Маркетолог | Определите, какие события в приложении вы хотите измерять. Определите и сообщите имена событий и параметры событий своему разработчику. |
Рекомендуется начать с 3-5 событий для использования в качестве KPI для измерения качества ваших пользователей (например, покупки, регистрации и публикации). Параметры события являются необязательными, и они могут использоваться с любым названием события. См. Рекомендуемые события по отраслевым вертикалям для типичных событий в приложении. |
| 2 | Разработчик | Внедрите код в приложение, где это необходимо. | Документация для разработчиков находится здесь. |
| 3 [Необязательно] | Маркетолог | Работайте с разработчиком, чтобы настроить поле идентификатора пользователя клиента (CUID). | Это поле помогает обогатить данные о внутренние события путем межссылки данные атрибуции AppsFlyer с другими вашими данными, используя CUID как ключ. |
| 4 [Необязательно] | Маркетолог | Сопоставьте события с соответствующими Партнерами на дэшборде. | Это непрерывная задача, зависящая от Партнеров, с которыми вы интегрируетесь. |
Определение внутреннего события приложения
После того как вы определите, какие in-app события вы хотите измерять, использовать наш Генератор внутренних событий приложения, чтобы задать события и параметры следующим образом:
- Выберите название события, наиболее подходящее для сценария, который вы хотите зафиксировать.
- Выберите параметры события, которые вы хотите связать с событием. Выберите параметры, которые предоставят дополнительный контекст событию и обогатят данные.
- Загрузка готового файла из генератора внутренних событий приложения, а затем поделитесь им с разработчиком.
Пример
Маркетолог Приложения для электронной коммерции хочет зафиксировать тип контента, который просматривают пользователи, чтобы лучше понять, какие категории наиболее популярны, и связать просмотры продуктов с их продажами.
Следующая таблица демонстрирует пример структуры события, которую маркетолог передает разработчику:
| Имя события | Параметры события | Ценности, значения параметров | Когда запускается событие? |
|---|---|---|---|
| af_content_view | af_price | Цена Продукта | Когда пользователь просматривает страницу с деталями определенного Продукта |
| af_content_type | Название категории Продукта, например, обувь | ||
| af_content_id | Идентификатор Продукта, например, SKU |
Рекомендуемые события по бизнес-вертикалям
Следующая таблица содержит ссылки на статьи, которые включают примеры и схемы типичных внутренних событий, которые мы рекомендуем регистрировать по вертикали.
Просмотр данных о событиях в приложении
События в приложении атрибутируются медиа-источнику, ответственному за установку, на протяжении всего жизненного цикла пользователя. Данные о событиях представлены как Пожизненная ценность (LTV) или данные об активности.
Вы можете просмотреть данные о событиях в приложении в следующих случаях:
- Обзорная страница Дэшборда: Отображает реальную эффективность привлечения пользователей (UA) и LTV. Примечание: Это включает выручку, разделенную между органическими и неорганическими пользователями, зарегистрированную через события в приложении, а также выручку от ретаргетинга, который учитывается дважды.
- Страница события: Отображает эффективность LTV in-app события через медиа-источники.
- Страница активности: Отображает внутренние активности за выбранный диапазон дат.
-
Отчет о внутренних событиях приложения с необработанными данными: Отображает данные об активности, то есть хронологический список действий, выполненных всей вашей пользовательской базой. В этот отчет включены ценности, значения параметров событий, например:
{ "af_level":"10", "af_score":"3387", "arena":"7", "char_type":"paladin" }Обратите внимание, что отчетность по сырым данным является премиум-функцией.
Примечание
Значения параметров внутренних событий приложения доступны исключительно в отчетах по сырым данным о внутренних событиях приложения. Они не отображаются на обзорном дэшборде, дэшбордах событий и активности, а также в отчетах по агрегированным данным.
Советы
При определении названий и параметров событий в приложении держите в уме следующее:
- Для обеспечения согласованности данных в отчетности по необработанным данным мы рекомендуем определять и использовать одинаковые названия и структуры внутренних событий приложения на всех платформах.
- Используйте минимальное количество событий, чтобы было проще сравнивать качество пользователей, приходящих из разных источников.
- Важно обеспечить конфиденциальность ваших пользователей. Не заполняйте ценности, значения внутренних событий приложения данными, которые могут напрямую их идентифицировать. Например, адрес электронной почты, имя, идентификационный номер, а в некоторых местах — почтовый индекс. Для получения дополнительной информации об ограниченных данных ознакомьтесь с Политикой конфиденциальности услуг.
- Обратите внимание, что AppsFlyer включает IP адрес устройств во время взаимодействий. В некоторых юрисдикциях или сценариях использования IP адрес может рассматриваться как персональная информация. Мы используем IP адрес для определения общего географического местоположения (уровень города, района) устройства, но не конкретного адреса. При необходимости вы можете маскировать IP адреса, чтобы они не отображались в Отчетах о необработанных данных.
- Единственным источником данных о выручке в AppsFlyer являются in-app события. Вы можете присвоить каждому событию определенное значение выручки и просмотреть его на Дэшборде вашего приложения. Узнать больше о параметрах монетизации. altrevenue_data.pngalt
Ограничения
При определении названий и параметров событий в приложении держите в уме следующее:
- Для названий внутренних событий приложения мы рекомендуем использовать только строчные буквенно-цифровые символы (a-z и 0-9). Названия событий чувствительны к регистру, то есть af_purchase и af_PURCHASE – это два разных события в сырых данных. Однако в сводных отчетах и дэшбордах (например, обзорном или для событий) разрешены только строчные буквы, и поэтому они могут отображаться как одно событие.
- Ограничение на количество уникальных событий составляет 300 в день. Узнать больше
- Уникальные пользователи учитываются только для первых 100 событий после установки приложения.
- Имена событий не могут начинаться с этих символов: " = + -
- Значения событий не должны содержать символ +, за исключением случаев в закодированных URL-адресах или кодированных в соответствии с ASCII.
- Имена событий не могут содержать пустых пробелов. Вы можете использовать подчеркивания (нижние тире) до или после названия события.
- Значения событий не должны превышать 2000 символов, чтобы избежать их сокращения в отчетах о необработанных данных. Однако, если событие поступает из SDK (пакет средств разработки ПО), рекомендуется ограничить его длину до 1000 символов, чтобы гарантировать, что нагрузка не будет урезана при отправке в HTTP-запросе.
- Если вы указываете ссылающийся URL-адрес в качестве значения события, он должен быть закодирован в URL.
- Медиа-реклама имеет некоторые ограничения для названий событий и параметров. Подробнее об ограничениях здесь.
Часто задаваемые вопросы
Следующий раздел содержит различные часто задаваемые вопросы о внутренних событиях приложений.
Как использовать параметр выручки?
Вы можете отправлять значения выручки с любым именем параметра и события. Однако, чтобы зарегистрировать выручку (включая отрицательную выручку) в необработанных и агрегированных данных AppsFlyer, необходимо использовать параметр af_revenue . Всегда используйте его с событиями в приложении, которые представляют фактическое получение выручки в вашей бизнес-логике.
af_currency обозначает валюту, указанную в af_revenue (или af_price). Если из параметров события отсутствует af_currency, AppsFlyer отправляет его со значением по умолчанию «USD». Дополнительную информацию о параметре af_revenue смотрите в Руководстве по Атрибуции выручки.
Если вы также хотите отправлять отчет по доходу с применением собственной логики, например, после вычета комиссий и налогов, отправьте af_net_revenueпоскольку пользовательский параметр наряду сaf_revenue .af_net_revenue не заменяетaf_revenue . Для получения более подробной информации см. раздел «Чистая выручка» .
Как AppsFlyer атрибутирует события?
Внутренние события приложений приписываются исходному медиа-источнику установки приложения.
При установке приложения (первом запуске) AppsFlyer использует различные методы атрибуции для определения атрибуции установки. Одновременно SDK AppsFlyer создает новый уникальный идентификатор AppsFlyer, который связывается с деталями атрибуции.
Каждое последующее внутреннее событие, выполняемое тем же устройством в приложении, имеет этот идентификатор. Это позволяет AppsFlyer атрибутировать событие исходному медиа-источнику. Рекламодатели могут использовать это для отслеживания полного пути пользователя в их приложении.
События недавно ретаргетированных пользователей могут иметь двойную атрибуцию.
AppsFlyer атрибутирует события установок как органические, если:
- Условия медиа-источника требуют удаления данных на уровне пользователей
- Пользователь удаляет данные приложения, сохраненные на устройстве, что приводит к созданию нового идентификатора AppsFlyer.
Регистрируются ли события, если устройство в автономном режиме?
Если пользователь инициирует событие при отсутствии интернет-соединения, AppsFlyer все равно сможет его зафиксировать. Вот как это работает:
- SDK отправляет события на серверы AppsFlyer и ожидает успешного ответа.
- Если SDK не получает успешный ответ, событие сохраняется в кэше.
- Как только следующий успешный ответ получен, сохраненное событие повторно отправляется на сервер.
- Если в кэше несколько событий, они отправляются на сервер поочередно.
Примечание
Кэш SDK может хранить до 40 событий, что означает, что сохраняются только первые 40 событий, произошедших в офлайн-режиме. Всё, что происходит после, до следующего успешного ответа, удаляется.
Время события, отображаемое в необработанных данных – это время отправки события в AppsFlyer после восстановления интернет-соединения. Это не фактическое время выполнения события.
Что такое комплексные внутренние события и как их настроить?
Сложные события в приложении позволяют отправлять несколько товаров за один вызов API. Они полезны, когда вы хотите сгруппировать несколько тесно связанных действий пользователя, например, добавление нескольких товаров в корзину за одну сессию.
Чтобы структурировать сложное событие в приложении, используйте af_content в качестве массива JSON. Каждый объект в массиве должен включать id и quantity. af_content_list является необязательным и может быть опущен.
Пример
{
"af_revenue": 4.99,
"af_currency": "USD",
"af_order_id": "12345",
"af_content": "[{"id":"ID1","quantity":"1"},{"id":"ID2","quantity":"1"},{"id":"ID3","quantity":"2"}]"
}
Важно!
Если строка af_content превышает 1000 символов, AppsFlyer может отправить событие в Meta без параметра fb_content. Если af_content_list в этом случае также отсутствует, Meta не получает никаких данных об идентификации продукта. Держите af_content в пределах 1000 символов для событий, которые включают множество элементов.
Полную информацию об отправке сложных событий в приложении в Meta см. в Отправка сложных событий в приложении в Meta ads.
Примечание: Аудитории AppsFlyer не поддерживают массивы в атрибутах событий, поддерживаются только числа или строки.
Можно ли добавить несколько товаров в одну транзакцию?
Вы можете добавить несколько товаров в одну транзакцию. Вместо отдельных значений для параметра события можно использовать массив элементов, описывающих транзакцию, разделённых запятыми. Формат должен быть строкой JSON.
Пример
В одной сделке г-н Смит покупает две одинаковые рубашки, одну пару обуви и шляпу в интернет-магазине, расположенном в США. Последовательность, в которой приводятся товары, должна быть одинаковой для каждого параметра.
"{"af_content_id": ["123","988","399"], "af_quantity": ["2","1","1"], "af_price": ["25","50","10"], "af_revenue": "110", "af_currency": "USD"}"
Несколько элементов отправляются дальше в виде массива в постбэках. На данный момент Meta реклама и X Ads не могут правильно разобрать параметры массива. Чтобы помочь в данной ситуации, AppsFlyer суммирует количество элементов (af_quantity) вместо отправки их в эти SRNs в виде массива. В нашем примере Meta реклама получит af_quantity=4.
Примечания
- Аудитории AppsFlyer не поддерживают массивы в атрибутах событий, поддерживаются только числа или строки.
- Несколько элементов можно использовать со следующими событиями в приложении:
af_add_to_cart, af_add_to_wishlist, af_tutorial_completion, af_initiated_checkout, af_purchase, af_rate, af_spent_credits, af_content_view, af_travel_booking, af_update
Как AppsFlyer обрабатывает дедупликацию событий?
У нас есть механизм дедупликации событий в приложениях. Механизм проверяет все события в приложении, чтобы выяснить, было ли идентичное событие, поступившее с тем же идентификатором AppsFlyer менее чем за 10 секунд до этого. Если такое событие обнаруживается, механизм удаляет дубликат.
Два события считаются идентичными, если в обоих совпадают следующие поля:
- Имя события
- Значение события
- Идентификатор приложения
- AppsFlyer ID
Примечание
Дедупликация применяется в отношении только тех внутренних событий приложения, которые отправлены из SDK.
S2S события в приложении не подлежат дедупликации.
Как долго AppsFlyer хранит данные на уровне пользователя и когда они должны удаляться?
Срок хранения сырых данных на уровне пользователя в AppsFlyer зависит от типа интеграции и требований партнёра. Агрегированные данные могут храниться до пяти лет
Сроки хранения могут различаться в зависимости от медиаисточника и методов доставки (например, Data Locker или Pull API), а также могут меняться в связи с юридическими, контрактными или партнёрскими обязательствами.
После удаления события, связанные с удаленными пользователями, отображаются как органические. Прошлые агрегированные данные остаются неизменными. Для получения дополнительной информации смотрите Удержание и обязательства по удалению данных.
Нужно ли добавлять параметр ОС (операционной системы) в мои события?
- Android SDK и iOS SDK автоматически добавляют параметр ОС (операционной системы).
- Для S2S API, начиная с 1 июля 2021 года, необходимо отправлять параметр ОС для iOS приложений. Если этот параметр не отправлен, данные считаются полученными от пользователя iOS 14.5, что влияет на доступность необработанных данных.
Смотрите также
This article was translated automatically and may contain errors. The English version is the most accurate - use the language selector to switch.