SOI и DOI: где архитектура воронки решает, а где только раздувает объем

SOI и DOI: где архитектура воронки решает, а где только раздувает объем

SOI дает быстрый вход: пользователь оставляет email, и лид сразу уходит в систему. Это полезно там, где критичны объем и скорость первичной валидации. Но архитектурно SOI чаще приносит больше шума: выше доля случайных регистраций, ниже качество базы и слабее сигнал для downstream-оптимизации.

DOI добавляет второй шаг — подтверждение email. Именно он фильтрует часть нецелевого трафика и делает постбэк чище. Минус очевиден: падает финальный объем, растет число точек отказа, а значит, нужно отдельно анализировать open rate, click rate и долю доставленных писем. Без этого легко ошибиться и обвинить связку, хотя проблема в доставляемости или тайминге письма.

Разберем технический флоу: где именно мы теряем трафик на этапе postback-событий? В SOI основной риск — ранний фейк и слабая атрибуция. В DOI — разрыв между lead и confirmed lead. Поэтому сравнивать эти модели только по CPL некорректно: нужно считать LTV по подтвержденным пользователям, CR в confirmation и долю невалидных доменов.

Если цель — масштабирование, SOI проще для теста оффера и креативов. Если цель — качество базы и предсказуемая монетизация, DOI обычно сильнее, но требует точной настройки email-цепочки, сегментации и контроля событий в трекере. Оптимизация — это не только креатив, но и математика удержания пользователя внутри воронки.