Последовательность событий в правилах валидации позволяет рекламодателям задавать цепочку событий, которую должен пройти реальный пользователь. Любое отклонение от заданного вами порядка или от интервалов между событиями обнаруживается и блокируется.
Введение
Рекламодатели могут определить последовательность событий, которую реальный пользователь должен пройти в вашем приложении. AppsFlyer оценивает эту последовательность с помощью окна оценки, которое начинается в день сохранения правила: оно ежедневно увеличивается до 30 дней, а затем становится скользящим 30-дневным окном, которое каждый день сдвигается вперед. События, произошедшие до создания правила, никогда не оцениваются.
Если последовательность нарушается — по порядку или по времени, — пользователь считается поддельным, и:
- Любые события в приложении, а также сессии после прерывания блокируются немедленно.
- Установка блокируется в рамках пост-атрибуции, если она попадает в окно пост-атрибуции (7 дней)
- Связанные события в приложении в пределах окна оценки блокируются в рамках процесса пост-атрибуции
- Другие события в приложении, которые соответствуют условиям правила в других частях приложения, не затрагиваются
Примечание: любое редактирование правила, включая выбор приложения, условий, источника трафика, последовательности событий, а также включение или отключение, сбрасывает окно оценки обратно на день 0.
Для кого это?
Эта функция подходит только для:
- События SDK — приложения, в которых будут создаваться правила только со событиями SDK.
- Неповторяющиеся события — приложения, в которых есть последовательность событий, где события не происходят более одного раза в этой последовательности. Если одно и то же событие происходит в последовательности более одного раза (например, событие C отправляется дважды), это считается нарушением, и связанные события блокируются.
- NOI-трафик — эта функция доступна только для NOI-трафика
Как настроить правило «Серия событий»
Чтобы настроить правило «Серия событий», выполните следующие действия:
- Перейдите в Settings > Validation Rules
- Нажмите + New rule
- Дайте правилу название
- Откройте вкладку Post attribution
- Выберите приложение, для которого нужно настроить правило
Примечание: для каждого правила можно выбрать только одно приложение - Определите источник трафика, для которого будет применяться правило
- Выберите условия. Сейчас доступны следующие варианты:
- Гео/страна
- Доступно только в расширенных отчётах.
- Уникальный идентификатор задается автоматически в зависимости от выбранного приложения: IDFA для iOS или Advertiser ID для Android. Вместо этого вы можете использовать Customer User ID для любой платформы.
- Определите последовательность событий: добавьте не менее 2 событий в том порядке, в котором их должен выполнить реальный пользователь
- При необходимости задайте минимальный интервал времени между каждой парой событий. Если его не задать, по умолчанию применяется минимальное значение — 1 секунда
- Проверьте раздел Rule outcome, чтобы подтвердить состояние окна оценки и минимальное общее время последовательности
- Нажмите Сохранить.
Двоеточие (:)
Не выбирайте все события приложения. Выбирайте только те события, при которых обычно возможны мошеннические действия.
Доступ к данным
Когда правило Series of Events блокирует установку или событие в приложении, сведения об этом записываются в отчеты о сырых данных. Перейдите в Raw Data > Protect360 & Validation Rules, чтобы найти заблокированные события, и используйте поля ниже, чтобы определить, какие из них были заблокированы этим правилом.
| Отчёт | Ключевые поля |
|---|---|
| Пост-атрибуционные установки |
|
| Пост-атрибуционные события в приложении |
|
| Заблокированные события в приложении |
|
Примеры
Ниже приведены примеры различных последовательностей событий и того, будут ли они считаться фродом или нет.
Пример 1
Определенное правило
Пользователь должен выполнять события в таком порядке:
- Событие A
- Событие B
- Событие C
Фактически выполнено
Пользователь выполняет события в таком порядке:
- День 0: произошла установка
- День 1: отправлено событие A
- День 2: отправлено событие B
- День 3: отправлено событие C
Результат
Не фрод. Пользователь выполнил последовательность событий в заданном порядке.
Пример 2
Определенное правило
Пользователь должен выполнять события в следующем порядке:
- Событие A
- Событие B
- Событие C
Фактически выполнено
Пользователь выполняет события в следующем порядке:
- День 0: произошла установка
- День 1: отправлено событие A
- День 2: отправлено событие C
- День 3: отправлено событие B
Результат
Фрод. Пользователь выполнил событие C до события B, что не соответствует заданной последовательности. В результате:
- Событие A будет заблокировано при пост-атрибуции
- Событие B будет заблокировано в реальном времени
- Событие C будет заблокировано в реальном времени или при пост-атрибуции, так как это событие нарушило последовательность
- Все последующие события будут заблокированы в реальном времени
Пример 3
Заданное правило
Пользователь должен выполнять события в следующем порядке:
- Событие A
- Событие B (минимальное время до предыдущего события: 1 час)
- Событие C (минимальное время до предыдущего события: 2 часа)
Фактически выполнено
Пользователь выполняет события в следующем порядке:
- День 0: произошла установка
- День 0: отправлено событие A
- День 0: событие B отправлено через 10 минут после события A
- День 0: событие C отправлено через 2 часа после события B
Результат:
Фрод. Пользователь выполнил все события в правильном порядке, но интервал между событиями A и B составил всего 10 минут, что меньше настроенного минимума в 1 час. Временное ограничение было нарушено, несмотря на правильный порядок последовательности. В результате:
- Событие A будет заблокировано при пост-атрибуции
- Событие B будет заблокировано в реальном времени, так как было нарушено минимальное временное ограничение
- Событие C будет заблокировано в реальном времени, так как оно следует за нарушенной последовательностью
- Все последующие события будут заблокированы в реальном времени
Пример 4
Заданное правило
Пользователь должен выполнять события в таком порядке:
- Событие A
- Событие B
- Событие C
Фактически выполнено
Пользователь выполняет события в таком порядке:
- День 0: выполнена установка
- День 1: отправлено событие A
- День 2: отправлено событие B
- Событие C не отправлено
Результат:
Не фрод. Пользователь выполнил события A и B в правильном порядке, но так и не отправил событие C. Неполные последовательности не считаются нарушениями. Ни одно событие не заблокировано. Правило продолжает оценивать будущие события в пределах 30-дневного окна оценки.
Пример 5
Определенное правило
Пользователь был идентифицирован по идентификатору пользователя клиента (CUID).
Пользователь должен выполнять события в таком порядке:
- Событие A
- Событие B
- Событие C
Фактически выполнено
Пользователь выполняет события в таком порядке:
- День 0: произошла установка
- День 1: отправлено событие A
- День 1: произошло удаление
- День 1: произошла установка
- День 2: отправлено событие B
- День 3: отправлено событие C
Результат
Не фрод. Поскольку пользователь был идентифицирован по идентификатору пользователя клиента (CUID) и события выполнялись по порядку.
Пример 6
Определенное правило
Пользователь должен выполнить события в таком порядке:
- Событие A
- Событие B
- Событие C
Фактически выполнено
Пользователь был идентифицирован по идентификатору рекламодателя
Пользователь выполняет события в таком порядке:
- День 0: произошла установка
- День 1: отправлено событие A
- День 1: произошло удаление
- День 1: произошла установка
- День 2: отправлено событие B
- День 3: отправлено событие C
Результат
Не фрод. Поскольку пользователь был идентифицирован по идентификатору рекламодателя Advertiser ID и события были выполнены по порядку.
Пример 7
Заданное правило
Пользователь должен выполнять события в таком порядке:
- Событие A
- Событие B
- Событие C
Правило создано 1 января.
Фактически выполнено:
- 1 января (день 0): правило создано. Начинается окно оценки. События, сработавшие до этой даты, игнорируются.
- 15 января (день 14): отправлено событие A. Окно расширяется: теперь оцениваются последние 14 дней. Окно расширяется: теперь оцениваются последние 14 дней.
- 30 января (день 29): отправлено событие B. Окно расширяется: теперь оцениваются последние 29 дней. Окно расширяется: теперь оцениваются последние 29 дней.
- 31 января (день 30): окно достигает 30 дней и становится скользящим 30-дневным окном, сдвигаясь вперед каждый день.
- 20 февраля: отправлено событие C. Теперь скользящее окно охватывает предыдущие 30 дней — до 21 января. Теперь скользящее окно охватывает предыдущие 30 дней до 21 января. Событие A (сработавшее 15 января) выходит за пределы окна и больше не оценивается.
Результат:
Не фрод. К 20 февраля скользящее окно охватывает период до 21 января, поэтому событие A (15 января) оказывается за пределами окна оценки. Оцениваются только события B и C — оба в правильном порядке, нарушение не фиксируется.
Пример 8
Определенное правило
Пользователь должен выполнять события в таком порядке:
- Событие A
- Событие B
- Событие C
Фактически выполнено
Пользователь выполняет события в таком порядке:
- День 0: произошла установка
- День 1: отправлено событие A
- День 2: отправлено событие B
- День 3: отправлено событие B
- Day4: отправлено событие C
Результат
Фрод. Поскольку одно и то же событие (событие B) произошло дважды, мы предполагаем фрод, так как одно и то же событие не может встречаться дважды в последовательности.
Пример 9
Заданное правило
Пользователь был идентифицирован по идентификатору пользователя клиента (CUID).
Пользователь должен выполнять события в таком порядке:
- Событие A
- Событие B
- Событие C
Фактически выполнено
Пользователь отправляет события с двух устройств, используя один и тот же CUID:
- День 0: на устройстве 1 произошла установка
- День 0: на устройстве 2 произошла установка
- День 1: событие A отправлено с устройства 1
- День 2: событие B отправлено с устройства 2
- День 3: событие C отправлено с устройства 1
Результат:
Не фрод. Поскольку пользователь был идентифицирован по CUID, оценка последовательности охватывает все идентификаторы AppsFlyer, связанные с одним и тем же CUID и идентификатором правила. События A, B и C были выполнены в правильном порядке независимо от того, с какого устройства они были отправлены.
Спецификации и ограничения
- В каждом правиле можно задать до 100 событий.
- При 80 событиях отображается предупреждение. При 100 событиях лимит достигнут, и правило нужно разделить, чтобы добавить больше событий.
- Минимальное время, которое можно задать между последовательными событиями, — 1 секунда. Если для пары не настроен интервал, автоматически применяется значение по умолчанию — 1 секунда.
- Максимальный конфигурируемый временной интервал между событиями составляет 30 дней и соответствует окну оценки.
- Окно оценки начинается с дня 0 (даты создания правила) и ежедневно увеличивается до 30 дней, после чего становится скользящим 30-дневным окном, которое сдвигается вперед каждый день. События, произошедшие до даты создания правила, никогда не оцениваются.
- Любое изменение правила сбрасывает окно оценки до дня 0.
- Для одной учетной записи можно задать до 10 активных правил.
- Правила для последовательностей событий можно использовать только для неорганического трафика.
- Поддерживается только трафик SDK. Трафик S2S не входит в рамки этапа 1.
- Незавершенные последовательности не помечаются как нарушения.
- Одно и то же событие не может появляться дважды в рамках одной последовательности.
- Между условиями поддерживается только логика AND. Логика OR не поддерживается.
Часто задаваемые вопросы
Что происходит после переустановки?
Если переустановка сбрасывает события, которые пользователь уже выполнил, это считается нарушением. Если пользователь продолжает с того места, где остановился, нарушение не фиксируется.