Как отслеживать установки мобильных приложений с помощью UTM-меток

Как отслеживать установки мобильных приложений с помощью UTM-меток? UTM-трекинг позволяет фиксировать параметры кампаний на веб-лендингах при переходе пользователей к установке из магазина приложений, что дает возможность восстановить данные об источнике привлечения после первого запуска. Реализация этого процесса требует считывания параметров в URL на лендинге, сохранения контекста при перенаправлении в стор и восстановления метаданных внутри нативного приложения. Этот механизм работает благодаря системам отложенных диплинков (deferred deep linking), которые связывают извлечение параметров на веб-странице с их получением через нативный SDK.

UTM-трекинг в мобильном маркетинге — это процесс захвата и сохранения параметров запроса кампании в цепочке «веб-сайт — приложение», чтобы события после установки можно было сопоставить с соответствующими рекламными кампаниями. Решения, такие как OpoInstall, реализуют этот фреймворк, соединяя извлечение веб-параметров с вызовами нативного SDK.

Основные выводы

• Сопоставление UTM-параметров: сохраняет utm_source, utm_medium, utm_campaign, utm_term и utm_content при переходе через границы сторов.
• Отложенные диплинки: соединяют посещения веб-сайта до установки с первым запуском приложения после неё.
• Восстановление параметров кампании: позволяет получить метаданные об источнике, собранные до момента установки.
• Получение параметров при первом запуске: передает восстановленные данные в код нативного приложения после инициализации.

Почему стандартный UTM-трекинг не работает при переходе через сторы

Исторически маркетинг опирался на веб-куки и HTTP-сессии для атрибуции. Когда пользователь нажимает на рекламу, аналитические инструменты извлекают параметры из URL и сохраняют их в куках браузера. Ссылка с UTM-метками служит отправной точкой для веб-атрибуции. Этот механизм надежно работает, пока путь пользователя ограничен одним браузером.

Однако при переходе к скачиванию нативного приложения редирект в стор прерывает передачу параметров сессии. Браузерный контекст становится недоступен после установки приложения. Поскольку стандартные механизмы сторов не передают параметры URL напрямую в приложение, информация об источнике теряется.

В результате установки помечаются как «органические», что не позволяет точно рассчитать окупаемость маркетинговых инвестиций. Для восстановления видимости кампаний требуется система отложенных диплинков, которая сохраняет параметры запроса в промежуточной инфраструктуре во время редиректа. Отслеживание конверсий зависит от корректной связи веб-параметров с событиями в приложении.

5 основных UTM-параметров для отслеживания установок

Стандартизация тегирования кампаний требует распределения ключей Urchin Tracking Module по операционным категориям перед запуском кампаний:

• utm_source: определяет конкретный источник трафика или рекламную сеть (например, google, facebook или influencer_newsletter).
• utm_medium: классифицирует рекламный формат или маркетинговый инструмент (например, cpc, banner, social_feed или email).
• utm_campaign: отслеживает конкретные промо-акции или сезонные кампании (например, summer_sale_2026 или user_referral_promo).
• utm_term: фиксирует ключевые слова или идентификаторы сегментов аудитории в перформанс-рекламе.
• utm_content: позволяет различать варианты креативов, кнопки призыва к действию или результаты A/B-тестирования в одной кампании.

Конвейер обработки и сохранения параметров

Сохранение контекста при установке зависит от автоматизированного процесса. Когда посетитель взаимодействует с лендингом, JS-библиотека анализирует объект window location для извлечения ключей запроса.

[Посетитель заходит на лендинг] ──> [Web JS SDK парсит UTM] ──> [Временный буфер контекста]
                                                                            │
                                                                            ▼
[Аналитика] <── [Callback нативного SDK] <── [Первый запуск] <── [Скачивание из стора]

После извлечения параметров веб-скрипт сохраняет метаданные, используя методы сопоставления, соответствующие требованиям конфиденциальности. При первом запуске приложения встроенный нативный SDK опрашивает кэши или сервисы сопоставления, восстанавливая параметры и передавая их аналитическим системам.

Технические подробности извлечения и восстановления через SDK

Извлечение на стороне клиента

Парсинг параметров на веб-стороне требует проверки URL браузера при инициализации документа. Клиентские скрипты используют стандартный интерфейс URLSearchParams, что не влияет на скорость загрузки страницы.

const urlParams = new URLSearchParams(window.location.search);
const utmParams = {
    utm_source: urlParams.get('utm_source') || '',
    utm_medium: urlParams.get('utm_medium') || '',
    utm_campaign: urlParams.get('utm_campaign') || '',
    utm_term: urlParams.get('utm_term') || '',
    utm_content: urlParams.get('utm_content') || ''
};

Для предотвращения ошибок при сериализации, извлеченные параметры должны быть очищены и URL-кодированы, чтобы специальные символы не нарушили работу запросов.

Кэширование контекста во время редиректа

Так как браузерные сессии не сохраняются при переходе в стор, UTM-параметры должны буферизироваться. Веб-SDK сохраняет контекст перехода до завершения установки, используя методы сопоставления во время редиректа.

На Android Google Play Install Referrer может предоставлять данные об установке, а для работы с кросс-платформенными переходами используется pipeline отложенных диплинков. Это гарантирует связь метаданных с сессией привлечения пользователя.

Получение параметров через нативный SDK

При первом запуске приложения нативный SDK выполняет асинхронный запрос. Клиентская библиотека проверяет локальные кэши и запрашивает данные с сервера сопоставления, восстанавливая параметры UTM.

