Разработка виджета контекстных опросов (in-app survey) для сайта

Наша компания занимается разработкой, поддержкой и обслуживанием сайтов любой сложности. От простых одностраничных сайтов до масштабных кластерных систем построенных на микро сервисах. Опыт разработчиков подтвержден сертификатами от вендоров.

Разработка и обслуживание любых видов сайтов:

Информационные сайты или веб-приложения
Сайты визитки, landing page, корпоративные сайты, онлайн каталоги, квиз, промо-сайты, блоги, новостные ресурсы, информационные порталы, форумы, агрегаторы
Сайты или веб-приложения электронной коммерции
Интернет-магазины, B2B-порталы, маркетплейсы, онлайн-обменники, кэшбэк-сайты, биржи, дропшиппинг-платформы, парсеры товаров
Веб-приложения для управления бизнес-процессами
CRM-системы, ERP-системы, корпоративные порталы, системы управления производством, парсеры информации
Сайты или веб-приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, конструкторы сайтов, порталы предоставления электронных услуг, видеохостинги, тематические порталы

Это лишь некоторые из технических типов сайтов, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента

Услуги, которые мы предлагаем
Показано 1 из 1Все 2062 услуг
Разработка виджета контекстных опросов (in-app survey) для сайта
Средний
~2-3 дня
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1361
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1251
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    957
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1189
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    929
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    948

Представьте: пользователь только что отменил подписку на Pro-тариф. Через минуту он получает email с просьбой ответить, почему ушёл. Шанс, что он откроет это письмо — меньше 5%. In-app survey решает эту проблему: вопрос появляется прямо в интерфейсе сразу после отмены. Конверсия в ответ подскакивает до 30%. Именно это даёт in-app survey — опрос, встроенный в контекст действия.

Мы 5+ лет разрабатываем сложные веб-приложения и реализовали in-app опросы для более чем 20 проектов. Гарантируем, что система не повлияет на Core Web Vitals и не создаст лишних запросов к API. Как показывает практика, внедрение in-app survey окупается в среднем за 2-3 месяца за счёт роста удержания на 15-20%.

Какие проблемы решает in-app survey?

Email-опросы теряют до 90% целевой аудитории: письма попадают в спам, забываются, открываются не в том контексте. In-app survey решает эту проблему — пользователь отвечает в момент, когда впечатление о функции ещё свежо. Результат: точная обратная связь, NPS с привязкой к действию, меньше отказов при сборе данных.

Сравнение эффективности: in-app против email

По данным исследований, конверсия in-app опросов в 3-6 раз выше, чем email. Причина — сокращение пути: не нужно переходить по ссылке, вводить логин. Всё происходит в одном окне. Наш опыт показывает, что даже короткий опрос из 3 вопросов собирает более 200 ответов за неделю на аудитории в 1000 пользователей.

Как устроена система опросов?

Система строится на двух компонентах: бэкенд на Laravel (таблицы survey, questions, responses) и фронтенд-виджет на React. Движок проверяет условия показа: событие, план пользователя, минимальное количество сессий, cooldown между ответами.

Схема базы данных

Schema::create('surveys', function (Blueprint $table) {
    $table->id();
    $table->string('name');
    $table->string('trigger_event');        // 'feature_used', 'upgrade_cancelled', 'idle_30_days'
    $table->json('trigger_conditions');     // {"min_sessions": 3, "plan": ["pro", "enterprise"]}
    $table->integer('delay_seconds')->default(0);
    $table->integer('cooldown_days')->default(30);
    $table->boolean('is_active')->default(true);
    $table->timestamps();
});

Schema::create('survey_questions', function (Blueprint $table) {
    $table->id();
    $table->foreignId('survey_id')->constrained()->cascadeOnDelete();
    $table->text('text');
    $table->enum('type', ['single_choice', 'multi_choice', 'text', 'scale', 'nps']);
    $table->json('options')->nullable();
    $table->integer('order')->default(0);
});

Schema::create('survey_responses', function (Blueprint $table) {
    $table->id();
    $table->foreignId('survey_id')->constrained();
    $table->foreignId('user_id')->nullable()->constrained()->nullOnDelete();
    $table->json('answers');                // {"q_1": "option_a", "q_2": "Great product"}
    $table->string('trigger_event')->nullable();
    $table->timestamps();
});

