Настройка правил событий

Правила событий расширяют Правила конверсии, позволяя проверять события после установки с помощью настроенных вами условий.
Если событие не соответствует этим условиям, Adjust отклоняет его и сообщает об отклонении в колбэках, экспортированных в CSV-файлы данных и отчетах.

Решение для роста:

Для активации правил конверсии (и правил событий) в вашем аккаунте напишите нам по адресу sales@adjust.com.

Перед началом работы

Что нужно знать, чтобы начать работу.

Требования

Пользователи с разрешениями на администрирование, редактирование или настраиваемое редактирование в Adjust.
Одно- или многоплатформенное приложения в Adjust.

Настройка правил событий

Чтобы настроить правило события, выполните следующие шаги:

В AppView откройте События и подписки и выберите событие, которое нужно проверить.
Выберите Редактировать событие .
Перейдите к проверке, которую вы хотите настроить.
Выберите для проверки один из следующих статусов:
- Активная — после сохранения правила проверка становится активной в системе Adjust. События, не прошедшие проверку, отклоняются .
- Тестовая — после сохранения правила проверка становится активной в системе Adjust. События, не прошедшие проверку, не отклоняются , а помечаются флажком и отображаются в отчете.
- Пауза — правило не применяется ни к каким событиям. Этот статус позволяет сохранить изменения, не активируя их.
Настройте одну или несколько проверок (см. Проверки).
Нажмите Сохранить изменения .

Примечание:

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

Удаление проверки правила события

Чтобы удалить проверку, просто установите для нее статус Выкл .

Проверки

К одному правилу события можно привязать несколько проверок.
Если проверка со статусом Активная не пройдена, событие отклоняется .

Целевые фильтры

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

Уровень кампании

По умолчанию проверка применяется ко всем каналам. Выберите уровень структуры вашей кампании, на котором будет проводиться проверка:

Каналы — ограничьте область проверки одним или несколькими каналами.
Кампании — ограничьте объем проверки определенным каналом, а затем одной или несколькими кампаниями в рамках этого канала.
Группы объявлений — примените проверку к каналу и кампании, а затем к одной или нескольким группам объявлений (идентификаторам источников) внутри них.

Примечание:

Множественный выбор поддерживается только в поле, соответствующем выбранному уровню кампании — например, в режиме Группы объявлений вы выбираете один канал, одну кампанию и одну или несколько групп объявлений. Поля выше этого уровня («Канал» и «Канал» + «Кампания») могут быть выбраны только в единственном числе и существуют только для того, чтобы ограничить область поиска выбранным вами уровнем.

Выбранные элементы применяются только на том уровне, где вы выбрали соответствующее значение. Если для поля выбранного уровня вы оставите значение Все или не выберете никаких значений — например, выберете Группы объявлений , но не выберете кампанию, — при сохранении настройка вернется к ближайшему уровню, где было фактически выбрано определенное значение (например, «Группы объявлений» → «Кампании» или «Группы объявлений» / «Кампании» → «Каналы», если ничего не было выбрано).

Версия установленного приложения

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

Примечание:

Под версией установленного приложения понимается версия, действовавшая на момент установки, а не текущая версия приложения. При обновлении системы после установки для пользователя сохраняются сведения об исходной версии системы для целей оценки правил.

Проверка источника

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

Принимаемый источник события

Ограничение допустимого источника событий.

SDK — принимать только события, созданные SDK.
S2S — принимать только межсерверные события.
- Если в вашем приложении включено использование межсерверного списка разрешенных IP-адресов , оно по умолчанию применяется ко всем событиям. Вы можете отключить эту функцию для определенных событий, чтобы исключить их из проверки IP-адреса, — если для событий от доверенных серверов партнёров достаточно аутентификации по токену, а для событий из внутренних или конфиденциальных потоков следует сохранить дополнительное ограничение по IP-адресу.

Если событие поступает из неразрешенного источника, оно отклоняется.

Совет:

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

Устаревшее событие

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

Проверка потока

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

Время с момента установки

Это условие требует, чтобы событие произошло в течение определенного периода с момента установки или после ее окончания.
Пример: «Больше или равно 5 минутам после установки».

Требуется предшествующее событие

Это условие требует, чтобы перед данным событием произошло другое определенное событие (например, Уровень 1 ) В качестве дополнительного ограничения можно указать минимальный или максимальный временной интервал между требуемым предшествующим и текущим событиями.

Важно:

Условие Требуется предшествующее событие работает только для событий, отправленных из SDK .
Не настраивайте эту проверку для событий, отправляемых между серверами (S2S) , так как она не будет оценена правильно.

Событие не может произойти, если... — взаимное исключение определенных событий

