Custom dimensions в трекинге: как не превратить бизнес-метрики в мусорный тег-спагетти

Custom dimensions в трекинге: как не превратить бизнес-метрики в мусорный тег-спагетти

Custom dimensions нужны не для красоты в кабинете, а чтобы связать клик, лид и деньги с теми признаками, которые реально влияют на экономику: плейсмент, креатив, тип оффера, модель оплаты, сегмент устройства, источник subID.

Рабочее правило: в dimension попадает только то, по чему ты потом будешь резать отчет или строить правило. Если поле не участвует в решении, не тащи его в трекер. Иначе получишь десятки почти одинаковых срезов, где не видно ни CPA, ни апрува, ни LTV.

Перед запуском зафиксируй схему:
— имя поля;
— тип значения;
— допустимые варианты;
— кто пишет его на входе: JS, postback, server-side;
— где оно живет дальше: отчет, BI, выгрузка, антифрод-правило.

Самая частая ошибка — менять смысл поля по ходу работы. Сегодня `segment=mobile`, завтра туда же кладут ОС, потом регион. После этого любые сравнения ломаются, а исторические данные становятся нечитаемыми.

Держи одну логику именования, один источник истины и короткий список dimension. Тогда трекинг перестает быть складом мусора и начинает работать как слой управления решением.