API: получение актуального опроса

class SurveyController extends Controller
{
    public function getForEvent(Request $request): JsonResponse
    {
        $event = $request->input('event');
        $user  = auth()->user();

        $survey = Survey::where('trigger_event', $event)
            ->where('is_active', true)
            ->get()
            ->first(function ($survey) use ($user) {
                // Проверяем cooldown
                $lastResponse = SurveyResponse::where('survey_id', $survey->id)
                    ->where('user_id', $user->id)
                    ->latest()->first();

                if ($lastResponse && $lastResponse->created_at->diffInDays(now()) < $survey->cooldown_days) {
                    return false;
                }

                // Проверяем условия
                $conditions = $survey->trigger_conditions;
                if (isset($conditions['plan']) && !in_array($user->plan, $conditions['plan'])) {
                    return false;
                }

                return true;
            });

        if (!$survey) return response()->json(null);

        return response()->json([
            'id'        => $survey->id,
            'delay'     => $survey->delay_seconds,
            'questions' => $survey->questions()->orderBy('order')->get(),
        ]);
    }

    public function submit(Request $request, Survey $survey): JsonResponse
    {
        SurveyResponse::create([
            'survey_id'     => $survey->id,
            'user_id'       => auth()->id(),
            'answers'       => $request->input('answers'),
            'trigger_event' => $request->input('event'),
        ]);

        return response()->json(['success' => true]);
    }
}

Frontend: SurveyWidget

// hooks/useSurvey.ts
export function useSurvey(event: string) {
  const [survey, setSurvey] = useState<Survey | null>(null);

  const triggerEvent = useCallback(async () => {
    const data = await fetch(`/api/surveys/for-event?event=${event}`).then(r => r.json());
    if (!data) return;

    // Показываем с задержкой
    setTimeout(() => setSurvey(data), data.delay * 1000);
  }, [event]);

  return { survey, triggerEvent, dismiss: () => setSurvey(null) };
}

// Использование в компоненте фичи
function FeatureComponent() {
  const { survey, triggerEvent, dismiss } = useSurvey('feature_export_used');

  useEffect(() => {
    // Триггер после успешного экспорта
    triggerEvent();
  }, []);

  return (
    <>
      <FeatureUI />
      {survey && <SurveyModal survey={survey} onClose={dismiss} />}
    </>
  );
}

SurveyModal с динамическими типами вопросов

function SurveyModal({ survey, onClose }: SurveyModalProps) {
  const [answers, setAnswers] = useState<Record<string, any>>({});
  const [step, setStep]       = useState(0);

  const currentQuestion = survey.questions[step];
  const isLast          = step === survey.questions.length - 1;

  const submit = async () => {
    await fetch(`/api/surveys/${survey.id}/submit`, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ answers, event: survey.trigger_event }),
    });
    onClose();
  };

  return (
    <div className="fixed inset-0 bg-black/30 flex items-end sm:items-center justify-center p-4 z-50">
      <div className="bg-white rounded-xl p-6 w-full max-w-md shadow-2xl">
        <div className="flex justify-between mb-4">
          <span className="text-xs text-gray-400">{step + 1} / {survey.questions.length}</span>
          <button onClick={onClose} className="text-gray-400 hover:text-gray-600">✕</button>
        </div>

        <QuestionRenderer question={currentQuestion} value={answers[currentQuestion.id]}
          onChange={val => setAnswers(prev => ({ ...prev, [currentQuestion.id]: val }))} />

        <div className="flex justify-end mt-4">
          <button onClick={isLast ? submit : () => setStep(s => s + 1)}
            className="bg-blue-600 text-white px-4 py-2 rounded-lg text-sm">
            {isLast ? 'Отправить' : 'Далее'}
          </button>
        </div>
      </div>
    </div>
  );
}

Сравнение каналов опросов: in-app vs email vs popup

Характеристика In-app survey Email-опрос Popup (всплывающее окно)
Контекстность Полная (привязан к событию) Низкая (открывается вне продукта) Средняя (появляется на странице, но не привязан к действию)
Конверсия в ответ 10-30% 2-5% 5-10%
Влияние на UX Минимальное (показывается после действия, с задержкой) Не влияет Высокое (перекрывает контент)
Сложность интеграции Средняя (требуется бэкенд + виджет) Низкая (простая форма) Низкая (вставка кода)
Типы данных Только выборочные (целевые события) Случайная выборка Все посетители

