Никто не использует Факт клиента?

Question

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

Я делаю что-то серьезно неправильно, желая узнать клиента?Цель состоит в том, чтобы дать возможность проанализировать поведение клиентов, например, частоту заказов, общие расходы, стоимость приобретения, отличия, количество продуктов и т. Д. Эти вопросы, естественно, означают для меня факт, а не измерение.У меня уже есть факт заказа, который отлично подходит для запросов, ориентированных на заказ, но не подходит для запросов, ориентированных на клиентов.

Чтобы дать вам немного больше подробностей, в Факте о клиенте, вероятно, будут присутствовать следующие показатели и измерения:

Меры:

• Количество клиентов
• Количество отдельных продуктов
• Количество выполненных заказов
• Общий доход
• Общая стоимость
• Количество полученных купонов
• Количество полученных купонов
• Стоимость полученных купонов

Размеры:

• Дата доставки заказа
• Время доставки заказа
• География доставки заказа
• Источник получения
• Тип заказа
• Тип купона

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

Answer 1

У нас есть факты о клиентах.Большую часть времени они представляют собой таблицы фактов, которые просто связывают несколько измерений.

Похоже, что многие ваши факты получены или обобщены.Зерно все равно будет важным.Если вы скажете, что количество заказов - это MTD (и какая дата) или за все время и т. Д.

Я не думаю, что с этим что-то не так, но я думаю, потому что это производные данные, большинство людейПоместите это в «витрину данных» или в любой лучший однозначный термин для подмножества для анализа.

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

У вашего клиента будет измерение (согласованное, поскольку оно распределяется между моделями), а затем факт CustomerStatsстол или что-то еще, с каждым фактом в том зерне, которое разделяет все эти измерения.

Answer 2

Причина, по которой многие системы ориентированы на заказ, а не на клиента, заключается в том, что вы идентифицируете клиента так часто с течением времени: прежнее отношение к бизнесу по мере того, как клиент превращается в отношение к отдельным сотрудникам как к клиентам, или наоборот, или клиент изменит / разделит / объединит адреса, или компания изменит свое имя, и мы хотим объединить (или отделить) старые и новые итоги производительности, или теперь адрес доставки и адрес для выставления счета необходимо расширить, чтобы включить адрес поддержки, или операторы забывают или ошибочно принимают одно адресное назначение за другое, или клиент хочет использовать специальный адрес доставки только временно, и т. д. и т. д.

Это более подробно рассмотрено здесь .

Answer 3

Меры, такие как order frequency, total spend, acquisition cost, distinct product count, на самом деле выводятся из Orders как таблица фактов, а клиенты - как измерение Агрегирование по каждому клиенту может быть так же легко агрегировано по продукту или географическому местоположению.

Как предложил Cade Roux, вы можете создать агрегированную таблицу клиентов, которая должна быть отделена от других таблиц фактов, однако это будет исключительно решение по производительности. Вы сохраняете максимальную гибкость, создав Customers как измерение Orders.

Answer 4

Возможно, я неправильно понял ваш вопрос, но давайте посмотрим, что можно узнать о поведении клиентов из factOrder only , по старинке.

Предполагая, что размер факта заказа составляет одну строку в заказе и что OrderID является вырожденным измерением.

-- Number of customers who ordered something at least once
select
    count(distinct CustomerKey) as PayingCustomers
from factOrder ;

.

-- Number of orders and sales per customer
select 
      CustomerKey
    , count(distinct OrderID) as NumberOfOrders
    , sum(ExtendedPrice)      as Total
from factOrder
group by CustomerKey ;

.

-- Histogram (x = NumberOfOrders, y = People, Amount)
with
orders_per_customer as (
    select 
      CustomerKey
    , count(distinct OrderID) as cnt
    , sum(ExtendedPrice)      as Total
    from factOrder
    group by CustomerKey
)
select
      cnt        as NumberOfOrders
    , count(1)   as People
    , sum(Total) as Amount
from orders_per_customer
group by cnt
order by cnt asc ;

.

-- Distinct products ordered by customer
select 
      CustomerKey
    , count(distinct ProductKey) as DistinctProductsOrdered
from factOrder
group by CustomerKey ;

.

-- Histogram (x = NumberOfDistinctProducts, y = People)
with
products_per_customer as (
    select 
      CustomerKey
    , count(distinct ProductKey)  as cnt
    from factOrder
    group by CustomerKey
)
select
      cnt       as NumberOfDistinctProducts
    , count(1)  as People
from products_per_customer
group by cnt
order by cnt asc ;