Custom dimensions ломают отчёт, если не задать их как схему, а не как набор полей

Custom dimensions ломают отчёт, если не задать их как схему, а не как набор полей

Если трекаешь не только клик и конверсию, а ещё маржу, LTV, статус лида, тип оффера и источник выплаты, custom dimensions должны жить по правилам:
— одно имя = один смысл;
— значение всегда одного типа;
— пустое значение не подменяется нулём;
— для статусов и категорий используй фиксированный словарь, а не свободный текст.

На практике ошибка одна и та же: в один dimension начинают писать и GEO, и плейсмент, и reason отказа. Через неделю отчёт уже не сводится, а в postback появляются строки, которые нельзя сравнить между собой. Если dimension нужен для фильтрации — он должен быть дискретным. Если для расчёта — его надо нормализовать до отправки в трекер.

Для бизнес-метрик полезно разделять уровни:
— атрибуция: click_id, campaign_id, adset, creative;
— экономика: payout, revenue, cost, margin;
— качество: approval, refund, chargeback, lead_status;
— операционка: sub_id, team, traffic_source, proxy_profile.

Храни словарь значений отдельно от логики отчёта. Тогда любой экспорт в BI, CSV или S2S не развалится, а пересчёт по окну атрибуции не потребует ручной чистки.

Если dimension нельзя описать одним правилом в документации — значит, это не dimension, а свалка.