Реализация AI-персонализации контента в мобильном приложении

Реализация AI-персонализации контента в мобильном приложении

Персонализация контента — это не рекомендательная система в чистом виде. Это более широкая задача: адаптировать порядок элементов, формат подачи, набор функций и даже тональность коммуникации под конкретного пользователя. ML здесь стоит на нескольких опорах: поведенческий профиль, контекстные сигналы (время, локация, устройство) и явные предпочтения.

Поведенческий профиль: что и как собирать

Профиль пользователя — это вектор признаков, который обновляется с каждой сессией. Для контентных приложений: какие категории читает чаще, сколько времени тратит, в какое время дня активен, какой форматы предпочитает (текст / видео / короткое / длинное).

struct UserContentProfile: Codable {
    var categoryWeights: [String: Double]   // "tech": 0.7, "sports": 0.2
    var formatPreferences: FormatPrefs
    var activeHours: [Int: Double]          // час -> вероятность активности
    var sessionCount: Int
    var lastUpdated: Date

    struct FormatPrefs: Codable {
        var longReadScore: Double    // 0..1
        var videoScore: Double
        var shortPostScore: Double
    }
}

Обновляйте профиль локально после каждой сессии — не ждите серверного ответа. Синхронизируйте на сервер в фоне через BGAppRefreshTask (iOS) или WorkManager (Android).

Контекстная персонализация

Одни и те же пользователи ведут себя по-разному утром и вечером, на работе и дома. Контекстные сигналы:

• Время суток — утром короткие форматы, вечером длинные материалы
• День недели — выходные vs рабочие дни
• Network type — на WiFi можно грузить HD-превью, на LTE — нет
• Battery state — при < 20% не запускать фоновую предзагрузку

data class RequestContext(
    val hourOfDay: Int,
    val dayOfWeek: Int,
    val networkType: NetworkType,
    val batteryLevel: Float,
    val location: LocationCluster? // не точная геолокация, а кластер (дом/работа)
)

class ContentRanker(private val model: TFLiteModel) {
    fun rank(items: List<ContentItem>, profile: UserProfile, context: RequestContext): List<ContentItem> {
        val featureMatrix = buildFeatureMatrix(items, profile, context)
        val scores = model.run(featureMatrix) // Float32 array
        return items.zip(scores.toList()).sortedByDescending { it.second }.map { it.first }
    }
}

Персонализация интерфейса

Помимо контента — сам интерфейс. Firebase Remote Config позволяет менять порядок секций главного экрана без релиза. Growth Book или Statsig — для более сложных экспериментов с UI-вариантами.

Конкретный пример: в новостном приложении блок «Для вас» для пользователей с > 30 сессиями показывается первым, для новых — после блока «Популярное». Это простое правило заметно влияет на удержание.

Персонализация push-уведомлений — отдельная задача. Не рассылайте одно и то же всем. Firebase ML + Audience Builder или собственная модель предсказания оптимального времени отправки под каждого пользователя. Push в неподходящее время = unsubscribe.

On-device vs server personalisation

Регуляторные требования (152-ФЗ, GDPR) влияют на выбор: если нельзя передавать поведенческие данные — on-device вынужден.

Избегайте «пузырей»

Чистая персонализация создаёт filter bubble — пользователь видит только то, что уже интересовало. Это снижает discovery и время в приложении через несколько недель. Стандартное решение: exploration coefficient — 10–15% слотов отдаётся не топу по релевантности, а случайным высококачественным материалам из неисследованных категорий.

Процесс работы

Аудит текущих событий и данных. Проектирование профиля пользователя и схемы обновления. Выбор архитектуры персонализации. Реализация ранкера (on-device или server). Интеграция контекстных сигналов. A/B-тест с контрольной группой (без персонализации). Аналитика: retention, DAU, CTR по персонализированным блокам.

Ориентиры по срокам

Правило-based персонализация без ML — 1–2 недели. Полная система с on-device ранкером, профилем пользователя, A/B-тестированием и аналитикой — 6–12 недель.