Охота за метрикой: Как я пытался внедрить data-driven подход в компании, которая не знала, чего хотела

История одного собеседования, которая ярко иллюстрирует разрыв между старым и новым миром digital-продуктов.

В мире digital-продуктов и e-commerce нет места догадкам. Есть только данные. Эту аксиому я и принес на собеседование в дорогую дубайскую компанию, рассчитывая на встречу с единомышленниками. Но reality check оказался жестче, чем ожидалось.

Data-Driven как религия: Мой подход к A/B-тестированию

Моя философия работы с гипотезами проста: любое изменение на сайте должно быть доказано цифрами, а не «чуйкой» продукт-менеджера или директора. Я не просто проводил A/B-тесты — я выстраивал целую систему сбора информации:

· Глубокий сбор метрик: Не просто «вариант А vs вариант Б», а максимально подробный портрет пользователя, который участвует в тесте. Отслеживание всего: от источника перехода до поведения на странице и конечной конверсии. · Масштабирование: Элегантное расширение модели до A/B/C/D-тестов, позволяющее проверять сразу несколько гипотез и находить не просто лучший, а оптимальный вариант. · Интеграция с аналитикой: Автоматизация процесса через выводимые шорткоды с метриками, помеченными Google Tag Manager. Это позволяло в режиме реального времени видеть, как ведут себя разные сегменты аудитории.

Венцом этой системы была идея автоматизации с помощью нейронных сетей. Зачем вручную анализировать каждую гипотезу, если можно обучить модель на основе накопленных данных, и она сама начнет предсказывать и предлагать winning-вариации для разных типов пользователей? Я видел эту картину целиком и был готов ее реализовать.

Собеседование: Мир, перевернутый с ног на голову

Мой энтузиазм столкнулся с суровой реальностью их внутренних процессов.

Акт 1: Встреча с директором. Занятой человек, погруженный в свои мысли. Создалось впечатление, что проект для него — чужой и не самый приоритетный. Основной месседж: «У нас есть конкуренты, в которых миллиардеры вкинули кучу денег». Мои предложения — хотя бы провести конкурентный анализ, изучить их рекламные кампании, UX-решения и позаимствовать лучшие практики — повисли в воздухе. Казалось, они хотели волшебную таблетку, а не системную работу.

Акт 2: Разговор с «техлидом». Это был кульминационный момент когнитивного диссонанса.

· Возраст и бэкграунд: Молодой человек, лет двадцати, позиционирующий себя как фуллстек-бэкендер. · Ключевое противоречие: Они искали фронтенд-разработчика, но при этом заявили о желании использовать WordPress в качестве фронтенда. Для любого технического специалиста это красный флаг. WordPress — это мощная CMS (система управления контентом), то есть бэкенд. К нему можно и нужно «подшивать» любой современный фронтенд (React, Vue.js) для быстрых, интерактивных и безопасных пользовательских интерфейсов. Использовать его как фронтенд — это создать монолитного Франкенштейна с кучей проблем с производительностью и безопасностью. · Не те вопросы: Вместо обсуждения архитектуры будущих A/B-тестов, построения SPA или работы с API, меня стали спрашивать про базовые CRUD-операции (Create, Read, Update, Delete) и «как я работаю с данными». Вопросы были странными и не соответствовали заявленным задачам.

Я вновь попытался вернуть разговор в русло продукта: подробно расписал, как можно автоматизировать их гипотезы, какую систему мы можем выстроить. Видимо, это было слишком.

Итог: Кто же им нужен?

Мне пришел отказ. И это, пожалуй, самый показательный результат.

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

Судя по всему, они искали исполнителя-кодерра с широким, но поверхностным бэкграундом, который:

· Согласится работать с устаревшей или неоптимальной архитектурой (WordPress как фронтенд). · Не будет задавать неудобных вопросов «почему»