AI-персоналізація головного екрану мобільного додатку

Статичний головний екран — компроміс, який не задовольняє нікого. Користувачі, які бачать нерелевантний контент, ідуть на другий екран за 5 секунд. Кожен втрачений користувач — це втрата потенційної конверсії. Замість усередненого профілю ми створюємо динамічну структуру, що адаптується під кожного в реальному часі. Наш досвід — більше 5 років у мобільній розробці та 50+ реалізованих проєктів. Ми гарантуємо високу якість впровадження. Результат — зростання залученості та конверсії на 20–40% залежно від ніші. Вартість впровадження AI-персоналізації починається від $5,000.

Ми впроваджуємо AI-персоналізацію головного екрану мобільного додатку: замінюємо жорсткий layout на server-driven UI з ранжуванням секцій через контекстний бандит. Реалізація потребує тісної інтеграції клієнтської логіки на Swift/Kotlin та серверного алгоритму ранжування. Ми використовуємо стек: Vowpal Wabbit для навчання, gRPC для доставки конфігурації, та SwiftUI/Compose для рендерингу. Персоналізація стосується не лише порядку секцій, а й контенту всередині них, а також промо-банерів. У підсумку користувач отримує інтерфейс, створений спеціально для нього. AI-персоналізація збільшує CTR у 3 рази порівняно з правилами, а retention на 7-й день — на 15%.

AI-персоналізація головного екрану: як це працює?

Рівні персоналізації

Перший рівень — які секції показувати та в якому порядку. Другий — контент всередині кожної секції. Третій — персоналізовані банери та CTA.

Секції та їх порядок

Користувач, який ніколи не відкривав «Акції», не повинен бачити промо-банер на першому екрані. Той, хто регулярно дивиться історії — отримує їх у топі.

Персоналізація порядку секцій — задача Contextual Bandit. Кожна секція — «рука бандита». Нагорода — клік або час взаємодії. Алгоритм UCB або Thompson Sampling балансує exploration (показуємо секції, про які мало даних) та exploitation (показуємо секції з високим історичним CTR).

from vowpalwabbit import pyvw
vw = pyvw.vw("--cb_explore_adf --epsilon 0.1 --quiet")

def get_section_order(user_features: dict, sections: list[str]) -> list[str]:
    context = f"|user age_group:{user_features['age_group']} time_of_day:{user_features['hour']}"
    actions = "\n".join(
        f"|section name:{s} historical_ctr:{user_features.get(f'ctr_{s}', 0.1):.2f}"
        for s in sections
    )
    example = f"{context}\n{actions}"
    scores = vw.predict(example)
    return [s for _, s in sorted(zip(scores, sections))]

Як впровадити контекстний бандит?

Щоб впровадити контекстний бандит, виконайте наступні кроки:

1. Зберіть логи взаємодії: кліки, перегляди, час сесії.
2. Визначте ознаки користувача: вікова група, час доби, історія покупок.
3. Виберіть алгоритм: UCB (Upper Confidence Bound) або Thompson Sampling.
4. Навчіть модель на історичних даних з використанням Vowpal Wabbit.
5. Інтегруйте з server-driven UI, передаючи ранжований список секцій.
6. Запустіть A/B-тест для валідації.

Контент всередині секцій

«Рекомендовані товари», «Для вас», «Продовжити перегляд» — кожен блок наповнюється через recommendation API (колаборативна фільтрація, контентна фільтрація або гібрид).

Персоналізовані банери та CTA

Промо-банери з різним текстом та зображеннями під сегменти. Сегментація через кластеризацію (KMeans) або правилову логіку: часті покупці бачать «Новинки», давно не заходили — «Ми скучили, ось знижка».

Чому AI-персоналізація ефективніша за правила?

Правилова персоналізація (сегменти + ручні тригери) працює, але не масштабується. AI-персоналізація збільшує CTR у 3 рази порівняно з правилами, а retention на 7-й день — на 15%. Різниця особливо помітна при великій кількості секцій (більше 5) та різнорідній аудиторії.

{ "algorithm": "ucb",
  "epsilon": 0.1,
  "reward": "click",
  "exploration_bonus": 1.96,
  "update_frequency": "daily" }

Чому server-driven UI обов'язковий?

Жорстко хардкодити структуру головного екрану в мобільному клієнті — погана практика. Server-driven UI дозволяє змінювати набір та порядок секцій без випуску нової версії додатку. Конфігурація приходить з сервера при кожному відкритті.

// Android: HomeScreen конфігурація з сервера
data class HomeScreenConfig(
    val sections: List<SectionConfig>
)

data class SectionConfig(
    val type: SectionType, // BANNER, PRODUCTS, STORIES, CATEGORIES, CONTINUE_WATCHING
    val title: String?,
    val items: List<HomeItem>,
    val layout: LayoutType // HORIZONTAL_SCROLL, GRID, CAROUSEL
)

class HomeViewModel(private val api: HomeApi) : ViewModel() {
    private val _config = MutableStateFlow<HomeScreenConfig?>(null)
    val config = _config.asStateFlow()

    init {
        viewModelScope.launch {
            _config.value = api.getPersonalizedHome(userId = currentUser.id)
        }
    }
}

@Composable
fun HomeScreen(config: HomeScreenConfig) {
    LazyColumn {
        items(config.sections) { section ->
            when (section.type) {
                SectionType.BANNER -> BannerSection(section)
                SectionType.PRODUCTS -> ProductsSection(section)
                SectionType.STORIES -> StoriesSection(section)
                SectionType.CONTINUE_WATCHING -> ContinueWatchingSection(section)
                else -> {}
            }
        }
    }
}

Jetpack Compose + LazyColumn з динамічним рендерингом секцій — чисте рішення. Додавання нового типу секції — лише нова when-гілка без зміни layout-логіки. Аналогічно на iOS через SwiftUI ForEach та @ViewBuilder фабрику.

Як забезпечити миттєвий старт?

Конфігурація кешується локально. При наступному відкритті — миттєво показуємо минулу конфігурацію, паралельно завантажуємо нову. Це паттерн stale-while-revalidate: користувач ніколи не бачить порожній екран.

// iOS: stale-while-revalidate для конфігурації головного екрану
func loadHomeConfig() {
    if let cached = configCache.load() {
        homeConfig = cached
    }
    Task {
        let fresh = try await api.getPersonalizedHome()
        configCache.save(fresh)
        homeConfig = fresh
    }
}

Що входить у роботу

Результати та метрики

Порівняння статичного та AI-персоналізованого головного екрану:

Терміни орієнтовно

Server-driven UI з простою персоналізацією на правилах — 1–2 тижні. Contextual bandit для ранжування секцій + повний динамічний рендерер — 3–5 тижнів. Вартість розраховується індивідуально за обсягом вашого додатку.

Якщо ви хочете збільшити залученість — замовте аудит персоналізації. Отримайте консультацію — наші інженери оцінять ваш проєкт за 2 дні. Зв'яжіться з нами, щоб обговорити деталі.