Настройка правил событий
Правила событий расширяют Правила конверсии, позволяя проверять события после установки с помощью настроенных вами условий.
Если событие не соответствует этим условиям, Adjust отклоняет его и сообщает об отклонении в колбэках, экспортированных в CSV-файлы данных и отчетах.
Для активации правил конверсии (и правил событий) в вашем аккаунте напишите нам по адресу sales@adjust.com.
Перед началом работы
Что нужно знать, чтобы начать работу.
Требования
- Пользователи с разрешениями на администрирование, редактирование или настраиваемое редактирование в Adjust.
- Одно- или многоплатформенное приложения в Adjust.
Настройка правил событий
Чтобы настроить правило события, выполните следующие шаги:
В AppView откройте События и подписки и выберите событие, которое нужно проверить.
Выберите Редактировать событие .
Перейдите к проверке, которую вы хотите настроить.
Выберите для проверки один из следующих статусов:
- Активная — после сохранения правила проверка становится активной в системе Adjust. События, не прошедшие проверку, отклоняются .
- Тестовая — после сохранения правила проверка становится активной в системе Adjust. События, не прошедшие проверку, не отклоняются , а помечаются флажком и отображаются в отчете.
- Пауза — правило не применяется ни к каким событиям. Этот статус позволяет сохранить изменения, не активируя их.
Настройте одну или несколько проверок (см. Проверки).
Нажмите Сохранить изменения .
Настроить проверки правил событий можно также во время первоначального процесса создания события.
Удаление проверки правила события
Чтобы удалить проверку, просто установите для нее статус Выкл .
Проверки
К одному правилу события можно привязать несколько проверок.
Если проверка со статусом Активная не пройдена, событие отклоняется .
Целевые фильтры
Целевые фильтры используются для более точного определения трафика, к которому относится каждая проверка. Фильтры настраиваются для каждой проверки отдельно и не влияют на другие проверки в том же правиле.
Каналы
Вы можете ограничить проверку только определенными каналами трафика. По умолчанию же проверка применяется ко всем каналам.
Версия установленного приложения
Вы можете ограничить проверку пользователями, установившими определенную версию приложения. Используйте эту возможность, чтобы гарантировать, что логика правила применяется только к тем пользователям, для которых она является допустимой и значимой — например, к пользователям, установившим версию, в которой все события и потоки, на которые ссылается правило, уже являются частью приложения.
Под версией установленного приложения понимается версия, действовавшая на момент установки, а не текущая версия приложения. При обновлении системы после установки для пользователя сохраняются сведения об исходной версии системы для целей оценки правил.
Проверка источника
Эта возможность используется для указания того, какой источник событий принимается, и для обработки событий, которые больше не активны в вашем приложении.
Принимаемый источник события
Ограничение допустимого источника событий.
- SDK — принимать только события, созданные SDK.
- S2S — принимать только межсерверные события.
Если событие поступает из неразрешенного источника, оно отклоняется.
Для событий, созданных SDK, проверьте интеграцию и настройки цифровой подписи SDK, чтобы обеспечить оптимальную защиту.
Для межсерверных событий проверьте настройки защиты S2S-запросов.
Устаревшее событие
Используется для отклонения события, которое было удалено из приложения и больше не срабатывает. Эта возможность позволяет аннулировать все оставшиеся триггеры для событий, которые больше не являются частью потока событий вашего приложения.
Проверка потока
Эта проверка используется для управления ожидаемой последовательностью действий, временем и требуемыми параметрами событий.
Вы можете выбрать несколько условий. В этом случае для прохождения проверки событию необходимо соответствовать всем выбранным условиям. В противном случае событие отклоняется.
Время с момента установки
Это условие требует, чтобы событие произошло в течение определенного периода с момента установки или после ее окончания.
Пример: «Больше или равно 5 минутам после установки».
Требуется предшествующее событие
Это условие требует, чтобы перед данным событием произошло другое определенное событие (например, Уровень 1 ) В качестве дополнительного ограничения можно указать минимальный или максимальный временной интервал между требуемым предшествующим и текущим событиями.
Условие Требуется предшествующее событие работает только для событий, отправленных из SDK .
Не настраивайте эту проверку для событий, отправляемых между серверами (S2S) , так как она не будет оценена правильно.
Событие не может произойти, если... — взаимное исключение определенных событий
Можно отклонить событие, если для данного пользователя уже было запущено другое указанное событие. Используйте эту возможность для взаимного исключения событий — если одно произошло, другое блокируется.
Пример: « покупка невозможна, если возврат средств уже был произведен».
События, уже связанные с существующим правилом взаимного исключения, помечаются в раскрывающемся списке как Уже связано .
При определении этого условия для указанного события автоматически создается симметричное правило с таким же статусом, и это правило отображается в пользовательском интерфейсе.
Если вы используете Целевые фильтры , убедитесь, что они согласованы по обоим событиям, чтобы избежать непоследовательного поведения при отклонении.
Последний триггер события произошел как минимум до — подавление событий по времени
Позволяет отклонить событие, если с момента его срабатывания прошло меньше времени, чем указано. Эта возможность используется для ограничения частоты принятия одного и того же события для данного пользователя.
Пример: «последний триггер покупки сработал как минимум 5 минут назад».
Обязательные параметры
Это условие требует, чтобы определенные параметры SDK (например, user_id, transaction_id) присутствовали в полезной нагрузке события. Вы можете указать несколько параметров. Если определены несколько параметров, все они должны существовать, чтобы событие прошло проверку.
Если вы хотите проверять параметры для действий при установке и после установки (а не для отдельных событий), используйте вместо этого тип Правило параметра.
Проверка дохода
Используйте эту проверку для валидации монетизированных событий на полноту, а также для верификации покупки.
Проверка считается пройденной или не пройденной на основании результата верификации покупки .
Включите также опцию отклонения событий с отсутствующими данными о транзакциях.
Конфигурация проверки доходов
Конфигурация верификации покупки осуществляется в разделе AppView → Защита → Верификация покупки .
Чтобы использовать результаты верификации покупки в потоке проверки доходов, необходимо сначала переключиться из устаревшего режима в режим событий .
- Верификация покупки не настроена для правил событий
- Пример конфигурации верификации покупки
Обмен данными
Для регистрации отклоненных событий используются:
Колбэки и данные, экспортированные в CSV-файл , если настроен триггер Отклоненное событие . Для каждой проверки отображается плейсхолдер {rejection_reason} с подробными значениями:
post_install_activity_event_rule_source_checkpost_install_activity_event_rule_flow_checkpost_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, когда правило находится в рабочем статусе.