Можно отклонить событие, если для данного пользователя уже было запущено другое указанное событие. Используйте эту возможность для взаимного исключения событий — если одно произошло, другое блокируется.
Пример: « покупка невозможна, если возврат средств уже был произведен».

Примечание:

События, уже связанные с существующим правилом взаимного исключения, помечаются в раскрывающемся списке как Уже связано .

Важно:

При определении этого условия для указанного события автоматически создается симметричное правило с таким же статусом, и это правило отображается в пользовательском интерфейсе.
Если вы используете Целевые фильтры , убедитесь, что они согласованы по обоим событиям, чтобы избежать непоследовательного поведения при отклонении.

Последний триггер события произошел как минимум до — подавление событий по времени

Позволяет отклонить событие, если с момента его срабатывания прошло меньше времени, чем указано. Эта возможность используется для ограничения частоты принятия одного и того же события для данного пользователя.
Пример: «последний триггер покупки сработал как минимум 5 минут назад».

Обязательные параметры

Проверьте параметры SDK события на соответствие одному или нескольким условиям — например, на существование ключа или на соответствие, наличие или исключение определенных его значений.

Для каждого условия выберите тип условия :

Существует — требует наличия одного или нескольких ключей параметров в полезной нагрузке события, независимо от их значения. Вы можете указать несколько ключей параметров; они все должны присутствовать, чтобы событие могло пройти проверку.
Равно — требует, чтобы значение параметра точно совпадало с одним из предоставленных вами значений.
Не равно — требует, чтобы значение параметра не совпадало ни с одним из предоставленных вами значений.
Содержит — требует, чтобы значение параметра содержало одно из предоставленных вами значений в качестве подстроки.
Не содержит — требует, чтобы значение параметра не содержало ни одного из предоставленных вами значений.

Выберите + Добавить , чтобы добавить дополнительные условия. Каждое условие оценивается независимо, и для того, чтобы событие прошло проверку, необходимо соблюдение всех условий.

Пример. Чтобы принимать событие только в том случае, если это премиум-подписка или золотая подписка, включающая идентификатор транзакции, установите:

Ключ параметра: subscription_tier — Тип условия: равно — Значение параметра: premium, gold
Ключ параметра: transaction_id — Тип условия: существует

Примечание:

Для проверки того, что значение параметра пустое, нет специального условия: Adjust не может надежно отличить ситуацию «значение пустое» от ситуации «значение отсутствует». Используйте существует , чтобы проверить наличие параметра в полезной нагрузке, как в условии transaction_id, приведенном выше.

Примечание:

Имена ключей параметров не могут содержать двойное подчеркивание (__).

Сопоставление ключей параметров осуществляется с учетом регистра — Subscription_Tier и subscription_tier рассматриваются как разные ключи. Значения параметров сопоставляются без учета регистра — значение subscription_tier, равное Premium, по-прежнему соответствует условию premium, указанному выше.

см. также:

Добавление настраиваемых параметров колбэка

Примечание:

Если вы хотите проверять параметры для действий при установке и после установки (а не для отдельных событий), используйте вместо этого тип Правило параметра.

Проверка дохода

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

Конфигурация проверки доходов

Конфигурация верификации покупки осуществляется в разделе AppView → Защита → Верификация покупки .
Чтобы использовать результаты верификации покупки в потоке проверки доходов, необходимо сначала переключиться из устаревшего режима в режим событий .

Верификация покупки не настроена для правил событий

Пример конфигурации верификации покупки

см. также:

Настройка верификации покупки для вашего приложения

Обмен данными

Для регистрации отклоненных событий используются:

Колбэки и данные, экспортированные в CSV-файл , если настроен триггер Отклоненное событие . Для каждой проверки отображается плейсхолдер {rejection_reason} с подробными значениями:
- post_install_activity_event_rule_source_check
- post_install_activity_event_rule_flow_check
- post_install_activity_event_rule_pv_status_check
В разделе «Отчеты» отображаются метрики Отклоненные события и Процент отклоненных событий с указанием причины отклонения :
- rejected_events_post_install_activity_event_rule_source_check (Проверка источника правила события)
- rejected_events_post_install_activity_event_rule_flow_check (Проверка потока правила события)
- rejected_events_post_install_activity_event_rule_pv_status_check (Проверка статуса верификации покупки правила события)
- rejected_events_post_install_activity_rule (Фильтры активности после установки) — сохранены для обратной совместимости

Результаты тестового режима

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

Чтобы различать тестовые и рабочие результаты, добавьте плейсхолдер {conversion_rule_status} в настройки колбэков или экспорта в CSV. Плейсхолдер возвращает test, когда правило находится в тестовом статусе, и live, когда правило находится в рабочем статусе.