In-app survey лучше email в 3-6 раз по отклику, а popup проигрывает по UX.

Что входит в работу

  • Миграции БД и модели Eloquent
  • REST API с кэшированием через Redis (снижение нагрузки на 80%)
  • React-виджет с поддержкой 5 типов вопросов
  • Админ-панель для просмотра ответов и управления опросами
  • Документация по API и настройке, код в вашем репозитории
  • 2 недели бесплатной поддержки после деплоя

Типичные ошибки при внедрении in-app survey

Распространённые проблемы и их решение 1. **Слишком много вопросов** — снижает отклик. Оптимум: 2-4 вопроса. 2. **Нет cooldown** — пользователь видит опрос каждый раз, это бесит. Ставьте минимум 30 дней. 3. **Показ на всех страницах** — должен быть привязан к конкретному событию. 4. **Игнорирование мобильной версии** — виджет должен корректно работать на экранах < 375px. 5. **Отсутствие обработки ошибок** — если API недоступен, виджет не должен ломать интерфейс.

Начало работы

По данным Wikipedia, контекстные опросы повышают отклик на 30-50% по сравнению с внешними каналами.

Оставьте заявку — мы оценим ваш проект за один рабочий день. Укажите стек, количество пользователей и события, которые хотите отслеживать. Система in-app опросов обычно окупается за две недели за счёт точной обратной связи и роста удержания.

Сроки: от 4 до 10 рабочих дней в зависимости от сложности. Гарантии: фиксированные сроки, полная документация, код в вашем репозитории. Свяжитесь с нами — мы поможем внедрить контекстные опросы, которые действительно повышают метрики. Получите консультацию прямо сейчас.

Настройка веб-аналитики: GA4, GTM, Яндекс.Метрика и Amplitude

Мы часто видим: конверсия 1.2 %, трафик растёт, а конверсия стоит. Маркетолог смотрит в Google Analytics и говорит: «пользователи уходят с шага 2 оформления заказа». Разработчик открывает тот же шаг — ошибок нет, в Sentry тишина. Значит, дело не в JS-баге, а в UX или в кривых данных, которые показывает аналитика. Аналитика ломается незаметно: событие перестало трекаться после редеплоя — никто не заметил; GTM-тег стреляет дважды — данные задвоились; фильтр GA4 исключает бота, который на самом деле — реальный трафик с корпоративного прокси. Закажите аудит текущих тегов — мы найдём причину за неделю.

После правильной настройки экономия рекламного бюджета может достигать 150 000 ₽ в месяц — это реальный кейс интернет-магазина с 50 000 сессий в день, где дедупликация purchase вернула 20 % неверно приписанных конверсий.

Почему события GA4 дублируются и как это исправить?

Universal Analytics закрыт, его место заняла событийная модель GA4. В ней нет фиксированных хитов страниц и транзакций — только события с параметрами. Это гибче, но требует правильного дизайна событий.

Автоматические события GA4 собирает сам: page_view, scroll, click, session_start. Рекомендуемые события нужно реализовать самостоятельно: purchase, add_to_cart, begin_checkout, view_item. Google ожидает конкретную схему параметров — если передать product_id вместо item_id, данные попадут в GA4, но не в стандартные отчёты e-commerce. Кастомные события для специфики проекта: filter_applied, video_progress, form_step_completed. Кастомные параметры необходимо зарегистрировать в GA4 Admin → Custom definitions, иначе они не будут доступны в отчётах.

Частая ошибка — событие purchase с дублями. Причина: тег срабатывает на странице /thank-you, пользователь обновляет страницу — второй purchase уходит в GA4. Решение: на бэкенде генерируем уникальный transaction_id и передаём в событие. GA4 de-duplicates по нему (в теории — проверяйте через DebugView). Правильная атрибуция экономит до 20 % рекламного бюджета, который раньше уходил на неверно приписанные конверсии.

Как настроить data layer, чтобы не потерять данные?