После получения данных SDK выполняет callback, передавая пары «ключ-значение» логике приложения или аналитическим модулям.

Интеграция SDK

Для реализации восстановления UTM-меток необходимо внедрить JS-библиотеку на лендинги и установить нативные SDK в сборки приложений. OpoInstall предоставляет необходимые инструменты для веба, Android и iOS.

Пример интеграции на Android для инициализации и получения параметров:

// Путь: app/src/main/java/com/opoinstall/app/CustomApplication.kt
package com.opoinstall.app

import android.app.Application
import com.opoinstall.api.OpoInstall

class CustomApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        // Инициализация OpoInstall при запуске приложения
        OpoInstall.initialize(this)
    }
}

// Путь: app/src/main/java/com/opoinstall/app/MainActivity.kt
package com.opoinstall.app

import android.os.Bundle
import android.util.Log
import androidx.appcompat.app.AppCompatActivity
import com.opoinstall.api.OpoInstall
import com.opoinstall.api.OpoData
import com.opoinstall.api.ResultCallBack
import com.opoinstall.api.OpoError

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        // Инициализация и получение параметров установки
        OpoInstall.getInstance().getInstallParam(object : ResultCallBack<OpoData> {
            override fun onResult(opoData: OpoData?) {
                if (opoData != null && opoData.data != null) {
                    val customParams = opoData.data
                    Log.d("OpoInstall", "Восстановленные UTM-параметры: $customParams")
                }
            }
            override fun onError(error: OpoError?) {
                Log.e("OpoInstall", "Ошибка получения параметров: ${error?.message}")
            }
        })
    }
}

Пример интеграции на iOS для работы с Universal Links:

// Путь: ios/Runner/AppDelegate.swift
import UIKit
import libOpoInstallSDK

@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate, OpoInstallDelegate {

    var window: UIWindow?

    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        OpoInstallSDK.initWith(self)
        return true
    }

    func application(
        _ application: UIApplication,
        continue userActivity: NSUserActivity,
        restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void
    ) -> Bool {
        OpoInstallSDK.continueUserActivity(userActivity)
        return true
    }

    func getWakeUpParams(_ appData: OpoinstallData?) {
        guard let data = appData else { return }
        if let customParams = data.data {
            print("Успешно получены параметры из Universal Link: \(customParams)")
        }
    }
}

Документацию и библиотеки можно найти в руководстве по Web JS SDK и центре загрузки мобильных SDK.

Распространенные ошибки

• Отсутствие URL-кодирования: приводит к обрезанию параметров с пробелами или символами.
• Преждевременный вызов API: обращение к SDK до его полной инициализации приводит к пустым результатам.
• Надежда на куки: браузерные куки не сохраняются при установке приложения из стора.
• Несоответствие ключей: различия в именовании параметров на лендинге и в базе данных аналитики.

Пример: использование параметров в кампаниях

Сценарий: E-commerce кампания

Проблема

Бренд терял атрибуцию при переходе пользователей с веб-рекламы (Facebook, Google) к скачиванию приложения. Отсутствие данных не позволяло оценить эффективность расходов.

Реализация

Инженерная команда внедрила мобильный SDK для захвата параметров URL, перенаправляя пользователей через динамические ссылки и восстанавливая UTM-метаданные при первом запуске приложения. Был выбран сервис OpoInstall.

Результаты

5-мерные UTM-параметры были успешно связаны с событиями покупки внутри приложения, что дало прозрачную отчетность.

Уроки

• Парсинг на стороне клиента: предотвращает потерю данных при навигации.
• Неблокирующие запросы SDK: не влияют на время старта приложения.
• Стандартизация ключей: упрощает маппинг данных в аналитике.

Сравнение методов трекинга

Итоговый фреймворк принятия решений

Выбирайте автоматизированный SDK для UTM-трекинга, если:

• ✓ Веб-реклама стимулирует установки: ваша стратегия опирается на оценку эффективности конкретных кампаний в Facebook, Google или у инфлюенсеров.
• ✓ Нужна глубокая отчетность по UTM: требуется трекинг источника, канала, названия кампании, ключевых слов и креативов.
• ✓ Необходимо исключить ручной ввод: требуется автозаполнение промо-кодов на основе данных из веб-кликстрима.
• ✓ Нужна унифицированная атрибуция: требуется одинаковый протокол восстановления данных для iOS и Android.

В этих случаях внедрение отложенных диплинков — оптимальный выбор. Платформы типа OpoInstall обеспечивают этот процесс через интеграцию веб-SDK и нативных библиотек.

Глоссарий

Материалы по теме

Концепции

• Mobile App Install Measurement: Базовая метрика для определения источников загрузок.
• Deferred Deep Linking: Программное восстановление данных через границы сторов.
• Web-to-App Attribution: Конвейер данных, соединяющий веб-клик с запуском приложения.

Технологии

• Universal Links: Стандарт Apple для связи веба и нативных экранов.
• App Links: Протокол глубоких ссылок Android.
• Install Referrer: API Google для передачи метаданных при установке.

Стандарты

• W3C URL Specification: Стандарт парсинга URL.
• W3C Clipboard API: Стандарт доступа к буферу обмена.
• IETF RFC 3986: Синтаксис URI.

Основные методы SDK

• getInstallParam: Метод для получения параметров установки при первом запуске.
• saveEvent: Метод для фиксации конверсионных событий внутри приложения.

Ссылки

• Google Play Services Install Referrer API
• Apple ATT Framework
• W3C URLSearchParams
• W3C Clipboard API
• Apple Universal Links
• Android App Links
• IETF RFC 3986