Custom dimensions ломают аналитику, если хранить в них все подряд и без схемы

Custom dimensions ломают аналитику, если хранить в них все подряд и без схемы

Для бизнес-метрик custom dimensions нужны не как «помойка» для любых полей, а как слой нормализации. В трекинге имеет смысл заводить только то, что потом реально режется в отчетах: campaign_id, geo, placement, creative_id, device_class, funnel_step.

Правило простое: одно измерение — одна семантика. Если в dimension смешать source и subid, отчеты быстро станут бесполезны. Лучше заранее зафиксировать словарь значений, тип поля и допустимую длину, иначе один и тот же параметр начнет писаться по-разному на уровне трекера, postback и BI.

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

Минимальный чек-лист:
— заведи отдельную схему именования для dimension
— не смешивай атрибуцию и бизнес-метрики в одном поле
— проверяй, что postback и API пишут одинаковый формат
— оставляй резерв под новые срезы, чтобы не мигрировать все заново

Если custom dimensions спроектированы как контракт, а не как временный костыль, отчеты переживают и смену трекера, и рост команды.