GTM — инструмент для управления тегами без деплоя кода. Но «без кода» не значит «без архитектуры». Data Layer — основа всего. Передаём данные из приложения в GTM через dataLayer.push(). Структура: event + контекстные данные. Для e-commerce: перед открытием страницы продукта — push с данными товара. GTM-тег читает из dataLayer, не из DOM.

window.dataLayer = window.dataLayer || [];
dataLayer.push({
  event: 'view_item',
  ecommerce: {
    items: [{
      item_id: 'SKU-12345',
      item_name: 'Название товара',
      price: 1990.00,
      currency: 'RUB'
    }]
  }
});

Плохая практика: GTM-тег парсит DOM — ищет цену в span.price, название в h1. Это ломается при любом изменении верстки. Хорошая практика: всегда dataLayer. Используем Preview Mode для отладки и GTM Server-Side для чувствительных данных — отправка с сервера, не с браузера, обходит блокировщики рекламы, не теряет данные.

Как Яндекс.Метрика дополняет веб-аналитику?

Для российской аудитории Метрика обязательна — особенно Вебвизор. Запись сессии пользователя, который бросил корзину, часто даёт ответ быстрее, чем неделя анализа воронки. Цели в Метрике: событийные (через ym(COUNTER_ID, 'reachGoal', 'GOAL_NAME')) или автоматические (клик по кнопке, посещение страницы). Связка с CRM через Метрика Плюс — передача офлайн-конверсий. Наш опыт: в 8 из 10 проектов после настройки Метрики находили скрытые баги в UX, которые не показывали другие системы.

Что даёт product analytics в Amplitude?

Amplitude — продуктовый инструмент, в отличие от маркетинговых GA4 и Метрики. Он заточен под анализ поведения пользователей внутри продукта: воронки, ретеншн, user paths. Amplitude подходит для SaaS-продуктов, мобильных приложений и любых сервисов с зарегистрированными пользователями, где важно понять, как проходят онбординг, на каком шаге уходят, какие фичи используют чаще. Ключевые концепции: identify (связать анонимного пользователя с userId после авторизации), group (аккаунт в B2B SaaS), когорты для удержания. Amplitude Chart — воронка шагов за последние 30 дней с разбивкой по источнику.

Мониторинг качества данных

Аналитика без мониторинга — чёрный ящик. Настраиваем:

  • GA4 Realtime — проверяем после каждого деплоя, что ключевые события приходят
  • Alerting в GA4 — аномалия в количестве событий purchase (резкое падение = что-то сломалось)
  • GTM Preview в staging-окружении перед продакшеном
  • Ручные тесты воронок раз в неделю — просто пройти путь покупателя и проверить, что всё трекается

Что проверяем после каждого деплоя

  • Все ли рекомендуемые события присутствуют в DebugView
  • Нет ли задвоений (считаем количество purchase на 100 сессий)
  • Не изменилась ли структура dataLayer после обновления фронтенда

Что входит в работу

Компонент Описание
Аудит текущих тегов Проверка существующих GTM-тегов, dataLayer, дублей и ошибок
Дизайн событийной схемы Документация: список событий, параметры, триггеры
Настройка GA4 + GTM Создание конфигурации, тегов, Custom definitions
Яндекс.Метрика Установка счётчика, создание целей, настройка Вебвизора
Amplitude (опционально) Настройка клиентского и серверного SDK, когорты
QA и мониторинг Тестирование в Preview Mode, Alerting
Обучение и передача Доступы, инструкция по добавлению новых событий, консоль

Процесс и сроки

  1. Аудит текущих тегов и данных (2 дня)
  2. Дизайн событийной схемы (2 дня)
  3. Разработка Data Layer и настройка тегов (3–5 дней)
  4. QA в Preview Mode и на staging (2 дня)
  5. Деплой и настройка дашбордов (1 день)
Сценарий Срок
Базовая настройка GA4 + GTM 1 неделя
Полный e-commerce tracking + Метрика 2–3 недели
Server-side GTM + Amplitude 3–5 недель

Стоимость рассчитывается индивидуально. Получите консультацию по настройке веб-аналитики для вашего проекта — мы оценим объём работ за один день. Свяжитесь с нами, чтобы начать.

Wikipedia: Веб-аналитика — подробнее о методах и метриках. Официальная документация по событийной модели GA4 доступна в Google Analytics 4.